►
From YouTube: Kubernetes SIG CLI 20230222
Description
Kubernetes SIG CLI bi-weekly meeting on February 22nd, 2023. Agenda and Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=kix.dacb86t0fknd
A
A
A
So
we've
already
passed
the
enhancement
freeze,
which
was
back
in
February
9th.
So
another
item
which
is
more
geared
towards
some
of
the
chairs,
which
is
that
we
have
the
six
Eli
annual
report.
I
have
the
link
there
for
the
report
or
for
the
starting
of
the
report.
It
should
be
started
by
March,
23rd
or
sorry
March
24th,
and
it
should
be
merged
by
April
7th.
A
A
A
B
Okay,
so
my
name
is
Rita
I've
been
working
with
gubernetes
now
for
like
six
seven
months
on
a
daily
basis
and
like
this
is
the
first
time
that
I'm
joining
one
of
these
calls
I've
been
part
of
these
Sig
dogs
channels
and
their
meetings
in
the
past,
but
I've
never
like,
like
I've,
only
been
a
local
in
the
six
CLA
channels.
Yeah
I
hope
to
click.
Take
part
more
on
this,
and
hopefully
click
learn
and
contribute
more
in
the
future.
D
A
E
A
A
D
D
F
That's
a
lot
of
the
the
question,
but
I
would
probably
the
all
is
most
likely
less
of
a
problem,
but
the
biggest
question
is:
do
we
want
to
present
the
entire
list
of
resources
that
the
delete
will
remove,
or
rather
we
want
to
do
it
in
a
strictly
iterative
way
where,
before
removing
a
particular
resource,
we
are
issuing
a
question:
are
you
sure
you
want
to
remove
X
and
then
a
user
has
to
make
a
decision?
And
then
again
are
you?
What
are
you
sure
you
want
to
remove?
G
We
show
them
the
whole
list
by
default,
but
if
they
put
like
s
for
split,
then
it
splits
it
down
into
you
know,
groups
of
five
or
something,
and
then
if
they
do
split
again,
then
it
goes
one
by
one,
and
so
you
only
ever
have
yes,
there's,
no
all,
but
it's
yes
to
whatever
we.
We
just
showed
you,
but
you
have
the
ability
to
interactively
make
those
chunks
more
granular.
If
you
want,
then
you
kind
of
get
both.
B
D
This
first
implementation
attempted
to
use
the
third
one
actually
I
mimic
that
in
my
PR
and
after
that
there
are
yes
and
no
options.
No,
yes
to
all
option,
and
after
that,
after
Brian
suggested
to
showing
the
lists
of
all
the
resources
and
yes
or
no.
But
there
is
no
partial
religion.
I
changed
my
implementation
to
the
second
one,
but
honestly
I'm
now
Katrina
proposed
fourth
one,
and
we
have
four
options.
Actually.
F
F
G
Actually
what
I
suggested
could
be
done
as
an
iteration
on
the
latter
like
if
we
start
off
with
showing
them
everything
we're
going
to
delete
and
give
them
a
yes
or
no
and
that's
it,
then,
in
a
future
release
we
could
add
the
S
option
that
then
breaks
it
down.
If,
if
needed,
like
that,
that's
compatible
for
what
it's
worth.
F
We
could
probably
label
the
slack
as
an
experimental
and
implement
it
as
a
simple.
Yes,
no
without
any
additional
actions
in
this
way
for
users
feedback,
whether
they
will
be
more
requests
for
all
type
of
operations
or
not,
and
if
nobody
will
complain
we'll
just
either
leave
it
as
is
or
we
will
turn
over
to
the
all,
maybe
I,
don't
know
that
was
my
proposal.
G
G
Guess
if
I'm
thinking
about
where
this
is
most
valuable,
to
have
Interactive,
like
which
side
should
we
optimize
for
because
I
think
you're
right
that,
like
we
will
have
users
that
are
doing
both
like
we'll
have
some
that
were,
are
typically
deleting
three
things
at
once
and
then?
Yes,
yes,
yes,
no
problem
and
ones
that
are
like
trying
to
delete
a
huge
list,
and
and
and
that's
really
really
tedious
to
hit.
Yes,
that
many
times
so
like
to
which
user
is
the
feature
more
valuable
and
I.
G
E
Then
the
next
question:
it
seems
to
me
that
maybe
we
could
find
a
marriage
of
some
of
these
to
say
that
maybe
the
default
is
one
at
a
time,
but
instead
of
just
a
y
and
N
you
could
be
L
could
be
one
of
the
options
and
you
type
L.
It
lists
all
the
things
it's
it's
that
have
matched
and
if
you
have
capital
y
or
something
it
just
deletes
them
all
or
a
complete
them
all
or
something
that
way
you
can
maybe,
with
a
single
experience,
you
can
cover
both
bases.
G
Yeah,
that's
kind
of
the
opposite
of
the
split
thing
I
proposed
I.
Guess,
like
you
have
one
you
get,
so
you
can
go
in
both
directions.
You
have
guess
no
for
what
you're
seeing
now
and
then
you
have
like
show
me
a
different
list,
a
bigger
list
or
a
smaller
list,
basically
with
the
command
and
then
I
would
say,
like
you
always
we'd
want
either
way
for
that
extra
option
to
just
be
producing
that
list,
and
you
still
need
a
y
or
an
N
explicitly
against
what
you're
currently
being
shown.
E
D
D
C
D
G
I
think
yeah.
The
the
point
is
really
good:
that
that
supporting
line
item
thing
is
kind
of
a
different
feature
than
what
we
provide
today,
that
it
allows
you
to
set
a
selected,
a
set
that
is
not
selectable
with
our
current
commands
that,
and
that
leads
me
to
lean
even
harder
in
the
direction
of
the
full
list
as
the
simpler
starting
point,
because
it's
like
it
just
lets
you
veto
or
not
the
current
function
functionality
so
that
that
seems
like
the
right
place
to
go
and
I
wondered.
G
If,
for
the
line
item
based
one,
would
there
be
some
sort
of
workflow
that
that
folks
could
set
up
for
themselves
where
they
pipe
it
an
individual
list
through
to
rmdishi,
and
then
it
would
sort
of
like
go
one
at
a
time
like?
Maybe
people
could
still
sort
of
hack
that
together?
If
that's
what
they
wanted
once
interactive
exists.
C
D
A
Okay,
I've
I've
attempted
to
capture
the
back
and
forth
of
this.
The
discussion,
but
I
might
not
have
been
completely
accurate,
and
so,
if
anybody
would
like
to
amend
those
notes,
please
please
do
I
think
that
that
the
decision
that
matcha
just
enumerated
was
we're
leaning
towards
an
experimental
flag
with
a
potential
change
in
the
future,
where
we
list
all
and
then
in
the
yes
or
no
is
for
the
entire
list.
Does
that
sound
about
right.
H
Thanks
sorry,
Sean
can
I
just
ask
a
question:
yeah
quickly
sure
go
ahead.
Thank
you.
Katrina
and
I
are
working
on
prune.
I
just
wanted
to
ask.
Do
we
want
to
think
about
supporting
this?
Yes,
no
for
things
that
are
going
to
be
in
prune
I'm
asking
you
to
do
it
I'm
saying
like
when
we're
building
it.
Should
we
think
about
that
coming
up
in
the
future,
so
prune
will
delete
some
objects.
Presumably
maybe
users
might
want
an
interactive
mode
on
that.
Also.
F
F
G
I
think
it's
a
really
interesting
idea,
though,
like
we
get
the
same
sort
of
complaints
with
pruning
as
we
do
with
the
delete
command.
So
it's
it's
a
good
point.
I
think
we
would
need
to
think
about
what
Interactive
sounds
like
it
means
on
apply,
because
pruning
is
just
a
sub
feature
of
apply,
so
I
think
like
users,
if
they
do
apply
Dash
I
or
whatever
they're
going
to
expect
more
than
just
interactive
prune
like
interactive
I,
don't
know
diff
approval
or
something
so
it
might
be
a
little
hard,
but
definitely
we're
thinking
about.
A
Foreign
yeah,
the
one
one
of
the
things
I
worry
about,
is
that
it
it
are.
It
already
feels
like
at
least
with
the
current
prune,
where
you've
got
prune,
allow
list
and
you've
got
the
labels
and
you've
got
the
prune
flag,
there's
already
a
lot
of
kind
of
noise
going
on,
and
then,
if,
if
you
also
wanted
to
specify
well
I
want
to
do
this
interactively.
That
might
be
like
this
other
fourth
dimension,
which
might
make
it
so
I
think
that
this
command
already
is
difficult
to
use
correctly.
A
G
A
G
A
J
J
F
I
was
initially
thinking
only
about
the
health
level
I,
just
like
Nick
mentioned
I.
Don't
did
the
only
get
all
the
essence
that
I
have
from
our
top
level,
because
that's
the
whole
point
to
be
able
to
get
rid
of
the
necessity
to
write
I,
don't
know
whatever
long
commands
and
replace
that
with
a
whatever
Outlets
or
shortcut.
You
want
to
come
up
with
I'm
trying
to
remind
what
I
did
in
that
PR
of
mine,
but
if
I
remember
correctly,
I
just
injected
new
commands
at
the
top
level.
F
J
A
F
F
J
Yeah
and
there
I
I,
ran
into
some
stuff
like
10
minutes
ago.
That
I
didn't
realize
was
going
to
be
a
problem
like
if
args
are
required.
The
way
that
I
have
this
put
together
right
now
is
not
going
to
work
and
I'm,
not
100
sure
why?
But
we
so
I'm
gonna
have
to
figure
out
some
ways
around
some
of
this
stuff.
Still,
it's
not
really
in
a
figure
out
where
it's
at.
J
F
C
J
C
G
So
I
just
wanted
to
clarify
like
what
the
stage
of
this
is
like.
Are
we
doing
experiments
to
inform
and
update
to
the
cap,
or
are
we
trying
to
implement
the
cap
and
sort
of
changing
our
minds
about?
Maybe
what
the
feature
should
be,
which
is,
is
fine
and
is
this
targeting
the
release?
I
just
wanted
to
clarify
like
what
we're
going
for
at
this
point.
J
J
J
J
D
J
F
I
J
J
Docs,
it
says
that
the
they
have
to
be
done.
It
has
to
be
after
the
flags
have
all
been
set.
So
if
you
set
a
flag
after
you
parse
it
overwrites
everything
from
what
I
can
tell
and
then
it
has
to
come
before
the
command
starts
to
actually
interact
with
the
flags,
which
is
very
strange
to
me.
But
okay.
J
There's
I,
don't
know,
there's
a
lot
of
other
flags.
That
I
think
would
probably
be
good,
but
they're
all
like.
What
do
you
call
it
like
a
rest,
client,
config
options.
I,
don't
know
how
important
that
would
be
to
anybody
specifically,
but
it
is
something
that
I
think
would
be
probably
pretty
useful
to
at
least
one
person
in
the
world,
but
we
can
also
just
like
skip
it
since
it's.
What
do
you
call
it?
J
J
E
J
I
think
a
lot
of
this
stuff,
probably
gets
done
just
by
virtue
of
the
cube
config
itself
and
so
being
able
to
set
a
specific
Cube
to
the
pig,
would
probably
be
enough
because
the
rest
of
these
are
like
specify
the
cashier
I
guess
that
one's
probably
not
defined
in
the
cube
config
but
like
the
cluster
name
or
auth
infos,
or
things
like
that
or
what's
included
in
these
timeouts
Etc.
So
probably
not
really
that
important.
But.
E
The
reason
I
asked
about
the
Alias
intersections
I
would
have
thought
that
in
git
I
can
make
an
alias,
which
is
prefix
with
an
exclamation
point,
which
basically
says
invoke
another
Alias.
So
if
we
wanted
to
make
an
alias,
for
example,
that
says
that's
special
to
a
particular
context
and
I
would
make
a
bang
alias
that
there's
a
coupon,
then
I
would
just
put
the
cooking
fig
there
right
on
my
Alias
valve,
and
you
don't
have
to
worry
about
it
at
all,
because
it's
just
to
reinvoke.
J
Yeah,
actually
that's
a
good
point.
If
I
could
get
aliases
to
work
right,
then
that
would
be
a
good
way
to
handle
that
I.
Suppose,
however,
that
does
just
kind
of
abstract
away
the
annoying
problem
of
having
to
have
that
that
flag
set
in
a
bunch
of
different
places
when
the
whole
point
of
the
default
flag
is
to
get
rid
of
having
to
set
that
in
a
bunch
of
different
places.
I.
G
J
J
J
J
F
I.
Think,
roughly
around
that
time,
you
should
be
also
able
to
access
conflict
facts
which
is
one
of
the
elements
that
holds
at
least
partial
information
or
two
Planet
things.
Most
likely.
Some
of
the
the
global
flag
should
be
accessible
there
as
well,
so
I
would
probably
look
somewhere
along
those
lines
to
be
able
to
effect
their
values
from
from
those
flags.