►
From YouTube: Kubernetes SIG CLI 20180718
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,
good
afternoon,
good
evening,
depending
on
where
you
are,
this
is
another
60
Li
meeting
our
event
agenda
is
packed
today.
So
let's
get
this
thing
going
right
away.
A
quick
announcement.
Future
freeze
is
on
July
31st
from
what
I
just
checked.
So,
if
you're
working
on
a
big
feature
for
111
release,
make
sure
to
create
a
an
issue
in
the
futures
repo,
and
please
link
that
one
to
the
planning
notes
from
a
month
ago
and
then
from
what
I
was
looking
just
into
the
release
notes
the
code.
A
B
A
That's
it
okay,
perfect
Phil
will
be
taking
over
the
next
two
weeks
of
taking
over
our
looking
after
our
test
skirt.
In
the
meantime,
I
encourage
every
single
one
of
you
to
sign
up
for
the
lists,
I
added
the
addition,
the
additional
dates,
so
it's
basically
the
entire
August
that
is
free
to
sign
up
it's
fun
to
be
the
test.
A
Uncle
you'll
learn
a
lot
and
I'm,
hoping
that
within
the
next
two
weeks,
we'll
be
able
to
create
a
short
video
how
to
how
to
be
a
a
test
on-call.
What
are
the
duties?
What
are
the
tools,
how
to
work
with
them?
Properly?
I
discussed
this
topic
with
Sean
a
couple
weeks
ago
and
he
promised
to
to
do
a
short
tutorial.
A
So,
if
you're
intimidated
by
being
doing
this
for
the
first
time,
don't
worry,
we
will
definitely
help
you
to
get
started
and,
and,
as
always,
you
can
always
reach
out
to
us
on
the
six
Eli
slack
and
ask
for
help
we'll
be
more
than
happy
to
help
with
any
any
questions
you
might
have.
Ok,
let's
then
jump
to
the
topics.
D
This
means
that
currently
in
crib
CTL,
when
you
do
dry
on
you'll
end
up
creating
the
request,
but
the
request
is
not
gonna
be
century
the
server
and
we're
trying
to
go
further
by
sending
a
request
to
the
server
with
some
specific
parameters,
the
request
is
gonna
be
processed,
but
not
persisted.
The
result
is
not
going
to
be
persisted.
The
goal
is
to
have
a
much
more
significant
driver
in
the
end,
because
you
have
the
admission
chain.
D
Somebody
day,
marriage
is
performed
on
the
server,
so
you
get
a
much
better
picture
of
what
could
have
happened
as
opposed
to
gypsy
GL
doing
what
it
knows,
which
is
fairly
limited.
So
we
need
to
will
updating
the
server
and
now
we'll
have
to
update
the
client
cube
CTL
to
maybe
use
this
feature
so
I'm,
suggesting
that
we
replace
the
current
trial
and
flag
to
use
this
server-side
our
trial
and
feature
as
Jordan
mentioned
it's.
D
It
can
be
useful
if
you
don't
have
a
server
to
not
talk
to
the
server
so
I'm,
also
suggesting
our
one
has
been
suggesting.
Thank
you
very
much
for
this
lecture
and
by
the
way
that
we
use
the
local
flag.
If
you
don't
want
to
talk
to
the
server
I
think
that'd
be
consistent
with
what
we
do
in
general,
in
cube,
cgl.
A
D
E
We
would
want
to
okay,
we
would
want
to
capture
all
of
all
of
the
commands
that
currently
have
dry
run.
Flags
I
think
it's
primarily
ones
that
do
creates,
though
we
should
do
a
sweet,
so
the
first
thing
would
be
to
find
out
all
the
current
commands
that
have
dry
run
and
then
make
sure
they
all
support
local
so
that
people
can
start
using
those
together.
E
B
E
E
A
My
question
is:
what
is
the
target
release
for
the
server-side
dry
run,
and
we
could
definitely
start
with,
even
in
112,
in
the
release
notes
to
mention
the
distinction
between
for
the
future
changes
about
the
local
and
dry
run.
To
start
with,
we
could
start
with
warnings
in
all
of
the
commands
that
are
currently
using
dry
run.
A
D
So,
in
the
meantime,
we're
probably
gonna
have
this
so
well,
try
one
which
is
gonna.
Allow
you
to
test
the
server
drone
eventually
managed
to
don't
you
not
flip,
but
replace
the
dry
run
with
the
cilantro
I.
Don't
I
think
it's
sort
of
too
early.
The
plan
is
to
have
it
in
112.
Yes,
alpha,
but
I
think
it's
too
early
to
tell
people
that
we're
going
to
use
a
different
option.
E
We
can
that's
why
they're
saying
if
we,
if
we
encourage
them
to
start
saving,
that's
local
if
they
don't
want
to
talk
to
the
server
at
all,
it
should
make
sure
that
works
in
112
and
have
people
announce
that
they
should
start
doing
that,
and
that
gives
us
in
a
good
place,
two
or
three
releases
in
the
futures
of
winter.
Whenever
we
want
to
the
switch
to
server
side,
we
have
already
announced
and
been
telling
people
they
should
use
local
if
they
don't
want
to
so
that
doesn't
require
any
server
side
changes
at
all.
Yeah.
F
A
E
What
we're
discussing
I
would
expect
it
to
end
the
112
release,
notes
and
in
every
command
that
currently
takes
dry
run.
If
you
specify
a
dry
run
and
don't
specify
local,
you
would
get
a
warning
by
local
to
avoid
it
talking
to
the
server
in
future
releases.
This
will
do
a
server-side
driver.
Somebody.
D
D
E
The
bar
is
lower
when
we're
adding
in
new
places
if
it
existing
for
existing
things
and
we're
talking
about
changing
it
from
being
local
to
remote,
but
the
output
format
stays
the
same
then,
once
we're
confident
that
the
server
has
support
for
it
and
we've
publicized
the
need
to
set
that
local
for
several
releases.
If
that's
what
people
want
and
that's,
okay,
if
we're
talking
about
changing
the
output
format,
that
gets
trickier,
so
we
just
need.
We
just
need
to
enumerate
where
it
exists.
E
F
F
That's
the
only
reason,
I'm
staffing
but
I
guess
we
should
like.
We
should
figure
out
if
users
aren't
using
it
directly
like
our
users
using
it
directly,
are
they
using
it
through
some
other
command
right,
like
in
the
case
of
a
diff
command,
for
instance,
users
aren't
specifying
the
dry
run
flag
directly
right
and
in
those
cases
we
have
a
lot
more
flexibility
and
we
don't
really
care
how
it's
exposed.
F
I'm
like
like
when
I
expose
you
as
a
flag
to
the
user,
we're
exposing
it
through
a
command
so
like
if,
for
instance,
depending
on
what
our
needs
are
right
or
where
our
focus
is,
we
might
not
be
in
any
urgent
rush
to
flip
over
existing
dry
run
commands
right.
We
might
not
be
getting
a
lot
of
end-user
value
out
of
that.
You
should
figure
that
out
the.
E
F
F
They
want
local,
so
a
space,
bang
local
he's,
not
surprising
I
mean
in
that
case
you
actually
want
I
know
it
depends
right
like
I
guess
it
depends
on
the
user,
and
maybe
you
have
a
different
use
case
in
mind,
but
I.
Imagine
if
you're
doing
dry
run
local
to
generate
config.
You
don't
want
the
defaults
in
there
because
you
might.
E
E
B
A
C
So
the
first
option
could
be
that
we
want
users
to
be
able
to
pull
watch
to
only
include
delete
events,
for
example,
for
an
object
being
launched,
as
the
second
option
could
be,
for
example,
only
watch
the
changes
to
an
object
until
the
objects
deleted,
and
then
a
third
option
could
be
to
watch
any
creation
and
change
events
to
a
given
set
of
food
resources.
So
I'll
go
ahead
and
make
up
a
google
talk
for
this
to
to
sort
of
put
what
is
requested
more
concrete
manner,
but
I
figure.
C
A
C
Actions
yeah,
so
that's
also
part
of
the
discussion,
I
kind
of
ordered
to
generate
with
this.
Basically,
how
would
we,
as
a
user,
specify
the
restrictions
were
in
place
and
lunch?
Is
it
worth
modifying
the
current
flag
or
making
different
flags
were
different,
essential
for
different
cases,
and
then
yes,
would
this
be
restricted
to
the
get
to?
Nor
would
this
be
something
that
would
work
for
us
any
other
areas
that
support
watching.
C
E
C
A
A
The
semantics
of
wait
are
slightly
different.
There.
You
specify
eight
conditions
that
you
are
expecting
to
happen
at
some
point
in
time,
doesn't
matter
whether
you're
waiting
for
creation
deletion
or
something
else
besides,
we
created
the
way
to
command
as
an
experimental,
so
we
can
freely
modify
the
the
current
functionality
as
we
wish,
assuming
that
we
are
improving
the
user
capabilities
for
for
using
the
correct,
so
in
that
particular
case,
I
would
just
focus
them
again.
That's
that
I
think
it's
significantly
big
for
for
one
thing:
okay,.
C
A
G
G
Okay,
so
I
hope
you
all
can
see
the
presentation
just
a
few
slides.
So
what
I'm
trying
to
present
is
true,
true
as
a
cube,
CTL,
plugin
manager,
which
builds
on
top
of
the
current
existing
cheap
CTL
plugin
system.
Why
we
have
done
this?
Is
we
have
taken
a
look
at
the
current
plugin
system
and
we
found
that,
even
though
it
existed
for
a
long
time,
there
are
not
a
lot
of
plugins,
it's
very
difficult
to
find
plugins,
it's
also
so
like
you,
you
can
search
get
up.
G
G
There
is
SV
cat
which
bundles
an
installer,
but
you
still
have
to
install
a
speaker
so
there's
like
no
automated
and
stable
way
of
installing
plugins
and
how
we
are
trying
to
tackle
this
problem
is
by
two
things:
discovery
and
lifecycle
management
of
plugins.
So
we
want
to
give
developers
a
platform.
So
there's
no
discovery.
We
wanted
to
give
developers
a
platform
where
they
can
publish
their
plugins
and
give
them
a
nightgown
yeah
like
a
simple
system,
so
we
call
this
platform
index.
G
This
is
like
where
all
the
definitions
of
all
the
plugins
are
león,
and
and
on
top
of
that
we
can
build
a
search.
This
is
for
the
user,
so
they
can
find
plugins,
Java,
plugins
and
then
move
on
to
the
lifecycle
management,
so
installation
we
download
the
plugin
we
check
against
the
platform
is
if
the
plugin
is
compatible,
we
extract
it.
We
can
verify
it
against
the
hash
and
then
move
it
into
its
location
and
try
to
be
atomic
doing
that,
and
then
we
also
have
upgrades.
So
we
whenever
we
have
updates
in
the
platform.
G
So
whenever,
with
updates
in
the
index,
we
can
detect
this
and
then
update
the
current
plugin
and
should
complete
the
life
cycle
of
removal.
All
right,
I
have
a
small
demo
to
show
you
this.
So
first
of
all,
I've
currently
no
plugins
installed,
and
then
we
can
install
the
can
install
crew
this
when
this
goes
into
Community
Services
optional.
But
this
is
the
current
state.
So
currently
crew
is
managing
itself.
Crew
is
a
plugin
sort
of
like
the
cruise,
the
plugin
and
it's
managed
by
crew.
G
G
We
can
also
specify
what
search
for
the
whole
search
experience
is
fuzzy,
alright
and
then
we
can
find
install
plugin.
G
We
have
decided
for
CS
short
CS,
sorta
supplied
in
which
basically
just
shows
the
clock,
the
current
cluster
certificate,
and
then,
when
we
run
again,
we
see
the
CSS
orders
finally
installed
and
we
can
run
it
yeah
so
that
that
basically
is
the
whole
experience
and
when
we
list
all
installed
crew
plugins,
we
can
see
that
we
have
see
I
start
installed,
and
this
is
like
the
current
yeah
version
of
a
plugin,
and
then
we
can
also
operate
our
plugins.
This
obviously
won't
work
because
we
don't
have
any
updates
to
the
index
yeah
so
far.
A
A
Okay,
I'm,
not
hearing
any
other,
so
I'll
go
ahead
with
mine.
My
first
and
biggest
question
is
something
that
you
also
mentioned
in
your
proposal,
which
means
that
the
crew
plugin
manager
is
and
will
be
a
problematic
with
the
new
plugin
mechanisms
that
we
are
currently
working
on,
yeah,
which
is
supposed
to
land
for
112.
How
are
you,
how
are
you
planning
to
address
this?
One
piece.
G
So
it
was
yeah
it.
We
knew
that
there
will
be
a
new
approach
to
installing
plugins,
so
we
designed
crew
to
be
not
affected
by
that.
So
let
me
show
you
two
slides,
so
this
is
currently
the
plugins
back
and
we
have
no
indicator
of
plug-in
so
plug-in
descriptor
files.
So
when
I'm
stoned
to
installing
plugins,
we
basically
move
operations
which
can
move
fryer
files
from
the
download
directory
to
the
installation
directory
with
the
get
approach
we
can.
G
A
But
if
you
are
able
to
address
the
problems
of
not
conflicting
the
mechanism
with
the
new
plugin
mechanism
that
we're
hoping
to
to
become
beta
and,
at
some
point
in
time,
the
officially
supported
plug-in
mechanism
and
entirely
drop
the
old
mechanisms
that
that's
very
important.
My
other
question
is
with
regards
to
searching
and
discovering
the
plugins.
A
G
F
Well,
yeah
I.
Imagine
that
would
be
like
something
that
we
want
one
in
the
first
request
because,
like
for
instance,
different
cloud
like
we
wouldn't
we
don't
want
the
main
repository
of
plugins
to
have
like
maybe
cloud
provider,
specific
plugins,
essentially
right
or
I
mean
maybe
we
do,
but
maybe
we
don't
or
there's
very
specific
plug-ins
for
niche
areas
and
but
folks
will
want
to
provide
those
plugins.
And
so
we
want
a
way
of
funding
those
together.
Well,.
A
To
start
with,
we
don't
have
anything
such
as
a
central
keep
CTO
plugins
repo
to
start
with
and
I'm
I'm,
not
sure
that
we
want
to
be
in
the
business
of
maintaining
one
so
definitely
having
a
configurable
list
of
plugin
index.
Whatever
you
want
to
call
it.
Plugin
repo
index
is
definitely
a
must
for
this,
because
this
will,
aside
from
moving
the
responsibility
for
our
maintaining
such
a
repo
from
us
to
some
other
folks.
A
A
Probably
a
different
topic
that
that
I
haven't
figured
out
yet
there
there
might
be
some
problems
with
the
plug-in
manager.
That
I
would
that's
that's
one
of
the
reason
that
I
was
somehow
trying
not
to
go
into
the
business
of
managing
plugins
beforehand,
and
I've
mentioned
that
several
weeks
ago
that
when
we
try
to
solve
this
problem,
there
will
be
issues
with
several
several
plugins
of
the
same
name.
A
Honestly
I'm,
not
sure
what
would
be
the
best
solution.
You
might
prepend
a
some
kind
of
a
repo
alias
to
the
plugins
from
installation
point
of
view.
It
should
be
pretty
easy,
but
I
think
the
biggest
issue
might
be
when
it
comes
to
usability,
because
how
should
it
be
able
to
discover
that
they're,
both
under
the
same
name
which
one
the
user
should
be
using?
A
E
A
C
E
Is
that
me
better?
Yes,
okay!
So
if
like
there's
the
the
way,
I
plug-in
things
of
itself
internally
right,
like
it's
ID
or
something,
and
if
you
have
a
registry,
then
that
plugins
would
be
in
the
registry
by
ID-
and
you
can
do
saying
things
like
it
has
to
be
a
reverse
DNS
name,
you
control
so
like
Amazon,
comm
or
Google,
calm
or
fubar,
calm
or
whatever.
E
E
And
so
if
the
user
wants
to
interact
with
AWS
and
Google
Cloud,
they
can
pull
down
both
of
those
plugins
but
then
say
actually
I
want
to
call
this
one
AWS
login
and
that
when
Google
login
so
like
the
part
of
the
power
of
the
simplicity
of
the
model,
where
the
plug-in
is
just
a
command,
you
run
that
user
can
rename
it
right
and
it
can
have
some
set
of
names
that
it
wants
to
contribute.
But
the
control
is
ultimately
the
users.
H
A
H
E
That,
and,
and
even
even
the
registries
of
the
registry
format,
is
basically
here's
a
here's,
a
JSON
blob,
that
is
a
list
of
descriptors
and
URLs,
that
you
can
grab
the
artifact
at
like
the
simpler,
the
better
and
if
the
thing
that
cute
control
ultimately
consumes,
which
is
what
we're
I
think
we're
trying
to
get
to
like
with
the
new
model,
is
just
a
really
simple.
Like
look
for
a
binary
with
this
name
or
an
executable
with
this
name,
yeah.
H
I
think
the
more
complicated
piece
in
this
is
cross-platform
capability
of
how
do
people
build
plugins
that
can
work
in
a
cross-platform
manner.
We
already
have
a
problem
where
we
were
very,
very
linux
heavy,
but
we
also
have
to
do
with
Mac
and
we
have
to
deal
with
and
there
you
might
write
it
as
a
shell
script
right
for
to
get
those
environments,
but
what
happens
when
you're,
bringing
something
like
Windows,
which
half
of
developers
use
and
lots
of
kubernetes
folks
do
it.
So
then,
now
you
can't
use
shell
commands
anymore.
I
G
We
allow
different
platforms
for
one
plugin
as
target
platforms,
so
so
we
have
a
list
of
platforms
and
those
can
be
matched
against
the
platform
Yoker
you
want
to
install
to
with
simple
humanities,
neighbor
selectors.
So
whenever
you
on
the
platform,
Mac,
OS
or
Linux,
this
will
install
from
this
location
and
we'll
use
those
move
semantics
to
move
the
files
and
the
one
is
for
the
windows
platforms.
G
A
Know
the
pleasure
answers
is
perfect
and
I
totally
agree.
It's
it's
reasonable,
but
we
still
will
have
to
solve
the
problem
of
the
the
name,
uniqueness
and
solving
that
as
Jordan
proposed
and
I.
Think
that's,
it's
probably
the
easiest
solution
to
let
the
user
decide
the
name
or
rename
the
plugin
or
it's
for
his
or
her
own
requirements
or
our
own.
C
I
Yes,
actually
I
think
I'm
done
here.
I
think
what
are
your
plug,
my
plug-in
manager?
You
know
ships
with
QC
tail
or
you
know
independently,
as
it
is
today
and
I
think
it
should
come
with
a
central
repository
out
of
the
box
and
the
reason
I
say
it
is.
This
is
because
I've
been
developing
some
plugins
myself,
I
had
about
I,
think
seven
or
eight
plugins
right
now,
and
if
people
go
ahead
and
you
know
tap
into
I,
don't
know
Google
plug-in
repo
or
Brad
hat
linux
plug-in
repo.
I
Then
this
kind
of
gives
no
opportunity
for
ping
the
plug-in.
So
we
discovered
and
the
lack
of
a
let's
say
you
know
blessed
default,
repository
kind
of
prevents
that
and
the
video
of
plug-in
managers
like
you
get
or
Braille,
is
that
there's
the
blast
manager
and
then
it
works
out
of
the
box
and
then
yeah.
You
have
the
discovery
mechanism
there.
Otherwise
we're
gonna
be
we're
gonna,
be
going
back
to
the
kid
hub
world.
You
know
people
will
dig
up
plugins
from
github
and
then
try
using
that.
I
E
I
think
my
main
concerns
would
be
like
landrush.
If
there's
an
official
central
repo,
you
have
a
land
rush
for
preferred
names
and
then
also
like
you
talked
about
like
a
blessed
or
curated
set
like
who-who
is
blessing
and
who
is
curating
and
what?
What
are
the
statements
being
made
about
things
in
that
central
repo
like
have
those
been
bedded?
Are
they
gonna
steal
your
credentials?
Are
they
gonna?
You
know
like
who
is
responsible,
I
guess
for
maintaining
that
yeah.
H
I
mean
you
get
into
the
whole
world
of
operating
a
central
repository
and
everything
that
goes
along
with
it,
which
is
a
non
small
amount
of
work
for
somebody
to
take
on
not
so
much
running
it,
but
all
of
the
logistics
of
to
give
people
the
ability
to
delete
things.
If
not,
how
do
they
then
version
things
in
it?
How
do
you
deal
with
a
security
report
on
one
of
these
things?
Do
you
take
it
down?
How
do
you
do
you
know?
What
do
you
do?
How
do
you
run?
H
You
know
your
terms
and
conditions
kinda.
You
know
good
you're
running
a
public
service,
all
the
operational
things
and
you
end
up
going
down
a
long
path.
I'll
tell
you
what
helm
is
doing
because
helm
is
a
package
manager
and
kind
of
has
to
do
with
the
same
thing,
with
charts
and
we're
looking
at
actually
switching
to
a
distributed
search,
so
you've
got
something
that's
distributed,
but
people
could
register
them
if
you're
not
familiar,
there's
something
called
packages.
It's
a
PHP
repository
for
finding
packages,
I'll
drop
in
a
URL.
H
H
Even
has
some
niceties
about
tying
with
github
to
show
you
stars
and
things
like
that,
but
at
the
end
of
the
day,
it's
really
just
a
distributed,
search
targeted
at
PHP
packages,
and
it
knows
how
to
find
them,
and
so
that
may
be
an
easier
way
because
then
you
don't
have
the
onus
on
it.
Yep
yeah
folks
can
distribute
them
initially
and
then
later
on.
If
you
want
to
layer
in
a
search
to
make
it
easier,
that
could
be
a
possibility
too.
H
You
know
because,
at
the
end
of
the
day,
we
all
have
to
deal
with
private
repositories
where
we've
got
our
own
company's
specific
plugins
and
things
of
that
nature.
So
everything
can't
be
public.
So
how
do
we
deal
with
maybe
doing
a
little
public
a
little
easy
search?
But
yet
allowing
for
distributed
setup?
Because
we
are
in
a
distributed
world.
C
A
D
So
this
is
just
a
quick
announcement
that
we
have
a
sort
of
pre.
Alpha
version
of
the
side,
apply
ready
in
the
branch,
so
we're
amending
the
south
side
apply
which
is
sort
of
similar
to
what
we
have
in
terms
of
gel
but
on
the
server
we're
implementing
this
in
a
branch
in
the
kubernetes
repo,
and
we
have
sort
of
a
alpha
version
right
now.
That
is
ready
for
the
cube
CTL
specific
belt.
D
You
can
create
objects,
I
mean
I
want
to
focus
on
this
year.
I
part
of
these,
but
but
we
have
some
sort
of
thing
working,
don't
expect
to
demo
I've
been
too
lazy
to
prepare
a
demo,
but
I'll
send
an
email
with
the
the
various
feature
that
I've
working
today
and
happy
to
talk
about
that.
Mostly
I
want
to
give
an
update
on
the
status
of
this
feature.
A
You
know,
we've
been
talking
like
you've,
been
talking
about
the
server
side
up
for
a
couple
of
months
already
and
being
able
to
see
that
in
action
would
be
pretty
awesome,
I
think
for
for
all
of
us.
So
if
you
could
find
a
couple
minutes
and
do
a
short
email,
one
example
how
this
works
with
a
short
summary,
what
is
currently
possible?
What
are
the
secret
goals
that
would
be.
That
would
be
very
appreciated.
Absolutely
awesome,
I
think
the
next
topic.