►
From YouTube: Kubernetes SIG CLI 20180912
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
afternoon,
good
evening,
wherever
you
are
welcome
to
the
sixth
seal,
a
meeting
for
September
12th
I
will
begin
with
a
few
announcements.
We
basically
a
zoom
number
change
coming
up.
It
was
supposed
to
potentially
have
happened
by
now,
but
apologize
for
the
delay
on
that.
It
will
happen
within
the
upcoming
weeks
and
we
will
send
an
announcement
when
that
does
happen.
Your
calendar
will
also
change
so
that
the
link
you
click
on
your
calendar
entry
will
now
take
you
when
that
happens.
It'll
take
you
to
the
new
meeting
number.
A
What
this
means
is
that
the
sample
seal
I
plug
in
now
serves
as
a
blueprint
for
anybody
to
create
a
plugin
and
go.
It
serves
as
a
blueprint
for
anybody
to
use
the
CLA
runtime
if
they
create
their
plugin
and
go.
You
know
to
essentially
use
those
utilities
to
to
aid
them
in
the
plugin
creation
process.
A
If
you
have
any
questions,
feel
free
to
reach
out
to
any
of
us
in
the
6cl
a
channel,
and
with
that
said,
there
is
a
112th,
unplanned
release
date
of
September
25th.
The
date
is
the
same
as
was
announced
last
time,
and
it
has
not
changed
and
yeah
basic.
What
that
means
is
that
master
will
reopen
for
113
in
September
19,
and
we
have
a
one
told
retrospective
and
113
planning
during
the
next
meeting.
We
will
be
reaching
out
to
Paris
for
that
as
well.
A
A
A
The
main
thing
people
want
is
they
want
to
either
filter
to
only
watch
certain
events
for
a
given
resource,
for
example,
they
want
to
know
essentially
when
a
specific
event
happens,
and
then
they
want
to
take
action.
When
that
event
happens,
there
were
a
few
overlapping
requests
with
the
wait
functionality
that
was
introduced
recently
to
keep
control.
A
So
people
wanted
to
watch
events
until
they
were
deleted
or
watch
events
for
a
resource
until
that
resource
was
created,
and
so
there's
some
discussion
as
to
whether
or
not
this
that
logic
entirely
the
lungs
within
the
wait
command,
so
that
feel
free
to
add
comments
to
the
Google
Doc.
Let
me
know
if
you
can't
access
it
and
I
will
give
you
access
to
the
Google
Doc,
but
yeah
the
main
gist
behind
this.
This
this
proposal
or
semi
proposal
is
to
at
least
get
ourselves
thinking.
A
You
know
voice
to
improve
the
watch
functionality.
So
a
a
major
feature
we
could
consider
for
this
could
be
to
either
add
a
new
command
or
perhaps
introduce
it
via
a
plug-in
functionality.
But
if
we
do
go
the
route
of
adding
a
new
command,
we
can
have
a
command
specifically
for
watch
logic
that
essentially
has
filtering
baked
in
you
know,
as
well
as
essentially
cross
functionality
with
a
Q
control
weight
command.
A
A
With
the
watch
functionality
in
mind,
we
have
been
tackling
or
we've
set
our
sights
to
tackle.
You
know
updating
that
functionality
as
well,
so
that
it
works
with
server-side
printing,
so
the
the
watch
functionality
that
currently
exists
with
the
get
commanding
Q
control.
It's
currently
the
last
piece
of
a
cube
control.
Yet
that
does
not
work
with
server-side
printing.
A
So
so
far
sorting
has
been
updated,
as
well
as
any
other
main
remaining
pieces,
but
watch
still
relies
on
the
old
code
code
path
that
essentially
involves
looking
at
a
handle
of
three
resource
and
so
I
believe
for
the
next
release.
We
should
make
a
focus
to
essentially
update
that
remaining
piece
so
that
we
no
longer
have
or
where
we
have
one
less
dependency
on
non
service
at
printing
and
and
anything
associated
with
that,
with
that,
I
will
give
the
floor
to
Shawn
for
the
next
topic
regarding
cube
control,
extraction
from
the
communities
credits.
B
So
there's
there's
not
really
much
to
update.
We
when
we
created
the
spreadsheet,
describing
the
remaining
items
necessary
to
pull
coop
cuddle
out
of
core.
We
realized
that
there
were
some
dependencies
that
were
we're
very
sticky
and
very
difficult
to
extract
specifically
they're
still
the
printing
and
there's
a
package
printing,
which
is
has
a
lot
of
dependencies
with
transitive
dependencies
within
core,
as
well
as
many
files
which
depend
on
it,
as
well
as
the
testing
package
and
the
test
API.
So
those
those
dependencies
in
particular
looked
insuperable
and
very
difficult
to
to
snip.
B
C
A
C
To
be
able
to
extract
ourselves
from
the
main
core
people,
I'm
inclined
to
copy
the
printers
as
external
versions
to
keep
CTL
so
that
at
some
point
of
time
we
will
have
the
split
the
internals
versions
of
the.
There
is
a
risk
that
for
some
time
it
might
happen
there
will
be
a
mismatch
between
the
printers.
So
we
just
need
to
ensure
that
both
the
printers
are
actually
returning
the
same
results,
but
that
will
at
least
gives
us
a
starting
point
for
the
extractions,
because
currently
the
printers
is
one
of
the
biggest
issues.
C
The
remaining
of
the
remaining
issues
are
somewhat
manageable.
The
printers
is
the
biggest
offender
as
of
today,
so
we
will
eventually
switch
the
service
I
printing
everywhere
and
everything,
and
so
basically
the
code.
The
printers,
the
external
printers
that
we
could
extend
to
the
separate
repo
would
be
part
of
code
that
will
just
be
removed
when
we
switch
to
the
server
side
entirely
and
when
we
remove
the
printing
stack
entirely
from
keep
CTO.
But
until
at
that
point
my
proposal
is
to
create
the
externals
live,
would
live
with
them
for
a
couple
of
releases.
A
Yeah
I
think
I
think
that's
a
reasonable,
reasonable
band-aid
for
the
time
being,
especially
since
it
doesn't
block
a
you
know,
majority
of
the
majority
of
the
of
the
conflicts,
I
guess
from
separating
you
from
the
main
from
the
core
Rico,
so
I
would
say
so
long
as
we
have.
You
know
some
mechanism
in
place
to
either
keep
the
external
copies
for
the
print
handlers
from
diverging
from
the
internal
ones,
or
you
know,
maybe
freeze
any
updates
to
both
so
that
we
don't
diverge
in
any
way.
I'd
be
okay.
A
With
this,
you
know
so
long
as
we're
conscious
of
the
fact
that
it
does.
It
is
a
temporary
measure
and
we
would
need
to
get
rid
of
the
external
copies
of
the
print
handlers.
You
know
as
soon
as
we
can
as
soon
as
we're
able
to
essentially
and
like
you
said,
resorts
of
server-side
printing
for
the
client-side
and
then
leave
the
internal
print
handlers
exclusively
to
to
the
server
I.
C
Think
that
we
have
an
integration
test
in
place
for
ensuring
that
there's
no
difference
between
server-side,
printing
and
regular
printing,
so
creating
a
similar
one
will
actually
just
this
test
that
we
already
have
in
place
should
ensure
that
we
don't
diverge,
because
if
we
do
diverge,
that
means
that
that
something
broke
and
there
and
the
test
should
fail.
If
the
test
doesn't
fail,
we
need
to
improve
the
current
test
for
the
server-side
printing
to
ensure
that
whatever
is
returned
by
the
server
is
the
same
as
you
would
do
with
a
regular
gypsy
to
printing.
C
D
C
D
C
Yeah,
that's
that's,
basically,
the
main,
the
main
gist
out.
Eventually,
it
will
go
away,
but
we
just
need
to
ensure
that
if
somebody
touches
the
surface,
our
printing,
the
the
external
printers
that
we
have
in
keep
CTL-
has
to
match
whatever
the
server
is
printing,
so
that
there's
no
divergent
both
cases
and.
A
In
this
case,
we
basically
have
you
know
a
collection
of
internal
handlers
at
the
server
uses,
but
we
need
those
to
be
external
for
the
client
to
use
it
without.
You
know
resorting
to
the
pending
on
on
server-side
code,
so
rather
than
ven
during
it
and
having
the
client
still
depend
upon
server-side
code
due
to
internal.
Do
donating
internal
versions
of
objects,
the
the
easiest
way
to
to
sort
of
have
this
band-aid
apply.
A
C
D
So
VIN
during
is
copying
into
a
directory
called
vendor
right.
That's
the
only
thing
it
is
right
or
yeah,
I
think
that's
the
directory
right
and
it's
having
it
will
manage
the
dependency
for
you
so
like
why?
Wouldn't
we
just
copy
it
into
that
folder
instead
of
copying
it
into
a
different
folder,
where
it's
not
obvious
that
it's
coming
from
someplace
else.
D
C
Had
a
discussion
about
the
vendor
egg
thing:
some
time
ago,
I
Fair
America
David
laid
out
significant
problems
with
yeah
with
it.
You
know,
honestly,
from
dealing
with
the
vendors
that
we
do
it
in
openshift
yeah,
as
if
it's
possible
to
leave
the
vendor
in
behind.
It's
always
a
good
idea.
So
if
we
can
go
with
that,
and
especially
that
we
went
all
the
way
up
to
this
point
where
the
majority
of
commands
is
working
with
the
client
go
and
the
external
libraries
that
we
have
available,
it
would
be
in
a
way.
E
D
By
default
on
currently
I
think
if
we
copy
it
over,
we
have
to
freeze
it.
We
can't
like
that
manually,
you
have
someone
doing
dips
between
files
and
updating
them
and
and
just
to
clarify
I
was
asking
about
ven
during
the
whole
kubernetes
repo
I
was
my
I
guess.
My
question
is
like:
if
you
just
want
the
internal
API
package
right,
like
one
way
of
getting
that
is
ven
during
it
and
pruning
everything
else
from
kubernetes
kubernetes,
in
which
case
it
lives.
D
D
C
A
Yeah
so
I
think
I
to
essentially
piggyback
on
on
on
macho
here.
I.
Think
a
risk
of
entering
does
end
up
being
that
it
is
the
case
that
we
could
end
up
injuring
more
packages
than
we
expected
because
you
know
either
you
have
a
connection
you
can't
break,
or
you
have
helpers
that
come
along
with
with
along
with
API
packages
like
we've
seen,
you
know,
with
some
work,
we've
been
doing
an
origin
for
example,
and
so
yes,
I
think
I
would
rather
try
to
save.
A
You
know
save
ourselves
from
potential
hassle
of
entering
more
than
we
signed
up
to
vendor
in
the
first
place,
but
also
you
know,
it'd
be
a
quick
and
more
long-term
solution.
I
think
to
to
have
cute
control
already
switched
to
using
client
go
and
the
API
package,
and
you
know
the
extracting.
It
should
just
be.
You
know,
taking
the
CLI
pieces
and
that's
it.
A
F
Yeah,
so
I
want
to
talk
about
QC,
GL
d
f--,
it's
a
feature
that
I
want
to
promote
in
better
in
the
next
series
in
113.
It's
been
alpha,
so
why
now
I
think
since
1
9
or
something
the
reason
why
it's
not
being
promoted
before?
Is
that
one?
F
So
the
goal
is
to
be
able
to
do
cube.
C
TLD,
if
my
configuration
files
and
that's
going
to
show
you
exactly
what's
gonna
happen
to
your
configuration
object
on
the
server
before
you
can
do
a
place.
So,
for
example,
when
you
want
to
create
an
object,
you're
going
to
do
cube,
CTL
F,
my
chief
my-my-my
fire,
and
it's
gonna
show
you
what
object
is
gonna
be
created
on
the
server
as
it's
gonna
be
modified
by
the
admission
shine.
It's
not
just
like
show
numbers
and
the
clients.
It's
gonna,
be
the
full
object.
F
So
you'll
see
the
defaults,
you
see
everything
and
if
you
change
once
the
subject
has
been
created.
If
you
change
your
field
and
you
do
a
diff
again,
it's
gonna
show
you
just
the
field
that
has
been
changed,
so
that's
pretty
convenient.
For
example,
if
you
update
the
EMH
version
and
you're
on
diff
again,
you
see
just
two
lines,
one
being
you
used
to
have
social,
a
and
now
your
version
B.
So
that's
gonna
be
super
convenient
and
that's
the
interface
that
we're
gonna
keep.
So
it's
gonna
be
just
cube.
F
F
C
F
F
Don't
we're
not
going
to
support
booting,
yet
I
think
intraday.
It's
gonna
be
useful
to
have
pruning,
for
example,
so
that
if
a
filer
has
disappeared,
then
you
see
it
being
removed
right
now
we
don't
have
that
so
new
fans
are
gonna,
be
shown
as
new
fans
and
changes
as
changes
but
dd-did
files
of
just
you
know.
D
A
D
A
D
Great
well,
thanks
for
getting
that
over
I.
Don't
think
I
had
a
whole
lot
to
say
on
this
other
than
that
for
area
of
api's.
We
have
way
of
saying
for
column
printing,
just
like
here's.
The
list
of
fields
like
so
cou
control
already
supports
printing
a
resource
as
a
list
of
columns
by
providing
the
list
of
columns
as
a
flag,
and
so
it
makes
it
look
like
the
normal
wide
format,
but
you
customize
it
declaratively,
instead
of
imperative
ly
or
something
else.
So
we
support
this
for
our
grid.
D
C
C
There
is
a
spec
that
allows
you
to
decide
what
will
be
printed
for
the
surface,
I
printing.
So
there
is
a
field
inside
of
the
CID
specification
that
says
additional
columns
by
default,
every
CR
they
will
print
name
and
a
creation
timestamp.
If
you
specify
the
additional
columns,
which
is
the
name
of
the
field,
the
Jason,
the
Jason
path
inside
of
your
CRD
and
the
serger
that
I
can't
remember
off
top
of
my
head
and
when
you
do
that
the
surface
high
print
ink
will
read.
C
C
Think
two
weeks
ago,
because
oh
I
know
was
a
third
field.
The
third
field
is
a
priority
and
we
had
a
discussion
two
weeks
ago
about
two
or
three
weeks
four
weeks
ago
about
the
priority,
because
the
priority
is
an
integer
currently
about
it
works
as
a
boolean
field,
meaning
that
if
you
specify
a
field
with
a
zero,
it
will
get
printed
by
default.
If
you
specify
anything
bigger
than
zero,
then
it
will
only
get
printed
if
you
specify
the
white
output.
C
D
D
C
D
C
B
C
C
A
B
E
B
D
E
B
D
Idea
of
once
a
month,
thank
you
ever
every
ever
week
might
be
a
bit.
I
mean
it's
it's
fine,
but
like
every
month
it
would
be
nice
it'd
be
great,
like
we
could
have
three
chickens
per
release
of
like
your
stuff,
that's
happening.
You
know,
I'll,
probably
make
writing
the
release,
notes
a
little
easier
because
we'll
go
in
like
having
I,
don't
know
familiarize
ourselves
with
the
notes
along
the
way.
C
Bugfixes
go
into
one
bucket
major
issue,
major
changes
features,
majority
of
them
should
be
tracked
by
us
during
the
planning,
and
then
we
drove,
but
there
are
some
changes
that
are
also
done
by
other
six
and
we
get
to
track
them.
Definitely
and
then
Michael
Angeles,
just
yeah
not
sure
what
will
fall
into
the
third
back
pocket,
but
I
do
hope,
Thea,
and
we
can
definitely
remove
to
start
with
everything
that
touches
the
generated
stuff.
I,
don't
care
about
those
at
all.
I
know
that
there's
like
at
least
a
couple.
D
C
A
C
A
A
A
D
One
thing
maybe
that
I've
I
wouldn't
I,
wouldn't
say
it's
a
progress
status,
but
maybe
just
to
follow
up
a
coup
Connie.
You
know
machi
and
I
had
some
conversations
about,
creates
and
there's
something
I've
been
thinking
about
more
and
more
and
trying
to
carve
out
the
time
to
prototype
I'm
planning
on
doing
outside
of
the
core
repo,
like
just
an
Indian
prototype
of
a
command
like
a
generic
crate
command
and
as
I
thought
about
it.
More
I
think
it's
probably
not
just
limited
to
create,
like
I,
think,
there's
a
lot
of
commands.
D
We
have
that
operate
on
a
single
resource
and
effectively
what
they
do
is
they
take
either
a
file
or
a
set
of
flags
and
use
those
to
generate
a
request
body
and
then
take
the
response
and
then
put
it
then
format,
the
output
and
and
while
for
some
cases
like
you,
probably
need
a
fully
Turing
complete,
complete
language
to
implement
them.
I
think
you
can
probably
get
75%
the
way
there.
C
Yeah,
if
I
remember
correctly,
we
discussed
create
incentive
to
start
with,
because
there
were
like
the
simplest
to
go
with.
Do
you
think
you
could
present
this
topic
in
more
depth
with
especially
the
product
I'm,
very
curious
about
it
during
one
of
the
next
meetings?
Maybe
not
the
next
one,
because
I'm
hoping
to
do
the
planning
and
rich
wrote
the
next
one,
but
whether
than
the
the
next
offered
that
one
yeah.
C
D
D
So
maybe
once
I
have
a
demo,
let's
say
sometime
in
the
next
four
four
six
weeks,
I'll
give
an
in-depth
presentation
on
what
I'm
thinking
yeah.
That's
perfect!
That's
perfect!
I.