►
From YouTube: Kubernetes SIG CLI 20190227
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
Okay,
good
morning,
good
afternoon,
good
evening,
depending
on
where
you
are
it's
February
27th-
and
this
is
yet
another
60
Ally
meeting,
my
name
is
bachi
I'm,
one
of
the
60
line
meet,
leads
and
I'll
be
hosting
you
today.
So
one
announcement
that
I
have
is
that
the
code
freeze
for
114
starts
next
Thursday
these
baits.
This
basically
means
you
should
have
all
your
PRS
open
and
merged
by
the
next
Thursday,
which
leaves
us
about
a
week
in
a
day
to
get
whatever
crazy
stuff
you're
working
on
for
114
to
land
and
master.
A
If
you
have
a
bigger
feature
that
you
are
working
on,
and
you
know
that
you're
not
gonna
make
it,
you
have
to
apply
for
for
an
exception,
but
that
will
be
very
hard
to
get
in
most
of
the
codes
should
land
by
by
March
7th
it's
still
a
week,
so
hopefully
everything
will
be
up
and
ready.
I
still
have
a
PR
to
reach
chuckle.
A
B
Like
sure
it
was
actually
very
calm,
we
still
have
a
couple
of
flakes,
but
it
it.
It
was
basically
green.
The
entire
time
and
the
the
flakes
that
we
were
having
before
with
the
port
forwarding
tests
seem
to
be
fixed,
I
think
that's
a
combination
of
us
moving
to
a
more
another
release
as
well
as
there
were
some
fixes
that
Nicolai
put
in
so
so
at
least
it
feels
like
it's
actually
getting
even
even
more
solid.
A
A
If
you
have
any
questions
with
regards
to
what
are
your
duties
and
responsibilities
feel
free
to
reach
out
to
Shawn
on
myself
or
fail,
then
it
will
be
more
than
happy
to
answer
all
your
questions
since
I'm,
seeing
anyone
sign
up
for
the
next
two
weeks,
I'm
gonna,
probably
just
copy
my
name
over
there
and
you
can
put
me
as
well
I'll.
Do
it
again
if
you
want
me
to
okay,
if
you
say
so,
then
I'm
gonna
put
your
name
in
that
case.
Thank
you.
Whimper.
C
A
I'm
hoping
that,
especially
with
the
port
forwarding
tests,
hopefully
fixed,
the
entire
thing
will
be
getting
more
and
more
in
shape.
Okay,
so
with
those
eight
ends
cursed
out,
we
can
move
to
the
main
agenda
topics
and
there's
quite
a
few
of
them.
So
Backman
go
ahead
and
pick
up
the
floor.
Hello.
D
D
Okay,
so
today,
I
would
like
to
talk
about
crew.
The
plugin
manager
that
we
were
working
on
a
couple
months
ago,
I
give
a
presentation
about
how
crew
works.
Since
then
the
project
has
grew
a
bit,
so
I
came
here
to
give
an
update.
Basically
so
crib
project
is
someone
you
might
know,
is
a
plug-in
manager
that
we've
been
developing
for
at
Google.
It
is
trying
to
make
it
super
easy
to
install
and
discover
plugins
for
users
and,
if
you're,
a
plug
in
the
wall.
D
For
yourself,
it's
trying
to
make
it
easier
to
package
and
distribute
and
make
your
plugins
discoverable.
So
crew
project
has
reached
five
hundred
stars
since
the
last
time
we
checked
in
here,
we
are
hosting
over
two
plugins
right
now,
so
these
plugins
live
in
a
centralized
repository
called
crew
index.
D
Here
you
know
we
got
pretty
much
like
one
or
two
plug-in
submissions
every
week,
which
is
great
and
a
lot
of
people
are
actively
working
on
their
plugins
and
there
they're
listing
in
their
readme
is
like
hey,
installed,
crew
and
then
just
run
crew
and
install
my
plug-in
name
and
then
you're
gonna
get
my
plugin.
So
these
people
are
coming
and
updating
their
versions
of
their
plugins
a
lot
too.
So
these
are
I
think
the
plug-in
ecosystem
is
growing,
maybe
better
than
we
expected
so
far.
D
D
Basically,
if
anyone
is
interested
in
cig
in
the
SE
helping
with
something
like
this
I'm
actively
looking
for
maintainer
x'
to
onboard.
So
if
plugins
are
interesting
to
you,
please
come
find
me.
If
you
haven't
seen
crew
before
I
would
suggest
you
to
check
it
check
it
out
or
I
can
probably
just
give
it
a
quick
one
minute
demo.
So
right
now,
I
have
a
cube.
Caudill
installation
and
I
installed
crew
on
my
machine,
so
I,
just
scooped,
CTL,
crew
search
for
example.
So
this
gives
me
all
the
available
plugins
right
I.
D
Let's
say:
I
choose
one
of
them:
XS
metrics
up
here,
which
shows
I,
guess
shows
and
XS
metrics
for
our
back
so
I
I
type,
Q,
CTA,
all
crew
install
XS,
metrics,
and
then
this
plugin
is
right
now
being
downloaded
and
then
after
it
is
downloaded
and
installed,
I
will
be
able
to
just
type
Q
cuddle,
XS
metrics
and,
as
you
see
here,
this
person
created
a
great
plugin
that
visualizes,
how
does
like
the
our
bag
of
the
current
user?
What
what
can
it
do
on
the
current
cluster?
D
So
this
is
a
simple
plugin
that
is
written
for
tube
cuddle
and
it
is
easily
installable
for
with
crew,
and
we
can
upgrade
and
delete
this
plug-in
as
well.
So
this
is
pretty
much
crew,
I'm,
basically
trying
to
also
look
guidance
from
the
sig
on
what
to
do
with
this
project
like.
Where
should
we
take
it
and
like?
How
can
we
get
more
at
you
know,
get
more
attention
of
the
world.
How
can
we
get
attention
of
two
authors
to
write
more
plugins
or
onboard
their
plugins
more
easier?
D
B
D
I
think,
since
the
last
time
we
talked,
we
didn't
really
do
anything.
It
is
basically
the
right
now,
the
current
processes.
There
is
a
centralized
room
for
everyone,
since
their
plug-in
to
and
I
I
have
a
simple
CI
that
validates
like
structurally.
The
plugin
is
installable
on
all
platforms
and
then
we
go
and
accept
a
plug-in
submission.
We
don't
know
what
code
goes
in
it.
It
is
entirely
up
to
the
user
to
trust
to
that
system,
or
not
so
right
now,
you're
installing
a
plug-in
from
a
source
that
you
don't
know,
that's
a
problem.
D
Similarly
I'm
trying
to
figure
out.
How
can
we
disable
the
centralized
discovery
and
have
people
like
to
say
your
work
at
Red
Hat,
and
you
only
want
plugins
from
Red
Hat
repositories
to
me
install.
So
how
can
we
accommodate
this?
So
we
will
need
like
Multi
index
model
for
this
or
like
people,
maybe
don't
want
to
submit
to
the
centralized
index
and
they
want
to
have
like
a
github
repository.
So
you
want
to
like
trusted
that
way,
for
only
so
there's
a
lot
I
think
there
are
some
designs.
D
One
made
a
designer
around
this
as
well.
We
haven't
found
the
time
to
go
on
implemented
so
like
crew
action,
crew
source
code
actually
has
been
untouched
for
a
couple
of
months
and
it's
been
working
fine,
but
we
will
need
more
features
to
actually
support,
really
use
cases.
So
I
think
we'll
get
there
at
one
point,
but
definitely
need
help.
So.
A
A
E
E
Under
and
I
think,
the
question
would
be
if
there
is
like,
is
this
in
scope
for
the
kubernetes
project,
and
that
would
be
maybe
worth
talking
to
sake.
Architecture
about,
however,
like
who
take
architecture.
Has
our
folks
and
sega
architecture
have
asked
us
about
plugins
on
several
locations
and
seemed
like
they're
pushing
me
that's
wanting
to
do
more
work
there
so,
and
we
said
that
not
having
a
distribution
mechanism
is
really
preventing
us
from
leveraging
that
mechanism,
so
I,
don't
think.
There's
yeah.
A
I
think
it
nicely
falls
into
whatever
we're
doing
within
the
sixty
lie,
even
though
we
stated
initially
that
QC
tale
does
not
have
any
blessed
mechanism
for
managing
plugins.
We
never
said
that
we're
not
going
to
write
any
and
having
a
separate
tool
which
is
a
plugin
by
itself,
and
you
know
ensuring
that
we
have
a
strong
user
base
and
there's
a
sufficient
support
and
and
requirements
from
from
users
to
use.
It.
A
E
I
think
the
the
biggest
thing
I
think
we
need
to
think
about
is
what
our
support
model
is
for
this,
because,
like
Amon
said
that
he
is
looking
for
other
people
to
help
carry
the
torch
on
this,
and
we
should
be
upfront
about
like
what
we
plan
on
giving
like
I,
think
moving
into
kubernetes
sakes
and
then
trying
to
like
we
can
promote
it
and
say
hey
contribute
to
this
project
is
a
great
thing
to
do.
We
need
to
decide
if,
like,
for
instance,
we
have
our
tests.
E
A
We
can
also
create
a
new
role
just
for
for
the
plug-in
maintainer
or
something
like
that.
That
would
just
follow
nicely
what
what
would
send
out
recently
with
regards
to
spreading
the
roles
that
we
might
have
within
the
six
I
think
that
that
would
pose
nicely
and,
and
it
would
encourage
more
people
that
are
interested
in
plugins
to
help
out
with
those
particular
stuff.
Only
yeah.
E
And
I'd
say:
actually
the
last
item
on
the
agenda
is
actually
about
updating
CLI
membership.
It
also
said
project
ownership
and
anything
right
now
we
don't
have
a
really
clear
model
for
who
owns
what
sub-projects
and
what
they
like
paths
for
getting
input
in
like
escalating
decisions
that
were
not
quite
sure
on
to
get
more
feedback
and
broader
feedback
is
and
so
developing
a
structure
of
saying,
like
here's,
owner's
files
for
each
sub
project
and
subdividing
to
control,
perhaps
into
like
DIF
I'd.
E
Imagine
she
clearly
be
owned
by
Antoine,
who
wrote
that
live
coupe
control
like
before
amazing
some
of
that
stuff,
and
so
that
aunt
weren't,
like
someone
come
into
Project
knows:
okay,
if
I
have
a
thing
about
diff,
this
is
the
owner
and
if
Antoine,
once
they
have
greater
broader
input.
He
knows
where
to
go
like
up
the
chain
of
the
pile
hierarchy
chain
to
a
higher
level
owners
file
and
pulling
those
people
yeah.
A
I
went
maybe
can
start
by
sending
an
email
to
six
CLI,
requesting
six
Eli
to
accept
crew
as
a
sub
project.
I
would
probably
CC
take
architecture,
and
maybe
sig
apps,
since
that
somewhat
falls
under
what
they
are
doing.
I
think
that
these
three
six
should
be
informed
about
and
overall
maybe
granny's
death,
and
that
should
suffice
and
then
we'll
wait
for
what
people
will
say
and
after
a
couple
of
days
will
just
say
if
there
isn't.
A
If
there
are
no
objections
that
we
will
continue
with
this,
and
we
will
move
the
projects
and
there's
currently
six
because
I
I'm
more
than
other
person,
sure
that
this
is
the
place
where
they
they
will.
They
should
land
and
then,
at
the
same
time,
that
email
will
spark
some
discussions
and
will
bring
awareness
of
the
project
to
other
grantees
deaths
as
well.
A
D
You
I
think
primarily
I'm
looking
for
like
guidance
and
expertise
from
the
sig
and
as
well
as
like
finding
a
way
to
like
on
Borneo
maintain
errs,
and
even
though
it
is
not
a
you
know,
main
sub-project
that
the
sig
actively
supports
with
on-call
rotation
and
stuff.
Like
that
any
help
there
would
be
super
appreciated.
Sure
I'm.
A
As
for
the
index,
itself
will
have
to
probably
write
down
some
guidelines
for
people
that
will
be
interested
in
in
maintaining
those,
because
it
will
be
slightly
more
challenging
to
ensure
that
the
plugins
that
we're
letting
people
accept
what
kind
of
requirements
we
expect
from
from
the
plugins
included
in
the
index
should
be
there
and,
at
the
same
time,
the
fact
that
we
will
be
working
on
a
current
e6.
We
could,
and
we
should.
We
use
the
entire
testing
infrastructure
for
that
we
have.
A
E
Good,
we
probably
only
the
the
indexing
thing
I
think
is
actually
most
of
the
complexity
of
this
thing
or
where
most
the
decisions
need
to
be
made,
and
so
maybe
we
can.
We
should
defer
that
for
a
separate
discussion
except
Carissa
project
first
but
say
like
sixty
lights,
not
maintaining
this
index
and
it's
not
blessed
yet
I
think
that
I
actually
had
a
lot
of
years
around
ways.
We
could
do
this
that
we
should.
A
Discuss
them
later,
in
that
case,
we
should
probably
make
it
somewhat
configurable
before
putting
it
so
that
it's
not
hard-coded,
and
then
you
know
that
should
be
very
simple
thing
to
do
and
then
yeah
it
definitely.
The
index
is
the
tricky
part,
the
most
tricky
part
I'd
say
due
to
what
are
the
guidelines
for
accepting
plugins?
What
are
the
requirements?
How
we
verify
do
we
provide
any
guarantees
with
regards
to
the
plugins,
are
available
there,
etc,
etc
so
yeah,
but
let's
start
with
crew
first
and
keep
the
discussion
going
on
the
index
itself
as
well.
A
E
If
you
don't
mind
what
I
did
is
I,
just
like
put
all
my
three
at
the
top,
so
I'll
go
through
them
and
I'll
just
try
and
be
really
quick
on
all
of
them
and
sure
what
happen
we
can
do
it
at
the
end.
After
we
talked
about
the
you
tail
stuff,
so
real
quickly,
I
have
an
observability
kept
out
which
attaches
headers
to
quests
from
ku
control
sent
the
API
server.
It
has
the
sub
command
that
was
sent
the
names
of
the
flags
that
were
provided,
but
not
their
values.
E
It
has
two
additional
headers
for
whether
or
not
the
input
was
from
a
file
from
a
remote
URL
or
from
standard
in
just
so.
We
can
have
a
better
understanding
of
how
people
are
using
the
system
and
then
standard
out
whether
it
was
like
yeah,
Mille
or
custom
columns
or
go
templates,
and
this
will
help
us
like
understand
whether
people
are
actually
using,
though
templates,
because
there's
some
issues
with
those
in
series
and
this
sort
of
thing
so
come
take
a
look
at
that
and
and
would
be
target
at
1.15.
E
So
it's
not
urgent
I
think
it
might
be
good
new
contributors,
you.
The
second
item
is
in
any
comments
on
the
PR
or
at
the
end
of
this
meeting.
The
second
comment
is
about
updating,
60
Li
membership.
If
you
look
at
the
owners,
aliases
they're
actually
I
think
those
were
auto-generated
and
they
don't
seem
to
reflect
what's
been
going
on
for
the
past
year
or
so,
for
instance,
I'm
not
in
the
maintainer
z'
list.
E
So
I
think
what
I'd
like
to
do
is
like
reset
those
and
maybe
just
do
like
a
yearly
reset,
where
I
was
planning
on
just
deleting
everyone
from
all
the
lists
and
then
sending
out
an
email
to
say,
see,
Li
and
the
folks
in
them
to
say
if
you
want
to
still
be
part
of
this
maintainer
or
still
part
of
the
sake
CLI
membership.
Please
comment
on
the
PR
with
a
justification
with
the
some
of
the
work.
E
You've
done
right
and
I'm
not
looking
for
real
high
bar
here,
but
just
something
to
show
that,
like
you've
shown
sustain
activity
for
the
past
six
months
or
a
year
and
then
also
that's
a
great
opportunity
to
bring
in
new
folks
who
may
not
be
part
of
those
lists,
so
that
was
the
best
way
I
could
think
of
doing.
That
was
just
delete
everyone,
and
in
that
way
everyone
is
set
at
the
same
bar
and
there's
no
real,
grandfathering
people
in
forever
and
then.
E
E
F
E
Some
of
the
information
here
is
copied
directly
from
the
existing
documentation
from
kada
stud
I/o,
but
we
structured
to
have
different
like
chapters
in
different
highlighting
and
we
just
cleaned
up
a
bit
updated
without
a
date
stuff,
some
of
its
copied
directly
from
the
control.
Command-Line
CLI
I'm,
not
sure
that
that's
strictly
necessary,
but
I
thought.
If
you're
going
won
an
Indian
book,
it's
nice
to
have
all
the
information
in
one
source,
so
you
don't
have
to
go
scrambling
across
multiple
sources,
so
I
copied
some
of
that
in
there
specifically
for
the
porcelain
pieces.
E
E
So
the
goal
here
is-
and
one
last
thing
is
that
if
you
look
at
the
existing
documentation
in
kata
style
and
start
poking
around
you'll
see
that
a
lot
of
it
is
very
out
of
date.
For
instance,
if
you
go
into
the
run
application
section
on
tasks,
there
is
a
section
called
perform
rolling
update
using
a
replication
controller,
replication
controller,
you
shouldn't
be
using
and
you
shouldn't
be
using
the
rolling
update
command.
A
Awesome,
can
you
hear
me
yes,
okay,
good,
because
my
zoom
is
in
a
weird
stay
and
I
was
wondering
whether
I'm
connected
or
I'm,
not
okay,
I
love.
This
inclined
are
there
any
questions
to
fill
with
regards
to
either
observability
cap,
the
six
CLI
membership
updates
or
the
doc
updates
I'm
guessing
for
the
cap
and
the
four
dog
updates.
A
The
best
questions
suggestions
would
be
to
leave
them
out
on
the
caps
and
fill
tan
out
both
of
the
cap,
the
cap
and
a
doc
update
PR
all
of
the
sixty
line
mailing
lists,
so
please
do
check
them
both
and
if
your
comments
or
suggestions
over
there,
that
will
we
not
lose
the
comments.
That's
for
the
60
line,
membership
Phil.
What?
What
are
you
planning
to
do
with
the
water?
Where
will
be
the
next
step?
You're
planning
to
do
with
the.
E
A
A
He
mentioned
that
he
was
actually
looking
for
some
kind
of
a
you
toes
repo
for
client-side
achievement
procedures,
meaning
that
there
is
some
kind
of
functionality
more
than
a
single
API
call
that
we
have
currently
baked
in
inside
of
Kim's
appeal
and
whether
having
some
kind
of
a
YouTube
repo
with
these
functionality
would
make
sense.
Till
I
run.
A
Ideally,
all
of
the
plug-in
authors
or
cubes
ETL
like
commands,
whereas
the
yuto's
is
not
necessarily,
and
the
question
is
whether
we
want
to
have
some
kind
of
a
youth
or
repo
or
the
fact
that
we
will
have
in
the
near
future,
we'll
have
a
separate
keep
CTL
repo,
inside
of
which
will
have
those
packages
that
will
contain
functionality
devoted
to
specific
commands,
which
should
make
the
vendor
Inc
of
those
packages.
Super
simple
for
people
that
are
instead
of
copying
pasting.
F
So
I
do
see
the
difference
between
you
know
scale
at
runtime
and
something
that
could
provide
more
command,
specific
behavior,
so
I,
you
know,
I
myself
would
be
in
favor
of
having
a
second
repository.
We
called
CLI
utilities
aims
at
providing
that
so
in
essence,
I
still
see
something
like
CLI
utilities
as
a
reap
of
being
used
by
third-party
clients
and
plugins.
Perhaps
I
just
think
that,
like
you,
said
not
shade,
because
the
scope
is
more
centric
to
you
know
particular
commands
that
it
should
be,
you
know,
kept
separate.
C
I
have
an
opinion
on
that
hi.
This
is
Antoine
I've,
seen
a
few
people
while
trying
to
reproduce
some
of
the
functionalities
of
QL
without
having
to
and
spawn
a
cube.
Coral
binary
like
they
are
like
building
some
libraries
that
needs
to
interact
with
communities
and
they
want
to
do
things
that
are
similar
to
cook
coral,
but
they
don't
want
to
do
always
that
system
cacao,
because
that's
terrible
and
so
I
I
see
a
lot
of
people's
well
like
I.
C
Have
a
bunch
of
pies
I
want
to
read
these
files,
get
objects
and
maybe
do
something
create
them
on
the
server
and
one
of
the
solutions
we
have
is
that
they
can
use
the
resource
below.
But
the
resource
builder
depends
on
the
generic
CLI
options.
The
Gina
x-ray
options
install
f4u,
which
maybe
makes
no
sense
for
this
person,
and
so
I
think
the
CLI
runtime
is
very
much
Ciera.
A
tree
burn,
which
I
think
is
not
the
necessary
to
correct
abstraction,
we're
looking
for
we're.
C
Looking
for
an
abstraction
which
is
we
want
the
features
of
Cape
Coral,
not
necessarily
the
the
CLI
features
of
Cape,
Coral
and
I,
see
how
Dre
might
be
useful,
for
example,
and
yeah
like
typically
so
now
apply,
is
going
to
be
extremely
easy
to
implement
for
people,
but
they
still
need
to
read
files
somewhere.
They
need
to
pass
the
files
they
need
to
find
the
eg
vaycay
and
all
of
these
things,
and
they
don't
want
to
know
about
F
and
all
of
these
things
so
I
definitely
see
about
you.
C
I
was
going
to
do
something
and
maybe
in
the
API
machinery
me
repository,
because
the
API
machine
real-
and
he
has
the
logic
to
split
by
so
I-
was
like.
Maybe
it
should
leave
here,
I,
don't
know,
but
I
see.
Do
you
D
usefulness
of
such
a
repository?
At
least
we
need
to
figure
out
well.
This
should
leave
well.
A
First
of
all,
the
you
should
be
able
to
use
the
resource
builder
without
on
the
necessity
to
attach
F
flex,
because
the
these
two
should
be
separate.
If
it's
not,
then
we
have
about
that.
We
need
to
fix
what
I'm
quite
confident
that
you
can
separate
these
two.
You
don't
have
to
have
the
flags,
but
you
should
be
able
to
use
the
resource
builder,
which
answer
the
first
question
regards
to
the
functionality.
A
The
other
issue
that
I
have
with
regards
to
providing
the
utils
is
that
we're
trying
to
move
a
lot
of
the
functionality
over
to
the
server.
So,
ideally,
we
would
have
all
the
logic
that
is
currently
baked
in
to
keep
CTL
available
on
the
server
and
I.
Remember
that
at
some
point
in
time-
and
that
was
one
of
the
directions
that
we
were
going
through
I'm,
not
saying
we
will
be
there
in
a
couple
of
months,
but
the
rather
in
a
couple
of
the
years
more,
but
eventually
those
function.
A
Now
we
will
be
avaible
on
the
server
and
the
reason
for
that
is
the
consumers,
because,
even
if
we
provide
the
library,
the
library
will
again
limit
the
scope
of
users
to
only
go
developers,
people
because
we
will
provide
those
libraries
and
go
whereas
having
this
functionality
on
the
server
sites
and
will
be
through
what
you
did
with
server-side
apply.
Similarly
to
what
happened
with
the
server-side
print
opens
the
gauge
to
a
further
set
of
users,
including
because
I'm
guessing.
A
C
A
C
E
Do
we
so
we
have
something
related
to
this,
which
is
moving
to
control
out?
This
is
aligned
with
that
in
the
sense
that
light.
Isn't
this
necessitates
moving
those
commands
out.
Does
this,
it
seems
like
this
work
is
strictly
in
addition
to
that,
like
neither
speeds
adopting
more
slows
it
down,
do
we
like
who
would
be
do
we
have
someone
staffed
to
do
this
right
because
I
can
imagine
like?
Is
there
a
developer
like
saying
oh
I'll
do
this
for
you,
or
is
he
just
asking
for
it?
It
was
just
asking
I.
A
Don't
think
well,
maybe
he
could
help
us
with
us,
but
in
all
honesty,
I
would
rather
do
the
move
to
separate
repo
of
cube,
CTO
and
then
I
was
talking
with
him.
Whether
he
would
be
satisfied
is
only
the
cube.
Studio.
Functionality
would
be
living
in
a
separate
repo,
whether
that
would
suffice
for
his
use
case,
because
then
he
would
just
vendor
and
keep
CTL
itself
and
could
be
used.
A
A
So
currently,
the
only
downside
is
that
you
need
to
vendor
the
entire
kubernetes
repo,
but
the
functionality
of
the
drain.
The
logic
of
Trane
is
a
helper
that
you
can
easily
import
and
reuse,
and
then
it's
not
tight
and
it's
not
tied
to
the
cube
cereal
drink
man,
but
rather
cool
to
tail
drain
command
and
invokes
at
the
same
helper
yeah.
A
E
Makes
a
lot
of
things
like
we
could
make
sense
to
move
the
code
like
we
can
folks
can
refactor
into
utils.
We
move
to
control
out
of
kubernetes
at
that
point
in
time,
people
should
be
able
to
vendor
or
use
go
modules
or
whatever
to
get
those
go
packages
and
whether
it
lives
in
the
kubernetes
SIG's
report
or
not,
is
kind
of
like
a
question
of
logistics.
Does
it
make
it
harder
for
us
to
release?
Does
it
make
it
easier
to
manage
issues
but
didn't
shouldn't
be
a
blocker
for
anyone,
yeah.
A
Exactly
oh
I
would
rather
focus
us
focusing
currently
on
the
separation
because
it
is
hard
and
it
is
taking
so
much
longer
than
we
initially
anticipated
and
and
we're
still
a
couple
of
months
away
from
from
doing
that.
So
we're
where
we
add
on
that
I'm,
not
sure
if
Sean
is
still
on
the
call.
He
mentioned
that
he
will
be
leaving
in
the
second
half.
A
A
F
Since
we're
talking
about
printers
in
addition
to
externalizing
the
you
know,
the
the
print
handlers,
there
is
one
more
item
to
take
care
of
with
regards
to
watch
events
so
currently
watch
events,
return
external
objects,
which
you
know.
Ideally
we
would
want
to
have
table
objects
there,
since
currently,
there's
no
way
to
take
advantage
of
server-side
printing
with
those
I'm,
not
sure
to
what
extent
this
blocks
the
effort
to
split
from
you
know
from
the
men
repo,
but
it
is
a
concern
nonetheless,
going
forward
a
server-side.
E
A
But,
like
I
said
it's,
that's
that's
the
least
of
a
problem,
because
we,
as
we
discussed
in
some
of
the
meetings
ago,
we
will
trace
the
code,
we
will
externalize
it,
we
will
freeze
it
and
we
will
forbid
any
changes.
If
somebody
wants
to
change
the
format
that
data
are
being
printed,
he
should
modify
the
server-side
printing
of
the
resources
and
not
the
client
part,
the
client
part.
It
will
diverge
and
that's
perfectly
fine.
We
will
just
freeze
it
at
the
moment
of
doing
it.
A
That
was
the
agreement
that
we
had
a
couple,
but
a
couple
weeks
back:
okay,
so
we're
still
probably
two
three
commands
away:
I'll
try
to
touch
base
with
with
Shawn
and
check
out
how
far
we
are,
what
we
can
push
forward
to
get
closer
to
the
to
the
final
step
and
I'll
sing
with
Huan.
With
regards
to
the
our
back
man,
Tyrel,
exactly
that
was
author.