►
From YouTube: Kubernetes SIG CLI 20181219
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
good
morning,
good
afternoon,
good
evening,
depending
on
where
you
are
I'm
very
happy
to
see
so
many
of
you
joining
our
6cl
I
call
and
before
we
jump
into
our
topics
and
the
test
grid
States
a
few
announcements.
First
of
all,
the
next
call,
which
is
planned
for
January
2nd,
will
be
canceled.
The
reason
for
that
is
this
is
shortly
after
New,
Year,
so
I
think
that
not
many
of
us
will
be
available.
A
The
next
important
thing
is
that
keeping
North
America
in
Seattle
happened.
Last
week,
six
CLI
held
two
sessions
over
there
I
linked
both
of
the
session,
which
is
introduction.
He
did
an
amazing
job,
introducing
sick
CLI
to
the
participants,
whereas
who
won
and
I
did
a
deep
dive
about
the
the
plugins
implementation.
A
B
Actually
it
was,
it
was
very
smooth
until
yesterday,
yesterday
morning,
two
tests,
the
G
and
the
gke
cereal
began,
failing
consistently
and
I'm
still
in
the
process
of
actually
digging
into
that,
but
but
because
it's
GK,
he
related
I,
think
that
it's
it's
maybe
google-specific
I
will
get
back
to
you
to
the
rest
of
the
cig
on
slack
once
I've
resolved
it
all
right
and
I'll
update
the
the
test
coverage.
Actually
I
forgot
to
do
that.
Yeah.
A
B
C
B
A
At
this
point
in
time,
there
is
a
quick
reminder:
if
you
haven't,
got
a
chance
to
sign
up
for
our
on
on
called
duties,
which
basically
means
you're.
Looking
after
the
test
grid,
there
is
a
short
introduction.
What
are
the
responsibilities
if
you're
interested
there
are
January
terms
that
you
can
sign
up
I
sign
up
for
the
next
two
rounds,
which
is
the
current
one
and
the
one
starting
in
in
January,
2nd,
I'm
hoping
since
it's
a
Christmas
slash?
A
Hopefully
never
not,
that
many
have
stuff
will
be
happening
in
between
so
I
should
have
somehow
managed
the
job
month
as
the
on-call
duty,
but
if
you're
curious,
paying
myself
or
any
of
the
other
six
yaaaaay
persons.
What
are
the?
We
were
more
than
happy
to
help
you
with
the
boarding
of
that
role
and
feel
free
to
sign
up
for
the
next.
B
A
They're
clear
the
clear
direction
coming
from
Brian
and
from
his
presentation
that
he
had
several
times
here
in
cubicle
and
as
well
as
deterring
the
contributor
summit
was
that
coronaries
is
going
into
the
being
a
platform
and
providing
a
lot
of
extension
points,
and
we
should
do
the
same
with
regards
to
cubes
ETL.
This
also
fold
folds
nicely
with
steps
that
we've
been
taking
so
far,
which
which
includes
moving
the
printing
to
the
server
side,
Phil's
proposal
about
moving
some
commands,
or
hopefully
more
commands
up
to
the
server
side,
the
so
called
driven
commands.
A
We
also
covered
some
areas
around
testing
and
improving
stability.
The
plug-in
mechanism
was
also
short,
they
discussed
and
so
forth.
So,
if
you're
very
curious
about
exact
details,
what
was
discussed
and
so
that
you
are
where
we're
keep
CTL
or
our
sig
will
be
going
in
the
next
couple
of
months
or
even
years
from
today.
It's
very
it's
very
good
to
go
through
the
document.
If
you
have
any
comments,
any
suggestions
or
questions,
most
importantly,
feel
free
to
now
to
add
them
to
that
document.
A
The
entire
stick
should
have
the
ability
to
to
comment
on
the
documents
or
more
than
happy
to
answer
the
questions
there
are
there
NORs
a
lot
of
discussion
basically,
but
but
we're
hoping
that
the
direction
that
we
set
up,
most
importantly
by
extracting
the
short
term
goal,
which
is
the
extracting
cubes
deal
so
a
separate
repo
which
will
allow
us
to
move
faster
and,
most
importantly,
in
separation
from
the
main
kubernetes
releases.
That
will
be
the
major
impact
for
this
sick
to
further
improve,
keep
CTL.
A
B
Was
just
gonna
add
this
kind
of
feels
like
a
kickoff
or
an
inflection
point
where
we're
for
our
long-term
planning.
So
a
lot
of
our
planning
has
been
in
a
medium
timeframe
and
we're
hoping
to
to
develop
plans
which
are
further
on
the
horizon,
which
was
one
of
the
one
of
the
main
takeaways
from
from
the
meeting
at
the
top.
We
put
some
of
the
high-level
areas
and
we
were
hoping
for
feedback
from
the
rest
of
the
community.
B
D
E
B
E
A
That
we
will
be
revisiting
this
document
over
the
course
of
several
next
releases.
So
whenever
we'll
be
planning
stuff
for
the
current
release
and
I'm,
hoping
that
this
will
happen
and
the
next
meeting,
hopefully
by
January
16,
we
will
have
the
dates
for
114.
I
haven't
seen
anything
set
in
stone
yet
so
I'm,
hoping
that
the
January
16
will
give
will
provide
us
with
those
dates
we'll
be
able
to
to
make
some
planning
decisions
for
114.
A
A
Okay,
with
this
being
said,
I
think
we
can
now
jump
into
the
second
topic,
which
is
actually
plugin
related
and
Ahmed
is
going
to
demoed
the
next
version
of
the
crew
plugin
manager.
That
was
demo.
Sometimes
it
was
sometimes
ago,
but
that
was
before
we
wrote.
We
rewrote
the
plug-in
mechanism.
I
spoke
with
with
that
last
week.
He
he
managed
to
update
the
mechanism
so
that
it
matches
the
Korean
plug
and
implementation.
A
F
Perfectly
I
see
a
sky
opens
really.
Alright,
that's
great
hello
folks.
My
name
is
Ahmed
I
work
at
Google.
So
a
while
ago,
around
the
summer
time,
we
started
looking
at
an
idea
around
package
management
for
plugins.
The
primary
driver
for
this
was
basically
discoverability.
We
realize
a
lot
of
people
are
developing
plugins,
maybe
not
so
much.
F
This
was
a
summer
intern
started
as
a
summer
intern
project.
The
intern
look
for
chart
who's,
also
active
in
his
community
as
lbv
on
github.
He
did
most
of
the
work
and
then
after
he
left,
we
did
some
migration
to
actually
migrated
to
the
new
plugin,
not
introduced
and
112
so
crew
project,
I'm
gonna
do
a
demo
here:
Cruz
a
package
manager
for
coops,
ETL,
plugins
and
then
so.
I'm
actually
gonna
go
ahead
and
show
the
readme
file
real,
quick,
as
you
can
see,
we're
right
now,
installing
ourselves
as
a
plugin.
F
So
it's
basically
acute
CTO
crew,
but
it
brings
a
few
plugins,
a
few.
Some
commands
with
itself
to
actually
discover
any
soul
and
manage
the
lifecycle
of
these
plugins.
So
I'm
gonna
go
ahead
with
the
installation,
I
believe
right
now,
I
don't
have
anything
installed
on
my
computer
or
small
crew,
so
I'm
gonna
do
the
installation
real,
quick,
I'm,
hoping
my
Wi-Fi
is
fast
enough
all
right.
So
when
crew
installs
itself,
it
tells
people
to
add
the
crew
pin
path,
which
is
basically
this
part
to
their
path
environment
variable.
F
So
this
makes
the
plugins
that
crew
install
discoverable
by
Q
control,
so
once
crews
install
I
can
just
call
it
my
snake
usage,
okay
and
then
you're
gonna
see
this
is
the
sub
commands?
The
crew
binary
provides
right.
This
is
very
familiar
stuff
to
you.
If
you're
dealing
with,
if
you
you
know,
play
the
play
with
the
plug-in
system,
so
here
crew
is
running
as
a
standalone
binary.
So
you
by
to
cue
CTL
players
list
you're
gonna,
see
that
crew
itself
is
indeed
a
plugin.
F
So
one
thing
I
want
to
do
is
I'm
gonna
write
you
city
out
research.
This
is
supposed
to
show
me
all
the
commands
that
are
all
the
plugins
that
are
available,
but
it
basically
says
that
right
now
you
have
not
downloaded
the
plug-in
in
next.
So
if
you're
familiar
with
excuse
me
advocate,
so
this
is
basically
we're
doing
at
cat
update.
So
a
lot
of
the
curves
basically
influence
from
homebrew
as
well
as
at
a
little
bit
so
right
now.
F
What
happened
was
that
when
I
ran
the
crew
update
command,
it
actually
went
to
the
repo
called
crew
index.
So
this
is
the
crew
index
report
is
where
the
where
we
store
the
plugins
so
right
now
this
is
a
sensor
likes
hard-coded
in
the
binary.
We
attempt
to
change
these
as
soon
as
possible
when
you
go
to
this
curve
index
repository
you're
gonna
see
a
directory
named
plugins
and
once
you
click
there,
these
are
all
the
plugins
we
available.
I
think
this
is
somewhere
close
to
20
players.
F
So
right
now,
I'm
gonna
look
into
the
manifest
file
of
one
of
the
plugins
as
an
example.
So
there
is
a
plug-in
called
our
back
view.
I
think
I,
don't
know
who
actually
do
all
this
looks
like
Jason,
Richard
Smith,
so
the
plugin
manifest
file
is
Lionel
file.
This
is
not
recognized
by
the
API
server
or
anything
we
just
try
to
stick
to
the
convention.
F
I
believe
in
this
case
this
plug-in
uses
go
so
they
basically
had
like
a
binary
built
for
each
operating
system
and
then
so,
basically,
when
I
run
this
command,
what's
gonna
happen
is
that
it's
gonna
go
in
and
go
ahead
and
download
this
URL,
and
then
it's
gonna
verify
its
sha.
This
is
gonna,
be
also
the
version
number
of
this
plug-in
and
then
the
plug-in
itself
is
a
binary
called
our
back
view,
and
then
we
define
a
few
operations
here.
F
This
basically
says
that
when
you
download
this
tarball
link,
the
bow
you're
gonna
find
the
file.
Listen
like
this.
Please
copy
this
file
to
this
directory
and
this
is
the
installation
directory
of
the
plug-in.
So
this
is
basically
imagine
this
like
a
staging
area,
so
this
files
directory
basically
explains
how
to
extract
stuff
out
of
the
tar,
Bowl
or
business
file,
and
the
another
important
field
is
the
bin
field.
This
basically
defines
very
your
entry
point,
is
so
I'm
just
going
to
go
out
and
install
this
plugin?
F
So
if
I
do
a
search
again,
I'm
gonna
get
all
these
plugins
I'm
gonna
write
your
seatbelt
code
and
still
are
back
for
you.
This
may
take
a
while
because
it's
a
go
plug-in,
I
think
so.
Right
now,
I
installed
the
plug-in
after
a
plug-in
installed
at
the
I
think
top
here
you
can
see
there
is
a
caveat
field
and
then
we
actually
prints
the
caveats
field
right
here.
F
So
if
there's
like
a
post
installation
instructions
like
if
you
need
to
install
additional
West
packages-
or
you
know
certain
tools
or
do
some
configuration-
you
can
put
it
right
here.
So
this
is
inspired
by
what
Humber
does
and
after
the
plugin
install
I.
Think
I
can
just
call
it
like
crimson
tail
plug-in
list,
and
this
is
the
native
command
that
I
know
about,
and
then
I
can
just
call
detail
our
back
to
you
I'm.
F
Just
like
you
know
any
other
crew,
CGI
plugin
I
think
it's
trying
to
do
something
so
I'm
just
going
to
turn
that
out
after
the
plug-in
is
installed,
I
can
actually
upgrade
it
by
saying
to
CTL
argh,
actually
Chris
feels
cool
upgrade
I
can
upgrade
each
plugin
or
all
the
plugins
and
this
command
which
actually
upgrades
the
crew
itself
as
well.
So
there
is
a
single
upgrade
command
and
you
cannot,
you
know
limit
it
to
our
back
view
as
well.
F
So
you
can
say
if
you
want
to
operate
just
our
back
view,
yeah
it's
already
on
the
latest
version,
and
now
you
know
I
can
go
ahead
and
delete
the
plug-in
as
well,
for
example,
if
I.
So
one
thing
to
note
probably
is
that
probably
notice
that
the
plug-in
was
actually
linked
in
a
directory
called
Chris
slash
bit.
F
So,
if
I
actually
go
ahead
and
install
the
plug-in
again,
which
will
take
a
little
while
I
quickly
want
to
show
how
the
crew
directory
looks
like
so
inside
the
crew
directory
we
have
basically
three
main
directories
index
is
where
the
index
is
stored.
Bin
is
where
the
symlinks
happen,
and
the
store
is
where
we'll
restore
the
installed
plugins.
So
if
I
look
into
the
store
with
a
three
command,
you're
gonna
see
that
this
is.
F
This
is
mostly
because
we
didn't
follow
through
and
we
we
were
trying
to
basically
understand
crew
or
sounds
like
what
are
the
use
cases.
How
are
people
gonna,
use,
plugins
and
what
kind
of
plugins
will
be
developed
and
how
can
we
accommodate
so
if
I
were
to
talk
about
like
top
two
missing
parts
of
true
is
right.
Now
we
don't
do
anything
about
twice
level
package
management.
F
So,
if
you're,
if
your
plugin
means
something
like
JQ
or
I,
don't
know
command
that
is
not
installed,
they
basically
need
to
tell
the
users
to
install
it,
and
the
second
part
is
right:
now
we
hard-code
a
centralized
repository
managed
by
Google.
We
intend
to
get
rid
of
that,
and
then
we
want
to
like,
let
people
add
more
repositories
from
either
github
or
from
there.
You
know
each
company
basically
should
be
able
to
like
maintain
their
own
private
repository
and
decide
what
should
be
installed
on
each
the
Walker's
machine.
F
That's
a
really
good
question
so
right
now
in
the
index
repository
since
we
have
a
centralized
repo
where
we're
accepting
these
plugins.
These
are
the
actual
names
of
the
players
by
the
way
so
like,
for
example,
when
I
go
into
each
yellow
file.
The
name
that
says
here
is
the
actual
name
of
the
plugin,
like
we
linked
this
sibling
based
on
this
name
specified
here.
As
far
as
the
naming
is
concerned,
we're
trying
to
I
wrote
a
document
in
the
crew
repository
say
it's
a
it's
called
the
naming
guide.
F
This
is
basically
just
my
opinion
naming
guide
about
like
how.
Basically
people
should
structure
their
plug-in
names.
I
think
you
know
there's
certain
topics
like
if
you're
doing
perfect
stuff
try
to
layout,
you
know,
do
the
prefix
of
the
vendor.
If
you're,
you
know
doing
like
something
with
the
verbs
and
the
nouns
try
to
put
the
verb
first,
just
similar
to
what
control
does,
and
you
know
stuff,
like,
don't
repeat,
TQ
whatnot,
so
a
lot
of
the
stuff
that
I
think
we
will
be
will
be
trying
to
enforce.
F
If
we
were
to
have
a
centralized
it.
Where
is
the
main
graph
like
we
don't
want
people
to
come
in
and
you
know
put
a
graph
on
the
coolest
names
right,
so
I
don't
know
how
to
solve
that
problem.
I,
don't
know
how
we
can.
Basically,
you
know,
have
I,
don't
know
like
a
central
repository
as
well
as
a
neutral
guide
where
people
you
know,
camp
to
name,
grabs,
I,
don't
know
how
to
prevent
that
honestly.
F
So
if
you
were
to
host
a
centralized,
you
I
think
we
need
to
be
a
little
bit
decisive
and
tell
people
that
your
plugin
is
not
named
correctly,
and
why
don't
you
consider
this
thing?
Is
that
safe
like
that?
But
I,
don't
know.
If
that's
the
right
thing
to
do
and
I
got
you
don't
want
to
be
hosted
on
the
index
repository,
they
can
still
distribute
their
politeness
through
their
own
github
repository
because
we'll
be
supporting
multiple
indexes
right.
So
yeah.
E
E
E
But
then
again,
you
also
end
up
with
packages
that
are
say
three
letters,
four
letters
and
they
might
not
even
so
I
guess.
If
it
comes
down
to
a
centralized
repo,
it
would
be
good
enforce.
Maybe
some
sort
of
policy
that
perhaps
has
people
put
there
they're
either
a
company
name
or
having
a
more
descriptive
name
to
their
plugin.
A
E
F
So
right
now,
if
you
want
to
get
started
today,
if
you
have
a
plugin
that
works,
all
you
need
to
do
is
make
its
release
available,
or
is
it
zip
or
tarball?
And
we
have
this
document
called
the
whole
pro
guide
of
the
crew
repository
I.
Think
it's
a
pre,
thorough
guide
on
how
to
you
know
how
plugins
work
as
well
as
like
how
we
write
these
plug-in,
manifest
files,
how
to
test
stuff
locally,
for
example,
and
we
actually
have
a
command
called
like
crew,
install
manifest
and
interstitial
archive.
F
So
this
is
basically
providing
those
without
writing
a
manifest
file.
You
can
actually
like
provide
these
things,
and
still,
you
know
sorry
without
like
actually
uploading
the
manifest
file
to
crew
index.
You
can
test
your
plugins
locally,
so
we
try
to
like
support
local
development
as
well.
I
would
recommend
anyone
if,
if
they
want
to,
like
you,
know,
take
a
stab
at
porting,
their
plug-in
crew
definitely
check
out
the
developer
guide.
I
think
that's
one
of
the
best
places
to
start
now
and
make
sure
you
know
you
have
a
publicly
accessible
on
binary.
F
One
area
we
didn't
speak
about
is
the
security
I.
Think
right
now
we
I
think
so
like
right
now
in
the
functions
that
I've
been
showing,
for
example,
our
back
view.
Plugin
is
basically
someone
is
making
this
release
available
on
github,
and
then
they
send
us
a
pull
request.
We
merge
it.
Davidson
say
we
have
a
new
version
and
then
we
don't
go
into
you
know
their
source
code
repository
and
take
a
look.
F
So
we
need
to
establish
some
form
of
either
transmit
the
developers
something
reputation
base,
or
we
basically
say
we
don't
take
no
retake,
no
responsibility
whatsoever
users
or
all
their
own.
If
they're,
installing
random
stuff
on
the
internet,
they
didn't
read
source
code
for
so
I.
Don't
know
how
realistic
is
that
but
I
think
plenty
plate.
Thank
You
vendors,
like
homebrew
most
roads,
rely
on.
B
B
F
Thank
You
Sean,
yeah
I,
don't
know
if
you
like,
we
should
go
into
the
binary
like
hosting
business.
I
feel
like
a
lot
of
companies
will
probably
like
you,
have
their
own
private
repos
and
maybe
for
the
public
stuff
you're
right,
maybe
like
we
can
tell
people
to
our
plate
upload
their
stuff
to
bin
tray
or
something
that
we
trust
but
again
I,
don't
know
like
this
is
I,
think
we
don't
go
and
read
the
source
code
of
the
plugins
I.
F
Don't
think
it'll
be
possible
to
do
so
if
I
were
to
go
to
Korean
thanks,
for
example,
if
I
were
to
like
look
at
the
pull
request
that
recently
got
merged
right
and
surprisingly,
there's
a
point
in
the
Udo
when
someone
you
know
sends
it
says
me
appear
like
this:
all
I
do
is
actually
I
download
the
zip
file
and
actually
look
into
what's
in
there.
If
it's
a
basket,
I
try
to
you
know,
read
it
and
see
what
has
changed
since
the
last
release.
So
yeah
I
don't
know
how
much
of
that
is.
A
A
It
might
be
caused
by
this
honestly
I'm
leaning
towards
a
solution
where
we,
where
we
would
upon
providing
such
a
central
index.
We
will
say
that
we
are
providing
the
the
index,
but
we
are
not
guaranteeing
or
we
are
not
providing
any
guarantees
with
regards
to
security
and
stuff,
like
that,
we
are
doing
our
best
effort,
but
that's
not
a
strong
guarantee
for
any
of
the
users
that
are
blindly
using
this
stuff
available
in
the
index.
A
I
think
we'll
have
to
figure
out
with
either
stick
architecture
or
or
even
with
the
CNC
of
how
how
to
do
it
from
the
legal
point
of
view,
because
something
tells
me
that
there
will
have
some
kind
of
a
legal
legal
statement
under
deal
under
that
index.
Also
we're
looking
what
the
legal
statements
are
when
it
comes
to
other
indexes.
Sorry
other
indexes,
such
as
homebrew
or
other
district,
what
they
are
providing.
A
So
that
will
be
happening
over
the
span
of
the
next
couple
of
a
couple
of
weeks,
maybe
months,
the
index,
the
index
repository
will
be
a
separate
thing.
I
guess
we
will
have
to
sort
out
the
the
legal
part
before
we'll
be
able
to
say
that.
Yes,
we
are
all
readiness
to
use
query
sick
repo
for
that
one
as
well.
F
F
People
are
gonna,
be
around
yeah
and
then,
after
that
we
should
probably
continue
the
opening
in
the
Korean
6th,
refill
and
yeah.
I
would
like
to
have
more
contributions
from
the
city
as
well
so
yeah.
If
you're
interested,
feel
free
to
like
ping
me
on
slack
or
you
know,
Twitter
wherever
you
want
to
chat
about
players.
A
C
Yeah
I'd
like
to
talk
about
that
Thank
You
Marcus,
so
the
PR
was
merged
as
most
likely
as
it
was
about
one
week
ago.
Oh,
it
was
murder
yesterday
and
three
Oh
mentioned
several
follow-ups
that
I
need
to
address,
so
those
follow-ups
include
several
different
areas
like
we
need
to
check
the
file
council.
We
need
to
check
the
Younger
file
for
group
reversion
kind
to
decide
if
the
file
is
a
customization
file
instead
of
using
the
hard-coded
founding.
That
is
one
follow
up.
C
The
other
follow
up
is
to
refine
the
customized
library
so
that
it
is
easy
to
car
those
built
functions
from
trip,
control
and
so
I'm
working
on
those
follow-ups.
Hopefully
we
can
get
a
PR
out,
maybe
working
progress
PR
by
the
end
of
this
week
and
for
the
status
of
the
customizing
cube,
control,
I.
Think
the
next
release
we
need
to
Google
have
this
available.
At
the
same
time,
we
also
need
to
update
the
documentation
to
show
the
user.
We
have
this
new
support.
D
Yeah,
that's
gonna
be
really
important.
Not
just
we
don't
just
talk
to
update
the
documentation
and
say:
hey
we
haven't
support.
We
need
to
really
make
sure
that
the
documentation
we're
providing
is,
is
up
to
up
to
par
and
not
it
feels
native
right
and
goes
into
like
how
it
works
with
the
various
to
control
command
in
what
the
options
are
available,
instead
of
simply
redirecting
into
the
customized
report.
Something
like
that.
A
You
to
use
the
system
there's
also
this
important
topic
that
we
discussed
last
week
with
Phil
is
that
currently
customized
does
not
have
an
explicit
API
version,
like
all
of
the
rest
of
kubernetes
has
so
to
ensure
that
we
can
move
forward
with
customized,
maybe
adding
some
new
features
and
stuff
like
that,
an
explicit
API
version
Inc
will
be
created,
work.
There
is
already
one,
but
it's
not.
It
is
not
explicitly
put
in
the
customized
files.
D
One
piece
of
infrastructure
we're
going
to
need
much
a
is
a
the
ability
to
do
or
or
a
pattern
or
guidance
for
how
to
support
multiple
versions
of
the
same
file
on
its
side.
Most
of
that
machinery,
this
in
the
API
server,
and
so
once
we
need
to
break
versions
or
go
from
beta
to
GA
or
whatever
is
we're
going
to
combine
those
yeah.
A
D
A
That
was
that
was
my
suggestion.
Let's
start
with
beta,
since
we
are
bringing
this
over
to
keep
CTO
will
be
actually
making
it
publicly
available
to
literally
every
single
cube,
CTO
consumer.
So
it's
worth
starting
with
beta.
That
will
allow
us
for
eventual
changes
within
this
scheme.
A
A
B
Sorry,
machi
I
figure
I'll
just
do
a
quick
update
on
the
coop
cuddle
independence
on
removing
it
from
the
kubernetes
repo
or
down
to
about
a
dozen
remaining
imports,
and
they
are
the
thorny
ones.
So,
we've
I
think
we've
made
really
good
progress.
We
had
some
good
discussions
on
it
on
coop
con
there's,
basically
only
about
two
or
three
areas
left
one
has
recently
making
progress
on
the
are
back
reconciliation,
which
is
for
coop
cuddle,
auth
reconcile
command.
B
That
dependency
is
being
addressed,
the
biggest
one
is
going
to
be
printing,
the
human
readable
dot
go
and
the
tables
that
are
importing
or
yeah
they're
they're
importing
internal
versions
of
objects
which
we
have
to
turn
to
external
versions.
But
you
know
we.
It
feels
like
we're
close
the
last
few
areas,
they're
going
to
be
thorny
and
difficult,
so
it's
hard
to
to
actually
put
a
timeline
on
it
right
now,
but
but
it
feels
like
we're
close.
A
A
We
need
to
keep
the
mechanisms
around
for
at
least
333
releases
or
a
year,
whichever
comes
first,
whichever
is
longer
so
in
our
case
that
will
be
actually
a
year
from
now,
which
is
four
releases,
to
be
honest,
so
that
bit-bit
needs
literally
copying
pasting
and
making
it
external
and
will
be
fraud
freezing
that
part
of
functionality.
So,
as
soon
as
we
will
drop
the
functionality,
we
will
remove
that
bit
of
code
entirely
from
A
to
Z
deal:
okay,
we're
top
250
minutes.