►
From YouTube: Kubernetes SIG CLI 20220323
Description
Kubernetes SIG CLI bi-weekly meeting on March 23, 20222.
Meeting Agenda/Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=kix.alt3br5igshx
A
Recording
to
the
cloud
so
welcome
to
march
23rd's
edition
of
the
6th
cli
biweekly
meeting,
I'm
sean
sullivan.
I
am
your
host
and
why
don't
we
get
into
announcements?
The
first
announcement
is
that
next
week
we
have
the
code
freeze
for
the
124
release,
so
it
would
behoove
you
to
if
you
have
anything
that
you
need
to
get
in
by
124
to
do
it
sooner
rather
than
later,
it's
already
starting
to
back
up.
B
Since
I'm
representing
here
both
sexyli
and
segapps,
and
I
was
talking
with
eddie
because
we've
been
bouncing
this
idea
for
quite
a
while
now
that
we
want
to
grow
the
group
of
people
who
can
work,
review
and
approve
code
for
for
six
cli.
I
I
brought
in
sick
apps
as
well
on
into
the
picture
and
we
figure
out,
and
we
wrote
it
down
as
well
in
the
in
the
annual
reports
that
we
will
be
kicking
it
off.
So
we're
hoping
to
to
get
it
initially
organized
on
monday.
B
B
A
C
Yeah,
I
put
the
next
these
two
yeah.
They,
if
you
have
tests
failing
on
a
pr
specifically
integration
or
verify
tests,
that's
not
something
in
your
pr
most
likely,
and
that
was
just
a
broken
upgrade
for
the
the
image
that
runs
your
test,
so
there's
more
in
the
sig
testing
channel.
If
you
come
across
that
and
the
I
put
a
call,
I
put
this
call
for
reviewers
on
here.
C
On
top
of
the
the
the
the
club
that
match
I
mentioned
on
monday,
we
got
a
lot
of
open
prs,
so
anyone
who
is
interested
in
doing
reviews
or
becoming
a
reviewer
or
dipping
your
toes,
please
feel
free
to
dive
into
any
pr
that
needs
a
review
or
is
not
approved
and
give
it
a
once
over,
and
you
know
then
tag
us
for
approval.
Just
give
it
a
shot
like
you
have
nothing
wrong,
nothing
to
lose,
there's
no
harm.
You
can
absolutely
do
by
reviewing
some
pr's
best
way.
C
A
Great,
so
why
don't
we
move
on
to
introductions?
So
at
this
point
in
the
meeting
we'd
like
those
who
haven't
been
to
our
meeting
or
we
haven't,
met
before
to
introduce
themselves,
if
you,
if
you
want
to
so
this
is
a
opportunity
to
to
to
raise
your
profile
and
for
the
rest
of
the
of
your
colleagues
in
kubernetes
to
to
actually
meet
you.
C
D
F
C
A
G
Yeah,
so
I
mentioned
a
couple
in
a
couple
of
previous
meetings
that
I've
been
working
on
getting
server-side
validation
into
beta
this
cycle,
and
so
that
would
replace
the
client-side
validation
that
we're
doing
and
there's
basically,
two
pr's
left
on
that
one
that
actually
does
the
server
set
one
that
actually
does
the
the
switch
in
cube
control
from
from
defaulting
from
using
client-side
validation
to
defaulting
to
using
server-side
validation.
If
it's
available
on
the
server
that
pr
is
ready
for
review
and
yeah
just
really
need
some
eyes
on
it.
G
I
would
love
to
get
anyone
from
six
cli
to
take
a
look
at
it
and
then
there's
a
follow-up
pr
on
that
that
I'm
still
working
on
now
to
get
to
fix.
Basically,
all
the
ete
tests
that
break
when
you
don't
have
kube
control
defaulting
to
using
client-side
validation
anymore.
So
that's
still
a
work
in
progress,
but
it
would
make
things
go
a
lot
faster.
If
that
first
one
could
get
some
reviewers.
I've
got
jordan
leggett
reviewing
the
first
one,
but
would
also
love
to
have
eyes
from
6
eli.
D
C
F
Yes,
okay,
so
if
I
do
temp,
so
I
have
my
own
build
of
cube
ctl
with
the
proposed
pr
and
then,
if
I,
if
I
try
to
complete,
I
now
get
plugins,
so
I
have
certain
plugins
installed.
Crew
is
one
of
them,
so
the
first
aspect
of
the
the
framework
is
to
complete
plug-in
names.
Okay,
but
once
you
have
plug-in
names
you
want
to
know
what
the
plug-in
can
do,
so
you
can
continue
and
then
you
get
completion
from
the
plug-in
crew
itself.
So
then
it
it
supports.
F
F
So
if
we
talk
about
shell
completion,
it's
only
the
plugin
that
can
know
what
the
completions
choices
can
be.
Okay,
that's
criteria!
Well
that
criteria
fundamental
number.
One
stop
me!
If
you
don't
agree
another
one
that
it
took
us
a
while
to
realize
that
we
can't
ask
the
plug-in
binary
to
give
us
completion
choices,
because
if
you
call
that
binary-
and
it
doesn't
know
anything
about
completions-
it
might
just
run
right
and
then
it's
going
to
do
what
a
plug-in
does
and
when
you
want
to
obtain
completion
choices.
You
don't
want.
F
F
F
F
F
So
then
I
I
looked
at
how
does
git
provide
plug-in
completion
and
from
what
I
could
gather
this
I
I
was,
I
could
barely
find
any
documentation,
but
for
what
I
understood
is
that
if
I
wrote
if
I
write
a
git
plugin
and
I
want
to
have
completion
shell
completion,
I
need
to
provide
a
bash
function.
That's
called
underscore
git
and
my
plugin
name
so
similar
pattern
and
then
the
completion
script,
the
bash
completion
script
will
call
that
function
automatically
and
then
get
what
the
completion
choices
are.
F
F
You
want
in
the
cubesat
will
call
the
executable
and
get
the
completions
we'd
use
a
standard
name,
so
the
proposal
says
cubectl
underscore
complete,
then
the
plugin
name,
so
a
slight
difference
from
the
plugin
executable
and
instead
of
somehow
loading
the
function
and
again
I
I
might
be
wrong
in
what
I
found
out,
but
we
would
cube.
Ctl
would
simply
ask
to
put
this
new
this
new
executable
on
the
path.
So
that's
how
the
user
would
and
we
could
automate
that.
F
Finally,
this
whole
thing
is
not
magic
right,
so
it's
just
a
framework.
You
still
need
each
plugin
to
provide.
That's
that
executable,
that
script
to
say
what
the
completions
are.
The
good
news
is
cobra
supports
that
out
of
the
box,
and
I
checked
and
more
than
half
the
plugins
on
crew
use
cobra,
which
is
a
nice
surprise,
so
it
could
be
quite
easy
through
crew.
We're
gonna
need
some
support
as
well.
So
I
mentioned
that,
and
I
forgot
his
name-
I'm
sorry,
the
crew
main
maintainer.
F
F
So
last
slide.
If
you
guys
want
to
use
it,
you
build
your
own
ctl
cube
ctl
using
the
pr
you
optionally,
download
the
plugin
I
just
mentioned,
and
you
ask
it
to
generate
scripts
for
you
and
then
that's
it.
You
can
just
so
we
can
try
live
if
you'd,
like.
I
don't
know
how
much
time
I
have.
If
you
can
name
me
any
plugin
that
you
like,
I
can
install
it
as
long
as
it's
on
crew
and
then
we
can
try
to
just
run
it.
F
F
B
So
probably
that
would
be
my
only
request
before
landing
this
functionality
so
that
we
have
it
documented
properly
in
the
form
of
a
cap
and
then
inside
of
the
pieces
where
I
can't
remember.
But
I
do
remember
that
we
have
some
docs
describing
this
mechanism.
It
would
be
also
good
to
to
update
it
to
update
to
update
them
as
well,
but
in
general
yeah.
I
I'm
in
a
full
support.
B
F
A
F
F
A
A
H
H
A
H
So
this
is
a
research
study
that
I
did
with
nick
mitchell
over
the
summer
as
part
of
an
internship
with
ibm
and
their
hybrid
cloud
research
group,
and
we
are
looking
at
how
different
tool
data
modalities
like
cli's
or
ides
impact
development
tasks
or
just
if
people
use
different
ones
to
complete
different
development
tasks.
And
this
is
the
main
binding
from
our
study.
So
we're
look
and
this
kind
of
encompasses
our
research
questions.
H
So
we
have
here
cli
id
web
console
and
we
gave
an
option
to
write
in
another,
and
this
was
a
survey
that
we
did,
and
these
are
the
results
from
that
and
we
found
that
a
lot
of
the
developers
prefer
clis
across
these
different
task
types,
except
for
monitoring.
Really,
monitoring
is
where
they
preferred
web
consoles
mostly
and
where
we
started
kind
of
looking
into
into
this
was
in
prior
work.
Of
course,
the
work
that
we
found
didn't
evaluate,
developer
preferences
based
on
different
task
types,
and
we
thought
that
was.
H
There
is
this
one
paper
too,
that
we
found
that
was
super
relevant.
They
looked
at
actually
like
cloud
development
in
the
and
ideas,
but
and
they
looked
at
programming
tasks
also,
but
not
the
types
of
them.
They
just
looked
at
levels
of
difficulty,
and
so
we
had
this
two-part
study.
We
did
that
survey
and
we
also
did
a
little
follow-up
comparative
user
study
and
those
are
the
research
questions
that
I
just
went
over
and
the
survey
we
recruited
60
people
in
part,
thanks
to
you
guys.
H
I
was
here
before
and
spoke
to
you
all
before
about
this
research
project
also
sig
usability
and
they
helped
us
out
with
posting,
getting
visibility
for
our
survey
on
linkedin,
and
we
would
have
loved
to
have
more
participants,
of
course.
But
this
is
just
the
amount
that
we
were
able
to
recruit
in
the
time
frame
and
the
number.
H
Respondents
was
really
small
also,
there
were
only
about
five
beginners
out
of
those
60
participants,
so
we
would
really
like
to
improve
this
further
and
just
get
it
out
more
and
we
tried
we
had
an
idea
to
publish
our
survey
on
the
kubernetes
website,
but
there
were
some
issues
with
it,
not
being
completely
vendor
neutral.
So
that's
something
that
we're
gonna
look
into
in
the
future,
but
if
anybody
else
has
input
on
just
better
ideas
for
recruiting
we'd
really
appreciate
that,
and
so
we
asked
them
questions
about
their
experience.
H
How
frequently
they
worked
on
these
tasks
and
which
tool
modality
preferred,
and
so
we
found
that
developers
frequently
work
on
multiple
types
of
tasks
every
day
so
monitor
it.
So
you
can
see
like
up
to
17
and
30
many
times
a
day,
working
on
cred
tasks
and
then
for
debugging.
It
was
like
13
weekly,
22
expert,
and
then
it
was
even
more
broken
down
for
for
monitoring.
H
But
this
is
something
that
we'd
also
like
to
to
further
understand
is
the
how
just
like
the
workflow
of
people-
and
you
know
a
lot
of
the
times-
we're
not
working
on
one
thing:
we're
jumping
between
different
things
and
that
can
impact
our
productivity
and
jumping
between
different
things.
We
want
to
be
able
to
do
that
efficiently,
so
maybe
you're
using
a
different
tool
for
that
reason.
H
I
D
I
Yeah
so
they're
almost
entirely
yellow
right
for
the
for
the
about
crowd
and
debugging
across
expertise
levels,
whereas
if
you
go
back
to
then,
but
the
monitoring
was
there's
still
cli,
but
it
was
much
more
as
he
said
web
console
dominant.
But
if
you
go
to
the
other
set
of
charts,
the
even
experts
aren't
doing
monitoring
tasks
very
often
right.
There
so
essentially
take
a
cross
product
for
these
two
and
get
the
actual
sort
of
expected
amount
of
time.
I
H
Yeah
definitely
we
wanted
to
look
at
the
frequency
too,
because
different
levels
of
effort
are
put
into
developing
these
tools.
So
we
wanted
to
understand
a
little
bit
more
about
how
often
people
are
doing
tasks
that
require
them
to
use
certain
tools
and
things
like
that
and
so
yeah.
We
did
this.
It
was
a
small
comparative
study.
We
had
four
participants
and
we
gave
them
it
and
we
wanted
to
kind
of
apply.
Our
survey
results
to
this
to
see
or
just
to
to
further
support
them
with
like
with
more
with
more
results.
H
You
know
they
they
knew
about
certain
commands
that
they
could
use
to
make
it
faster,
but
didn't
necessarily
remember
them
at
the
time.
So
that's
something
that
was
reflected
in
their
responses
for
how
this.
How
could
this
will
be
improved?
Maybe
the
the
syntax
or
other
problems
like
this?
One
of
our
participants
mentioned
a
failing
watch
flag,
not
giving
an
error
message.
All
of
a
sudden,
and
so
that
can
be
annoying
and
then
for
the
openshift.
H
No,
thank
you
please
chime
in
so
in
our
future
work.
We
want
to
refine
our
survey
to
be
vendor
mutual
and
put
it
on
the
kubernetes
website
so
that
we
can
get
more
participants.
We
can.
We
can
get
more
beginner
responses,
that's
really
important
and
we'd
like
to
post
it
on
the
website
and
also
do
some
more
contextual
interviews
to
more
deeply
understand.
You
know
what
developers
workflows
are
like,
so
there's
a
kubernetes
project.
H
B
B
H
I
I
B
Watch
so,
unsurprisingly,
that's
not
a
big
surprise
to
me,
because
honestly,
I've
seen
many
colleagues
of
mine,
preferring
to
use
the
unix
watch
command
over
the
built-in
watch.
That's
within
the
cubical,
the
the
biggest
benefit
of
using
the
unix
watch
command
over
the
kubeco
one.
Is
that
you're
getting
a
fresh
view
of
the
entire
get
command
versus
just
the
diffs,
because
the
dash
watch
works,
that
it
will
print
the
current
state
and
then
it
will
show
only
the
differences
which
in
some
ways
might
be
a
little
bit
more
harder
to
parse.
B
But
that's
how
the
the
watches
are
are
are
currently
done.
Maybe
we
could
make
it
more
towards
what
the
the
the
the
unix
version
does
as
in
print
the
whole
state
at
once,
but
that
that
would
have
to
be
optional,
because
I
I
I
assume
that
with
one
it's
easy.
But
if
you
have
like
a
50
resources
that
you're
watching
getting
updates
for
one
and
printing,
all
50
would
be
undesirable.
So
I
guess
the
decision
is
you
know
we
have
to
weigh
in
one
way
or
the
other
for
the
watch,
but
yeah.
I
C
C
The
other
thing
I
I
wonder,
I'm
sure
we
can
get
funding
either
from
the
cncf
or
whoever
you're
working
with.
If
we
do
another
one
of
these,
we
should
run
like
an
ad
campaign
on
stack
overflow
for
any
questions
that
are
tagged
with
cube,
control
and
stuff
and
yeah.
There's
there's
a
lot.
We
can
do
to
get
this
in
front
of
more
developer,
but
the
the
marketer
in
me
is
coming
out
now
from
working
with
martin.
H
D
H
E
Mentioned
that
when
we
were
talking
about
watch
a
second
ago
that
a
bunch
of
the
participants
were
experienced,
keep
calling
users,
you
kind
of
expected
that
they
would
know
about
watched
what
was
their
pre-existing
level
of
familiarity
with
openshift,
like
the
oc
console
like?
Were
they
familiar
with
both
of
these
tools
to
the
same
extent
before
they
performed
the
task.
H
D
I
H
Definitely
this
was
with
like
four
people
and
we
were
just
kind
of
trying
to
figure
out
what
the
study
could
be
and
it
could
definitely
be
improved
more
and
I
think,
having
people
that
use
openshift
every
day
instead
of
like
use,
cooper,
law
every
day
and
use
openshift.
Rarely
would
be
much
much
better
and
much
more
revealing.
I
I
Sorry
about
that,
I'm
sorry
and
that
in
the
charge
when
she
had
the
other,
I
think
cora.
You
actually
have
data
for
that
too,
to
say
what
people
actually
answered
for
other
and
it
was
interesting,
I
think
super
correctly,
for
the
monitoring
of
is
where
there
was
the
most
diversity
in
other
and,
just
speaking
exactly
exactly
to
my
point,
people
were
answering,
I
think,
a
dozen
different
random
tools
that
all
look,
pretty
cool,
yeah.
H
H
A
A
D
A
D
Yes,
hi
after
cora's
very
interesting
presentation,
it
would
be
pretty
boring
to
ask
reviews,
but
I
would
definitely
do
that.
First
one
was
approach
thanks
eddie,
but
for
the
second
one,
server
resource
function
in
discovery
was
the
application
three
years
ago,
and
I
thought
that
it
is
good
time
to
remove
it
from
all
over
the
places,
and
it
would
be
great
if
you
can
have
a
look
at,
and
I
wonder
your
opinions
about
it.
Is
there
any
drawbacks
or
we
can
safely
remove
it?
That's
it.
Thank
you.
E
Yeah,
so
this
is
a
feature
that
sort
of
spans
two
of
our
sub
projects.
Customizing
cube
pedal.
This
is
actually
the
number
one
feature
request
customize.
If
you
count
up
all
the
duplicate
issue,
upvotes
and
I
split
up
the
implementation
into
two
pr's,
the
main
one
is
actually
the
second
pr,
and
the
idea
here
is
that
end
users,
when
they
they
use
q,
pedal
customize.
E
They
want
to
be
able
to
know
what
what
version
of
customize
they're,
using
as
historically
it's
the
customize,
has
been
evolving
faster
than
q
pedal,
and
so
it's
even
more
important
to
be
aware
of
what
features
that
is
available
to
you
when
you're
using
these
commands.
What
version,
if
you're
using
version,
two
three
or
four,
depending
on
which
version
of
a
cube,
pedal
that
you're
using
you
might
have
very
different
capabilities.
E
So,
historically,
what
they
had
to
do
is
go
to
our
readme
and
look
at
this
little
chart
and
sort
of
find
the
version
mapping,
and
that
is
really
not
a
great
experience.
Nobody
likes
that.
So
it
again
is
number
one
uploaded
feature
and
it's
also
been
requested.
I
noticed
on
the
oc
version
which
embeds
customize
as
well,
so
everyone
wants
this
information,
so
I
took
a
stab
at
implementing
this
and
in
hopes
of
getting
it
into
the
next
release
and
yeah.
E
So
that's
why
they're
based
off
each
other,
but
the
main,
the
main
pr
is
the
implementation
really
of
of
that
sub
command,
and
I
went
through
a
few
different
iterations
trying
to
decide
how
to
best
do
this
and
where
I
landed
is
following
an
approach
that
we
actually
it's
very
similar
to.
I
think
the
standard
approach
for
embedding
version
information,
because
version
information
is
really
a
property
of
a
release,
not
of
something
that's
statically,
a
property
of
individual
files
in
the
code.
E
So,
what's
often
done
as
part
of
release
process
and
many
of
the
go
tools,
I've
worked
on
including
customize
itself
by
the
way
and
q
pedal
is
we
use
ld
flags
as
part
of
the
build
process
to
actually
take
the
release,
information
and
embed
it
into
binary
at
that
time?
That
way,
we're
making
sure
that
we're
embedding
the
correct
thing
for
the
release-
that's
happening
at
the
moment,
so
yeah
customized.
Does
this
cube?
E
Color
does
there's
lots
of
other
go
tools
to
it
and
there's
an
existing
version
script
that
I
was
able
to
hook
into
to
grab
the
customize
version
and
make
that
available
as
an
ld
flag
right
into
the
vendor
code.
So
it's
actually
plugging
into
the
same
version.
Provenance
code
is
what
customize
calls
it
and
there's
precedent
for
that
as
well.
We're
doing
that
for
a
client
go
for
whatever
reason
as
part
of
the
release
process.
E
So
I'm
just
imitating
that
I
think
this
approach
works
pretty
nicely
in
that
it
doesn't
interfere
with
independent,
build
processes
like
if
you
build
oc
and
it's
embedding
cube
control
or
embedding
customized
directly
or
some
other
tool
that
embeds
customized
directly.
It's
not
this
isn't
going
to
cause
you
to
get
an
incorrect
version.
Readout
like
you,
would
if
we
were
hard-coding
inside
like
we're,
making
a
constant
or
something
like
that
which
was
a
problem
with
previous
approaches.
When
I
started
working
on
this
and
yeah.
E
So
I
this,
I
I'm
fairly
happy
with
this,
but
I'm
also
very
open
to
other
approaches.
The
important
thing
to
me
here
is
that
we're
able
to
provide
this
feature
to
our
users,
because
it's
it's
super
desired
by
both
the
cube,
pedal
and
the
customized
communities
so
yeah.
I
had
a
conversation
with
machia
on
that,
and
I
know
that
it's
concerned
about
implementation.
So
we
wanted
to
discuss
that
here
today
and
maybe
see
if
anyone
else
had
had
something
to
say
as
well.
B
If
you
look
at
keep
cuddle
version,
you
will
only
see
the
server
version
and
the
client
version
without
going
into
details
that
we're
using,
I
don't
know,
try
and
go
this
version,
api
machinery
that
version
and
so
forth
and
so
forth.
So
that
would
actually
be
a
precedence
for
cube
cuddle.
To
give
you
a
little
bit
more
detailed
information
about
the
library,
because
for
me,
even
if
that's
exposed
directly
as
a
stock
command,
I'm
still
treating
that
as
a
library.
E
I
understand
that
from
the
maintainer
perspective,
that's
what
it
is,
but
if
we
take
the
end
user
perspective,
they
have
no
idea
how
we
do
the
integration
right.
Did
we
do
it
with
a
go
module?
Did
we
like
download
the
binary
dynamically
like
I
could
cuddle
plug-in
like
they
have
no
idea?
So
for
them.
E
This
is
an
embedded
tool
and
we
actually
see
a
lot
of
confusion
around
it,
not
behaving
the
exact
same
way
as
the
independent
tool,
because
that's
the
perception
and
you
can
see
that
in
the
issue
reports,
if
you
read
through
it,
that's
really
how
the
user
expectation
shakes
out
like
they
really
think
that
they
should
be
able
to
discover
what
version
it
is
and,
in
fact,
like
we're
exposing
that
in
a
table,
because
there
is
a
version,
compatibility
with
the
client
go
version,
that's
totally
irrelevant
to
the
end
user.
They
don't
care.
E
B
E
B
I
C
C
B
E
D
B
I
completely
forgot
about
the
apply
k,
as
nick
pointed
out,
and
let's
let's
make
it,
then
a
single
place
to
present
that
information.
In
that
case,
I
think
the
test
you've
added
there
can
be
modified
such
that
it
will
verify
if
the
output
of
the
the
usual
version
also
contains
the
customers,
the
appropriate
customers
and
I'll
tag,
the
the
the
other
in
a
after.
This
call.
E
Thank
you
just
to
make
sure
I
understand,
I'm
totally
fine
with
embedding
it
in
the
top
level
one,
and
I
think
the
dash
k
is
a
pretty
compelling
argument
for
doing
that.
Do
you
want
it?
You
want
it
to
appear
as
like
a
third
thing
right
now:
client
server
version
server
version,
and
then
I
have
customized
version.
E
Are
we,
okay
with
the
fact
that
the
version
information
would
actually
be
a
lot
more
sparse
than
what
we
have
for
client,
because
one
thing
that
came
up
in
my
experimentation
here?
Is
that?
Because
this
is
an
independent
code
base,
it's
not
actually
coming
from
kk.
If
I
wanted
to
get
crazy
and
include
like
the
get
shaw
and
other
details
like
that
of
the
release,
then
we
would
have
we
would
be
bringing
the
github
api
into
the
build
pipeline,
which
I
was
thinking
was
none.
E
A
B
That
starts
client
only
shows
it
was
meant
to
not
require
server
version,
and
I'm
I'm
I'm
hesitant
on
adding
flags
for
each
and
every
single
thing,
because
if
you
do
you'll
get
a
more
detailed
information
if
you
ask
for
yum
or
json
output
so
there,
yes,
that
will
be
a
separate
field
in
the
json.
So
you
want
to
make
sure
that
it
also
prints
nicely
in
the
in
those
two.