►
From YouTube: Kubernetes SIG CLI 20181024
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
Look
it's
a
word
for
a
fourth
60
to
our
6c,
a
CLI
meeting
good
morning
good
afternoon
good
evening,
depending
on
where
you
are
I.
Don't
have
any
particular
announcements
for
today
other
than
the
Future
freeze
started.
That
basically
means
that
no
new
features
are
allowed
to
land
for
for
113
release
put
bugs
and
the
ones
that
we
already
have
open
are
fine
to
work
on
the
test
grade.
B
A
Cool
thanks
I've
noticed
that
there's
one
issue
that
was
called
out
to
60
Li
I
think
I
was
earlier
today
or
yesterday
by
Josh,
Burris
and
I've
noticed
that
Jordan
open
a
PR
to
add
some
additional
debugging,
but
I
think
I
might
be
related
to
what
you're
saying
so
yeah
and
efficient.
That
is
it.
This
is
quite
old
issue
that
it's
been
there
for,
since
May
or
even
sooner
okay.
A
We
have
the
testing
playbook
pretty
packed
over
for
a
feast
the
couple
next
month,
but
just
a
reminder.
If
you
want
to
fly
there,
all
of
our
tests
on
cold
person
whose
responsibility
is
to
have
a
look
at
the
test
grid
and
ensure
that
if
there
is
a
flake
appearing
that
is
assigned
to
our
sick
to
respond
open,
an
issue
or
eventually
paying
the
necessary
person
or
try
charging
the
issue
and
providing
with
a
possible
solution.
A
A
Let's
jump
to
the
main
topics
of
the
agenda
today,
the
first
topic
that
I
wanted
to
bring
up
is
promoting
plug-in
mechanism
to
beta.
So
as
part
of
the
effort
that
we
over
that
we
went
over
the
past
release,
which
is
112,
we
rewrote
the
plug-in
mechanism,
so
that
is
currently
similar
to
what
git
git
does,
which
basically
means,
if
you
have
a
binary
in
your
path,
whether
cubes
ETL
prefix,
that
binary
binary
will
be
picked
as
a
cube,
CTO,
plugin
and
execute
it.
A
So
far,
we
haven't
seen
any
major
issues
with
the
new
mechanism
and
the
ones
that
we
that
we've
been
assigned
to
are
already
fixed.
Even
back
ported
back
to
112,
the
majority
of
the
the
problems
were
were
filled
by
the
cap
team.
So
thank
you
very
much
for
that.
That
was
very
helpful
to
to
fix
the
other
day
issues
over
there.
A
Currently
we're
we're
thinking
about
promoting
this
mechanism
to
beta
to
be
more
widely
promoted,
and,
additionally,
both
one
and
I
will
be
talking
about
the
mechanism
during
cube
con
in
Seattle.
But
if
you
know
about
any
issues,
problems
concerns
whatever
they
want
to.
Let
us
know
feel
free
to
ping
me
or
who,
on
or
eventually,
if
you
have
any
doubt
with
whether
we
should
not
promote
this
mechanized
debate.
I
yes
yet
feel
free
to
to
speak
up
now,
or
it
will
happen
in
the
upcoming
weeks.
C
A
The
Crypt
lagging
manager
was
presented.
The
stake
meetings
some
time
ago
and
I
was
actually
when
we
were
working
on
the
new
locking
mechanism
percent
mechanism.
I
remember
talking
with
with
them
back
then
that
is,
we
will
be
changing
the
the
the
plugins
over
to
the
new
mechanism.
I
would
really
like
to
see
them
to
switch
over
to
the
new
mechanism
as
well
per
se.
The
idea
of
a
plugin
manager
and
completely
fine
with
the
idea
I
did
not
try
the
newest
version.
A
A
C
A
I
did
not
see
or
hear
from
him
over
the
past
readings,
so
I'm,
assuming
that
everything
is
working,
just
fine,
because
I
think
was
doing
that
filled
in
the
the
issues,
at
least
at
the
beginning
of
more
towards
the
end
of
112
release,
I
think
somewhere
around
beta
or
even
one
of
the
release
candidates,
and
we
addressed
his
issues
from
there.
I
remember
that
they
were
updating.
D
To
be
invoked
when
the
correct
path
is,
you
know,
executed
by
a
user,
so
an
example
of
this
you
know
could
be.
Maybe
someone
wants
to
extend
the
other
plug-in
command
to
add
more
overview
of
users
plugins.
So
in
this
case,
in
cube
control,
we
would
essentially
annotate
the
plug-in
command
in
the
commentry,
and
then
the
plug-in
mechanism
would
see.
For
example,
when
cube
control,
plug-in
foo
is
being
invoked
and
foo
is
a
plug-in,
executable
executable
that
exists.
D
It
would
see
that
the
plug-in
command
already
exists,
but
it's
annotated
accordingly
and
dos
allows
it
to
be
extended,
and
so
the
qto
plug-in
to
executive
all
would
be
I
love
to
run.
In
that
sense,
we
would
not
want
to
do
this
with
every
command.
So
commands,
like
you
can
short
get,
for
example,
would
get
very
messy
if
we
did
allow
them
to
be
extended.
So
one
reason
I
can
think
for
this
is
because
you
know
maybe
people
would
choose
to
you
know.
D
D
So
I
think
to
at
least
start
up
with
this
improved
behavior.
It
would
be
nice
to
to
have
a
very
limited
number
of
official
commands.
You
know
that
wouldn't
suffer
from
from
debugging
hell,
for
example,
to
allow
to
be
extended.
A
good
point
that
I
saw
made
by
amat
actually
on
the
mailing
list
discussing
delete
behavior
recently
was
that
if
we
choose
to
allow
plugins
to
completely
override
existing
commands,
we
could
potentially
run
into
the
issue
where
you
know.
D
Maybe
a
malicious
script
could
put
plugins
in
a
user
spot
and
then
plugins,
but
in
depth
or
essentially,
users
would
end
up
accidentally
or
unknowingly
executing
a
plug-in
executable
when
they
don't
mean
to
when
they
execute
on
normal
to
control
command.
So
there's
a
few
there's
a
few
things
to
consider
before
we
we
allow,
perhaps
users
to
completely
overshadowed
existing
commands,
I.
Think
it's
good
to
begin
discussion
on
this
now.
I'll
start
a
Google
Doc,
where
we
can
possibly
highlight
all
of
the
things
to
consider
regarding
this
but
yeah
for
now.
I.
D
Think
a
good
starting
point
is
to
select
a
few
amount
of
commands
and
I'll
potentially
drafting
a
doc
where
we
can
reach
consensus
on
which
commands
it
should,
you
know,
be
included.
As
far
as
part
of
you
know,
the
extensibility
update
for
the
next
release
with
that
being
said,
are
there
any
questions?
Concerns
comments
well,.
C
D
D
A
But
even
with
that,
what
will
happen
if
I,
if
I
name
my
plugin,
get
check
out,
does
it
mean
that
the
kid
check
out
will
stop
working
or
get
will
pick
up
the
yeah
my
check
out
plugin
or
it
will
complain
that
get
check
out?
Is
that
known
and
will
just
silently
ignore
the
fact
or
have
you
ever
tried
this?
This
year's
case.
D
A
A
Not
I'm
not
opposed
to
or
but
at
the
same
time,
I'm
not
too
too
happy
with
this
approach.
So
it
would
be
good
to
get
a
strong
decision,
whether
we
want
to
move
in
one
or
the
other
direction,
but
just
gathering
feedback
from
what
people
want
to
do
with
plugins,
as
well
as
what
other
plug-in
Omega
doesn't
provide
and.
D
I
saw
ant
one
just
come
inside,
so
it
is
that
this
is
with
regards
to
get
plugins.
So
just
get
ignore
your
plugin.
If
you
attempt
to
ok
so
yes
I,
it
looks
like
it
does
behave.
Similarly,
Muslims
I
think
that
the
only
immediate
use
case
I
can
think
of
for
allowing
a
command
to
be
overridden
is
essentially
in
the
case
of
a
package
manager
like
route
where
maybe
they
want
to
take
advantage
of
the
plug-in.
C
D
And
maybe
add
to
it
for
their
specific
use
cases
so
I
think
you
know
if
there's
no
position
to
just
having
the
plug-in
command
being
expendable
from
the
get-go
and
nothing
else.
You
know
that
would
also
be
a
valid
case.
Something
had
support.
This
is
also
not
to
imply
that
we
will
never
reconsider
this
position
to
extend
other
commands
in
the
future.
I
think
it's
it's
good
to
revisit
this.
D
So,
where
we
left
off
at
server-side
printing
was
essentially,
we
switched
the
get
command
to
by
default.
Request
table
objects
from
the
server.
What
this
means
is
that
the
server
tells
the
client
you
know
how
to
print
human
readable
output
instead
of
the
client
having
to
know
how
to
print
in
order
for
each
resource.
D
What
we
did
not
do,
as
part
of
this
update,
is
implement
that
same
behavior
as
part
of
watching
resources.
So,
although
the
normal
cube
controlled
yet
command
is
able
to
handle
a
table
response
from
the
server
adding
the
watch
flag
to
the
command
makes
it
fall
back
to
the
previous
behavior
of
you
know,
having
the
client
look
up
a
hard-coded
list
of
handlers
to
know
how
to
print
human
or
developer
for
a
resource.
D
Since
the
overall
goal
is
to
you
know
completely
eliminate
any
of
that
old
behavior
from
to
control,
then
it
makes
sense
that
we
address
this
by
having
the
watch
behavior.
If
queue
control
get
work
with
table
objects,
the
only
limitation
we
currently
have
that
I've
seen
you
know
for
for
updating
the
watch.
Behavior
is
that
watch
depends
on
events
being
emitted
from
the
server,
and
these
events
include
external
object
versions.
D
You
know
in
them,
so
when
you're
watching
a
pod,
for
example,
if
the
watch
behavior
of
a
few
control
get
notes
to
reprint
that
object
whenever
it
receives
an
event
from
the
server
containing
the
MP
nerd
object,
because
the
client
you
know
needs
to
rely
on
the
server
to
tell
it.
What
specifically
to
print
about
that
object,
then
we
would
need
for
the
server
to
emit
events
with
table
objects
in
them
as
well.
D
D
A
A
A
Of
course,
there
are
tons
of
helpers
and
they
see
a
lie
like
them
cup,
completions,
copy-paste,
backward
search
to
replay
the
same
commands,
etc,
etc.
That
make
the
accidental
execution
of
commands
a
slightly,
simpler
and
and
then
at
the
same
time,
I
realize
that
the
majority
of
the
Linux
servers
that
I've
worked
with
have
an
alias
for
the
remove
command,
which
is
which
ensures
that
every
single
time
you're
removing
resources
as
a
root
user.
E
E
A
A
Additionally,
that
will
unnecessarily
require
the
delete
command
to
build
the
tree
of
the
resources
that
are
present
in
the
namespace,
which
might
be
only
a
couple
of
resources,
but
it
might
also
be
significantly
big
namespace
with
huge
amount
of
resources.
So
I
would
really
like
to
avoid
that
part
of
yeah
of
your
proposal.
E
A
A
A
A
D
Yeah,
okay,
I
love
some
thoughts
on
the
on
the
mailing
list
thread
mainly
concerning
the
script,
ability
and
the
president
that
this
might
set
for
the
future.
So
you
know
it
might
not
seem
like
it
may
be
like
a
big
deal
now,
but
this
you
know
this
might
introduce
the
notion
that
it
might
be
okay
to
add
interactive
behavior
here
and
there.
C
D
Not
just
for
the
leaflet,
but
for
any
commands.
You
know
the
future,
whether
it's
a
command,
theater
or
an
entirely
new
command,
and
so
I
think
that
this,
like
you,
said
if
it
might
make
it
clumsy
for
people
that
depend
on
scripts,
for
example,
that
all
of
a
sudden
they
have
to
sort
of
tread
carefully
when
writing
their
scripts,
because
they
might
use
a
flag
that
causes
interactive,
behavior
or
not
so
I.
D
Think
at
the
very
least,
we
should
try
to
see
if
there's
a
non
interactive
illusion
to
preventing
accidental
deletion
of
namespace
all
any
resource,
but
namespaces
in
particular,
in
this
case
I,
think
an
idea
that
was
presented
a
while
back
that
involved.
You
know
having
an
annotation
serve
as
a
safeguard
for
accidental
deletion.
I
think
that's
that's
something
worth
revisiting,
so
you
know
for
those
unfamiliar
with
the
idea
that
the
main
gist
is
that
you
would
have
a
specific
annotation
on
a
resource
that
you,
the
namespace
admin,
for
example
the
place
on
that
resource.
D
And
then
you
know
when
deleting
time
came
about,
if
your
resource
had
that
annotation
and
then
the
server
would
reject
deletion
of
that
resource,
be
it
a
namespace
or
not.
Unless
you
know
either
you
removed
that
annotation
or
in
this
case
I
guess
we
could.
We
could
have
a
specific
not
in
an
interactive
flag
for
the
delete
command,
such
as
confirmed,
which
removes
that
annotation,
perhaps
before
sending
the
object
government
regulation.
If.
A
I,
remember
correctly,
the
float
that
we
suggested
for
what
you
said
was
that
you
would
have
a
admission.
Plugin
I
will
be
looking
at
the
label
or
annotation,
and
if
it
is
present,
it
would
reject
every
single
delete
operation
which
would
require
you
to
manually,
remove
the
annotation,
and
only
then
we
replay
the
delete
operation.
That
would
be
a
two-step
process
that
can
be
easily
implemented
currently
with
the
mechanism,
because
we
have
the
the
web
hook,
admission
plugins
that
allow
you
to
hook
an
into
into,
for
example,
deletion
of
all
resources.
A
D
A
Right
but
the,
but
then
that
data
that
forces
you
to
some
conventions
around
annotation,
which
is
somewhat
not
necessarily
desirable
and
yeah,
and
it
would
also
require
you
to
write
the
diskette.
The
second
part,
which
is
the
admission
and
that's
something
that
we
don't
want
to
do
as
part
of
six
e
Li
Shan,
was
quoting
the
UNIX
manual
and
basically
lower
case.
I
is
prompt
for
before
every
removal
there's
also
uppercase
I,
which
promise
before
removing
ball
more
than
three
files
or
when
removing
recursively
yeah.
A
So
the
question
is
how
others
feel
with
with
this
exception,
because,
honestly,
that
would
be
the
only
place
where
we
would
allow
their
interactive
to
happen
yet
still.
At
the
same
time,
there
are
possible
solutions
in
place
already
that
can
ensure
that
we
don't
need
to
do
the
interactive
stuff
and
leave
the
interactive
part
only
for
the.
C
A
That's
that's
off
the
table.
We
cannot
change
the
default
behavior,
it's
that's!
If
we,
if
we
are
going
to
introduce,
it
will
be
similar
to
the
dish,
I
and
a
removal
tool
from
the
UNIX,
but
so
it
can
so
that
you,
as
a
cluster
admin,
can
have
a
knowledge
for
the
cube
CTL
delete
command,
which
will
always
ensure
that
you
are
running
with
delete
with
with
that
I,
for
example,
but
that
that
cannot
be
a
default
option,
because
we
will
break
the
backwards
compatibility.
A
Okay,
let's
so,
basically
folks,
if
you
have
any
objections,
feel
free
to
respond
to
the
mailing
list
6ui
and
raise
your
concerns.
Why
you
think
we
should
not
add
interactive
I'm
currently
somewhere
in
the
middle
of
whether
I
do
want
to
support
this
idea
or
I.
Don't
I
can
basically
defend
both
ideas.
A
F
Yeah
here
find
it
and
on
the
email
list,
but
basically
this
is
the
proposal
that
we
had.
It
is
that
had
full
stack,
so
they'll
be
a
b6
IP
address
and
a
v4
IP
address
associated
with
each
pot.
So
I
see
the
changes
were
being
liked
them.
They
get
quads
and
describe
quads.
You
get
in
point
will
now
have
multiple
IP
addresses
and
we're
looking
at
having
a
comma
delimited.
A
I
didn't
look
at
your
proposal
right
after
you
said
it
out
over
to
the
60
Li
mailing
list
and
overall
I
didn't
have
any
objections.
The
proposal
that
you
put
together
the
proposed
changes
in
the
the
Sigma
in
a
cube,
CTL,
describers
and
printers
seemed
reasonable
to
me.
So
I
did
not
have
any
objections.
Let
me
quickly
scroll
to
where
that
was.
F
C
F
C
A
A
It
is
just
expanding
the
current
field
with
the
additional
data,
depending
on
whether
you're
working
in
dual
stack
or
whether
you're
working
in
that
before
or
v6,
which
basically
means
you
would
have
extended
output
for
IP
column
and
built
in
and
and
and
get
command,
as
well
as
it
described
command,
which
would
give
you
the
IPS,
based
on
the
stack
that
you
have
enabled,
whether
both
or
one
or
the
other.
Is
that
correct.
F
Yeah
right
there's
only
one
if
you
only
have
one
IP
and
you
don't
get
the
one
display
and
then
I
do
have
a
question,
though,
on
the
screen
on
the
describe
pod.
You
know
if
they're
shows
I
need
with
this.
Would
you
prefer
that
this
replaces
the
current
IP
or
should
we
display,
like
the
current
IP,
which
would
just
have
one
preferred
IP
and
then
another
column
that
had
IPS?
That's
plural,.
F
F
F
A
C
C
So
printing
is
going
to
be
a
thorny
issue,
in
fact,
I'm
hoping
that
ma
che
and
Wan
can
stick
around
for
like
two
or
three
minutes
just
so
that
we
could
connect
about
the
describers,
but
but
I
think
that
we've
actually
made
exceptional
progress.
There
are
two
to
three
other
issues.
Besides
the
printing,
one
is
interrupts
and
Clayton
actually
has
a
PR
that
he
he's
moving
that
functionality
into
its
own
repo,
actually
air
into
the
util
repo.
C
If
I
remember
correctly,
there
there's
a
different
approach
that
I
took
was
just
to
pull
it
into
coop
cuddle,
but
I.
Think
Clayton's
is
much
more
general
and
helpful
to
the
rest
of
the
community.
There's
there
is
a
there's
something
about
our
Beck
reconciliation,
which
is
actually
pretty
thorny
and
it
has
to
do
with
a
the
are
back.
C
C
And
it's
not
clear
to
me
now
how
we're
going
to
address
that
one
but
like
I,
said
I,
think
we've
made
great
progress
and
I
think
it's
going
to
be
kind
of
just
a
lot
of
work,
trying
to
to
get
printing
to
depend
more
on
external
versions
versus
internal
versions,
in
order
to
be
able
to
move
move
forward
on
that
remaining
large
issue.
But
but
I'd
like
to
talk
to
you
guys
later,
if
that's
okay,
sure.