►
From YouTube: Kubernetes SIG CLI 20220209
Description
Kubernetes SIG CLI bi-weekly meeting on February 9, 2022.
SIG CLI Meeting Agenda and Notes:
https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=id.4r1ml65tgujc
A
A
A
A
B
C
All
right,
I'll,
just
start
and
sean
can
sort
his
audio
out,
so
we
got
together
yesterday.
So
the
annual
report
is
something
that
all
the
sigs
prepare
and
this
all
grows
into.
The
projects
kind
of
like
state
of
the
union
for
the
past
year,
as
well
as
the
cncf,
provides
an
update.
So
we
can
share
the
one
from
last
year
if
anyone's
interested
it
was.
It
was
public,
and
so
we
have
a
kind
of
a
tempo
that
we
just
need
to
work
through.
C
Here
we
got
together
and
we
filled
in
a
bunch
of
stuff.
The
ask
from
the
rest
of
the
sig
is
any
shout
outs
highlights
work.
We
missed.
Please
just
take
a
look
at
this
doc
field.
It
should
be
open
for
everyone
to
edit
and
contribute
to
so
feel
free
to
toss
any
comments
or
anything
you
have
on
here
and
yeah.
We
want
to
make
sure
everyone's
work
is
highlighted
and
any
of
our
needs
and
other
bits
are
tracked,
so
I
think
the
sub
project,
specifically
nick.
C
C
B
C
B
C
C
F
Yeah
I'll
introduce
myself
since
I'll
be
presenting
right
now,
yeah
I
work
with
sean,
so
I
hadn't
introduced
myself
earlier.
I've
worked
with
the
kubernetes
kernel
team
at
google,
the
api
express
expression,
working
group
and
yeah.
I'm
here
to
talk
about
a
proposal
to
extend
cube
cuddle,
explain
with
a
new
output
type.
Should
I
share
my
screen
to
show
that
document
or
I'm
not
sure
the
protocol
here.
F
Yeah,
it's
fine,
it's
it's!
Actually,
it's
fine
to
be
scrolled
down
to
the
cube
cuddle
explained
ux
section.
I
think
we
can
just
stare
at
that
yeah.
So
my
team
has
been
approached
by
a
number
of
other
teams
for
advice
on
how
they
can
automatically
generate
documentation
for
their
kubernetes
clusters
and
unfortunately,
we
never
have
a
really
good
answer
for
them
and
we
looked
around
at
what's
available
in
the
community
and
we
found
that
there's
a
couple
of
options,
but
they
all
seem
to
be
made
not
with
everybody
in
mind.
F
Some
of
them
generate
html.
They
might
only
include
kubernetes
core
types.
They
don't
allow
you
to
have
your
own
custom
formatting
or
they
use
open
api
v2.
So
we
wanted
something
that
protect
all
these
boxes
and
we
built
a
prototype
using
open
api
v3,
and
we
looked
at
it
and
said
this
looks
a
lot
like
coop
cuddle
explained,
so
we
thought
it
would
be
very
natural
to
extend
the
command
line.
F
We
also
wanted
to
embed
some
templates
for
everyone
to
use
that
are
just
generally
useful
one
being
the
current
output,
which
is
human
readable.
We
have
an
embedded
template
that
replicates
that,
and
also
one
for
markdown,
so
yeah
we're
here.
I'm
here
just
to
propose
this
as
an
idea
to
extend
coop
cuddle,
explain
to
seek
feedback,
and
hopefully
someone
who
wants
to
take
this
under
their
wing
and
extend
it
with
my
team's
help.
B
The
the
descriptions
being
comments
for
the
fields
and
fields
having
empty
values,
so
basically
something
like
a
generate
empty.
I
don't
know,
let's
say
pod
with
all
the
fields
filled
in
with
their
descriptions
but
with
empty
values,
so
that
you
can
then
take
this
thing
and
you
know,
fill
in
submit
it
over
back
to
the
cluster.
F
Yeah,
that
sounds
like
a
really
cool
idea:
I'm
not
sure
what
kind
of
like
technical
problems
someone
might
run
into
like,
for
instance,
like
coming
up
with
default
values
for
types
that
might
fit
the
cell
validations.
That
sounds
like
a
pretty
hard
problem,
but
so
people,
someone
might
anyone
can
put
in
any
template
and
format
it
whatever.
What
way
they
want
is
the
idea.
B
Let
me
let
me
tell
you
a
little
bit
of
history.
Why
I'm
asking
about
something
like
that,
so
eddie
and
myself
and
a
couple
folks,
we've
been
discussing
options
for
replacing
create,
commands
the
create
job
create
deployment
of
all
those
specific
commands
with
a
rather
generic
generate
command
and
eddie
was
working
on
a
prototype.
B
Now
that
you're
mentioning
the
topic
that
there
could
be
an
option
for
a
format
template
I'm
not
saying
that
it
has
to
be
done
right
away,
but
I'm
just
wondering
if
that
would
be
possible,
because
if
then
then
I
guess
there
might
be
even
more
use
cases
for
this
approach.
But
the
general
idea
is
definitely
sound.
F
D
Go
ahead
yeah,
so
the
the
problem
with
the
yamal
is
that
generating
from
a
template
engine
means
that
if
you
have
any
weird
character,
that
is
not
very
general,
then
it's
to
start
breaking,
and
there
are
many
many
ways
that
you
can
have
yammer
break
because
of
the
formatting.
And
so
I
think,
if
we
wanted
to
generate
yaml,
we
could
do
it,
but
we
don't.
We
probably
shouldn't.
Do
it
from
the
time
to
play.
C
Yeah,
that's
fair.
The
I
was
just
gonna
say
the
there
was
a
working
group.
Api
expression
kept
that
kevin
weiss,
mueller
opened
to
add
examples
to
the
open
api
data.
Open
api
has
a
actual
field,
for
example
data
we're
just
not
using
it,
and
so
that
was
one
of
the
things
that
we
were
hoping
to
pull
from
for
this,
like
you
know,
generating
stuff.
In
terms
of
where
you
get
that
you
know
template
data
from.
D
E
Just
to
throw
something
out
there,
if,
if
we
could
have
a
dash
o
jason
option
for
explain
and
then
have
all
of
these
template
formatters
as
crew
plugins,
just
to
keep
these
things
a
little
bit
more
orthogonal,
I'm
not
sure
whether
that
runs
from
the
same
problem.
That's
why
I
pointed
out
in
terms
of
serializability
versus
json,
but
that
might
give
a
little
more
flexibility
for
us.
D
D
I
think
it's
better
if
you
specify
the
template
instead
of
a
plug-in
which
is
going
to
be
complicated
to
implement
yeah,
I
mean
I'm.
What
I'm
saying
is
that
I
I
think
it's
good.
If
we
can
replace
the
if
you
can
change
the
template,
but
then
it
should
be
a
template
like
if
you
want
to
expose
things
in
a
different
way.
You
provide
to
some
plate,
probably
not
a
plugin,
which
means
that
you
have
to
compile
something.
You
have
to
write
code
and
whatnot,
I'm
not
sure
what
the
benefit
would
be.
C
The
I
think,
nick
you
were
talking
about
something
that
I
had
commented
here
antoine
this
comment
specifically,
was
we
already?
You
know
how
we
have
the
concept
of
printers
already
for
the
different
output
types.
If
we
we
already
have
a
go
template
output
type,
if
we
can
extend
that
to
work
with
files.
Does
that
solve
your
problem?
If
we
can
bring
the
printers
to
using
explain
and
not
just
get,
I
don't
know
how
tightly
coupled
they
are
actually.
D
D
D
No
for
sure
but
yeah,
if,
if
you
do
a
control,
get
that
show
and
you
specify
your
template,
the
template
receives
the
objects
that
the
object
that
you
want
right
right,
like
you're
gonna,
receive
one
pad
and
that's
gonna
print
one.
But
the
content
of
the
bird
here
for
kubrow
explained
the
the
template
receives
the
definition
of
the
bud,
not
a
specif,
an
instance
of
a
bud,
but
the
definition
of
the
bud
yeah.
So
that's
completely
different
things.
E
You
had
to
use
case
and
cooley
for
this
very
case.
That's
why
I
asked
about
the
json
output
it'd,
be
nice
to
be
able
to
in
any
kind
of
tool
to
be
able
to
pretty
print
this
information
in
a
live
form,
so
in
other
words,
rather
than
generating
a
static
document
being
able
to
generate
a
ui
component.
For
example,
imagine
going
from
explain
to
a
react
component,
be
nice
if
they're
a
way
of
doing
that,
rather
than
right
now
we're
parsing
out
the
the
text.
You
know,
which
is
horrible.
D
F
B
B
C
C
H
H
Does
that
work
sure
yeah?
So
basically,
I'm
just
here
to
update
you
now
that
the
enhancements
freeze
is
over
and
we've
got
our
enhancement
merged
and
approved
for
124.
what
the
what
the
kind
of
status
is
of
the
modifications
to
cube
control
validate.
So
if
you'll
remember,
I'm
working
on
server-side
validation,
so
basically,
when
you
do
kube
control
validate
and
you
send
a
object
with
unknown
fields
or
duplicate
fields
that
were
previously
getting
dropped
by
this
api
server
or
carried
out
via
client-side
validation.
H
That
is
now
going
to
come
from
the
server
and
you
know,
there's
a
history
if
you
go
through
kind
of
the
cap
in
the
earlier
discussions
of
why
client-side
is
bad,
why
server-side
is
better
et
cetera
and
basically
the
big
dif.
So
what
I
had
proposed
last
time,
I
chatted
at
the
beginning
of
this
kept
cycle.
Was
that
there's
kind
of
cube
control
validate
flag
currently
as
a
boolean,
so
you
either
true,
do
the
validation,
false,
don't
do
the
validation
and
then
I
had
originally
proposed
kind
of
three
domains
of
of
validate.
H
So
you
know
the
true
and
false
for
backwards,
compiled
compatibility,
client
or
server,
and
then
the
strict,
ignore
and
warn
specifically
for
server
side.
The
feedback
I
got
and
the
solution
we
went
with
is
that
we
don't
want
to
give
people
the
option
to
do
client-side,
validation
or
server-side
validation.
We
want
it
to
be
intent-based.
H
Basically,
under
the
hood
we're
going
to
check
if
server
side
validation
is
available,
if
so
use
that
otherwise
defaults
back
to
client
side,
and
so
this
will
have
the
effect
of
in
the
long
run,
basically
deprecating,
client-side
validation,
as
all
servers
gain
access
to
server-side
validation.
There
was
some
feedback
around
you
know.
Client-Side
validation
has
some
uses
when
it's
not
connected
to
a
server.
H
H
Basically,
for
I
don't
know
at
least
until
after
this
goes
ga,
and
then
I
think
I
think
the
plan
is
to
basically
start
warning
on.
You
know
if
you're
not
connected
to
a
server
at
all.
Do
a
client
set
that
client-side
validation
with
a
warning
saying:
hey.
This
is
going
to
be
gone
at
this
release.
You
know
connect
to
a
server
if
you
want
any
validation
at
all
or
use
this
external
feature.
That
does
client-side
validation
kind
of
thing,
but
that
is
yeah.
That's
that's,
I
guess
does
that
answer
your
question.
C
C
C
I
I
Yeah,
so
from
this
issue
on
the
server
side,
we
implemented
lazy
marshalling
to
sort
of
improve
the
performance
of
the
api
server
when
there's
a
lot
of
crds.
This
is
mainly
around
open
api
and
like
marginal
open
api,
and
I
think,
on
the
client
side,
when
there's
a
lot
of
crds,
there's
still
this
issue
that,
like
could
be
pretty
slow.
I
I
So
with
open
api
v3,
so
everyone
is
probably
going
to
open
mpiv2.
We
have
this
endpoint
slash,
open
api,
slash
v2
that
returns
the
aggregated
spec
for
all
of
us
here,
all
the
built-in
type,
crds
and
etc
with
open
api
v3.
We
sort
of
wanted
to
improve
on
this,
and
since
an
aggregated
spec
is
very
large.
We
split
it
up
into
groups,
separate
group
versions
such
that
we
have
this.
This
kind
of
works
similar
to
discovery.
I
I
And
one
of
the
catching
mechanisms
that
one
we
were
introducing
in
this
release
for
beta
is
something
around
the
idea
of
cache
busting.
So
before
talking
about
cache
busting,
I
can
talk
about
how
things
currently
work.
So
currently
we
use
etags
and
open
api.
A
client
would
send
a
request
to
the
open
api.
It
would.
I
The
open
api
would
basically
the
server
would
hash
the
output
and
provide
an
e-tag
for
the
client
such
that
next
time.
The
client
sends
a
request.
It
will
provide
the
same
e-tag
and
if
the
resource
is
not
changed,
then
a
three
or
four
not
modified
responses
returned
and
we
basically
saved
the
like
the
round
trip
of
having
the
entire
open
api
spec
sent
back
to
cloud
now.
The
problem
with
this
is
that,
with
opening
pad
v3,
we
basically
isolated
the
open
api
specs
into
group
versions
and
for
clusters
with
a
lot
of
crds.
I
You
can
also
we
can
have
the
possibility
of
similar
to
what
we
have
discovery,
having
a
lot
of
tiny
requests
for
upgrade
versions
and
having
to
basically
maintain
every
time
we
need
a
let's
say,
invalidate
cash.
We
need
to
constantly
ping
or
just
watch
query
the
the
endpoints
to
make
sure
that
nothing
is
updated,
and
this
is
quite
expensive.
I
F
I
The
client
can
easily
see
which
pages
are
updated
and
which
pages
has
basically,
another
request
is
not
needed
for
them,
and
so
obviously
this
is
an
improvement
in
that
the
client
can
now
selectively
choose
whether
to
send
requests
to
work
with
versions
depending
on
what
it
needs,
and
the
other
benefit
of
this
is
that
we
have
a
on
the
client
go
side.
We
have
it.
I
Maybe
on
startup
but
subsequent
requests
to,
let's
say
group
version
is
invalidated.
We
don't
have
to
invalidate
the
entire
tree.
We
can
only
only
a
particular
group
version
that
change
will
be
invalidated
from
this
discovery
document
and
reduce
that
this
was
theoretically
reduced.
The
amount
of
requests
that
we
sent
to
have
the
keyboard
server
from
the
discovery
side.
H
A
A
D
And
one
consequences
of
this
is
that
we,
you
can
now
refresh
the
discovery
almost
every
single
time,
instead
of
not
knowing
when
to
invalidate
or
using
a
random
unarbitrated
time
to
keep
the
cache
which
is
plus
setting
when
it's
10
minutes,
and
sometimes
it
needs
to
be
refreshed,
and
we
don't
know
it
needs
to
be
refreshed.
Now
we
can
literally
refresh
away
time
because
we're
not
going
to
have
many
requests,
and
so
it's
going
to
be
almost
free
to
just
make
sure
it's
up
to
date.
I
D
C
J
Yup,
this
is
something
that
this
is
something
that
came
from
mache
and
it's
really
just
to
make
sure
that,
when
you're
doing
concurrent
changes
to
config,
whether
that
you
know
being
whatever
you're
using
right,
that
only
one
process
actually
can
write
to
the
config
file
one
time
so
right
now
it
uses
the
lock
file
mechanism,
which
works
to
some
extent.
But
it's
not
fully
atomic
versus.
If
you
use
the.
I
J
Well,
the
largest
issue
so
far
that
I've
gotten
feedback
on
is
the
introduction
of
a
new
dependency
which
is
scd's
file,
walking
mechanism
as
a
dependency
in
the
client
go,
and
that
seems
to
be
the
only
thing
that
had
raised
questions
you
know.
Do
we
want
to
include
that
as
a
dependency,
or
do
we
want
to?
B
B
So
there
are
probably
a
couple
of
options
you
can
maintain
the
current
solution,
which
is
not
ideal.
We
can
try
implementing
per
per
os
solutions
which
isn't
super
hard
or
we
can
bring
in
dependencies
external
dependencies.
But
that's
where
jordan
worries
come
in,
because
that
basically
means
we
will
be
pulling
in
additional
depth
on
to
pretty
much
every
client
go
consumer
because
that
bit
of
code
resides
in
client
bill.
C
J
It
yeah
it's
another
syscall
to
lock
file
x,
I
think,
is
what
the
name
of
it
is
it
it
honestly.
It's
not
terrible.
The
only
reason
I
didn't
implement
it.
You
know
essentially
how
scd
did
it
was
only
because
the
scd
implementation
has
been
pretty
much
battle
tested
at
this
point,
and
we
know
that
it
works.
So
it
was
one
of
those
you
know.
Did
we
recreate
the
wheel
or
yeah?
We
just
use
one
that
we
know
works.
J
B
J
Yeah,
it's
not
terrible.
You
know,
there's
a
couple
of
implementations
that
I
wasn't
completely
sure
about.
Like
you
know,
obviously
linux
is
pretty
solid,
there's
some
other
ones
like
plant,
nine
and
solaris,
and
things
like
that
that
I
would
not
be
able
to
test.
As
far
as
I
know,
but
even
those
implementations
seem
fairly
simple.
B
C
B
B
C
C
J
B
G
Do
we
need
to
talk
about
the
point
that
machia
pointed
out
jordan
mentioned
on
the
on
the
issue
that
like
do?
We
even
want
the
locking
behavior
in
the
first
place,
because
it
solves
a
very
narrow
problem
of
the
right,
but
like
usually,
if
you
have
multiple
processes
contending
over
the
file,
that's
not
really
going
to
solve
the
problem
on
the
whole.
B
B
G
B
B
G
I
think
that's
what
I
would
prefer
to
see
since
it
seems
like
this
is
causing
problems
and
is
not
really
that
helpful
like
improving.
It
would
solve
some
of
the
problems,
but
it's
not
like
it's
just
encouraging
people
to
do
things
that,
like
they're,
still
not
safe.
Despite
this
feature,
existing
I'd
rather
see
it
go
but
like
between
nothing
happening
and
this
pr
with
the
no
dependencies
going
in.
I
would
still
prefer
that,
because
it
does
solve
the
budget
regarding.
B
B
B
I
mean
if
you
look
at
the
and
you
had
it
open
a
minute
ago,
the
other
pr
where
he
was
like.
I
don't
feel
safe
yeah
just
that
one
and
I
was
like
maybe
something
has
changed
over
there.
The
past
18
months
since
that
was
initially
brought
up,
which
I
am
totally
in
favor
of
we
just
probably
need
to
warn
everyone
that
this
will
happen
and,
just
you
know,
I'll,
send
one
of
my
golden
thoughts
out
later
today.
To
always
use
separate,
keep
configs
for
your
processes,
sometimes
those
those
advices
help.
C
J
C
C
E
Or
can
we
super
quick
so
at
long
last
there's
a
lot
of
electron
issues
under
the
covers?
We
couldn't
sign
and
notarize
the
mac
os
builds
of
kui
for
the
longest
time.
It's
those
bugs
are
still
there,
but
there's
some
workarounds
and
so
we've.
I
decided
to
just
finally
do
that
and
stop
waiting
for
them
to
get
their
fixes
in
place.
E
So
mac
os
build,
signed,
notarized
lots
of
bug
fixes
flowing
through
I'm
not
going
to
board
with
the
details
there.
The
other
thing
you
can
check
out
some
links
there.
We
like
your
feedback
on
this.
I
think
there's
some
excellent
opportunities
there.
So
kuiz
had
some
notebook
support
for
a
while.
Now
it's
sort
of
just
been
in
a
prototype
kind
of
phase.
We
push
it
to
the
next
level,
ability
to
parse
and
render
markdown
into
into
kind
of
guided
documentation.
E
So
the
k-net
stock
condition
maybe
has
margin
examples.
Although
yeah,
I
think
they
should
be
okay,
they
so
anyway.
So
the
idea
is
that
we
can
guide
people
through
a
series
of
complex
tasks.
This
is
all
just
running
on
top
of
kui
the
code
blocks.
This
is
all
on
a
static
website,
but
if
you're
running
in
kui
on
your
laptop,
these
code
blocks
would
be
executable,
there
would
be
progress
metrics
towards
goals.
I
think
to
me
the
most
interesting
opportunity
that
we
can
explore
here
is
to
customize
integration.
With
this.