►
From YouTube: Kubernetes SIG CLI 20230405
Description
Kubernetes SIG CLI bi-weekly meeting on April 5th, 2023. Agenda and Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=kix.8q0ykafq42vp
A
Welcome
to
the
April
4th
edition
of
the
kubernetes
6C
live
bi-weekly
meeting
I'm
Sean
Sullivan
I'm
your
host.
We
will
jump
right
into
the
announcements,
there's
not
too
many
of
them,
so
the
release
is
scheduled
for
next
week.
April
11th
on
Tuesday,
that's
version
127.,
and
another
important
announcement
is
that
the
kubecon
EU
in
Amsterdam
is
coming
up.
A
There's
a
link
there
to
register
for
the
contributor,
Summit
and
additionally,
I
think
a
lot
of
work
has
already
been
done,
but
the
six
Eli
annual
report
will
be
merged
by
the
end
of
the
week
and
I.
Think
we've
we've
got
quite
a
bit
in
there,
but
please
have
a
look
at
the
link
and
see
if
there's
anything
else
that
you
think
should
be
shared
with
the
rest
of
the
kubernetes
community
yeah.
So
with
that
does
anyone
else
have
any
other
announcements
that
they
would
like
to
share
with
the
60
Liars.
A
If
not,
we
can
move
on
to
the
next
section,
which
is
where
we
get
to
meet
the
new
members
of
the
6cli
or
people
who
haven't
been
here
for
a
while.
So
if
you
would
like
to
introduce
yourselves
to
the
6cli,
this
is
an
opportunity
to
do
that.
It's
completely
voluntary!
If
you
don't
want
to
that's
fine
as
well,
so
is
there
anyone
who'd
like
to
introduce
themselves.
B
Yeah
I
can
go.
My
name
is
I
worked
with
the
Ericsson,
so
I
have
one
issue
in
the
cube
grain
that
I
want
to
discuss
today.
I
have
I
mostly
work
with
the
metal
cube.
Community
is
a
cluster
is
related
to
the
cluster
API
yep,
that's
mostly
it
from
I,
say
I
just
wanted
to
discuss
my
issue
that
I
have
in
the
kubernetes
here.
A
A
B
Yes,
it's
not
an
issue,
it's
a
small
Improvement
that
I
want
to
do
basically
in
queue
train.
We
have
this
one
callback,
which
is
on
board
deleted
or
evicted.
I
would
like
to
have
a
few
more
callbacks.
When
we
start
the
eviction
process,
we
will
should.
We
can
add
another
call
Deck
and
also
if
the
the
eviction
or
the
tradition
is
failed,
we
can
send
another
callback,
but
the
why
we
are
doing
is
why
I
want
to
do.
B
This
is
because
we
are
using
this
Cube
brain
in
cluster
API,
a
controller,
and
there
are
sometimes
some
ports
stuck
get
stuck
in
the
eviction
process
and
it's
really
difficult
to
find
which
Port
is
stuck
in.
So
with
this
callbacks,
we
can
have
like
more
granularity
on
the
on
this
direction
process
and
we
can
report
them
easily
where
we
want.
I
would
like
to
know
if
it's
okay,
if
this
thing
makes
sense
or
is
there,
what
are
the
comments
of
the
6li
Community
like.
C
C
D
E
E
E
It's
more
so
like
we
expose
things
that
we
need
for
other
commands
in
other
places.
I
know.
In
the
past
we
have
decided
to
expose
things
that
people
needed
or
made
a
couple
changes
to
what
we
Expose
and
I
think
I'm.
Okay,
doing
that
in
general,
with
the
understanding
that
it's
not
a
version
guarantee
API,
and
if
we
need
to
change
something,
we
might
change
it
and
not
know
who's
using
it.
C
No,
it
was
just
poking
around
the
the
drain
helper
to
see
what
code
we're
talking
about
modifying
here,
because
I
have
that
same
sentiment
like
I.
Don't
have
any
objection
to
having
that
functionality,
but
given
that
this
is
mostly
built
for
cube,
cuddles
needs
and
maintained
for
that
and
it's
the
helper,
it's
not
part
of
the
like
main
surface.
C
B
E
Yeah
I'm
I'm
in
favor
of
that
it
sounds
like
Katrina
would
be
too,
with
the
caveat
that
we
don't
like
version
or
guarantee
compat
for
especially
helper
commands
like
that.
Probably
would
be
not
a
reason
to
break
it
in
the
future.
It's
probably
been
pretty
stable
that
helper
for
a
while,
but
that's
just
kind
of.
Like
the
general
caveat
we
have
there.
B
B
F
F
Excuse
me
so
we've
had
a
couple
issues
that
have
come
up
and
this
is
related
to
it's
sort
of
a
very
special
case,
but
if
you
have
a
pod
that
has
multiple
containers
and
one
of
so
that
I
put
the
three
things
that
have
to
happen
there.
Oh
wait!
Sorry!
Sorry,
if
you
can
look
at
the
the
overview
that
I
linked
on
the
third
link
there,
okay.
F
F
Let's
scroll
down
to
the
example
to
illustrate
the
problems.
So
this
here's
an
example
of
a
pod,
the
pod's
called
unlimited
container
and
it
has
two
two
containers.
One
of
them
has
a
CPU
limit
of
50
and
a
memory
limit
of
200
and
then
the
second
container
bar
has
no
limit.
It
has
some
requests,
but
it
doesn't
have
a
limit.
So,
in
this
case,
yeah
so
I
just
summarized
what
I
said
there
in
the
table
and
if
you
scroll
down
a
little
bit
farther
I,
ask
the
question
like
well
based
on
that
configuration.
F
What
what
should?
What
would
you
expect
that
the
the
CPU
limit
be
for
the
overall
pod?
Should
it
be
50
or
unlimited,
given
that
I
think
it's
intuitive,
that
it
would
be
unlimited,
because
there's
two
containers
one
has
a
limit
and
the
other
does
not.
Therefore,
the
overall
pot
is
unlimited,
but
if
you
do
a
coupe
cuddle
describe
node,
you
see
something
that's
kind
of
confusing
so
down
there,
the
fifth
pod
there,
my
my
pod,
the
unlimited
container.
F
F
So
as
soon
as
you
have
one
container,
that's
unlimited
effectively,
there's
no
limit
on
the
overall
resources
on
that
node,
I,
guess
I'm,
not
sure
I'm,
not
sure
so
I
I
put
all
these
I
tried
to
kind
of
summarize
what
the
problem,
what
the
questions
are
and
the
open
questions
section
down
below
and
I
guess.
This
came
up
in
the
bug
scrub
and
a
couple
years
ago.
F
I
did
my
PR
there's
actually
several
places
that
where
a
similar
calculation
was
performed,
but
not
in
exactly
the
same
calculation
and
it's
a
little
confusing
to
to
figure
out
exactly
what
it's,
how
it
interprets
that
since
then,
it
looks
like
some
work
has
been
done
in
the
API
to
to
unify
all
those
different
places
that
it
previously
was
calculating,
but
we
still
have
two.
We
still
have
our
way
of
showing
what
we
think
the
limits
are
and
the
real
way
and
far
as
I
can
tell
they
are
pretty
similar,
so
I.
F
Don't
necessarily
think
that
that
we
are
different
than
the
way
it's
really
happening,
but
I
guess
there's
a
couple
main
questions.
First
of
all
is
50
the
right
number
to
show
there
and
second
of
all,
if
it,
if
it,
if
it
is
correct,
maybe
you
know,
maybe
we
should
be
showing
a
warning
or
a
notification
that
says:
hey
you
know
one
or
more
containers
is
unlimited.
Therefore
this
number
is
not
accurate
or
may
not
be
accurate
and
and
so
on
and
so
forth.
So
I
guess
I've
said
a
lot
there.
Does
that?
B
A
E
Yeah
I
know
that
this
is
a
general
Community
issue
like
I'm,
pretty
sure,
there's
tons
of
blog
posts
written
about
explaining
not
to
use
a
request
without
a
limit
and
I
know.
This
is
like
pretty
sure
this
is
part
of
the
ckad
or
one
of
the
kubernetes
certifications.
They
they
ask
and
test
you
on
this
scenario,
but
I
agree.
It's
very
confusing
and
I've
had
people
bring
it
to
me
a
few
times.
F
I'm
not
so
sure,
on
the
API
side,
if,
if
it
really
is
unlimited,
it
might
actually
be
50
in
this
case,
I'm
not
I'm,
not
even
sure
that
what
we're
showing
is
wrong
and
I
looked
at
it
a
little
bit
and
haven't
had
as
much
time
as
I'd
like
to
kind
of
dig
in
and
really
find
out.
If
it's
really
50
or
unlimited
I
mean
maybe
what
we're
showing
is
exactly
right
and
we
just
need
to
explain
it
better.
F
F
Stamp,
that's
a
good
point.
There
was
a
lot
of
discussion
or
a
fair
amount
of
discussion
on
that,
and
in
fact,
the
code
that
my
PR
was
changing
has
actually
changed
since
then,
so
it's
possible
that
there
have
been
changes
made
since
my
PR
was
kind
of
old
like
a
year
and
a
half
old.
So
so
it's
possible
that
that
something
was
changed,
looks
like
they
cleaned
it
up
and
unified
all
the
different
places
where
it
was
previously
calculated.
C
Yeah
I
agree
that
the
the
important
thing
is
that
we're
accurately
reflecting
what
what
happens
that
we're
giving
correct
information
and
I
don't
think.
First
thing
is
the
one
that
has
the
answer
and
what
that
behavior
is
I,
think
that
would
be
Sig
note
or
Sig
scheduling,
probably
sick.
Note
based
on
the
discussion,
if
I'm
skimming
it
correctly,.
G
It
it
can't
that
the
pr
that's
I
think
it
was
on
screen
right
now.
It
seemed
like
it
it
reached
like
we
got
the
right
people
looped
in
everything
was
going
well
like
it
seems
like
we
probably
shouldn't
have
closed
it
right,
like
we
shouldn't
start
a
new
PR
and
like
make
everyone
repeat
the
same
process
right.
F
F
E
G
F
G
F
D
D
B
F
A
F
Yeah
I
can
take
that
I.
Guess
I
guess
my
my
thinking
is
probably
there's
two
two
things
here.
One
is
from
Coupe
cuddle's
perspective.
We
want
to
show
what
is
accurate,
but
from
the
api's
perspective
there
there
may
or
may
not
be
a
change
needed
there,
but
it's
sort
of
like
independent
of
of
what
we
do
so
I
guess
from
from
our
six
perspective.
F
If,
if
I
can-
or
you
know,
if
I
I
or
somebody
else
can
figure
out
what
the
actual
behavior
is,
then
we
can
make
sure
that
we're
reflecting
the
actual
Behavior
first.
So
that
sounds.
That
sounds
like
actually,
maybe
that's
where
it
ends,
since
the
the
behavior
is
the
API
and
the
comment
I
saw
that's
basically
saying
hey:
if
you
change
this
function,
that's
an
API
change
that
needs
to
be
API
reviewed.
Is
that
what
everybody
else
is
thinking
here
is
that
our
primary
goal
just
needs
to
be
to
reflect
the
way
it
works.
F
C
C
Only
thing
I
would
add:
is
that
like,
if,
if
that
turns
out
to
be
unintuitive
like
the
real
Behavior,
turns
out
to
be
what
people
are
reporting
to
us
as
a
bug,
we
might
want
to
ensure
that
the
the
there's
proper
documentation
of
the
way
that
it
really
is
beyond.
You
know
our
display
being
correct
so
that
when
we
have
those
issues,
we
don't
have
to
go
through
the
whole
digging
digging
up
whether
or
not
this
is
right
again.
D
E
A
H
H
There's
the
biggest
one
is
pretty
much
a
coupe
conform
or
cube
valve
Cube
Val
is
currently
deprecated
and
points
new
users
to
Coupe
perform
they're
based
on
popular
Json,
schema
libraries.
So
first
they
convert
the
kubernetes
schema
the
Json
schema
and
then
validate
objects
based
on
that,
so
right
out
the
right
out
of
the
box,
they
kind
of
just
don't
support
big
custom
kubernetes
validations
that
we
want
to
do
this
chart
kind
of
shows.
H
We
would
probably
want
a
first
party
Upstream
supported
solution.
The
second
column
is
a
quick
prototype
tool.
I
made
that
does
have
some
problems,
but
it
definitely
improved
the
situation
for
all
the
kubernetes
specific
validations
and
addition,
in
addition
to
catching
everything
that
kubeconform
can
catch.
There
are
some
gaps
with
the
open,
API
spec
itself,
but
we
also
have
on
my
team.
Someone
is
working
on
a
proposal
to
change
kubernetes
types
to
use
open,
API
more
in
their
validations,
rather
than
the
hand-coded
native
type
validation,
so
that
should
improve
over
time
yeah.
H
The
third
solution
people
have
is
driver
and
client,
which
is
based
on
open,
API
V2
and
the
a
handwritten
open,
API
validator,
that's
in
the
Kube,
open,
API
repo,
it's
pretty
feature
incomplete,
doesn't
catch
most
things
and
I.
Think
a
good
end
state
for
this
project
is
to
not
only
have
a
standalone
tool,
but
also
to
link
it
back
into
cuddle
and
use
it
for
the
client-side
validation
when
it's
doing
its
create
edit
supplies,
Etc
so
yeah
to
serve
dry
run.
H
Server
side,
of
course,
is
going
to
catch
everything,
so
that's
something
that
people
do
end
up
doing
they'll
start
up
a
kind
cluster
apply
all
their
objects
to
it
and
just
try
directly
against
the
cluster.
That
way.
Problem
with
that
is,
that's
really
slow.
You
know
spin
up
a
kind
cluster
to
test
on
it.
You
can't
really
do
it
like
interactively
in
an
IDE,
so
a
client-side
offline
tool
is
probably
the
best
way
to
go
about
this.
H
What
I'm,
looking
for
from
this
sig
I
guess,
is
a
kind
of
a
sanctioned
approval
that
this
is
something
we
want
to
do
there.
You
know
we
do
already
have
precedent
with
the
dry
run
client,
it's
just
not
as
good
as
it
could
be
how
we
want
to
do
this.
We
like
whether
we
want
to
open
up
a
new
repo
in
6ks
IO
or
continue
I.
Think
this
most
of
the
code
for
the
current
implementation
is
in
Cube,
open
API.
So
that's
definitely
an
option
to
put
things
in
that
Library
there.
H
A
So
so
I
would
just
add
that
I
think
that
this
is
this
idea
of
a
client-side
validation
is
becoming
more
and
more
important,
as
we've
moved
a
lot
of
the
validation
to
the
server
side.
There's
kind
of
this
Gap,
where
client-side
validation
is
becoming
more
challenging
and
and
so
this
actually
something
that
is
kind
of
sanctioned
by
the
6
Eli
Maybe
very
helpful.
A
Since
we
don't
really
have
a
say
in
how
Coop
conform
works,
kubel
is
is
deprecated
and
if
we
sponsor
a
particular,
this
particular
tool,
which
appears
to
be
a
Quantum
Leap
better
than
then
we're
going
to
have
a
lot
better
say
on
how
that
works,
and
it
kind
of
fits
within
our
our
Charter
very
well.
I
believe.
C
Everything
schema
wise,
that's
possible,
but
there's
always
going
to
be
some
cases
that,
without
hitting
the
real
API
server,
specifically
the
one
that
you're
targeting
and
that
has
all
of
the
the
policies
in
place
that
that
you
are
actually
going
to
deploy
against.
You
can't
be
a
hundred
percent
sure
that
doesn't
mean
that
it
isn't
useful
to
have
something
that
catches.
C
The
vast
majority
of
issues
at
CI
time
I
completely
agree,
but
I
just
wanted
to
bring
that
up
because
I
think
that's
something
we
usually
talk
about
in
these
conversations
and
the
other
question
big
question
that
I
have
I
guess
is
is
around
like
if
the
Sig
is
going
to
sponsor
a
solution
to
this
I
guess
our
current
one,
which
you've
pointed
out
rightly
in
the
table,
is
the
dry
run
equals
client.
You
know
that's
baked
into
Cube
control
and
people
do
use
that
for
validation
today.
C
So
is
our
ultimate
goal
just
to
provide
a
separate
Standalone
tool
that
would
maybe
be
exposed
as
a
crew
Plug-In,
or
are
we
experimenting
and
potentially
going
to
bring
something
into
Cube
control
bopper,
but
it
replaced
dry,
run
equals
client.
So
if,
with
those
kind
of
questions
that
push
me
towards
like,
maybe
we
do
need
a
quick
pep
but
I'm
not
I'm,
not
saying
for
sure.
C
It's
just
I
know
that,
for
example,
the
pruning
effort
that
we
did
a
number
of
years
ago,
I
think
it
was
chartered
something
like
2017
2018
as
a
separate
sub-project
and
that
ended
up
not
really
being
brought
back
into
Cube
cuddle
is
originally
intended
because
there
wasn't
an
explicit
plan
to
do
so
and
we're
now
we're
now.
Finally,
addressing
that,
with
a
with
the
full
cap
that
that
we
are
just
implementing
for
127,
so
I
just
want
to
kind
of
tackle
up
front
like
what.
C
What
do
we
see
like
the
end
user
experience
that
we're
going
to
recommend?
Are
we
going
to
tell
people
we're
going
to
deprecate
during
people's
client
we're
going
to
replace
it,
we're
going
to
enhance
it,
we're
going
to
have
a
separate
built-in,
or
is
it
ultimately
like
a
crew
plug-in
that
would
level
alongside
what
they
do
today?
H
I'm
not
sure
what
other
people's
think,
but
I
think
the
best
fit
would
be
to
publish
this
as
like
a
coupe
cuddle
plug-in
that
people
invoke
Standalone
and
also,
but
it's
also
available
as
a
library
that
could
cuddle
might
Link
in
the
future,
but
definitely
integrating
into
pedals
not
wouldn't
be
my
first
priority.
The
first
priority
would
be
to
get
the
Standalone
tool
so
to
integrate
into
Cube
cuddle
like
I,
see
what
you
mean
that
it
would
require
cut.
C
C
Sorry,
can
you
rephrase
that
so
we
do
have
a
lot
of
restrictions
on
how
we
can
Implement
things
in
Cube
Kettle,
and
what
what
kubernetes
kubernetes
projects
can
depend
on
I?
Don't
remember
the
specifics
of
it,
but
the
sub
command
for
it
convert
there
we
go
Cube
cuddle
convert
originally
was
a
sub
command.
We
had
to
pull
it
out
and
it's
published
as
a
crew
library
for
dependency
reasons,
if
I
understand
correctly
so
I'm
wondering
if
we
have
the
same
issue
here
or
if
that's
not
a
relevant
concern.
H
I
haven't
looked
deeply
into
that.
My
initial
gut
feeling
is
that
there
probably
shouldn't
be
any
dependency
problems,
I'm
using
pretty
much
only
kubernetes
dependencies
from
from
KK,
and
you
know,
they're,
it's
a
kubernetes
dependencies
and
the
whole
transitive
chain
of
those,
so
I
haven't
really
pulled
in
anything
extra
outside
of
that
I'll.
Definitely
look
into
that.
A
The
the
coupe
cuddle
convert
issue
was
that
it
had
to
it
in
order
to
do
the
convert.
You
have
to
depend
upon
the
internal
version
of
objects
which
is
not
supposed
to
be
dependent
on
it's
not
supposed
to
get
outside
of
the
API.
So
there
was
that
one
particular
sub
command
that,
because
we
wanted
to
keep
it
had
to
be
pulled
out,
you're
right
for
dependency
reasons.
E
C
Yeah
and
one
more
thing
like
we
do
have
a
validate
flag.
Specifically,
maybe
that's
worth
like
this
validate
is
strict,
strict
Warner
ignore
and
it
uses
server-side
validation,
if
possible.
So
I
think
if
we're
talking
about
like
what
what
validation
strategies
the
Sig
offers
and
we'll
recommend
that
that's
a
good
one
to
include.
C
A
A
And
for
for
Brian
and
Arta
Marley
anyone
else,
who's
interested
in
websockets
I,
as
I
mentioned
before
I
sent
the
document
actually
I'll
just
put
the
document,
the
URL
in
the
in
the
notes
about
transitioning,
from
from
Speedy
to
websockets
and
and
so
this
this
particular
item.
This
particular
issue
has
been
going
on
for
eight
years
and
so
there's
a
significant
amount
of
context,
and
so
that's
the
the
URL
for
that
particular
document.
So
I
wanted
to
to
centralize
and
organize
the
did.
A
It
touches
multiple
parts
of
the
system.
It
touches
everything
from
Coupe
control
to
the
API
server,
API
server
proxies
to
kubelet
and
then
kublet,
actually
even
proxies
to
The
Container
runtime.
So
in
in
the
code
that
I've
been
debugging,
I've
actually
been.
You
know,
writing
log
statements
in
all
of
these.
These
elements
and
I
tried
to
actually
include
all
of
those
nitty-gritty
details
on
how
using
kind
that
was
the
the
development
environment.
I
was
using
the
kind,
a
kind
cluster.
A
A
So
you
guys
can
just
go
ahead
and
change
the
document
as
it
is
and
and
please,
if
you
get
the
chance
you
know,
let
me
know
whether
or
not
you
can
you
can
build
the
container
D
that
container
runtime,
that's
vendoring
in
the
API
server
websocket
code.
You
know
that
that
whole
debugging
cycle
is
is
pretty
involved
and
if
you
get
the
chance,
let
me
know
what
what
you
think
about
that
and
whether
or
not
it's
explained
or
if
you
have
some
better
health,
better
ways
of
doing
that.