►
From YouTube: Kubernetes SIG CLI 20170412
Description
Kubernetes SIG CLI bi-weekly meeting for 20170412.
https://github.com/kubernetes/community/tree/master/sig-cli
B
There's
a
couple
changes
we're
going
to
need
to
make
now
one
is
for
merging
lists
and
retaining
ordering
because
things
like
environment
variables.
We
support
the
strategic
merge,
which
is
by
kind
of
synthetic
map
style
of
merging,
but
that
was
the
ordering
and
and
so
when
she
has
a
working
on
a
design
on
how
to
keep
at
least
relative
ordering
set
the
user
to
the
user.
B
Applying
the
config
it
looks
like
ordering
remains
consistent,
but
one
challenge
is
that,
because
of
the
way
we
support
version
skew
between
client
server
old
clients
will
send
old
patch
styles
to
new
servers.
New
clients
will
send
new
pad
styles
to
old
servers,
both
need
to
continue
to
function
in
a
way
that
does
not
break
anything
so
the
old
client,
if
there's
an
old
client
or
an
old
server
involved
that
should
work.
B
The
way
it
did
both
are
old
and
the
strategy
we've
been
using
so
far
is
to
add
to
incrementally
add
directives
whenever
we
need
to
modify
behavior
and
so
the
old.
So
the
new
client
will
send
what
is
effectively
the
old
patch
or
something
that
will
be
treated
exactly
the
same
as
the
old
patch.
So
it
doesn't
have
to
be
the
same
bites,
but
to
interpret
it
the
same
way
and
old
server
would
need
to
interpret
it
the
same
way
and
then
sending
new
directives
that
modify
the
behavior
and
then
because
servers
will
drop
directives.
B
C
B
C
C
B
Definitely
not
so
like
in
the
old
case.
It's
like
you'd
get
a
random
order,
and
now
you
don't
get
a
random
order,
which
is
that
things
like
a
clear
win.
Yeah
it
doesn't
rescue
any
worse.
It
could
have
been
that
order.
I.
Think
there's
a
couple
others
where
most
of
the
ones
we've
encountered
is
like
clearly
broken.
C
But
that
is
this
question.
It
might
be
the
type
of
thing
where
you
bubble
it
up
to
the
release
notes
in
a
way.
That's
like
you
know,
technically
we're
changing
behavior
here,
but
we
think
if
we
move
from
unpredictable
too
predictable,
you
know
there's
a
small,
and
so
you
might
be
relying
on
the
unpredictable
behavior.
But,
like
really
was
just
a
matter
of
time
before
you
got
screwed
anyway,
yeah.
B
B
Because
there's
always
like
pretty
exclusively
no
anyway,
some
feedback
we
got
from
that
was
that
the
patch
style
becomes
ugly
and
unwieldy.
Because
we
add
now
you
have
to
do
maybe
two
or
three
directives
to
send
a
patch
and
so
they're
kind
of
Intel
here
and
it's
not
it's
not
a
lobbyist
from
a
human,
constructing
a
patch
and
I
think
that's
just
something
we're
going
to
have
to
live
with
until
we
decide
to
really
rethink
how
we're
doing
the
patched
and
versioning
it
or
something
like
that.
C
B
It
is
not
documented
well
that
is
actually
something
that
came
out
of
one
cheese
in
my
discussion
is
were
constructing
a
document
in
that
document.
The
intention
is
for
that
to
contain
background
on
patch,
like
what
it's
used
for
all
the
directives
and
all
the
formats
with
examples
in
their
motivation
and
then
a
section
on
how
we
change
the
past
strategy
going
forward,
which
is
it.
C
A
B
So
we
don't
have
to
have
compiled
and
types
to
figure
out
how
to
patch
things,
which
is
really
good.
It's
really
going
to
help
with
the
version
skew
issues.
It
also
means
we
can
add
arbitrary
metadata,
pretty
simply
by
adding
a
tag
on
the
types
back
though,
and
then
it
appears
in
the
open
API.
So
there's
anything
about
a
type.
The
Coronet
is
type
that
we
think
the
schema
should
have
it's
now
trivial
to
add
it
in
and
get
it
in.
The
client
I
know.
A
B
A
Just
for
death
right
because
yeah
actually
using
metadata,
looks
like
you
know,
a
good
starting
point
for
expansions,
not
sure
if
you
agree
talking
about
getting
describe
you,
we
were
discussing
a
little
bit
about
it
yesterday
because
you
could,
you
know
just
mark
well,
this
column
should
appear
in
get
in
this
in
this.
You
know
third
party
research,
something
like
that.
So
are
you
thinking
about
it?
In
terms
of
you
know
the
the
the
depth
and
the
described
being
extensible,
we
have
all.
B
Right
forget:
I.
Definitely
think
that
would
be
a
just
nice
easy
when
to
in
not
just
for
to
control
gift,
I
kind
of
think
of
it
as
what
is
the
simple
print
version
of
this
resource
or
something
generally
useful.
If
you're
writing
a
Java
client
and
you
want
a
to
string
a
deployment
you
don't
want
to-
maybe
don't
want
to
dump
the
whole.
Oh
right,
you
want
to
have
a
clear,
just
small
to
string
like
we
display
include
control.
So
having
metadata
to
say
here
is
the
simple
way
of
printing.
C
I
know
and
I
and
I
don't
have
all
the
details,
but
I
know
I
heard
clay
at
some
point
mentioned
that
some
of
this
formatting
for
how
we
output
stuff
moving
some
of
that
stuff
server
side.
I
got
to
be
honest.
That
kind
of
gives
me
the
heebie-jeebies
I,
like
the
idea
of
providing
more
metadata
in
something
like
an
open,
API
or
you
know,
spec
versus
you
know,
Halloween
out
tube
controller
moving,
also
reside
yeah.
B
I
agree
with
that.
I
certainly
think
for
ninety
percent
of
cases
with
get
like
just
saying:
here's
the
columns
we
already
support
print
these
columns
in
control.
Why
not
just
attach
it
to
the
schema
as
a
one-line
comment
and
you're
done,
makes
more
sense
than
trying
to
add
complex
business
logic
for
stuff
like
describe.
C
B
A
Let
let's
say
you
you,
you
have
a
third
party
resource
so
how
you
actually
tagged.
You
know
your
column
to
appearing
get
right,
so
I'm
not
sure,
that's,
probably
not
part
of
the
PPR
descriptor
right,
so
we
could
think
about
providing
some
to
link
or
you
know,
add
metadata
or
anything
like
that
or
even
something
more
generic,
but
that
cluster
admins
good
use.
B
Go
and
I'm
interested
in
investigating
more
is
XY
ger.
It
can
be
generated
for
anything
and
so
for
third-party
resources.
We
could
generate
full
swagger,
that's
compatible
with
an
everything
that's
compiled
in
that
include
schema
that
allows
you
to
do
tonight,
side,
validation
of
deals
and
hype.
That
includes
the
print
columns
or
anything
else,
and
then
you
can
throw
that
in
an
annotation
or
a
first-class
field,
or
we
can
decide
how
we
want
to
attach
it
to
the
third
party
resource.
But
then
you
get
a
lot
more
fidelity
yeah.
C
So
I
mean
there's
this
there's
a
spectrum
from
sort
of
like
here's,
the
preferred
fields
that
are
sort
of
intrinsic
to
the
type
versus
here's
user
preferences
right
and
sort
of
it.
The
limit
here
we're
uploading
user
preferences,
4tube
control
to
the
server
in
some
way.
I
could
see
these.
You
know
these
types
of
preferences
being
codified
as
a
config
maps,
and
maybe
you
have
a
cluster
wide
config
map
that
actually
lays
out
the
stuff.
C
You
know
that
the
cluster
admin
has
set
up
for
this
thing
and
then
you
have
up
her
name,
space
or
or
some
way
a
per
user
config
map,
but
actually
lets
you
store
this.
It
seems
like
a
little
bit
of
an
advanced
case,
but
it
seems
like
we're
somewhere
on
that
spectrum.
In
terms
of
you
know,
user
preference
type
of
stuff,
it
feels
a
little
bit
like
say,
get
ignore
right.
So,
like
you
know
where
it's
like,
you
can
have
your
personal
get
ignore
you
have
the
repo
kit
ignore
you
can
have.
C
C
A
Yeah,
it's
also
kinked.
Among
my
mind,
we
discussed
these
scenarios
some
time
ago.
Groups
right
so,
for
example,
I
would
like
in
this
cluster
that
these
third-party
resource
of
mine
to
be
part
of
the
all
group,
so
that
every
time
I
do
keeps
it
at
all
or
the
little
death
resources
included.
So
somehow
you
know
that
could
be.
You
know
a
closer
white
preference
so
that
cluster
admins,
you
know
baguette,
has
a
part
of
the
whole
group,
but
I
could
also
have
maybe
some
my
own
preferences.
A
But
you
know
the
cluster
white
part
of
its
I
think
that's
feasible
right,
because
you
know
we
discussed
that
invest
already
being
able
to
be
flexible
about,
what's
included
in
groups
like
all
so
maybe
in
a
cluster
why'd,
you
know
scope,
we
could
think
about
it,
maybe
not
that
hard,
but
as
I
said,
we
should
probably
have
some
tooling
around
it
so
that
those
are
evidence
could
easily
tag.
You
know
these
third-party
research
is
part
of
all
now,
so
just
include
a
metadata
to
be
it's
your
enemy,
yeah.
C
Yeah
yeahs
it
it
just
and
one
of
the
things
that
that
we
did
in
164
q
badman
was
we
introduced
a
new
name
space
called
tube
public
with
the
ideas
it's
a
place
where
you
can
put
stuff
like
config
maps,
where
you
want
to
publish
it,
and
it's
not
sensitive
information
anyway.
So
that
might
be
an
appropriate
place
to
put
a
put
big
data
like
this
I
think.
B
One
thing
I
actually
might
be
interesting
like
that,
could
potentially
be
done
as
an
extension.
If
we
have
the
right
extension
points
in
coop
control,
so
like
I
guess,
we'd
have
to
think
more
about
this,
and
this
would
go
into
the
plugins
kind
of
thought.
But
if
you
could
create
a
third-party
resource
or
aggregated
resource,
that's
like
coop
control
preferences
and
then,
if
there's
right
hooks
in
coop
control
like
it
can
get
the
flags
from
there
or
something
like
that.
C
I'm,
mostly
just
auditing
this
class,
so,
like
you
know,
ignore
me,
I
can't
keep
my
mouth
shut
but,
like
you
know,
feel
free
to
ignore
me.
I
mean
the
one
thing
that
I
was
I
was
looking
for.
Is
that,
as
we
finish
up
16
and
hits
head
towards
17,
you
know,
there's
there's
a
lot
of
push
to
get
more
formal
about
features
and
actually
making
sure
that
we
get
this
stuff
published,
and
so
one
of
the
things
that
we
did
and
custard
life
cycles
that
we
started
a
doc.
C
Here's
all
the
things
we'd
like
to
do
things
that
book
that
signed
up
for
17
and
then
helped.
You
know
facilitate
the
people
who
signed
up
there
to
actually
do
the
right
feature
process
and
get
the
design
doc
stone,
and
so
then
it
ends
up
being
a
little
bit
of
a
living
document.
In
terms
of
you
know,
backlog
of
ideas,
along
with
the
stuff
that
that
is
in
scope
for
17
I,
can
share
that
with
you.
B
C
I
think
it's
just
the
type
of
thing
where
it's
like
you
know
it's
it's
a
touchstone
where
you
can
review
throughout
the
cycle
of
like
okay.
How
are
we
doing
on
this?
Do
we
have
the
feature
equals
they're
designed
you
know
and,
and
it
sort
of
becomes
ongoing
agenda
item
for
us,
so
I'm
not
sure
how
how
you
want
to
work
it,
but
but
I,
you
know,
I'd
love
to
see
sort
of
you
know.
What's
on.
What's
on
the
plate
for
17
around
the
stuff,
the
other
thing
posting
two
links
now
yeah.
A
We
have
we
have
a
these
two
documents,
one
more
like
a
road
map
for
the
year
and
the
other
is
a
four
you
know
individual
releases
but
I
think
that's
something
we're
not
doing
something
like
you,
Joe
mentioned.
You
know,
updating
the
dock
with
this
status
and
where
is
the
proposal
and
all
this
kind
of
stuff,
so
yeah.
That
sounds
like
actually
a
good
idea,
because
we
we
plan
and
didn't
touch
the
documents
after
dad.
So
it
won't
believe
me.
B
A
Yeah
I
have
a
idea.
Folks,
I
could
pull
things.
Also,
sorry,
sorry,
Joe
I
had
no
God.
Please
I
have
a
couple
of
things
three.
Actually.
First
one
is
a
some
time
ago
we
wrote
these
kind
of
onboarding
process
for
people
that
would
like
to
contribute
to
cube
CTL.
So
that's
a
documenting
the
in
that
community
ripple,
but
I
wanted
to
confirm
with
you
guys
if
we,
you
know,
publish
that
in
a
public
made
only
for
anything
like
that.
If
we
didn't
do
that,
yes,
I
think
that
would
be
a
nice
idea.
A
A
I'll
do
that,
then.
You
know-
and
you
know
make
sure
that
maybe
we
get
a
couple
needs
more
people
to
help
cuz,
where
we
really
indebted
specially
for
people
to
help
review,
pull
requests,
and
things
like
that
so
anyway,
I'll
do
a
kind
of
cultural
action
for
people
in
cube
Deb.
The
second
thing
I
have,
actually
you
mentioned
a
little
bit
about
it-
keeps
each
other
plugins,
so
I
wanted
to
mention.
What's
the
status
around
it,
so
I
have
the
pre
request
for
v-0
of
plugins,
which
already
got
a
two
round
of
reviews
and
I.
A
A
Yes,
there
is.
There
is
a
feature
issue
and
also
up
purple
a
written
proposal,
ok,
cool
yeah
and
that's
the
link
for
the
upper
class.
So
that's
V
0.
So
the
first
round
of
support
for
cube,
CTL
plugins,
that's
basically
binary
expansions
in
no
support
to
you
know
apraxia
to
the
API
or
anything
like
that.
But
when
I
started
playing,
you
know,
writing
the
double
request
and
actually
writing
a
simple
example.
Plugging
I
realized
that
it's
already
pretty
powerful.
A
So
if
you,
if
you
guys,
want
to
provide
any
feedback
and
helping
reviewing
it's
a
pretty
big
one
but
we're
you
know
pretty
excited
about
it,
so
yeah
enta
see
you
know
what
people
will
come
up
with
once
we
have
it,
but
anyway
that's
VZ
rose,
so
not
GA.
We
are
planning,
to
probably
you
know,
add
some
kind
of
alpha
or
beta
process
around
it
anyway.
So
that's
plugins
and
I
know
I,
guess
that
that's
what
I
had.
C
A
It
drifted
a
little
bit,
especially
because
the
design
doc
is
not
very
much
detailed
about
these,
like,
for
example,
the
searching
process,
so
we're
tipsy
tell
will
search
for
plugins.
So
this
kind
of
details,
so
I'm
planning
once
we
we
are
pretty
close
to
getting
it
merge
to
work
on
the
on
the
you
know,
to
updated
design
doc
and
actually
that
will
spin
up
a
kind
of
document
for
people
that
want
to
start
playing
around
with
it.
A
B
A
Yeah,
actually,
some
time
ago,
I
start
I.
You
know
the
kind
of
a
perfect
concept,
so
I
wanted
to.
You
know,
create
a
cube
CTL
repo
in
my
own
github
account
and
just
import
the
CMD
CTL
package
and
director
depths,
so
that
we
could
have
an
idea
about
everything
that
gypsy
girl
is
important
today
and
especially
think
it
should
not
be
using
some
things
from
the
made
things
that
are
not
in
the
client
go
or
the
API
machinery
repose,
letting
the
tyranids
repo
and
keeps
itself
should
not
be
using.
A
So
I
need
that
exercise
some
time
ago,
and
we
have,
I
think,
one
of
the
tricky
ones
is
going
to
be
the
generated
internal
client
sets
because
we
are
just
importing
everything
you
know.
Another
depth
under
the
main
in
the
main
rebel
under
internal
clients,
have
the
generated
once
so.
Basically
you
know
the
coin
parts
of
it.
So
there
are
a
few
pieces.
A
B
A
I,
like
her
actually
paste
the
link
here,
so
that's
the
generated.
Go!
That's
based
on
a
rifle
that
only
has
CMD
keep
CTL
a
copy
from
the
CMD
key
detail
package
from
the
main
grateful
so
I
just
generated
the
go
depths,
and
that's
basically
all
that
the
chips
yet
to
tell
command
imports
so
yeah
there
definitely
something
that
should
not
be
there
and
anyway,
but
I
think
moving
on
it's
going
to
be
nice
to
have
lipstick
tail
on
in
its
own
repo.
D
A
D
Yeah:
let's
try
to
pull
it
up,
that
I
look
for
over
the
back
and
also
with
respect
to
the
acute
cuddle
extraction.
Yeah,
it's
going
to
be
it's
going
to
be
tricky.
I
were
putting
together
a
document
to
describe
what
we're
going
to
do
and
why
we're
gonna.
Do
it
and
we'll
send
that
out?
Hopefully
this
week
but
yeah
there's
a
lot
of
dependencies
that
need
to
be
broken.
It's
going
to
be
fun.
C
C
C
D
B
B
And
actually
one
thing,
I'm
hoping
that
we're
able
to
make
progress
on
either
this
release.
Our
next
release
is
better
visibility
into
whether
we
think
we're
agreeing
for
release
I
feel
like
during
the
release
process.
It
seems,
like
everyone
may
be
kind
of
thinks
they
are,
but
then
the
release
team
thinks
maybe
they're
not,
and
it's
not
clear
that
every
sake
or
sub
team
understands
exactly
what
their
health
is.
With
respect
to
cutting
and
release.
I
know
that
I
don't
think
we
have
great
visibility
into
that.
A
They're
running
now,
or
at
least
they
was
either
1.6
release
process.
I
know
because
I
fix
that
couple
failures
on
skill
death,
but
they
were
running
at
least
I
I
suppose
they
are
running
now
Oh
said
of
the
test
grid,
but
that's
does
I,
I'm
not
sure
I'd
have
to
check
but
yeah.
I
think
it's
it's
part
of
that.
That's
great
now,
but
at
least
it
to
atom
1.6.
B
D
It's
not
really
the
dependencies
I
mean
dependencies
breaking
is
going
to
be
pretty
straightforward.
This
work
to
do,
but
it's
relatively
straightforward.
It's
setting
up
integration
tests
that
will
support
having
the
option
to
push
coop
cuddle
more
frequently
than
the
rest
of
it
than
the
rest
of
the
core.
So
that's
going
to
mean
ski
tests
are
going
to
become
sort
of
a
not
an
abnormal
thing.
They're
going
to
become
a
normal
spring
cube
cuddle
messn.
D
C
D
E
A
B
B
We
want
to
help
facilitate
that,
so
the
to
control
as
libraries
and
infrastructure
and
then
command
piece,
which
is
how
do
we
write
a
client
that
people
use
like
Jeff,
was
saying:
that's
really
decoupled
from
cougar
Nettie's,
the
server
side
piece
anyway
and
then
there's
as
a
platform,
which
is
the
plugins
piece.
How
do
we
allow
folks
to
discover
and
install
new
functionality
for
working
with
the
cluster.
E
B
Yeah,
I
really
think
we
need
a
way
of
summarizing
this,
like
look,
how
many
links
there
on
this
page
like
how
are
we
supposed
to
figure
out
what
our
health
is
like
by
clicking
through
all
these
links,
but
makes
no
sense
I'm?
Maybe
we
can
figure
out
if
there's
any
infrastructure
that
allows
us
to
publish
just
which
tests
are
failing
to
a
single
dashboard
that
we
can
look
at.