►
From YouTube: Kubernetes SIG CLI 20170913
Description
Kubernetes SIG CLI meeting Sep 13th, 2017.
A
B
Yeah
so
I
still
kind
of
was
all
around
how
we
can
more
address
going
forward,
reliably.
Keeping
all
the
tests
running
and
issues
finish,
triage
and
that's
their
stuff
and
what
I've
been
thinking
is
mm-hmm
developing,
like
kind
of
maintainer
role,
where
there's
a
set
of
responsibilities
and
possibly
a
rotation
or
some
way
where
we
can
identify
a
group
of
individuals
responsible
for
keeping
the
code
and
project
relatively
healthy
mm-hmm.
B
A
I
was
also
thinking
a
little
bit
about
it
and
basically
the
the
main
issue
we
had
was
that.
Well
initially,
we
had
one
skill
test
failing
for
about
two
weeks
right
until
it
got
fixed,
so
that
topic
we
we
covered
in
the
last
Sigma
teen
already
and
last
week.
We
also
had
another
skill
test
fail
for
about
four
to
five
days,
something
like
that
until
we
noticed
and
got
it
fixed
and
that
was
related
to
a
commit
that
get
merged
after
the
code
freeze.
A
But
anyway,
what
I
was
thinking
about
doing
in
the
mask
next
couple
days
was
to
start
a
new
page
on
our
committee
community
repository
where
I
would
collect.
You
know
all
resources
that
the
person
in
charge
of
you
know
the
maintenance
versus
rotation
would
need
so
so
I
would
start
by
you
know
creating
that
page
and
collecting
every
link
for
for
our
dashboard
and
every
thing
we
need
in
terms
of
tooling
to
support
that
role
and
I.
A
Something
like
that.
But
I,
don't
know
what
you
guys
think
we
kind
of
felt
the
need,
or
for
that
you
know,
because
of
you
know
these
sub
sequential
test
failures.
We
had
on
skill
tests,
especially
because
they
were
failing.
You
know
for
for
a
long
time.
So
do
you?
Do
you
guys
any
therapy
news
about
it?.
C
A
If
yeah,
yeah
and
I
think
I
said
we,
we
could
start
with
the
approvers,
but
of
course,
if
anyone
else
from
the
sea
would
would
that
is
not
yet
in
a
proverb
would
like
to
get
involve
or
you
know,
eventually,
people
don't
have
the
time
to
do
that.
If
you
are
in
approval
and
don't
have
the
time
to
do
that,
we
can,
you
know,
think
about
something
different,
but
anyway,
that
would
be
at
least
a
starting
idea
to
put
that
together
and
start
a
process
like
that.
One.
B
Thing
I
like
about
the
approvers
and
they
don't
necessarily
have
to
be
in
the
rotation,
but
I
do
think
I
think
that's
a
nice
starting
place
and
I
do
think
they.
They
need
to
be
available
for
triage,
because
in
both
issues
with
the
broken
sea
to
test
it
meant
there
was
not
like
a
readily
available
group
of
people
who
had
been
approving
the
code
that
we
could
just
say
like
who,
like
hey.
B
B
Cool
thanks,
Fabio
gathering
those
resources
seems
like
a
critical
first
step
so
important,
and
and
thank
you,
chef
for
offering
to
to
join
the
rotation.
I
think
that
serves
to
do
a
purpose
of
both
helping
with
the
sustaining
engineering
of
the
project
and
scaling
it
as
well
as
growing
leadership
within
the
sig
and
helping
people
take
on
bigger
and
broader
tasks.
So
thank
you.
B
B
B
We're
running
into
merge,
keys,
need
to
be
changed,
but
there's
static
and
can't
be
changed
without
breaking
backwards,
compatibility
because
they're
implicit.
So
we
need
to
introduce
more
directives
for
having
the
ability
to
change,
merge,
keys
and
make
them
dynamic
as
we
can
fix
each
one
of
these
things
makes
the
patch
way
more
complicated
because,
instead
of
just
deleting
an
item
from
a
list,
we're
now
deleting
an
item
and
then
creating
this
side
directive
that
contains
an
item
and
then
another
side
directive
that
contains
the
order
of
items
there's
a
little
list.
B
B
Do
the
code
structure
and
we
tried
it
two
times
and
if
we
just
do
a
quit
like
the
death,
becomes
really
easy
because
you
just
if
the
file
you're
gonna,
put
against,
what's
there
now
and
what
your
local
file
is
and
whatever
else,
and
what
and
also
the
the
code
structure
right
now
is,
does
a
couple
of
a
diff
sand.
It
makes
it
actually
pretty
hard
to
do
a
three-way
diff,
because
there's
all
these
branches
what's
in
within
the
2-way
diff
to
say
am
I
doing
deletes.
Am
I
doing
ads?
Am
I
doing
updates?
B
B
So
the
it
does
is,
there's
a
lot
more
code
in
the
proposal,
but
most
of
that
code
is
interfaces
like
clean,
clear
interfaces
and
structs
that
define
the
logic
exactly
as
it's
going
to
work,
and
it's
like
a
lot
of
you
know
a
lot
of
five-and-ten
line
functions
that
just
do
one
thing.
So
this
results
in
a
lot
more
code,
because
that
means
more
functions
and
documentation,
but
overall
I
think
it
will
allow
us
to
maintain
the
code
a
lot
better
or
more
easily
so
yeah.
If
anyone's
interested
in
apply
that's
there.
D
Applaud
the
idea
of
keeping
it
simple,
so
yeah,
so
that's
really
exciting,
I
think
to
try
and
take
a
step
back
and
and
say:
can
we
keep
that,
especially
when
you
get
these
really
subtle
semantics
on
the
server?
It's
just
a
bug
farm
and
you
find
yourself
being
bugged
for
bug
compatible
over
time.
Stop
talking
versioning,
the
merge
algorithm
would
yeah
idea,
but
it
smells
bad
yeah
and
so
yeah
I.
So
that
seems
like
a
step
in
the
right
direction.
D
Think
initializers
do
similar
things
right
and
we
look
at
pod
presets
and
you
start
looking
at
things
like
pod
presets.
That
actually
are
gonna,
add
containers
right.
It's
like
now.
We
have
a
whole
nother
sort
of
ball
of
wax
in
terms
of
things
mucking
with
the
definition
and
how
do
we
act
go
through
ahead
and
do
and
do
that
in
a
sustainable
way?
My
my
gut
here
is
to
keep
that
like
I.
D
Don't
think
we
understand
this
problem
well
enough
to
actually
come
up
with
the
one
true
solution
and
so
when
in
doubt
move
it
to
the
client,
because
the
clients
a
lot
easier
in
some
ways
to
actually
version
deprecated
and
ship
different
versions
of
there's
places
where
we
can't
do
that,
but
I
think
there's
places
where
we
can't
so
like
four
initializers
I
think
one
option
here
might
be
to
as
much
as
possible
like
let's
say
that
you
want
to
add
SDO
to
a
pod
right.
You
can
do
that
client-side
or
you
can
do
it
server-side.
D
If
we
do
it
server-side
now
we're
actually
really
fundamentally
mucking
with
a
pod
definition.
Yes
do!
Does
it's
not
a
small
tweak
when
sto
gets
injected
into
a
pod?
This
is
this
is
a
lot
of
tweaking
to
that
thing
and
that's
gonna
make
the
apply
like
hit
all
sorts
of
wacky
corner
cases
as
you
do
stuff
like
that,
are
we
better
off
doing
something
like
having
initializer
actually
or
you
know
an
admission
controller
reject
a
pod
if
it
doesn't
have
sto
applied?
D
So
this
means
that
you're
checking
and
then
just
say:
well,
you
have
to
do
its
client-side
and
then
we
can
explore
what
is
the
right
way
to
actually
manage
merging
this
stuff?
Client-Side,
hey
I,
don't
know,
I
feel
like
I
feel
like
we're,
rushing
to
do
stuff,
server-side
and
it's
it's
gonna
end
poorly,
but
but
I
you
know,
I
don't
have
a
lot
of
data.
This
is
just
my
gut
feel.
Yeah.
B
B
D
B
Initializers
are
weird
the
thing
with
initialize
with
deployments:
is
they
I
think
they
get
added
at
creation
time?
So
if
you
employment,
does
it
reinitialize
like
what
is
it
real
nice
flies
from
if
you
if
the
initializer
makes
a
decision
based
on
the
contents
of
the
deployment,
and
then
you
change
the
contents
of
the
deployment?
Does
it
doesn't
read
analyze
this
I
don't
understand
I.
D
And
this
is
this:
is
the
thing
is
that
there's
this
whole
workflow
of
like
you,
want
to
have
this
lockstep,
but
we
make
a
change
and
then
these
folks
get
to
vote
and
tweak
it,
and
then
it
becomes
effect
like
like.
You
can
imagine
that
you
have
a
whole
workflow
for
how
you
actually
sort
of
like
make
changes
and
have
lots
of
people
tweak
it,
and
you
end
up
with
a
bunch
of
layers
that
get
collapsed
together
all
server-side,
but
we
don't
actually
call
out
those
layers
specifically.
D
So
we
do
things
like
the
base
and
the
three-way
merge,
because
we
don't
actually
have
those
things
and
so
I
mean
I.
I
I
understand
how
we
got
here.
I'm
just
like
there's
a
certain
amount
of
like
you
can
make
a
bunch
of
rational
decisions
and
then,
at
the
end
you
go
like
this
is
kind
of
a
little
crazy,
so
I
think
it's
it's
worth
sort
of
taking
a
little
bit
of
a
step
back
on
some
of
this
stuff
and
so
I
think
moving
towards.
Let's
just
keep
it
simple.
B
B
So
using
the
things
that
we
know
work
like
put
I
think
you
know,
we
have
to
support
that
and
it's
very
simple
how
it
works:
cool,
yeah
and
again,
the
top
level
goal
is
like
just
keep
what
we
have
now
we're,
not
gonna.
We
can't
take
away
like
the
workflow
we've
already
given
users,
but
just
make
it
simple
to
change
simple,
to
maintain
and
allow
it
so
that
we
can
involve
it
into
something
that
makes
more
sense,
yeah
and.
D
I
mean
and
technically
the
the
the
optimistic
concurrency
is
going
to
work
most
the
time
unless
you
have
some
sort
of
like
catho
logical,
like
to
folks
really
beating
on
something
right,
I
think
again,
the
one.
The
one
thing
that
worries
me
is
like
auto-scaling.
Maybe
that's
that's
the
one
place
where,
where
you
might
start
getting
conflicts,
I
think.
B
If
we
have
a
problem
with
optimistic
blocking
our
clusters
fruit,
because
this
thing
should
take
less
than
a
second
right-
we
use
some
psych
20
minutes
at
CPU
time
right
the
object
back
if
that
takes,
if
there's
an
optimistic,
walk
and
there's
consistently
like
with
exponential
back-off
like
your
clusters,
just
being
so
slammed,
it's
probably
gonna
burn
to
the
ground.
That's
true!
That's
true,
I!
Think
more
things
like
like
queue
control
at.
B
D
B
D
That
you
do
the
the
patch
client-side
and
then
you
still
do
a
put
exactly
so
you
know
you
change
these
things
on
this
thing.
Let's
go
ahead,
will
extract
a
patch
out
of
that
we'll
grab
the
latest
version
updated,
send
it
boom
you're
done
exactly
yeah
all
right.
So,
let's
exciting
I
like
seeing
things,
get
simplified
yeah.
It's
important.
B
B
B
A
Still
related
to
the
release,
the
the
one
feature
we
had
for
41.8
was
keep
CTL
plugins
as
alpha,
so
we
we
made
it
so
all
Uppercross
got
Mars
before
code,
freeze
and
documentation
was
actually
already
reviewed
and
merged,
so
we
have
ducks
for
for
plugins
and
that's
it.
So
a
plugins
is
making
it
on
1.8
as
an
alpha
feature.
A
D
A
B
A
Just
as
as
an
example,
but
actually
you
know
in
terms
of
that-
will
really
make
use
of
the
the
power
of
plugins
I'm
working
on
the
set
of
commands
for
the
Service
Catalog.
So
that's
going
to
really
use
yeah,
that's
a
little!
That's
a
little
deep!
There
yeah,
that's
very
deep,
deep,
and
actually
you
know,
but
on
the
other
hand,
it's
going
to
really
use
all
features
we
currently
have
in
the
plugins
framework.
A
D
C
D
Yeah
all
right,
I'll
I'll,
think
about
it
a
little
bit,
but
if
you
guys
have
have
ideas
for
stuff
where
it's
mostly
the
plumbing,
but
does
something
kind
of
fun
and-
and
you
know
you
can
see
like
oh
now-
I
have
I
can
insert
my
own
wacky
code
here.
That
might
be
that
might
be
fine,
yeah,
all
right,
cool,
very
cool,
exciting.
B
B
None
of
them
are
like
upgrade
tests
that
take
a
really
long
time,
they're
all
pretty
reasonable
and
I
think
the
best
strategy
for
doing
this
is
if
we
break
all
of
our
tests
out
into
their
own
jobs,
so
they're
not
part
of
the
main
jobs.
We
can
get
a
nice
long
history
and
track
record,
proving
that
those
have
like
zero
flakiness
right
and
if
we
can
go
two
weeks
with
now,
without
a
single
failure
or
a
month
without
a
single
failure.
B
That
makes
it
easier
for
us
to
say
why
don't
we
just
put
these
in
the
pre
submit
their
their,
you
know
totally
stable
and
then,
if
there's
like
other
within
the
same
job
today,
there
might
be
like
other
tests
that
are
flaky
that
aren't
ours
right
so
today
that
would
prevent
these
things
from
being
in
the
pre
submit,
because
there's
other
tests
that
we
don't
own
that
are
flaky,
but
by
bringing
them
into
our
own
jobs.
We
just
run
our
stuff,
so
the
whole
tests.
C
Thank
you
so
I
have
two
topics
here.
The
first
one
is
still
the
dynamic
resources,
fetching
I
think
we
had
a
discussion
last
time,
16
meeting
so
I
just
talked
a
little
background
here,
the
previously
our
coop
control
cat
health
message.
We
just
pumped
some
hard
coded
resources,
which
is
not
a
good
experience
for
developers
and
users,
and
we
should
fix
them
by
giving
you
an
more
accurate
resources
list.
C
It's
kind
of
like
we
removed
all
of
those
hard-coded
resources,
bringing
our
help
messages
and
if
you-
and
we
from
the
message
like
if
you
want
to
check
those,
what
kind
of
resources
provided
by
API
server
use,
could
control
API
resources,
which
is
a
new
sub
command
to
tell
user.
You
can
use
that
command
to
check
what
kind
of
resources
we
provide
advice
server.
C
So
the
implementation
of
this
solution,
it's
much
more
easier
and
I
I,
just
don't
have
he
think,
he's
addressing
for
a
solution
why
it's
like
he
doesn't
wanna.
You
know
when
prompted
the
method.
He
doesn't
want
to
talk
the
coop
control
to
talk
to
the
server,
but
I
think
the
coop
control.
It
will
like
always
talk
to
server
like
every
10
minutes
right
so
for
and
if,
if
we
got
the
cash,
we'll
just
use
me
a
catch
instead
of
have
some
network
transmission,
so
I'm
not
sure
what
his
you
know.
C
Disagree
with
solution
wise
like
the
implementation,
it's
a
little
ugly
or
some
thing.
I
just
saw
the
trust,
networking
transmission,
it's
always
necessary,
but
but
only
only
if
we
didn't
hit
the
cash
but
the
cash,
no,
no
matter
what
kind
of
command
you
use
you.
If
you
did
not
have
the
cash,
we
will
always
have
the
network
transmission
and
always
have
to
talk
to
the
server.
So
so
I'm
not
have
a
strong
opinion
on
solution,
while
I
just
want
to
take
it
for
you
guys
to
have
some
suggestions
suggest
rely
on
it
and
yeah.
So.
C
B
Sounds
reasonable
to
me.
One
benefit
of
that
is
that
we
have
tips
for
delete
like
there's
queue,
control-alt-delete,
there's
control,
get
there's
list
or
whatever
I,
don't
know.
There's
a
number
of
these
things
that
use
the
list.
So,
like
updating
the
help
text
to
say
like
to
look
for
the
resources.
Do
this.
It
means
we
don't
have
to
plug
that
end.
Every
command.
E
So
I
have
some
contacts
about
this.
I
think
Jonas
pond
is
a
so
there
may
be.
There
may
not
be
a
live
server
that
one
user
exploring
the
Q
control
command.
So
in
this
case,
if
we
don't
have
a
live
server,
so
Q
control
catch
help
should
not
return
an
error,
so
it
should
have
something
helpful,
so
I
think
s,
:
yep,.
C
A
What
you
would
otherwise
you
know
fed
from
the
server
is
that
we
still
have
to
maintain
it
right,
so
the
problem
is
still
there.
So,
even
though,
if
you
fall
back
to
a
hard-coded
version,
you
have
to
maintain
it
on
our
code
base,
so
I
would
say
personally:
I
prefer
solution
to
and
it's
much
simpler
and
we
just
get
it
out
of
our
way
so
and
with
the
other
commander,
I
think
the
command
being
suggest,
as
this
keeps
itself
API
research,
researchers
right.
So
with
that
command.
A
We
are
really
sure
that
what
the
results
you
are
getting
are
accurate
right,
because
sometimes,
if
you
fall
back
to
a
hard-coded
versions
version,
for
example,
the
result
could
not
be
completely
accurate
and
on
the
Lessing's,
Cigna
team,
I
think
Phillip
mentioned
the
idea
of
using
the
client
research
or
something
like
that.
But
you
still
have
the
problem
which
gives
scaled
versions
q
so
anyway,
I
think
solution.
2
is
better.
In
my
personal
opinion.
A
C
Thank
you
sounds
great
yeah
I
think
solution.
2
is
it's
good
if,
if
you
like
guys
are
great
unless
also
there's
a
still
a
little
problem
is
like
accept
that
help
method
hard-coded
help
message.
We
also
have
two
places
which
also
use
hard-coded
resources
list
is
there's
another
to
function
in
pkg.
Slash
could
control
slash,
could
control
that
go,
there's
a
tooth
on
screen
name
the
resources
short
card
form
for,
and
resources
Alice's,
those
two
function,
Ally
effect,
bash
completion
and
another
command
coop
control,
GATT
resources
show
can
so
that
flag
show
can
is
like.
C
If
the
resources
have
a
shortcut,
we
prefer
to
use
a
short
card
info
instead
of
the
full
name.
So
those
two
functions
also
use
a
hard-coded
resources
list,
but
I
don't
think
it
will
have
a
big
impact.
So
if
you
guys
also
want
to
take
those
lists
to
like
then
I
make
house
or
something
I
just
don't
know
how
to
deal
with
those
two
functions.
Oh
I
will
just
keep
it
for
if.
B
C
B
A
Yeah
I
agree,
we
are,
you
know.
I
personally
are
I'm
personally,
very
happy
that
we
are
getting
read
off.
You
know
particle
the
resources
one
at
a
time
and
something
I
probably
didn't
mention,
but
before
code
freeze
we
got
one
per
request
merged
that
makes
groups
like
all
dynamic
based
on
the
on
the
discovery
client.
So
that
was
one
more
place
where
we
had
a
hard-coded
list
of
what
were
part
of
get
sorry.
What
was
part
of
the
you
know?
A
A
C
Okay,
so
my
my
second
topic
is
a
question
about
the
coop
control,
cache
magnesium
I
think
I
just
did
a
little
research
on
open,
API
validation
and
that
HTTP
cache
I
think.
Currently
we
have
a
two
cache
mechanism
in
our
control.
Y
is
for
discovery
plant.
Another
is
for
the
open,
API
validation,
cache,
which
use
HTTP
cache
I.
C
Just
think
we
gonna
keep
all
those
two
magnetism
at
the
same
time
for
long
term,
because
currently
the
HTTP
cache
will
also
poison
clay,
cache
the
discovery
information
because
we
add
a
trigger
in
discovery,
client
and
the
client
goal,
I'm
and
I,
don't
think
it
maybe
have
it.
Maybe
I,
don't
have
any
big.
You
know
common
with
the
user,
because
we
kind
of
don't
aware
that,
but
are
we
gonna
make
make
it
a
more
clean
and
you
know
accurate
manipulation
of
how
we
call
this?
What
kind
of
thing
we
want
to
cache?
C
What
kind
of
thing
we
don't
want?
Cash,
for
example,
like
we
can
advance
those
HTTP
cache,
maybe
so
some
HTTP
header
to
tell
server
what
kind
of
information
we
want
to
cache
or
something
I
just
saw.
Can
we
have
a
better
cash
mechanism?
Maybe
a
consistency.
Magnesium
instead
of
true
mechanism
and
well
also
have
a
effect,
a
little
effect,
another
mechanism
which
maybe
make
people
a
little
confused.
It
won't
be
a
big
effect
to
user,
but
yeah
I
just
had
a
little
do
have
a
long-term
solution
for
that
yeah.
A
A
One
idea
is
to
open
a
one
new
issue
for
that,
and
we
tackle
that
in
the
long
term
it's
kind
of
a
technical
debt
that
would
we
could
definitely
you
know,
improve,
but
yeah
I,
don't
think
we
even
have
a
one
issue
for
that
yet
or
anything
like
that,
but
one
one
someone
that
you
could
you
know
start
to
share
some
ideas
and
some
shirt.
Some
discussions
with
is
David.
E
E
So
it's
basically
have
a
a
base.
Layer
and
people
can
also
have
some
customized
overlay
layer,
so
it
can
generate
a
manifest
that
can't
type
to
keep
control
apply.
So
you
can
first,
a
generator
base.
Layer
under
applied
is
created
and
then
pipe
the
overlay
and
player
to
apply
and
there
it
will
update
under,
like
inject
some
config
map
under
labels
and
secret.
Something
like
that
when
I'm
working
with
Jeff
Gregg
and
on
on
this.
A
F
F
F
It
gets
proposal
I
had
in
mind
gloss
to
it
in
order
to
make
it
behave
more,
like
LS,
/,
fabiana's
suggestion
on
on
the
PR.
It's
to
basically
do
a
cube,
CPL
exit
beforehand
to
see
if
that
directory
exists,
and
then
they
basically
go
from
there.
So
so
right
now
the
issues
that
we
don't
check
at
all
whether
the
the
destination
path
exists,
and
so
we
make
various
assumptions
about
in
the
command.
F
And
basically,
if
you
guys
agree,
we
could
probably
before
a
hand,
do
a
remote
call
see
if
holder
exists
and
then,
if
it
does,
then
you
know
if
you're
gonna
copy
a
directory
copy
it
underneath
the
the
one
that
already
exists
on
the
pod
so
and
then,
if
the
directory
doesn't
exist,
then
honor
the
you
know,
final
fragment.
So
if
you're
wanting
to
copy
directory
foo
s
directory
bar
under
the
temp
directory
on
a
pod,
do
that
if
those
already
exist
so
I
just
wanted
to
see
if
there
was
any
feedback.
A
Yeah
when
we
can
purely
follow
up
on
the
issue,
but
you
know
my
initial
concern
was
you
know:
tween
introduced
new
ways
of
doing
things
right
so
as
much
as
we
can
do
whatever
CP
or
SCP
does
I
think
the
better,
because
that's
what
people
are
already
used
to
to
to
do
right.
So
I
didn't
try
to
check
what
SCP
does
in
that
case,
but
that
was
the
CP
example,
but
anyway
we
can
follow
up
there,
but
I
think
the
major
point
is
try
to
not.