►
From YouTube: Kubernetes SIG CLI 20170719
Description
Bi-weekly meeting for the SIG-CLI Kubernetes group.
A
A
So
while
we
be
having
a
lot
of
poor
requests
and
a
kind
of
seen
a
shortage
of
people
to
help
with
reviewing
code,
so
I'm
doing
a
lot
of
those
and
other
than
that,
I'm
also
starting
to
work
a
little
bit
on
some
improvements
and
refactorings
to
the
printers
package,
so
I'm
not
sure
what
you
guys
think
about
it.
But
the
printers
package
has
a
number
of
issues
today,
and
mostly
its
kind
of
you
know,
we
have.
We
have
a
lot
of
things
that
are
really
not
not
very
clear,
not
very
well
design
it.
A
So
we
have
a
lot
of
like
things
like
I,
don't
know,
printer
options,
stretched
that
go
ahead
and
over
a
lot
of
number
of
methods
and
functions,
and
so
I'm
starting
some
work
on
improving
those
that
will
also
improve
the
reusability
of
the
printers
package,
because
today
it's
really
hard
to
you
know,
use
them
and
we
have
some
some
packages
other
than
the
cube
kettle
starting
to
use
printers.
So
we
are
kind
of
in
a
need
of
improvements
in
the
printers
package
that
that
is
also
somehow
related
to
splitting
cubes
excel
to
its
own
repo.
B
So
arm
related
to
60
li
on
there's
this
project.
That
happy
is
involved
in
cold
case
on
it,
as
part
of
that
is
this
tool
called
cube,
config,
and
so
it's
another
command-line
client
for
kubernetes,
but
really
looking
to
be
sort
of
more
principled,
around
sort
of
workflow
versus
a
real
sort
of
toolbox.
Just
wanted
to
make
folks
aware
of
that.
Another
thing
that
we're
working
on
in
cig
cluster
lifecycle
is
there's
a
certain
set
of
labels
that
are
sort
of
well
known
labels,
and
these
things
are
kind
of
scattered
all
throughout
the
codebase.
B
And
so
it's
one
of
these
sort
of
refactoring
things
that
we
have
to
figure
out
as
we
as
we
try
to
exact
extract
things
like
like
you,
keep
cuddle
and
so
I'm
starting
to
float
a
proposal
on
sort
of
establishing
a
registry
for
labels
that
is
separate
from
the
main
code
base.
So
that
will
be
helpful
eventually
in
terms
of
being
able
to
extract
stuff
out.
A
B
C
B
And
you
know
and
I
think
over
time,
and
it's
still
fuzzy
it's
probably
going
to
be
more
opinionated
around.
You
know
you
have
like
some
of
the
problems
we
face
with
things
like
you
know:
Cube
control
apply
with
prune
right
because
cube
control
really
operates
on
this
sort
of
soup
of
object.
That's
very
difficult
to
actually
have
a
reliable
workflow
around
a
larger
set
of
objects.
B
B
Think
you
know
this
is
what
we're
aiming
for,
where
it's
more
of
a
bundle
similar
to
a
helmet
art,
but
it
is,
and
it
can
be
used
by
home
charts
it's
one
of
the
things
that
we
want
to
want
to
make
possible
so
that
you
can
use
how
you
can
take
one
of
these
and
deploy
it
with
with
helm.
But
then
it's
also
usable
purely
from
the
command
line.
B
Okay,
recognize
that
right
through
that
it
doesn't
require
service
I'd
like
like
teeler
and
help
exactly
and
so
what's
fascinating
is
inside
of
Google
there's
actually
two
commands
for
interacting
with
Borg
they're.
The
sort
of
raw
command
called
Borg
print,
which
is
that's
not
confusing
at
all,
which
is
very
much
of
a
you
know.
Board
is
not
restful,
it's
more
of
an
RPC
thing,
but
essentially
it's
a
wrapper
around
calling
those
our
pcs
directly
and
then
there's
a
board
config,
which
uses
the
separate
DSL
and
that's
more
akin
to
something
like
terraform.
B
And
so
you
know
none
of
this
stuff
Maps
directly
into
kubernetes.
It's
kind
of
all
echoes,
but
but
so
far
you
know
cube.
Cuddle
has
been
mostly
sort
of
the
raw
stuff,
with
sort
of
hints
of
the
more
sort
of
terraforming
type
of
thing,
sprinkled
here
and
there
and
I.
Think
honestly,
we've
been,
we
haven't
done
a
good
job
of
communicating
that
to
users
and
I
think
it
creates
confusion.
B
So
some
of
those
some
of
the
stuff
that
we're
looking
at
with
with
case
on
it
is
how
can
we?
How
can
we
actually
build
something
which
is
a
pure,
more
pure
expression
of
that
sort
of
you
know,
declarative.
You
know,
write
it
down
type
of
workflow,
so
that
I
would
I
mean
one
of
the
things
that
might
be
useful
and
it
might
actually
be
I'm
not
as
familiar
as
I
should
be,
with
the
plug-in
model
for
for
cube
cuddle.
A
B
A
B
Different
bank
connection-
exactly
that's
cool,
so
yeah,
so
but
then
things
like
the
printers
then
end
up
like
if
you
want
to
have
something
that
you
know.
Prints
and
integration
looks
like
it
feels
like
like
a
chip
control
deaths.
That
is
not
anything.
That's
sort
of
broken
out
super
sharable
way
yet
yeah
exactly
okay,
okay,
cool,
okay,
yeah!
You
know,
as
we
sort
of
get
further
with
with
the
the
case
on
it's
tough
in
my
you
know,
make
sense
to
think
about
this
as
an
extension
for
freaking
control,
mm-hmm.
C
Of
my
time,
working
on
the
control
extraction,
if
we
want
to
move
up
the
some
some
utility
to
the
weeks,
we
will
have
two
new
ripple,
slider
utility
vehicle,
which
will
include
the
generic
facilities,
and
then
we
will
have
another
utility
vehicle.
It
will
include
pranati
related
utilities,
so
at
this
time,
I'm
working
working
on
creating
the
utility
vehicle
under
after
finish,
that
are
you
working
on
creating
the
community
related
or
iterative
loop.
C
D
I,
just
have
a
question:
speak
of
that
split.
The
cook
control
to
independent
report.
I
just
have
a
question
about
that:
API,
API
group
and
they're
live
internal
type.
Do
we
have
to
you
know,
keep
our
own
internal
type
in
our
coop
control
own
report.
It's
like
it's
like
when
you
will
split
the
riffle
into
an
independent
riffle.
It's
like
we
have
to
drop
some
type
like
like
like
do
we
have
to
keep
the
both
internal
type
and
the
server
life
type?
All
we
just
keep
the
server
life
type
in
our
I
mean
o.
D
Could
control
Ripple
I.
Think
monkey
had
a
usual
vote,
so
there's
no
question
and
I
think
David.
He
is
Jordan.
They
they
they.
They
are
working
on
some
disgusting,
but
I
just
don't
know
what
would
be
like,
because
if
we
keep
the
server
life
type
allocated
with
your
life
type
in
overcook
control,
Ripple
I
think
some
unit
has
will
be
really.
You
know
a
lot
of
work
to
do
right.
Oh.
D
Papiano
I
also
have
a
passion
about
that.
A
fixed
hardwood
aromatic,
oh
okay,
Oregon
to
use,
have
you
ever?
Do
you
remember
that
PR?
If
yeah,
it's
an
error,
message
occurring,
cool
control
apply
and
we
want
one
reuse
like
money,
our
bishops
origins.
You
know
I,
so
that
the
error
method
were
just
charcoal
to
cook
control.
We
want
to
replace
it
with
ownership,
CRI
all
also
command.
So
your
suggestion
is
like
include
a
new
attribution
of
command
mmm-hmm.
A
Could
you
could
you
yeah
yeah
that
that's
actually
a
problem?
We
have
not
only
in
apply,
but
in
a
lot
of
places
for
you
to
tell
commands.
Basically,
the
string
keep
CTL
is
hard-coded
in
a
number
of
places.
If
you
check,
for
example,
a
long
descriptions
and
examples.
It's
hard
coded
in
a
lot
of
commands
so
and
also
like
I,
said
in
a
number
of
error
messages,
so
keep
CTL
string,
hard-coded
and
basically
my
idea
was
that
we
try
to
make
it's
more
structured.
The
way
commands
are
created.
A
So,
if
you
take,
for
example,
the
CH
CMD
that
go
file
under
the
cube
CTL
CMD
package,
you
will
see
that
we
try
to
you
know
kind
of
conform
to
a
you
know
a
a
proposal
like
new
CMD,
you
know
CMD
name
or
like
Museum
D
apply,
but
that's
not
an
interface
or
anything
like
that.
So
what
I
was
thinking
about
was
to
propose
an
interfaith
interface
or
at
least
a
structured
function
for
how
you
create
commands.
A
And
if
you
take,
for
example,
a
comment
there
today,
you
will
see
that
some
takes
the
factory
and
the
in-and-out
return
writers
as
arguments.
Some
other
doesn't
take
the
out
the
the
in
as
an
argument
as
an
argument.
Some
of
others
don't
take
the
error
out
as
an
argument.
So
there's
not
clear,
you
know
wait
for
creating
in
commands,
so
the
idea
was
to
create
an
interface
to
conform,
those
command
creations
and
that
could
include,
for
example,
the
the
complete
validate
in
run
functions.
So
they
could
be.
A
You
know,
explicitly
declared
by
this
command
interface
and,
along
with
that,
we
would
make
the
constructor
like
new
CMD
blah
blah
blah
take
a
new
stretch.
The
stretch
that
would
you
know
have
some
attributes
like
the
reader
in
the
writers
like
out,
and
there
are
route
and
also
something
that
we
would
use
to
like
the
base.
Cmd
name
in
this
case,
the
tip
CTL
string.
A
That
would
we
would
use
you
know
to
to
in
descriptions
and
error
messages,
and
all
of
that
so
anyway,
it's
a
it's
kind
of
an
idea
of
improving
the
way
we
create
command,
because
today
it's
really
not
structured.
We
try
to
follow
a
convention,
but
there
is
nothing
that
enforces.
You
know
that
how
you
build
the
constructor
and
you
know
the
the
other
methods
but
yeah.
That
would
be
the
idea
recently
who
and
implemented
ethics
for
for
a
similar
issue
and
I
added
a
comment
there.
A
D
A
Right,
it
would
be
in
our
code
and
actually
an
interface
that
we
defined,
so
part
of
that
would
be
to
also
try
to
not
be
that
much
dependent
on
the
Cobra
structure
right
because
cover
today
is
everywhere.
So
we
would
define
our
own
interface
for
that
and
not
rely
on.
You
know
whatever
cover
proposes,
but
yeah
I
would
not
require
any
change
in
Cobra.
A
A
Can
you
guys
still
hear
me
not
sure
I
saw
I,
assume
error
message
here
anyway?
Let
me
so
basically,
we
have
to
decide
here
if
we
want
to
propose
a
CLI
plugins
as
a
formal
new
feature
for
1.8.
So
the
feature
freeze
for
for
the
next
release
is
on
August
first
and
what
it
would
mean
by
proposing
plugins
as
a
formal
feature,
basically
would
be
that
you
know
we
would
list
plugins
as
a
new
formal
feature
in
1.8.
Part
of
the
release
would
probably
require
some
documentation.
A
We
would
still
have
to
decide
the
level
of
support
we
would
have,
but
probably
at
least
for
1.8.
It
would
be
alpha
alpha
or
beta,
but
probably
alpha,
but
anyway,
that
would
we
we
have
CI
plugins
here
for
quite
some
time
already
still
missing
some
pieces,
but
the
basis
for
it
is
here
for
for
some
time
already,
but
we
never
made
it.
A
B
It
definitely
makes
the
case
for
this
and,
like
I
know
like
the
refractory
budget
is
like
zero,
it's
like
negative
but
like
if
we
could
take
some
of
the
current
cube
control,
commands
and
break
those
out
as
plugins
and
actually
sort
of
dog
food.
That
is
part
of
the
core.
You
know
the
experience
of
what
we
have
now.
That
would
demonstrate
that
the
plug
interfaces
are
good
and,
and
it
would
actually
help
us
to
to
make
sure
that
is
there
sort
of
sufficient
in
something
that
we
want
to
actually
keep
overtime.
B
A
Absolutely
I
would
personally
love
that
you
know
I.
Think
one
of
the
major
problems
about
kind
of
taking
existing
commands
and
moving
to
place
would
be
that
we
don't
have
a
an
easy
way
to
install
them
today
right,
so,
basically,
you
have
to
to
copy
the
plugin,
the
scripture,
the
scriptorium
binaries
under
dot
q,
/
plugins
directory.
A
So
but
anyway,
one
of
the
places
where
we
are
kind
of
using
plugins
as
a
dog
food
is
a
the
service
catalog
set
of
commands
right,
so
greater
yeah,
it's
not
a
an
existing
set
of
commands,
so
it's
a
new
one.
So
probably
it's
one
of
the
places
where
it's
it
applies
well
to
being
a
you
know,
our
own
dog,
food
or
Plains.
A
So
there
really
not
much
yet
related
to
search
element
that
s
plugins,
also
because
I
have
to
pull
requests
that
it
kind
of
requires
and
are
not
yet
merged.
Our
therefore
for
being
reviewed,
but
currently
the
the
proposal
is
to
use
it
in
service
catalog
commands
it's
not
really
not
not
very
easy
to
to
install
them.
We
will
have
to
think
about.
You
know
in
future.
A
How
will
we
make
that
easier,
so
I
would
love
to
have
a
way
to
you
know
actually
have
a
kind
of
package
distribution
mechanism
for
plugins,
but
not
sure
how
that
would
work
yet
so,
but
anyway,
I
wanted
to
turn
share
my
screen,
but
I'm
using
a
upstream
version
of
fedora
and
he
doesn't
work
with
zoom,
so
yeah.
Let
me
actually
paste
the
the
link
here
in
chat.
A
A
It
doesn't
reverse
many
sinks,
so
it's
basically
directly
related
to
the
sink,
so
that
was
I
was
not
completely
sure,
but
it
really
makes
a
new
new
feature,
but
anyway,
I
think
making
it
an
official
feature
would
be
good
in
terms
of
having
documentation
and
having
some
new
eyes
on
on
this
thing,
we
are
calling
plugins.
So
I
would
like
to
hear
what
you
guys
think
about
it.
If
we
formally
propose
it
as
a
new
feature,
it
means
we
have
to
start
to
formally
support
it.
A
B
B
It's
going
to
force
us
to
think
over
the
longer
term.
About
sort
of
you
know
long
term
support
and
versioning
and,
like
you
know,
how
are
we
going
to
support
this
for
years
right
versus
something
that's
just
sort
of
like
hey?
Let's
try,
some
stuff
out
so
I
think
you
know
starting
down
that
path
makes
a
ton
of
sense.
Yeah.
Okay,
are.
E
B
A
Yeah,
one
of
the
reasons
I
would
also
have
want
to
have
these,
as
a
more
formal
feature
is
that
I
would
like
to
have
some
new
eyes
based
on
security
on
a
chip
scale
plays
because
you,
you
know,
we
are
opening
a
proxy
to
the
API.
We
are
introducing
some
token
authentication
mechanism,
but
anyway,
that's
kind
of
a
it's
a
proxy
for
the
API.
You
know
already
authenticated,
meaning
that
e
you
open
that
a
new
local
host
on
a
given
port
that
would
be
open,
for
example,
for
anyone
in
that
same
machine.
A
E
A
A
You
know
validate
some
some
art
of
our
choices
around
specifically
the
proxy
for
the
API.
You
know
that
there
are
some
some
other
possibilities
around
how
plugins
access
the
API.
So,
for
example,
we
could
just
simply
provide
the
deploying
the
authentication,
token
or
certificates
or
things
like
that
as
in
bars
or
even
really
don't
bother
about
it
and
let
every
plugin
take
care
of
reading
the
cube,
config
file
and
using
the
token,
but
anyway,
the
idea
is
to
have
some
externalize
based
on
on
those
decisions.
A
Okay,
if
there's
there
isn't
any
other
major
concerns,
I'll
go
ahead
and
start
with
the
process
or
of
proposing
as
a
formal
feature
alpha
for
1/8,
if
you
guys
agree
with
it.
So,
as
I
said,
we
have
been
here
for
some
time
already,
but
I
think
even
in
terms
of
features
we
are,
we
were
not
there
yet
to
be
considered
as
alpha
once
we
got
the
super
request.
I
have
opened
one
related
to
the
perks
API
in
the
other.
A
D
Hi
I
just
have
a
another
question
about
cook.
Cook
control
is
not
not
to
apply
aesthetic
with
Philips.
You
just
suggest
introduced
a
flag
is
like
a
tip
waiver
and
it
could
open
an
external
teeth,
but
I
just
found
that
that's
like
it's
really.
You
know,
maybe,
if
not
go
to
support
it,
because
introduced
of
external
flag
for
our
code
base
will
break
the
previous.
The
logic
of
that
that
that
that
code,
because
we
reuse
the
code
added
added
command
so
I
was
checking
the
cook
control
edit.
D
It
doesn't
support
a
like
opener
external
editor
flag,
so
it
is
using
a
environment
variable
to
support
that.
So
do
you
think
we
can
drop
that
flag,
because
I
really
think
I
can
introduce
that
flag,
but
I
think
you
will
break
the
logic
of
previous
call
and
make
the
code
readability
really
bad
and
make
it
really
complex.
So
yeah
I
learned
I
married
to
the
building
like
the.
E
E
Don't
think
the
flag
is
necessary,
I
mean
the
only
thing
I
want.
Is
that
arm
it
like?
If
a
user
could
have
it
pop
up?
Gui
diff
viewer
versus
a
is
able
to
configure
like
what
application
uses
to
dip
it,
or
rather,
if
it
opens
it
an
application
or
if
it
just
like
prints
and
stuff
out
of
the
screen,
we
can
maybe
chat
up
after
the
meeting
or
outside
this
okay.
D
E
B
B
And
having
like,
if
you've
used,
terraform
there's
like
terraform
plan,
which
gives
you
a
really
nice
idea
of,
like
it's
kind
of
a
dry,
run,
it's
kind
of
a
dip,
it's
kind
of
like
you
know,
what's
going
to
happen
when
I
run
this
and
I
think
anytime,
you
know
where,
where
you're
doing
op
stuff
having
that
sort
of
like
okay,
let
me
just
take
one
final
look
before
I.
Actually,
press,
yes,
is
a
really
good
thing,
so
I
think
you
know
having
a
div
is
going
to
be.
A
E
B
Know
it's
interesting
yeah
if
you
have
I
think
you
know.
The
interesting
thing
here
is
that
is
that
you
know,
as
you
move
toward
declarative
flow
you're,
essentially
moving
the
source
of
truth
for
what
should
be
running
in
your
cluster,
from
what's
actually
sort
of
applied
to
the
cluster,
to
sort
of
source
code
management.
Something
like
that
right
and
so
essentially,
like
you
know,
we're
enabling
a
reconciler
leap
here,
and
so
sometimes
there's
a
human
in
that
loop.
B
Sometimes
there
isn't,
the
diff
is
useful
for
also,
but
to
actually
see
do
I
have
to
actually
reconcile
right.
So,
like
you
know,
because
like
right
now
you
can
just
naively
go
like
we'll.
Just
call
cute
control
apply
is
see
what
happens
right,
but
if
you
have
a
monitoring
system
and
you
want
to
actually
sort
of
do
a
markup
like
hey
I,
did
a
change
out
here.
I
get
a
roll
out
you're
going
to
want
to
attach
metadata
with
that
monitoring
system
and
that
diff
actually
ends
up
being
part
of
that.
B
B
B
E
B
B
We
had
cute
control
plan
run
right,
that's
going
to
be
a
hell
of
a
lot
more
discoverable
and
it
actually
reads
well
for
that
type
of
stuff
and
and
it's
a
small
UX
change.
It's
the
same
functionality
in
some
ways,
but
it's
essentially
saying
plan
what
you
are
going
to
do
for
your
run
versus
actually
just
doing
the
rock
yeah.
So
just
throwing
throwing
I'm
just
trying
to
I'm
trying
to
noodle
around
like
how
do
we
actually
take
something
like
a
dip
and
and
recast
it
in
a
way?
B
E
A
huge
step
in
the
right
direction,
so
very
exciting
and
one
thing
I
just
amend
is
so
I,
like
your
plan,
run
I.
Think
that
makes
sense,
because
I've
been
trying
to
figure
out
how
people
get
people
to
do
that.
Yeah
I
think
we
should
move
away
from
run
in
general
and
towards
the
create
subcommands,
because
run
only
gives
you
a
deployment
and
then,
if
you
want
to
use
like
pods
or
staple
sets
or
anything
else
like
it,
the
syntax
is
pretty
confusing.
But.
B
E
B
E
C
E
Then
and
then
the
problem
is
right,
like
the
set
of
flags
like
you
list
all
the
flags
for
all
the
generators
you
could
possibly
use
but
like
each
like,
only
certain
fights
work
with
job.
Another
flags
work
with
deployment
is
really
hard
to
figure
out
what
works
with
what
so
sub
commands.
I
think
it's
going
to
be
better.
B
E
E
B
B
Imagine
that
I
had
some
sort
of
template
file
that
was
self
describing
and
I
could
introspect
this
template
file
and
say
what
are
the
parameters
there,
which
is
something
that
JSON
it
supports,
and
you
could
essentially
install
that
saying
this
template
file
ends
up
being
used
for
this
template
file
ends
up
being
used
it
for
create,
and
so
you
could
say
you
maybe
just
drop
a
file
someplace.
That
says
this
is
the
new
template
file
for
the
foo
bar
operator
and
then
the
create
command
says.
B
Oh
I
have
a
template
file
for
foo
bar
and
then,
when
you
actually
run
it,
it
actually
intersects
that
to
understand
the
parameters
and
generates
the
command
on
the
fly
and
so
creating
a
new
exude,
create
template
and
sent
essentially
is
authoring
a
single
file
and
dropping
a
new
in
the
right
directory.
You.
B
B
E
Right
like
it
would
be
really
cool
if
you
did
kooky
cold,
create
dash
F
on
a
URL.
The
URL
have
like
a
bunch
of
resources
in
it,
as
the
CRD
has
like
several
config
maps,
one
containing
the
open
API
one
containing
the
template
to
do
the
auto
crate
commands
and
then
the
controller
in
it
and
then
effectively
when
you
call
create
on
that.
You
get
like
a
first-class
resource.
Ok,.