►
From YouTube: Kubernetes SIG CLI 20211103
Description
Kubernetes SIG CLI Bi-weekly Meeting on November 3, 2021.
Agenda Notes:
https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#heading=h.ckd97cj90dzs
A
A
A
The
kubernetes
steering
committee
is
speaking.
There
are
four
openings,
this
particular
term
and
if
you
are
able,
if
you
are
a
member
and
you
should
have
received
an
email
saying
you
are
a
member,
then-
and
you
have
voting
rights-
please
go
to
that
link
to
vote
for
the
kubernetes
steering
committee.
A
A
A
D
D
G
E
A
So
the
first
topic
is
has
to
do
with
having
moving
coop
control
out
of
the
kubernetes
kubernetes
repository.
I
see
that
nabaroon
is
is
at
the
meeting,
so
we
we
met
mate
eddie
myself.
We
met
with
some
sig
releasers
to
begin
the
process,
and
this
is
going
to
be
a
very
lengthy
process
to
begin
the
process
of
pulling
code
control
out
of
kubernetes
kubernetes
and
into
its
own
repository
and
all
the
steps
that
and
and
what
order
of
those
are
going
to
happen.
A
So
the
only
thing
that
we
wanted
to
I
wanted
to
bring
up
was
that
this
is
happening
to
let
the
rest
of
the
60
line
know
that
this
is
happening,
that
if
you
want
to
participate-
and
if
you
have
ideas,
please
join
us.
So
the
next
steps
are
going
to
be
we're
currently
in
the
brainstorming
phase,
and
we
have
a
link
to
the
notes
of
the
the
initial
meeting
with
sig
release.
A
And
so,
if
you,
if
you
want
to
get
involved,
please
do
get
involved,
and
this
is.
This
process
will
probably
play
out
over
several
releases,
but
we
hope
to
have
the
next
step
is
to
create
a
cap
and
to
get
consensus
on
that
cap
so
that
we
know
exactly
what
those
next
steps
are
going
to
be
so
eddie
or
manche.
Do
you
have
anything
else
to
add
or
does
or
does
anybody
else
want
to
have
any
other
ideas
that
they
want
to
present
on
this
particular
topic.
B
B
But
then
there
is
life,
so
it
might
take
a
little
bit
of
extra
time
than
we
initially
anticipated,
and
on
top
of
that,
there's
a
ton
of
stuff
that
we
already
identified.
That
needs
to
be
solved
like
versioning
to
be
able
to
fully
replace.
If
you
have
some
ideas,
thoughts,
suggestions
we're
more
than
happy
to
hear
from
you
either
during
the
six
cli
calls
or
feel
free
to
reach
out
to
us
on
slack
we're
hoping
to
provide.
B
A
an
update
every
now
and
then
during
the
six
cli
calls
so
we're
hoping
that
this
will
be
slowly
moving
forward,
but
don't
hesitate
to
reach
out
and
either
ask
for
clarifications
or
provide
feedbacks
and
suggestions.
There's
there's
definitely
something
that
we
that
we
will
need
to
improve
over
time
and
all
the
feedback
is
more
than
welcome.
E
H
Navaroon,
I
I'm
driving
from
the
community
side.
I
don't
say
that
I'm
just
driving
it
from
the
secretly
side.
I
want
to
contribute
on
the
cli
side
as
well.
So
I
would
just
ask
anyone
if
you,
if
you
have
any
thoughts,
questions
comments,
concerns
please
look
at
the
notes
in
that
doc.
Go
ahead
and
suggest
your
opinions
tell
us
what
you
see
this
effort.
How
should
it
pan
out
so
that
we
can
also
incorporate
in
our
feedback
cycle
clint?
That
was
a
really
nice
feedback
from
you.
H
D
A
So
I
think
that
feedback
on
how
to
contribute
as
a
new
contributor
would
be
useful.
I
think
that
a
lot
of
these
items
are
going
to
require
a
lot
of
kubernetes
open
source
context,
and
so
it
might
not
be
the
best
thing
to
initially
get
involved
in
with
the
six
cli
I'd
like
to
hear,
but
I'd
like
to
hear
other
what
others
think.
E
Yeah
we're
gonna,
so
one
of
the
big
things
that
we
identified
is
that
we're
gonna
have
to
move
and
figure
out
a
lot
of
testing,
just
in
terms
of
like
the
test
that
we
run
on
cron
job,
the
test
that
we
run
in
every
pull
request
right
now.
The
cube
control
repo
is
not
set
up
to
take
any
prs,
and
so
we're
going
to
have
to
do
a
lot
of
migrations,
especially
in
the
testing
world.
E
So
that
is
an
area
where
we
definitely
could
use
some
help
and
attention
is
kind
of
cleaning
up
our
old
tests.
There's
a
lot
of
there's
honestly
a
lot
of
commands
that
don't
have
tests
and
there's
definitely
functions
and
functionality
that
isn't
tested.
So
that
might
be
a
great
place
for
new
contributors.
If
we
can
identify
those
and
set
people
off
on
a
path
there,
but
yeah
it's
the
release,
tooling
is
going
to
be
pretty
difficult
for
newcomers
to
jump
into.
H
I
think
also,
once
we
chart
out
and
brainstorm
what
exact
steps
we
need
to
take
up,
then
it
would
become
like
pretty
easy
for
new
contributors
to
jump
in,
and
I
eco
like
edits
thoughts
on
the
testing
part.
There
is
a
lot
of
effort
that
is
needed
and
once
we
figure
out
looking
at
previous
context,
then
we
can
write
out
like
what
all
needs
to
be
done,
and
then
we
will
basically
involve
folks
from
the
community
who
want
to
start
contributing
to
6
year
life
or
any
other
parts
of
the
code
base.
A
A
Okay,
great?
So
the
next
item,
I'd
like
to
bring
up,
is
actually
similar
in
format
to
the
previous
item.
In
that
we're
going
to
initiate
we'd
like
to
initiate
the
a
brainstorming
session
and
figure
out
exactly
what
the
steps
are
going
to
be
taken
to
get
the
coupe
control
apply
to
become
server-side
as
default
as
opposed
to
client-side.
A
I
A
I
B
I
B
Maybe
it
would
be
reasonable
to
at
least
say
that
in
the
next
or
in
the
following
release
and
put
a
warning
already
like
a
release
ahead
of
time.
So,
for
example,
if
you
decide
to
push
the
idea
in
124,
it
would
be
nice.
I
think
in
123
to
put
a
warning
already
that,
oh
and
by
the
way
we
will
be
changing,
keep
gotta
apply
over
to
the
survey
by
default
in
next
release
or
into
releases
so
that
there's
at
least
some
knowledge
being
spread
across
users.
I
B
C
Hey
john,
oh
yeah,
so
I
was
talking
with
eddie
at
kubecon
and
he
had
mentioned
that.
Maybe
we
should
have
a
cube,
rc
some
kind
of
rc
file,
but
I
wanted
to
sort
of
ask
and
get
folks
as
thoughts.
So
I
have
many
times
in
the
past
desire
to
have
some
kind
of
kubernetes
client-side
config
that
extends
beyond
my
cubeconfig,
especially
since,
if
you're
using
a
cloud
provider,
you
tend
to
get
two
configs
all
the
time
and
you
know
they're
given
to
you
by
a
provider.
C
So
some
of
the
things
that
have
come
up
for
me
in
the
past,
so
client
grow
credential
plugins,
which
can
be
invoked
through
your
tube
config,
technically
have
a
a
known
security
issue,
which
is
the
fact
that
if
you
downlig
from
an
untrusted
source
and
run
it,
you
can
arbitrarily
execute
any
binary
in
the
machine
and
do
anything
it
wants
with
that
binary.
As
long
as
it's
executable,
it's
not
great
right.
C
So
I
could
imagine
an
allow
list
inside
of
a
global,
rc
style
file
that
says
well,
I
only
expect
to
execute
like
these
five
clis
or
I
only
expect
to
execute
cli
signed
by
my
company's
signing
certificate
whatever
and
the
as
a
for
example.
That
would
prevent
you
from
arbitrarily
executing
bash
on
the
user's
machine
and
running
an
arbitrary
shell
script.
C
Another
thing
that
has
come
to
mind
for
me
recently
is
we're.
Looking
at
extending
the
client
go
credential
plug-in
stuff
to
support
sort
of
like
an
automatic
local
proxy
to
allow
for
authentication
capabilities
beyond
bearer
tokens
and
client
certificates,
in
particular,
to
allow
for
things
like
request,
signing
and
tls
offload
to
external
tls
engines
like
a
yubikey
or
something
clientgo.
C
C
C
E
Yeah
thanks
for
coming
mo.
This
is
something
that
we've
talked
about
a
few
times.
It's
a
prerequisite
for
a
lot
of
other
work.
It
just
hasn't
been
prioritized,
but
if
this
is
something
that
you're
interested
in,
that
could
put
the
fire
under
the
butt
and
we
could
work
together
if
you'd
like
to
get
it
over
the
finish
line
the
what
are
some
of
the
other
things
that
came
up
just
yeah.
The
major
idea
is
just
separating
server
configuration
from
user
configuration
right
and
that's
the
root
of
it.
E
Is
we
don't
cloud
providers
shouldn't
try
to
set
user
permissions
and
random?
You
know
preferences
inside
of
a
cube
config,
so
users
should
be
able
to
specify
that
as
a
global
type
thing
that
gets
applied
to
all
clusters,
so
yeah,
I
don't
think
anyone
will
be
against
the
addition
of
something
like
this.
We
just
haven't
prioritized
it.
B
Yeah
I
I
was
looking
before
this
call
actually
for
the
actual
issue,
because
I
thought
that
we
have
an
issue.
That's
describing
this
problem,
the
only
one
that
I
found
was
about
the
ansi
callers
for
keep
cuddle,
get
commands
and
others
and
that
popped
up
there.
I
remember
that
eddie's
proposal
with
keep
cuddle,
delete
and
dash.
Oh
also
mentioned
the
topic
of
having
the
preferences
I'm
on
board
about
this,
and
we
just
need
someone
else,
someone
who's
interested
in
doing
this
to
push
this
over
it.
D
E
E
C
C
Yeah
I
mean
I
so
I
haven't
asked
the
other
sig
leads
on
this
one,
but
I
suspect
that
I
would
not
get
pushback
on
having
some
kind
of
like
like.
Basically,
the
hope
I
had
was
that
you
know
if
you
don't
have
one
of
these
files,
nothing
changes,
but
once
you
create
one,
you
have
to
tell
us
what
binaries
you
want
arbitrarily
executable
in
some
way,
shape
or
form
right,
like
you're,
basically
by
creating
the
file
you're
opting
into
like
a
better
mode.
C
C
So
I
think
it
would
be
a
pretty
easy
thing
to
document
and
describe,
and
obviously
the
error
messages
would
indicate
very
clearly
that
like
why
it's
upset
and
it's
refusing
to
execute
the
plugin
but
yeah
I
at
the
very
least
I
would
want
segath
to
review
those
aspects
of
it.
I
don't
think
they
necessarily
have
a
strong
opinion
on
the
other
bits.
E
B
E
B
E
B
B
C
C
A
B
So
it's
very
similar
in
the
basic
case,
it's
very
similar
to
keep
cuttle
get
events,
but
on
top
of
that,
you
can
specify
a
particular
resource
that
you
want
to
have
events
for,
so
you
can
think
of
it
as
a
functionality
that
is
similar
to
when
you
do
keep
cuddle
describe,
for
example,
deployments
at
the
bottom
of
the
describe.
There
is
usually
a
a
set
of
events
related
to
this
particular
deployment.
B
Now
you
have
that
ability
to
do
this
just
from
a
single
command.
A
big
shout
out
goes
to
brian,
who
is
very
patient
with
me
on
this
one.
It
took
me
a
while
to
get
to
this
vr,
but
now
that
we
have
the
initial
bits
in
place,
I'm
pretty
confident
that
we
can
make
it
better.
So
give
it
a
try
report,
whatever
you
don't
like
or
or
what
what's
missing
there,
and
we
will
be
gladly
accepting
npr's
improving
that
command.
B
A
F
F
I
think
and
walked
away
with
the
direction
to
try
to
add
a
a
with
type
function
which
would
function
similarly
to
there's
other
with
options
like
with
the
old
credentials,
or
I
can't
remember
what
all
the
function
names
are,
but
I
was
going
to
go,
try
to
add
a
new
with
function
and
when
I
did
that,
I
still
got
stumbled
and
stymied
because
those
functions
are
exposed
on
the
cube,
configs
or
the
config.
What
is
it
called?
Configs?
F
That
wasn't,
you
know,
wasn't
well
received
because
it
was
basically
a
a
second
function.
It
does
exactly
the
same
sort
of
thing
which
you
totally
get.
However,
when
I
looked
at
it
again,
the
only
place
for
me
to
be
able
to
use
this
with
function
is
actually
inside
of
the
config
itself,
so
there
was
no
way
for
me.
F
I
couldn't
find
a
way
at
least
nothing
struck
me
when
I
looked
at
it
a
couple
weeks
ago
to
somehow
access
and
override
those
two
either
one
of
those
two
entities:
either
the
wrap,
config
function
or
the
dialer.
The
only
way
I
could
find
do
it
is
to
actually
expose
these
config
flags.
I
went
back
and
I
looked
at
what
was
in
the
config
flags.
You
know:
is
there
something
that
is
in
there
that
shouldn't
be
in
there
like?
If
I
were
to
provide
a
prototype
that
the
library
would
just
use?
F
Would
that
be
good
enough
and
everything
in
there
is
basic
stuff?
It's
a
bunch
of
strings
and
it's
all
stuff
that
I
either
could
control
in
a
config
file
somehow
or
could
control.
I
just
you
know
just
through
code.
I
just
don't
have
access
to
it,
so
what
I
would
propose
is
to
actually
maybe
eliminate
the
ancillary
function
that
we
created
and
just
jam
them
all
into
one
and
make
it
just
the
one
function
that
just
takes
the
cube,
configs
or
the
config
flags.
F
B
B
E
B
F
F
F
F
F
F
B
A
G
So
I
just
kind
of
wanted
to
bring
that
up
and
get
a
heads
up
there
that
this
is
kind
of
on
the
horizon
and
if
there
are
thoughts
or
lessons
learned
from
like
the
the
the
dry
run,
migration
or
anything
like
that
that
I
should
know
about
in
beginning
to
introduce
the
the
client-side
stuff
to
this
next
release
and
there's
a
cap
out
there.
That
kind
of
just
says
that
doesn't
really
say
anything
about
the
the
command
line
other
than
we
want
to
eventually
deprecate
client
side
and
so
I'll.
G
G
Yeah,
so
a
lot
of
the
a
lot
of
people
don't
like
it,
I
think,
is
one
of
the
main
reasons.
The
issue
is
that
there's
so
I
mentioned
I
talked
about
this
in
the
in
the
cat,
but
basically
you
you
know
you
need
to
have
various
client
side
or
you
know
various
implementations
for
for
every
different
client,
and
this
lets
us
have.
You
know
a
single
implementation
on
the
server.
G
G
G
D
H
Is
that
going
to
affect
how
oc
diff
works?
Because
my
understanding
is
that
it
actually
uses
the
patching
mechanism
of
the
client-side
client
essentially
to
generate
diffs?
And
I
know
like
there's
some
issues
with
that
right
now
and
that
it
doesn't
always
show
in
the
diff
what
you're?
What
you're?
Actually
looking
for?
Because
it's
trying
to
generate
a
patch
not
showing
you
the
difference
and
there's
a
there's.
A
slight
subtle
difference
between
the
two
operations.
G
G
Yeah,
that's
that's
a
good
question,
so
I
think
so
so
currently
we
can
there's
you
know.
Diff
has
a
server-side
and
client-side
option
right
and-
and
so
I
imagine
that
the
validation
will
kind
of
work
in
this,
like
server-side
validation,
should
provide
the
same
guarantees
as
server-side
diff.
What
it
means
on
on
client-side
diff
is,
is
I'm
not
totally
sure.
B
I
I'm
not
100
sure
that
the
client-side
validation
has
anything
to
do
with
this,
because,
if
I
remember
correctly,
the
client-side
validation
is
basically,
we
are
creating
open
api
schema
and
we
are
applying
open
api
schema
validation,
rules
onto
the
resources
that
you
are
trying
to
submit.
So
it
is
only
create
and
couple
opera
or
apply,
probably
not
100
sure
about
this,
but
I
I
don't
think
yes,
it
creates
patches
depending
whether
it's
on
a
client
side
or
it's
a
server
side
in
case.
B
The
solution
was
simple,
just
pass
validate
false
and
it
will
work
just
fine.
I
think
it
it
improved
over
the
past
time.
I
think
antoine
did
a
lot
of
work
with
open
api
bits
to
make
the
the
client
side
violation
more
reliable,
but
I
still
think
that
it
might
be
beneficial
for
clients
to
be
able
to
validate
without
sending
this
over
to
the
server
so
yeah.
D
Yeah,
that
makes
sense
I
wanted
to
make
earlier
in,
like
defaulting
instead
of
removing.
Is
that
I,
I
suspect,
well
it
yeah.
I
know
that
there
are
a
lot
of
folks
that
use
this
in
context
that
don't
have
server
access,
and
is
this
like
the
best
validation
ever
is
it?
Is
it
going
to
be
as
good
as
server
side
like
probably
not,
but
it's
still
a
very
useful
thing
to
be
able
to
do
to
be
able
to
to
run
those
validations
without
access
to
any
particular
server.
G
A
G
A
A
A
E
Yeah
these
will
fly
real,
quick,
so
mark
our
resident
awesome.
Auto
completion
wizard
wants
to
start
working
on
a
way
for
cube
cuddle
plug-ins
to
be
able
to
provide
completion
for
those
that
don't
know
cube.
Color
plug-ins
are
independent
binaries.
That
kind
of
get
called
by
cube
control
and
so
mark
has
like
a
phase
one
sample
pr
up.
I
imagine
this
is
going
to
have
some
broader
implications.
E
E
E
E
Some
folks
from
the
community
have
volunteered
to
create
more
of
a
template
of
repository,
so
this
would
allow
a
cube
control,
plug-in
author
to
come
by
click,
create
from
this
template
and
provide
them
a
repo
scaffold
it
out
with
all
their
bits
to
write
their
plugin
for
fun
and
joy.
I'm
not
sure
if
we
need
a
new
repo,
but
I
wouldn't
be
opposed
to
them.
Spicing
up
the
current
sample
plug-in.
B
B
I
think
it's
better
to
to
not
have
this
many
stuff
but
better
to
to
keep
it
simple.
Alternatively,
we
can
probably
create
subdirectories
for
different
plugins.
It
doesn't
mean
that
it
has
to
be
just
one.
It
can
have
multiple
like
this
is
the
bird.
This
is
the
bear
bare
bones,
cube,
pedal
plug-in,
or
this
is
a
little
bit
more
featureful,
or
this
is
a
full-blown
cubecar
plug-in
with
with
colors
and
rainbows,
and
I
don't
know
what
else
you
can
think
of.
E
Yeah
the
so
what
they
specifically
want
to
add
is
like
there's
no
make
file
in
that
plug-in
repo,
so
they
were
like
we
can
provide
a
make
file,
so
it
it
looks
like
a
bunch
of
like
very
straightforward,
simple
stuff.
We
don't
obviously
have
to
take
all
like
the
go,
releaser
and
other
bits,
but
I
just
I
wanted
to
and
you're
wagging
your
finger.