►
From YouTube: Kubernetes SIG CLI 01172018
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
Prior
to
break
there
was
a
discussion
going
on
about,
as
we
want
to
break
up
cute
control,
make
extensions
on
cute
control
work.
Well,
we
really
needed
a
better
solution
than
what
we
had
for
things
like
Service,
Catalog
or
CR
DS
for
cute
control.
To
show
something
we
need
to
keep
control,
get
there's
a
longer
term
direction
about
for
other
types
of
commands.
A
So
it
is
a
very
limited
thing
and
it
wouldn't
work
for
anything
more
complicated
or
that
needed
to
deal
with
lists,
and
so
we
were,
we
had
a
approved
proposal
and
sig
API
machinery,
Phil
and
I
really
wanted
to
hash
out
some
of
the
details
just
to
make
sure
we
were
on
the
same
page
and
we
kind
of
argued
through
the
cases
of
we
want
everybody
using
cube
control
to
continue
to
have
a
good
experience
for
listing
resources.
It's
kind
of
one
of
the
most
fundamental
things
you
do
in
the
Q
control.
A
A
Or
resources,
but
we
also
want
to
be
open.
Api
approach
works
very
well
for
CR
DS,
so
you
don't
have
to
write
code
and
then
in
the
future,
for
things
like
offline
listing
of
files,
you
have
on
the
file
system
or
showing
summary
data,
we're
gonna
needle
slightly
more
client
centric
approach
for
some
of
those
use
cases,
but
we
were
going
to
go
ahead
with
server-side
printing
in
1:10
to
beta.
The
I
was
going
to
pull
together
the
list
of
work
items
and
do
this
on
the
mailing
list.
A
A
C
C
A
C
C
D
D
A
D
D
A
D
E
D
A
And
this
was
actually
someone
brought
this
up
porcelain
mode
for
apply
for
people
who
did
want
to
do
a
little
bit
more
advanced
scripting
until
there
is
an
API
one
way
to
try
out
the
things
we
would
do
on
the
server
would
be
a
porcelain
style,
apply
on
the
CLI
and
buy
porcelain.
I
mean
a
structured
response
for
that.
You
could
get
JSON
back
instead
of
a
just
an
exit
code
or
do
dry
run,
and
we
have
like
some
of
the.
A
D
That's
exactly
kind
of
how
we've
been
thinking
about
it.
There's
a
number
of
pieces
like
when
you
suggested
do:
do
you
want
to
list
the
items
before
executing
with
a
prompt
so
that
if
you're
gonna
like
delete
10
items
accidentally,
you
get
a
prompt
and
a
list
of
what
they
are
or
do
we
want
to
change
slightly
the
merge
logic
for
the
edge
cases.
D
D
One
thing
we
could
do
is
just
create
a
new
binary
and
push
it
every
two
weeks
right
and
then
we
don't
have
to
wait
till
went
in,
but
it
can
just
have
like
all
the
stuff
and
a
saya
as
we
head
right
on
it
and
then
fold
that
into
either
server
side
or
client
side
or
figure
out
where
it
goes.
Or
we
could
put
it
in
one
in
coop
control
where
it
would
be
available
to
a
lot
more
users,
but
would
be
harder
for
us
to
push
iterations
on.
D
D
D
F
B
Sub-Resources
yeah,
it's
something
that's
been
explored
server-side
and
now
we
have
polls
from
community
members.
Polynomial
there's
been
plumbing
through
the
generic
client
through
cube
control.
So
you
can
generically
scale
things
it.
It's
really
useful
because
it
matches
custom
resource
definitions,
custom
resources
which
weren't
matched
before
I.
B
Think
that
I'd
like
to
see
us
expand
those,
and
there
are
some
obvious
targets
if
we
coordinate
with
API
machinery.
So
we
have
scale
that
ones
happening
now,
but
I
also
see
things
that
we
haven't
CLI
like
logs
and
exec,
where
we
have
basically
a
command
that
is
issued
on
a
sub
resource
where,
logically,
you
have
multiple
resources
that
can
participate
in
it
and
would
be
good
targets
for
for
making
generic.
B
So
I'm
gonna
take
it
forward,
probably
to
API
machinery
that
actually
happens
today
and
decide
what
the
next
target
is
looking
at.
It
I
think
that
logs
is
probably
the
next
easiest
one
there's
not
a
whole
lot
of
existing
pieces
today,
there's
just
pod
logs
and
it's
streaming
in
one
direction,
not
too
for
us
to
just
try
to
get
that
API
working
properly.
D
D
It
probably
also
is,
as
part
of
that
is
worth
considering
like
how
do
we
want?
Are
there
things
that
we
may
want
this
to
behave
in
a
generic
fashion
for
like
Princeton's,
logs
I,
think
just
works
on
pods
now
and
so
like?
Maybe
how
we
didn't
vision
that
working
for
other
things
like
doing
vision
logs
against
the
service
or
a
deployment,
is
the
current
request
like
gonna
work
for
those,
and
we
don't
need
to
solve
those
problems,
but
it's
think
it's
worth
at
least
well.
B
I
think
we
need
to
solve
it.
For
one
I
I
was
planning
on
taking
forward
a
a
plan
to
use
discovery,
choose
a
20
on
side
match
against
a
generic
set
of
all
the
options
that
can
be
used
from
a
client,
and
we
have
examples
today
and
acute
control
of
logic
to
choose
a
part
of
a
replication
controller
as
if,
for
instance,
I,
don't
think
services
are
there
yet,
but
we
have
replication
controller
and
replica
set
and
deployment
does
I
recall,
maybe
a
job
too
much
I
like
them.
D
Yeah
and
and
so
along
that
same
line
like
I
like
that,
like
I,
definitely
like
the
area
and
I
think
there's
even
the
spectrum
of
solutions
within
there
and
the
ones
I.
Think
I've,
seen
with
scale
are
cool
I.
Think
it's
interesting
I'm
in
the
go
client
right
as
as
a
structured
object
and
then
I
forget
the
details,
but
effectively
it's
it's
compiled
in
the
vago
client.
D
That
makes
sense.
There's
like
a
prototype
of
something
that's
just
exploratory,
that
I
published
before
the
break,
which
allows
the
sub
resources
and
their
request
bodies
to
be
dynamically
discovered
and
not
compiled
in,
and
so
like.
So
there's
a
scale
one.
But
in
that
case
the
command
doesn't
even
know
about
the
scale
sub
resource.
So
it
dynamically
discovers
the
sub
resources
themselves
and
then
looks
at
the
request
bodies
for
those
sub
resources
and
then
maps
those
into
flags
dynamically
based
on
types
and
names
and
that
sort
of
thing
so.
B
A
Could
be
loose,
I
mean
if
there's
some
aspect
of
this
is
there's
the
two
parts.
If
I
want
to
use
this
as
a
structured
API
which
I'm
writing
a
generic
client,
that
is
code
based
versus
the
I'm
writing
a
CLI
which
there's
already
a
translation
layer
between
the
strongly
type
scale
resource
and
the
weakly
typed
CLI
flags,
so
I
think
that's
kind
of
the.
There
is
a
little
bit
of
a
distinction
there.
D
Yeah
exactly
I
think
in
like
within
that
there's
a
spectrum
from
like
I
know
nothing
about
this
API,
so
I'm,
just
gonna
parse
it
based
purely
on
type
to
weave
like
metadata
to
the
fields
so
the
scale
resource
or-
and
we
could
have
like,
for
instance,
the
scale
resource,
publish
its
request
body
and
say
this
is
the
flow.
These
are
the
things
and
how
to
expose
them
right.
D
If
there's
enough
data
within
the
schema,
either
through
convention
or
through
annotating
through
configuration,
you
can
skip
the
step
of
manually
mapping
flags
to
request
body
arguments
but
you're,
absolutely
right.
David,
like
there's
a
lot
of
ways
you
can
poke
holes
in
that
I'm
sure
there's
a
lot
of
edge
cases
where
you
say
it
wouldn't
work
so
I
think
it's
just
worth
something
to
explore,
because
what
it
does
enable
if
we
were
able
to
be
successful
in
that
is
it
enables
folks
who
write
CDs
not
to
be
restricted.
A
I,
like
the
good
enough'
mentality
for
CRE
deeds,
which
is
you,
don't
have
to
write
a
binary
plugin
and
you
get
forced
into
the
conventions.
I
mean
it's
almost
like
cute
control
create
in
some
respects,
which
is
arguably,
if
cube
controlled,
create
deviates
too
much
from
the
object
itself.
We're
doing
something
wrong
like
it's
supposed
to
be
just
simple
enough,
but
there'll
be
there'll,
be
examples
of
like
you
know
the
field
names
of
acute
control
create
argument.
A
If
we
ever
revved
any
of
the
API
versions
would
start
to
drift,
and
so
now
you
run
into
this
problem
of
you
know.
We
have
to
api's
the
flags
and
the
CLI
or
the
the
flags
and
the
CLI
and
the
API,
and
instead
of
being
honest
about
making
the
user
make
that
choice
or
having
that
convention,
we're
introducing
a
translation
layer.
D
F
Well,
what
we're
trying
to
do
is:
oh,
it's
hard
to
explain.
Oh
like
we,
we
get
what
resources
are
available
and
create
the
Cobra
commands
based
on
what's
available,
so
you
can
create,
you
can
go,
Q
control
create
and
the
name
of
the
resource
and
the
resources
are
what's
available,
and
we
were
talking
yesterday
about
how
to
parse
flags
so
to
keep
moving
forward.
But
it
it's
very
much
working
progress
yet
so
nothing's
sure.
D
D
What
they're
working
on
during
this
meeting
can
also
update
that
doc,
and
then
we
can
figure
out
how
we're
going
to
make
sure
how
we're
going
to
track
all
those
work
items
for
fee
release
110
and
please
make
sure
that
you
have
the
cap,
where
appropriate,
criminis
enhancement
proposal
to
track
the
work
items
or
an
issue
or
figure
out
what
the
right
scope
of
tracking
that
is.
D
C
D
Is
anything
else
on
server-side
printing
that
you
wanted
to
talk
about?
No.
A
D
G
Real
quick
well
so
it
regards
to
to
plugins,
although
I
have
no
basically
havin
over
here
for
one.
E
D
So
important,
thank
you
for
bringing
that
up.
I've
observed
like
for
King,
already
happening
of
our
infrastructure,
and
if
we
can
write
it
once
or
maybe
twice
once
like
in
a
place
that's
published
and
once
in
our
internal
representation,
then
that's
way
better
than
everyone
having
to
reinvent
it.
That's
like
a
different
way.
E
D
I
know
Antoine's
intent
that
his
stuff
can
be
used
also
by
plugin
authors.
One
thing,
I
think
would
be
helpful.
The
to
write
up
for
folks
and
I'm,
hoping
maybe
to
give
a
coupon
talk
on
this
we'll
see,
is
the
different,
the
different
ways
you
can
write
tools,
and
one
way
is
you-
can
use
like
the
compiled
in
types
and
write
logic
for
very
specific
api's,
and
this
works
great
and
a
controller.
D
They
are
now
writing
tools
against
that
should
probably
work
in
stiction
api's
that
they
know
about,
and
the
extension
API
folks
go.
Writing
those
extensions
also
don't
know
about
this
tool
right
and
the
common
world.
We
see
today
at
least
extension
API
folks
know
about
coop
control,
so
they
can
kind
of
like
test
against
it
and
make
sure
it
works.
D
And
in
folks
writing
tools
tend
to
know
about
the
api's
they're,
targeting
if
they're,
targeting
against
the
core
set
like
services
and
deployments
and
these
sorts
of
things,
but
in
the
the
way
and
the
place
where
plug-in
developers
are
working
in
need
to
develop
tools
that
work
in
stations.
Neither
one
can
actually
test
directly
one
against
one
another
to
see
that
they
work
and
they
need
to
follow
patterns
to
make
sure
they
do
right
and
and
like
one
of
those
is
the
one
David
had
brought
up,
which
is
using
sub
resources.
D
But
that
means
folks
writing
plugins
need
to
know
like
here's.
The
pattern
for
talking
to
sub
resources
instead
of
directly
invoking
scale
on
such-and-such
resource,
as
well
as
working
with
unstructured
objects
and
maybe
inspecting
objects
schema
depending
on
what
you're
doing
you
need
to
be
working
with
objects
based
on
either
properties
about
those
objects
or
on
the
methods
they
expose
through,
like
sub
resources,
for
instance,
and
so
any
libraries
we
can
publish
that
help
in
this
area,
because
it's
actually
something
challenging
to
do
I
think
would
really
help.
Folks.
D
H
This
is
Carolyn.
Alright,
sorry
never
been
here
before.
Hi
Carolyn,
Van
Slyke
from
Microsoft
I've
been
working
with
Jonathan
on
the
Service
Catalog
plugin
and
standalone
binary
I'm
a
little
confused
by
what
you
said
like.
Is
that
something
that
would
be
targeted
towards
somebody
like
what
we've
been
doing
with
Service
Catalog,
where
we're
making
very
specific
commands
that
only
work
with
service
catalog?
Or
is
this
a
different
type
of
plugin
that
you're
thinking?
That
would
need
that
unstructured
access
to
the
results
from
API
calls?
No.
D
I
mean
the
so
the
work
you're
doing
is
more
of
similar
to
the
controller
targeted
focus
where
there
is
a
specific
API.
You
want
to
make
changes
on
and
you're,
not
like
I.
Think.
One
thing
you
need
to
do
is
like
refresh
for
a
list
or
something
and
so
you're,
probably
not
trying
to
create
a
generalized
notion
of
like
relisting
of
things
like
resync,
for,
like
all
sorts
of
different
objects.
D
You're
really
just
focused
on
real
estate
brokers
for
your
API,
using
the
compiled
and
client,
not
the
generic
on
structure
stuff,
but
the
compiled
in
client
I
think
targets
what
you
need.
You
do
have
another
thing
you
need
to
be
careful
about,
which
is
when
you
are,
when
the
client-server,
our
version
skewed,
the
serialization
when
done
through
ghost
rocks,
drops
fields,
and
so
you
can't
do
a
naive,
read,
update
right,
because
when
you
round-trip
the
object,
deserializing
it
and
then
serializing,
it
will
potentially
lose
information.
D
So
we
need
to
also
develop
more
guides
and
possibly
tools
with
some
tooling
around
that
already
to
help
and
there's
essentially
two
techniques
for
dealing
with
it.
The
first
is
that
you
do
not
use
the
naive,
serialization
technique
and
work
against
a
json
map
or
something
another
I
think
proto's
will
soon
support
this,
but
you've
work
against
a
representation
of
the
object
that
doesn't
drop
information.
D
H
D
D
One
thing
of
note
is
like
the
our
test
grid.
We
have
a
lot
of
tests
that
are
not
part
of
the
submit
queue
blocking
suite,
and
yet
we
still
consider
them
important
for
determining
the
health
of
our
code
for
release,
and
so
we
is
very
easy
for
us
to
get
into
a
state
where
those
tests
are
failing
and
if
no
one
looks
at
them.
D
We
go
and
like
release
the
code
anyway,
because
no
one
else
is
looking
at
them
for
us,
and
so
we
probably
want
to
set
up
some
sort
of
more
formalized
responsibility
around
ensuring
those
don't
just
get
broken
and
we
ignore
them.
So
I
thought
just
an
on-call
rotation
might
be
a
simple
way
of
trying
to
sell
all
this
on.
D
B
D
D
People
do
go
in
and
have
to
do
this
front
work,
but
we
don't
really
have
a
structured
way
of
recognizing
them
or
making
sure
that
they
don't
have
to
do
with
all
the
time
in
an
ad
hoc
manner,
but
maybe
eliminating
how
often
you
end
up
looking
at
the
test
grid
to
you
know
one
week
you
quarter
or
something
might
be
a
carrot,
but
yeah
good
point.
We
need
to
figure
that
out
I,
don't
chocolate.
D
D
Okay,
great
so
please,
if
you
haven't,
make
sure
you're
on
the
6
July
mailing
list
and
that
isn't
blocked
by
your
spam
filters.
I
know
it's
easy
to
block
discussion,
forums
and
mailing
lists
and
that
sort
of
thing
but
I'm
planning
on
sending
out
a
doc
that
formalizes
the
points
here
about
our
110
goals.
And
then
hopefully,
anyone
who
owns
them
can
fill
in
the
details
if
they're
missing
and
where
the
specific
work
for
those
items
is
being
tracked.