►
From YouTube: Kubernetes SIG CLI 20230111
Description
Kubernetes SIG CLI bi-weekly meeting on January 11th, 2023.
Agenda and Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=kix.knnov04oprwo
A
A
A
A
B
Are
yeah
I
am
pretty
new
to
this
CCL
CLI
I
have
attended
one
meeting
so
far,
and
just
so
just
to
put
it
out
there,
myself,
doggy
I'm,
joining
from
India
and
I,
have
been
contributed
to
kubernetes
talks
earlier
and
now
I'm
pretty
darn
interested
in
community
CLI.
So
that
is
why
I'm
here
and
trying
to
contribute
to
some
good
first
issues.
Thank
you.
C
A
D
Related
to
that
for
customize
we're
also
planning
a
major
version.
Release
I
believe
I
mentioned
this
before
the
holidays,
because
this
is
a
plan,
that's
been
in
the
works
for
a
while,
and
we
actually
were
hoping
to
get
the
release
out
before
the
holidays,
but
for
various
reasons
we
weren't
able
to
and
we're
now
targeting
the
end
of
the
month,
so
we'll
provide
more
information
on
what
exactly
lands
in
the
release
when
we
do
it,
but
it's
going
to
be
an
exciting
one.
D
A
D
Thanks
Sean
yeah,
so
this
is
still
a
draft
PR.
It's
still
something
that
we're
very
much
working
on
and
we
wanted
to
present
it
early
both
because
there's
only
a
month
left
before
enhancements
freeze
and
we
want
to
allow
lots
of
time
for
feedback,
but
we
also
want
to
invite
other
people
to
get
involved
now
that
we
think
we
have
enough
information
sort
of
set
down
in
the
cup
to
provide
that
background,
for
people
to
understand
where
we're
thinking
and
all
the
context
that
has
gone
into
the
process.
D
D
Join
us
on
this
cup
whenever,
whenever
you're
able
to
so,
please
feel
free
to
jump
in
and
comment
on
the
kep.
The
main
point
of
presenting
today
is
that
we
would
like
to
invite
questions
and
discussion
and
also,
if
you
want
to
reach
out
to
us
in
in
Slack,
to
get
involved,
then
that's
great
too,
so
to
just
give
a
quick
overview
for
those
who
might
not
have
been
present
at
the
at
the
previous
conversations.
D
There
is
currently
a
feature
in
queue,
control
called
pruning,
which
is
part
of
the
apply
command
and
lets
you
sort
of
manage
a
set
of
objects.
The
way
that
you
applied
images
field.
So
you
want
to
be
able
to
declare
that
you
have
a
set
of
objects
that
exists
that
should
exist,
and
if
you
then
remove
something
from
your
set
and
you
apply
again
that
object
that
you
removed
from
the
configuration
should
disappear
from
the
cluster.
D
So
it
adds
it
adds
that
deletion
ability-
and
this
is
something
that's
existed
in
Q
control,
sense
version,
1.5,
so
very
long
standing.
But
it's
since
then
been
an
alpha
and
there
are
a
bunch
of
reasons
for
that
which
are
outlined
in
the
cup,
mainly
around
the
implementation.
That
was
chosen
having
some
fundamental
limitations
that
the
bugs
in
question,
like
it's
very,
very
difficult
to
to
fix
it
without
completely
changing
that.
D
So
there
have
been
some
previous
attempts
to
sort
of
come
up
with
Alternatives
and
there
have
been
some
experiments
within
6
CLI
in
a
a
different
repo,
not
in
in
the
acute
control
itself,
to
sort
of
prove
out
these
different
approaches.
So
what
the
Sig
was
thinking
at
kubecon
is
that
you
know
we're
at
this
point
where
we
really
need
to
get
rid
of
the
alpha.
D
That
we're
going
for
here
is
something
that
is
fairly
constrained
as
part
of
the
plan
and
lockdown,
where
we're
not
sure
what
we
should
be
doing
so
that
we
can
get
something
in.
That
will
be
a
very
good
foundation
for
iteration
low
level,
something
that
we
can
build
on
get
feedback
and
and
be
able
to
move
forward
with
and
have
it
completely
get
rid
of
the
older
Alpha.
D
So
there
is
really
quite
a
lot
of
information
in
there
about
the
background,
the
feature
history
and
all
the
different
Alternatives
that
we
saw
in
the
community.
The
discussions
that
we've
had
so
far
summarized
I
don't
want
to
spend
the
whole
meeting
like
going
over
that
so
like
if
you,
if
you're
interested
in
that
background,
if
you're
interested
in
getting
involved
in
the
effort,
please
take
a
look
at
that
and
I
think
it's
hopefully
very
useful.
D
E
Sure
yeah
I'm
absolutely
happy
to
I
think
that
was
I.
Think
that
was
a
perfect
introduction.
I
think
yeah
I,
just
emphasize
like
it's
building
on
the
discussion
that
we
had
at
kubecon
I
think
we're
trying
to
do
something
very
much
in
that.
In
that
spirit
and
start
with
an
alpha
and
discover
things
and
like
I
was
saying
we
should
have
you
know
all
these
different
objects
and
Katrina
was
like
no,
no,
let's
just
like
pick
one
to
start
with,
and
we
can
always
expand
it
later,
but
you
can
never
sort
of
contract.
E
So
that's
the
spirit
we're
going
with
here.
I
think.
The
other
thing
that
I
think
was
a
big
lesson
from
for
me
from
that.
The
talk
which
Sean
Katrina
LED
was
an
idea
that
came
up
around
porcelain
versus
plumbing
and
that
we
should
try
to
create
some
Plumbing
that
can
be
used
by
lots
of
tooling,
and
so
we
are
proposing
something
that
we
think
is
hopefully
pretty
lightweight
and
Universal
and
that
all
the
tooling
we'll
be
able
to
use,
and
that
does
not
preclude.
E
E
The
idea
is,
we
have
a
parent
object
which
could
be,
as
it
says,
their
config
map
secret
or
crd
of
the
choice
tools,
choice.
We
might
constrain
that
for
the
alpha,
but
some,
let's
call
it
a
parent
config
map.
It
will
have
a
label,
so
you'll
be
able
to
do
one
of
the
accelerated
like
queries
to
get
those
objects.
E
That's
something.
We've
wrestled
with
a
bunch,
but
I
think
there
are
some
things
we've
done
specifically
to
make
that
to
avoid
the
problems
we
identified
in
the
earlier
Alpha.
So
we
now
have
a
specific
list
of
gvks
that
we're
going
to
query
so
it's
scoped.
In
that
sense,
we
have
a
specific
list
of
namespaces
that
we're
going
to
query
those
are
both
annotations
on
that
apply
set
object.
E
E
Think
it's
good
from
that
perspective
as
well,
but
there's
a
lot
of
details
in
this
in
this
cap
and
you
know,
obviously,
if
you
see
anything
that
we
could
defer.
That's
super
welcome
as
well
like
you
know,
if,
if
there's
something
that
we
don't
have
to
do
right
away
in
the
alpha,
that
would
be.
That
would
be
awesome
because
then
it
leaves
options
open
to
us.
So
the
goal
is:
get
this
Alpha
out
into
people's
hands,
see
what
works,
see,
what
doesn't
and
and
move
forwards
and
evolve
as
we
go
forwards.
D
Sorry
reference
implementation
of
the
standard
that
we're
proposing
here.
So
a
lot
of
the
cap
is
talking
about
that
standard,
because
we
want
to
make
sure,
like
the
the
label,
basically
that
that's
going
to
work
for
tools,
Beyond
key
control
and
that
this
makes
sense
on
a
fundamental
level
as
the
plumbing
and
then
at
the
end
here,
which
is
now
on
screen.
We
have
like
right
now
fairly
skeleton
proposal
for
what
the
the
reference
implementation
itself
will
look
like.
C
E
E
Labels
are
lightweight
enough
that
Helm,
if
they
want
to,
would
be
able
to
add
those
labels
as
well
and
then
what
you'd
be
able
to
do
is
you'd,
be
able
to
say
like
if
you
were
trying
to
like
prune
an
object
which,
which
helm
was
managing
Coupe
cuddle,
might
be
able
to
say
things
like
hey
hold
on
a
minute.
You
know
this,
isn't
your
object.
Are
you
sure
you
really
want
to
do
that
sort
of
thing?
E
E
Don't
really
know
what
what
potential
there
is
here,
but
like
the
this
is
the
plumbing
for
people
to
do
all
this
stuff
and
the
the
reason
one
of
the
reasons
to
do
labels
is
because
Helm
could
do
this
I
think
relatively
easily
as
an
additive
thing,
so
that,
and
they
wouldn't
have
to
like
change
how
they
store.
You
know
their
objects.
They
wouldn't
have
to
fundamentally
re-architect
they're,
just
adding
a
couple
of
labels
to
be
like
hey
I
own.
E
This
sort
of
like
an
owner's
ref
right
owner's
ref
is
something
they
could
add,
without
sort
of
changing
a
lot
of
what
they're
doing,
there's
a
description
of
why
we
can't
use
owners
drafts
or
why
we
think
we
can
use
it
as
refs
in
there
as
well
the
so
that's
that's
broadly
what
I?
What
I
would
hope
that
all
the
tooling
that
is
out
there
could
opt
in
to
start
using
these
labels
and
would
get
the
benefits
of
like
you
could
cuddle
not
stumping
over
them?
E
One
of
the
reasons
that
we
can't
like
there's
a
long-standing
thing
that
Helm
is
separate
from
crew
cuddle,
and
so
we
can't
integrate
the
two.
So
you
know
from
that
direction.
It
feels
like
we
plumbing
and
Coupe.
Cuddle
is
the
right
way
to
go
plumbing
and
reference
implementation
that
is
ideally
compatible
with
Helm,
but
I
don't
know
if
we
could
do
anything
deeper
from
a
sort
of
this
is
the
deal
type
thing
perspective.
D
D
E
D
E
A
Foreign,
so
I
had
a
quick
question
just
as
a
clarification,
so
my
understanding
of
of
this
I've
already
talked
to
Justin
and
and
I've
and
and
Katrina
and
I.
We
also
talked
in
that
meeting
so,
if
I
understand
this
correctly
we're
storing
the
gvks
and
the
name
spaces
in
an
object
in
the
cluster
and
and
of
course
we
we
need
this
GVK
and
namespace
in
order
to
be
able
to
query
to
determine
what
the
set
of
previously
applied
objects
is.
Is
that
correct?
A
E
E
A
A
If
it's
client
side
apply
we're
going
to
be
retrieving
all
of
the
objects
in
order
to
calculate
the
patch
or
see
whether
or
not
they've
they
exist
and
and
then
the
the
second
prune
step
with
these
gbks
and
namespaces,
we
would
also
retrieve
a
set
of
objects
and,
and
if
there's
nothing
to
prune,
then
those
objects
are
completely
overlapping.
So
we're
retrieving
them
twice.
Is
that
correct.
E
I,
don't
know
if,
if
we
wanted
to
do
a
deeper
refactoring,
which
I
don't
think
we
want
to
do
for
Alpha,
but
if
we
want
to
do
a
deeper
refactoring
like
you
might
say
that
those
two
could
probably
be
combined
and
there
are,
there
are
a
lot
of
things
that
are
going
on
here,
such
that
I
would
like
to
sort
of
try
it
and
see
how
bad
it
is
in
practice.
So,
for
example,
if
you
have,
we
don't
expect
there
to
be
that
many
different
kinds
in
a
typical
apply
set.
E
We
don't
expect
to
be
that
many
namespaces
in
a
typical
apply
set,
so
we
may
actually
come
out
cheaper
in
that
a
list
can
be
fewer
requests
than
I
get
like.
So
we
we,
we
lose
some
on
the
one
side,
but
we
gain
some
on
the
other,
because
we're
using
a
list
which
is
like
scoped
by
the
only
accelerated
query
in
the
API
server,
which
is
like
label
queries.
It's
not.
The
other
thing
that
I
was
sort
of
thinking
about
is
like
we
do
want
to
get
everyone
to
service
at
apply
right.
E
That's
the
that's!
The
the
other
thing.
That's
I
think
motivated
like
your
involvement
here,
right,
Sean,
correct
and
I.
Think
we're
really
thinking
about
server
side,
apply,
I,
think
Katrina
and
I
were
talking
this
morning
about
whether
we
could
there's
some
flexibility
in
or
we're
debating
whether
a
tool
should
name
itself.
E
So,
in
other
words,
shouldn't
apply
to
encourage
the
tools
to
put
an
ID,
and
maybe
there's
some
concern
over
whether
a
server-side
apply
would
still
need
that
initial
get
because
you
want
to
detect
overlapping
or
overlapping,
apply
sets
and
I
was.
We
were
wondering
if
it's
possible
to
do
that,
something
with
the
field
manager
and
map
that
to
the
name
of
the
tool,
and
would
that
actually
be
a
really
nice
Synergy,
but
I
feel
like
this.
E
Is
sort
of
the
thing
where
we
have
to
do
the
do
the
code
and
see
what
shakes
out
there's?
Certainly,
but
yes,
there
is
certainly
the
potential
that
this
could
be
in
the
worst
case
scenario
inefficient
compared
to
other
approaches
like
the
inventory,
where
we
store
a
list
of
every
GB
k
n.
But
my
expectation
is
that
when
we,
when
we
build
that
Alpha
and
put
it
into
customers,
hands
that
we'll
find
that
in
typical
cases
it
is
not
actually
a
significant
performance
issue.
A
G
So
to
tackle
this
problem,
there
will
be
actually
two
issues
that
we
would
have
to
solve.
One
would
be-
and
it
was
approach
in
the
past-
and
there
are
linked
in
the
agenda-
was
to
get
rid
of
the
local
hosts
defaulting
entirely.
Unfortunately,
there
are
other
code
that
relies
on
that
and,
if
I
remember
correctly,
the
dash
dash
local,
if
you
specify
that
and
we
drop
the
default
into
localhost
that
stopped
working.
G
So
solving
both
somewhat
in
parallel
or
one
after
another
would
be
desirable
and
we're
just
looking
for
someone
who
would
be
interested
in
in
picking
this
up.
There
will
be
a
lot
of
digging
through
existing
code
and
ensuring
that
this
is
working
as
it
should
I'm,
not
sure
how
much
code
we
have
with
regards
to
local
and
I.
Think
based
on
the
past
experience
that
we
don't
have
any
tests
around
the
local
invocation
so
yeah.
G
That
would
have
to
be
double
checked
before
we
proceed
with
with
eventual
moves
and
then
also
having
some
kind
of
a
reasonable
mechanism.
I
wonder
because
currently
we
have
the
mechanism
that
should
be
able
to
produce
to
know
whether
a
local
flag
was
specified,
because
the
parametrical
is
one
on
the
track
that
we
have
in
the
generics.
G
Delight
around
times
the
sorry
generation
light
options,
maybe
there
would
be
an
option
to
be
able
to
not
to
require,
because
one
of
the
PRS
linked
there
approached
the
Top
Lane
by
adding
conditions
across
all
the
commands,
ensuring
that,
if
it's
local,
it
should
do
something
else
which
I
don't
think
is
the
right
approach.
I
want
to
see
something
more
structural
with
regards
to
supporting
the
local
or
not
inside,
of
the
the
CLI
options
somewhere
that
this
is
more
like.
G
C
Problems,
one
thing
that
surprised
me
was
when
I
run
poop
cuddle
in
the
cluster
itself
inside
of
a
pod.
Imagine
if
it
works,
because
the
secrets
are
mounted
somewhere
and
not
an
issue.
That
would
surprise
me
because
it
I
wasn't
expecting
it
to
work.
I
was
expecting
not
to
do
something
and
it
just
magically
worked.
That's
not
the
case.
Maybe
where
there
was
seem
like
there
was
a
bit
of
a
gap
in
its
expectation
versus
reality.
G
H
Yeah,
so
this
one
is
gonna
touch
a
lot
of
parts
of
the
stack
from
loading
cubeconfig
to
warning
the
user.
So
if
there's
anyone
who's
kind
of
interested
but
intimidated
in
working
in
this
feel
free
to
to,
let
us
know
you
can.
Let
me
know
I
think
this
might
be
a
good
one
if
we
get
like
a
pairing
group
together
on
if
we
have
a
few
people
working
on
it
together,
because
this
this
will
really
touch
all
parts
of
cube
control.
From
like
loading
to
warning
and
running.
B
Oh
just
to
add
to
that
and
a
similar
issue,
the
issue
issue
number
1340
that
was
assigned
to
me
and
I
thought
it
would
be
a
simple
issue
where
I
have
to
change
the
warnings
and
I
added
a
follow-up
comment
on
that
yeah
issue.
1340
yeah
I
believe
this
is
where
I
needed
help,
and
that
is
what's
what
is
being
discussed
right
now.
So
if
some,
if
someone
can
just
quickly
look
at
the
comment,
last
comment
over
there.
B
H
This
was
adding
extra
column
support,
so
you
could
tack
on
extra
columns
and
his
implementation
was
good,
except
it
dropped
a
bunch
of
client-side
calculated
columns,
and
so
ultimately
he
closed
this
and
didn't
want
to
move
forward
on
it.
I
think
varsha
wanted
to
pick
this
up.
I
don't
know
if
arsha
is
on
the
call
right
now.
H
No
okay
I
can
poke
varsha
on
slack,
but
I
we
wanted
to.
This
originally
was
refreshed
by
a
user
requesting
adding
a
specific
column.
This
one
I'll
put
it
in
the
chat
and
we
don't
really
want
to
add
like
more
flags
for
like
small
specific
columns.
We'd
rather
have
like
a
blanket
people
can
add
the
columns
they
need
feature,
and
so
that's
where
the
stem
from
and
I
put
on
the
agenda,
because
there
was
something
we
had
to
talk
about,
but
I
didn't
write
it
down
on
the
agenda.
H
G
The
printing
is
being
specified
by
the
plus
by
the
cluster,
the
cluster
returns
as
table
objects
which
provide
you
with
specific
values
that
should
be
printed
to
support
the
extra
columns.
We
would
have
to
explicitly
request
that
a
full
object
is
included
as
the
last
column,
which
is
not
a
case
by
default,
but
whenever,
for
example,
we.
H
H
G
For
sorting
the
pots
for
for
drain,
but
I
started
wondering
whether
there
will
be,
if
we
add
respecting
priorities,
if
there
will
be
questions
for
oh
I
want
to
have
yet
another
few
or
something
else,
and
what
kind
of
options
other
users
might
want
to
see,
and
rather
than
adding
one
off.
We
would
try
to
tackle
this
in
a
more
generic
way,
so
that
users
have
a
little
bit
more
freedom.
With
regards
to.
G
Yes
and
basically,
we
would
have
to
figure
out
whether
that
kind
of
approach
would
be
better
and
what
are
the
current
defaults
that
we
have?
We
could
probably
change
the
defaults
as
they
are
if
we
don't
have
any
particular
guarantees
currently
and
then,
rather
than
having
a
one-off,
more
generic
approach
would
be
better,
probably.
J
J
To
deal
with
it
at
all,
well,
the
the
one
thing
that
I
considered
but
never
really
implemented
or
tried
to
implement,
was
specifying
a
list
of
priorities
that
it
would
kind
of
Bucket
look
at
those
spots
in
based
on
the
list
and
not
drain
By
Priority
for
each
single
value.
So,
for
example,
you
could
like
draw
in
a
critical
pods,
then
those
second
level,
critical
chords,
then,
let's
say
priority
above
1000
or
something
like
that.
J
G
I
remember
when
we
were
discussing
this
last
time.
The
first
thing
that
popped
up
in
my
head-
and
you
just
said
it
the
same
way
I
started
wondering
whether
people
will
be
interested
in
when
they
will
be
interested
in
training
by
priorities,
whether
they
will
be
interested
in
draining
criticals
first
and
then
follow
or
in
a
different
order
where
the
protocols
will
be
the
last
one.
H
J
J
J
D
Option
that
might
be
suitable
instead
of
respect
priorities
or
completely
generic.
Maybe
we
have
something
like
a
like
a
order,
mode
flag
that
takes
an
enum
where
we
have
like
all
at
once
or
By
Priority,
and
that
would
give
us
an
extension.
Point
like
matcha
is
looking
for
in
the
future
to
potentially
support
different
ordering
targets
or
strategies
without
having
to
support
everything
arbitrarily
like
running
at
arbitrary
fields,
which
would
probably
be
pretty
difficult
to
implement.
G
G
I'll,
try
talking
with
our
class
results.
I
know
that
they
are
happily
relying
on
the
training
mechanism,
although
they
yeah
they
are
reusing.
The
current
training
drain
implementation
I'll
see
if
they
experimented
with
different
sorting
mechanism
for
for
if
they
did
not
be
curious,
because
we
are
heavily
relying
on
this
mechanism
during
openshift
upgrades,
so
I'll
check
with
them.
What
kind
of
options
are
they
consider
and
I'll
leave
some
comments
on
the
issue.
J
A
J
J
F
F
K
K
Somehow-
and
this
is
just
a
draft
where
I
tried
to
to
do
something
simplification,
but
there's
a
lot
of
questions
that
basically
has
have
to
be
answered
by
by
you
guys
so
I
just
wanted
to
bring
it
up
so
that
someone
can
maybe
have
a
look
there
and
give
me
some
feedback.
So
I
can
I
can
somehow
help
you
finalizing
that.
K
D
A
J
L
G
Basically,
you
went
from
a
simple
by
priority
over
to
enums
through
emails
to
list
which
is
introducing
even
more
complicated
way
of
specifying
how
the
training
should
look
like
I'm
worried
that
by
following
this
pattern,
you
basically
come
into
a
place
where
you
come
up
with
a
simple
DSL,
just
to
be
able
to
specify
that
priority,
and
that's
something
that
I
would
not
want
to
see
happening
in
the
first
place.
So
I
would
prefer
to
go
back
a
step
and
try
to
figure
out
the
actual
problems
that
are
there
before
solving
them.
J
I
D
Right
we
understand
that,
but
at
the
same
time,
when
we
introduce
a
flag
to
Cape
control,
it's
a
pretty
big
deal.
So
we
want
to
make
sure
that
we're
introducing
something
that
is
going
to
serve
us
well
in
the
future,
like
once,
we
have
that
flag.
Is
that
going
to
give
somebody
an
idea?
Well,
I
wish
it
was
ordered
this
way.
D
So
that's
why
match
is
suggesting
that
you
send
an
email
to
kadev
to
solicit
opinions
on
what
those
other
things
like
those
unknowns
might
be,
so
that
it
can
inform
what
your
flag
looks
like
from
the
beginning,
and
we
don't
end
up
handing
ourselves
into
a
corner
where
the
flag
doesn't
actually
work
for
for
a
lot
of
other
legitimate
use
cases
in
this
exact
same
area.
Does
that
make
sense.
C
C
Yeah
yeah
because
schedule,
for
example,
already
takes
into
account.
You
know
the
gangs,
the
groups
of
the
Pod
groups
takes
into
account
preemptability
and
priority
classes,
so
maybe
even
like
a
an
alpha
perspective,
a
cool
cuddle
drain
dash
dash
preempt,
and
then
it
just
asks
the
scheduler,
in
this
case
the
code
scheduler
in
my
example,
which
to
do
a
pre-ent
all
you.