►
From YouTube: Kubernetes SIG Node 20211109
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
Hello,
it's
on
november
9th
2021.
It's
a
weekly
signal
meeting
welcome
everybody.
Today
I
chant
the
a
in
plus
input
and
play
sport.
Vertical
skellig
is
renee.
Here
I
forgot
to
check.
A
So
what
was
the
question?
Your
item
is
first
and
agenda
if
you
want
to
start
with
that.
B
Yeah,
okay,
I
think
this
is
mostly
a
status
update
and
check
on
where
we
are
with
with
getting
the
reviews
done.
So
it
looks
like
what
we
have.
I
was
in
the
sick
node
meeting
last
week
and
discussed
the
changes
that
wong
wei.
Basically
for
sorry,
six
scheduling
still
haven't
had
my
coffee,
yet,
okay,
the
six
cadillac.
C
B
Where
they
had
some
requested
some
changes,
I
did
that
over
the
weekend.
I
think
I
was
able
to
figure
it
out
myself
without
needing
any
help
from
anybody
else,
and
so
far
it
looks
like
we
should
be
on
track
to
getting
the
getting
a
sign
off
from
six
scheduling.
I'm
gonna
ping
one
way
sometime
this
week
and
see
where
he
is
at
we
need.
I
don't
know
if
alan
tau
and
lana
had
a
chance
to
look
at
my
changes
in
the
cubelet,
mainly
catched
up
with
the
latest
code.
B
There
were
some
changes
with
the
memory
qos
part
of
it,
which
I
needed
to
look
at
closely
and
then
one
of
the
changes
was
that
learned
how
it
requested
was
not
to
store
v1
resources
in
the
container
status.
The
cube
container
status,
which
I
did
storing
it
in
the
resource
in
a
platform
agnostic
way
for
now,
and
using
that
to
compare
when
we
call
the
changes
that
he
had
requested
to
call
get
pause
status
before
doing
the
comparison
check
for
compute
resize
that
didn't
work,
I
tried
it.
B
D
Have
started
reviewing
it,
I
spent
about
an
hour
on
it
and
I
got
halfway
through
one
commit,
so
it's
very,
very
large.
It's
going
to
take
some
time.
I
have
found
some
stuff
in
the
api
review
already
and
I
haven't
even
started
looking
at
the
actual
cubelet
implementation.
So,
okay,
I'm
sure
people
will
look
at
it
because
it's
very
large
and
because
again,
this
kind
of
like
wasn't
really
marked
for
ready
for
review
until
like
kind
of
late
in
the
cycle.
D
E
Yeah,
I
also
revealed
the
cubelet
part
this
morning
and
I
think
I
I
mentioned
several
issues
before
and
I
based
on
my
understanding
most
of
them
also
so
so
for
the
code
refactoring,
I
mean
the
code
cleanup
part
I
think
you
already
addressed
most
of
them
and
in
terms
of
the
architectural
or
logical
improvement
I
I
think
most
for
most
of
them,
you
I
did
you
just
added
to
do
for
beta,
which
could
be
fine,
but
still,
I
think
there
are
still
two
open
comments
not
resolved
and
especially
for
the
poor
part
cash
thing,
because
I
don't
think
the
behavior
is
is
correct.
E
I
think
it's,
it
may
introduce
risk
conditions,
so
I
hope
that
which,
which
is
exactly
the
the
thing
mentioned,
the
the
gut
part
data
is
before
deep
and
I
don't
quite
understand
why
it
didn't
work.
I
just
posted
a
comment
on
your
change,
so
please
take
a
look
and
reply
there
and
we
can
discuss
on
your
pr.
Okay,.
B
Yeah
yeah:
let's
see
if
we
can
get
traction
on
this
and
slack,
then
we
can
figure
it
out
this
week.
I'll.
If
you
have
time
for
a
zoom
call,
I
can
go
over
why
it
didn't
work
and
the
api.
I
don't
think
the
there's
any
changes
tim
hawkin
had
already
signed
off
on
it.
D
I
didn't
see
an
actual
api
approval.
I
saw
kind
of
a
soft
yes,
so
I
went
through
and
reviewed
and
I
caught
a
few
more
things.
So
tim.
D
F
B
And
when
we
get
close,
another
set
of
changes
come
in
and
we
revisit
this
whole
thing.
This
is
crap,
it's
getting.
It's
really
getting.
D
D
And
there
are
there's
a
bunch
of
work
that
needs
to
get
done
as
atlanta
said,
and
I
I
noticed
these
things
in
my
last
review
before
there
are
a
bunch
of
architectural
issues
with
how
this
is
wired
into
the
cubelet.
We
appreciate
your
patience,
but
it
has
to
meet
the
code
quality
bar,
so.
C
I'm
sorry
I
was,
I
was
sick,
and
so
I
think
that
everyone
do
their
best.
I
understand
relay-
and
this
is
a
drag
too
long
because,
like
more
than
two
years,
but
the
elena
is
our
apm
reviewer
from
the
sig
node
and
she
raised
some
concern.
I
think
the
atlanta
also
also
because
don't
know
the
background.
The
context
so
so
can
ana
share
your
concern
about
api
level
stuff.
C
Then
we
can
see
that
how
we
are
going
to
best
continue
to
move
forward
because
there's
also
because
from
the
this
particular
feature-
and
we
may
already
receive
of
the
approval
last
round
so
so
expectation
we
can
understand
expectations
aside
from
move
forward
from
based
on
the
epa
or
poor,
but
we
all
understand
how,
during
the
development
phase,
we
may
find
more
issue
doing
that,
so
a
software
always
have
to
iterate
right.
So
so
I
understand,
what's
the
the
winning
came
from
and
because
it's
been
so
long
and
it's
really
expected
kubernetes.
C
So
that's
that's
why
pharmaceuticals
expected
the
kubernetes
and
the
know
the
level
of
the
change?
So
so
that's.
Let's
share
of
the
comment
and
see
what
can
be
moved
forward
to
earn
of
the
alpha
and,
and
what
have
to
address
by
the
alpha
is
that
okay
and-
and
I
understand
right
now-
it's
like
the
it's
really
it's
very
powerful
for
everyone,
and
because
many
people
join
and
for
relay.
C
This
is
take
long
and
for
atlanta,
because
it's
just
pick
up
this
one
and
and
all
the
sudden,
and
so
some
of
the
background,
the
contacts
don't
know
and
but
because
analysts
represent
of
the
signal
for
the
aps,
sorry
know
the
level
of
the
api
change.
So
there's
the
huge
responsibility,
so
we
need
to
care
about
of
the
maintenance,
long
term
and
also
reliability.
C
So
from
the
different
perspective,
there
are
different
opinion.
Let's
just
share
from
the
pr
and
carry
on
from
the
from
the
chat
and
also
offline.
Discussing
and
kap
together
is
that
okay.
A
I
think
renee
may
have
dropped
from
the
call
so
yeah
we.
We
definitely
need
to
move
it
forward
and
I
just
checked
the
list
of
all
pr's
all
caps
for
this
milestone
and
we
have
similar
situation
for
many
of
them
that
are
not
currently
merged.
We
have
like
two
or
three
merged
already,
like
ephemeral,
containers,
pod
resources,
api
extension
and
cpu
manager
for
extension,
like
improvement,
but
all
that
all
other,
like
they
change
in
all
the
time
there
is
like
grpc
improvement.
A
That
is
a
very
straightforward
cap,
but
even
that
cap,
like
just
last
week's
team,
up,
improves
the
api
of
port
spec,
so
handlers
will
be
separate,
so
this
pr
needs
to
be
rebased
now
and
review
it
again.
So
yeah,
it's
always
something
happening,
and
I
afraid
that,
since
quote,
freeze
is
very
soon.
We
may
miss
many
caps
in
this
in
this
milestone.
A
Yeah,
I
also
want
to
make
sure
that
everybody
understands
we
are
also
working
on
a
couple.
Duplications
right
now,
like
docker
stream,
is
going
to
be
dedicated
next
release,
so
we
need
to
help
customers
there
and
the
dynamic
config.
We
also
want
to
clean
up
this
code,
and
it
also
takes
time
of
maintainers
and
people
contributing.
A
Okay,
let's
move
on
to
next,
I
think
ronald
ford
admission
handler.
F
Can
everyone
see
me?
Oh,
I
just
wanted
to
follow
up
on
the
kept
that
we
had
and
derek
had
a
few
questions
like
why
can't
we
use
native.
So
let
me
give
a
bit
of
context.
First,
I'm
from
aws
and
we
run
fargate
we
provide
eks,
fargate
and
eksfargate
does
not
allow
privileged
parts.
Today
we
have
written
like
code
internally,
which
would
basically
scan
the
part
spec
and
see
if
it's
a
privileged
context
or
not
and
through
a
admit
handler,
it
would
reject
that
pod.
F
We
want.
We
want
to
upstream
that
as
form
of
plugins.
So
what
we
want
to
do
is
essentially
introduce
admit
handler
that
would
talk
to
certain
plugins
that
can
only
understand
node
label
properties.
That
could
be
like
if
a
node
cannot
support
privilege
but
part
as
in
in
the
case
of
target,
then
it
would
reject
it.
That's
the
context.
F
F
F
So
if
you
use
any
kind
of
admission
policies,
any
cluster
administrator
can
change
those
also,
we
even
demon
sets
cannot
be
like
privileged
or
static.
Parts
cannot
be
privileged,
as
of
today
like.
That
is
what
we
think.
That
is
how
we
think
about
things,
so
questions
so
far.
A
Yeah,
I
remember
you,
you
also
showed
the
flight
deck
last
time
you
you've
been
here,
and
so
you
got
an
update
on
enhancement.
F
I
have
not
like
updated
it.
I,
so
the
language
is
the
only
thing
that's
left,
but
I
wanted
to
unders
to
make
sure
like
the
use.
Cases
are
clear.
I
can
share
my
screen
and
I
can
show
where
I
am
at
cap,
but
like
in
terms
of
alternatives.
Is
there
anything
that
I
need
to
think
about
as
well
as
to
like
or
like?
I
wanted
to
see
like
if
this,
if
this
in
general
sounds
useful
to
like
in
terms
of
use
cases
as
well,
so
that's
one.
F
The
second
thing
is
like
if
we
like,
if
we
as
an
aws
would
help
would
finish
the
camp
by
the
end
of
this
year,
like
our
version
and
then
sent
for
approvals,
can
we
possibly
finish
when
would
like?
Assuming
everything
goes
well?
How
soon
should
I
get
the
code
as
a
pr
out
so
that
it's
it's
fairly
understandable,
so
that
I
can
go
and
like
plan
out
as
well
with
other
folks.
A
If
you
put
some
use
cases,
maybe
you
can
review
them
and
read
them
offline.
I
think
we
discussed
last
time
that
there
are
definitely
some
use
cases.
You
just
need
to
understand
how
it
feeds
into
into
other
priorities
and
whether
we
can
prioritize
it
and
run
with
it.
So
yeah.
If
you
put
use
cases,
let's
review
some
of
them
yeah
and,
as
you
see
right
now,
everybody
busy
with
card
release,
so
I
think
you
may
expect
some
reviews
after,
like
quote
freeze
for
this
milestone
case.
F
So
yeah
the
way
I
was
thinking
about
it
was
like,
probably
by
december.
We
would
do
our
part
through
the
cap
and
everything
and
next
we
would
target
it
for
1.24,
so
that
everyone
gets
some
breathing
room.
I
don't
want
us
to
discuss
and
get
it
reviewed
right
now.
I
just
wanted
to
make
sure
like
take
some
action
items
for
myself
and
like
get
it
if
there's
any
from
whatever
I
have
communicated.
F
A
One
thing
you
may
want
to
do
is
to
go
to
seek
security
and
talk
with
to
understand.
Like
I
mean
your
poll
admission
thing
will,
will
allow
some
like
to
secure
your
workload,
so
you
want
to
protect
one
actor
from
another
actor
and
that
may
need
some
security
considerations.
So
just
a
small
advice.
What
you
can
do
before
continuing
with
cap
reviews.
F
Definitely
that,
yes,.
A
It
really
depends
on
what
kind
of
promises
you
want
from
this
plugin
to
give
you
and
what
kind
of
security
you
expect
so
yeah.
That
might
be
a
good
forum
for
you
to
discuss.
A
Yeah,
thank
you
for
bringing
it
in.
I
think
the
next
one
is
myself.
We
need
to
discuss
this
cap
and
pr
to
switch
sierra
api
to
v1
so
right
now
there
is
a
agreement
that
latest
pr
from
sasha
is
something
that
looks
promising
the
most
promising
the
problem.
With
this
pr
I
mean
it
was
discussed
and
we,
I
think
it's
in
a
decent
shape
right
now.
The
problem
with
this
pr
is,
it
will
put
users
of
v1
alpha
2
at
this
advantage,
because
those
apis
will
run
slower.
A
A
They
haven't
performed
this
advantage
and
the
question
the
real
question
we
want
to
understand
is
what
kind
of
timelines
we
have
for
container
d,
so
container
d
1.6
needs
to
be
released,
so
customers
at
least
has
this
option,
and
ideally
a
1.5.
A
There
is
a
pr
in
1.5
container
g
to
back
port
v1
support,
and
we
want
to
understand
how
to
like.
Can
we
release
this
card
fix?
At
least
at
the
same
time
as
kubernetes
will
be
released,
otherwise,
once
kubernetes
is
released,
every
container
the
user
may
be
a
disadvantage
because
of
the
performance
heat.
G
Yeah-
and
I
think
that
yeah
this
is
the
123
right
like,
ideally,
I,
as
you
said
right
like,
I
feel
the
right
way
really
is.
If
you
want
to
support
it
on
the
one
phi
x
to
get
that
v,
one
proto
added
like
it's
exactly
the
same,
so
I'm
I
don't
feel
like
super
motivated
and
as
we
discussed
in
the
previous
meetings
like
the
cubelet
and
the
community,
are
having
to
bear
the
overhead
of
maintaining
two
versions
of
the
cri,
both
in
terms
of
additional
code
and
in
terms
of
the
performance
overhead.
G
So
unfortunately,
mike
is
out
today,
so
I'm
not
sure
we'll
get
an
answer.
Maybe
we
can
just
sync
with
him
on
the
timelines
for
the
port
to
one
phi
and
what
the
release
for
one
six
is
looking
like.
A
Yeah
I
wanted
to
ask
a
question
like
if,
theoretically,
we
postponed
it
to
124
and
it
will
be
like
docker,
sim
removal
and
v1
us
transition
at
the
same
time,
and
by
that
time
we
will
sure
have
container
g
reduced
and
already
in
use
how
much
it
will
like
how
bad
will
it
be
like?
Is
there
some
disadvantage
from
with
this
approach?.
G
The
disadvantage
really
is
just
we
are
just
delaying
it
even
more
other
than
that.
I
don't
see
a
huge
disadvantage.
G
A
Okay,
so
let's
get
some:
let's
wait
for
mike
to
come
back
and
understand.
What's
the
timeline
for
the
users?
Okay,
it's
my
my
only
concern,
I
think
all
other
concerts
about
rest
in
this
pr.
So
if
we
can
get
cut
energy
like
releases
lined
up,
we
can
go
ahead.
G
H
I
understand
I
understand
that,
but
on
our
hand,
like
many
users
are
still
using
the
docker
shin
and
docker
stream,
it
means
like
three
layers
of
serialization
or
well
api
conversions
between,
like
coblet
to
docker,
docker,
to
contain
reapi
and
so
on.
So
what
we
are
talking
potentially
is
something
with
users
hard
to
notice.
I
would
say.
D
I
probably
would
suggest
that
the
users
that
have
performance
concerns
aren't
going
to
be
using
docker
shim
at
this
point
like
the
cri
has
been
well
supported
for
quite
a
long
time.
I
I
took
this
one
to
api
review
and
there
were
pretty
big
concerns
about
always
doing
this
internal
conversion
in
the
cubelet
like
we
want
to
avoid
doing
that
as
much
as
possible.
We
don't
really
want
to
support
two
versions
if
possible.
D
The
biggest
stepping
block
here
is
the
fact
that
container
d
still
doesn't
have
support
for
v1,
but
because
they're
identical
at
this
point.
Probably
the
easiest
path
forward
is
to
support
both
for
now
fall
back
if
the
runtime
doesn't
have
v1
and
then
as
soon
as
v1
and
v1
alpha
2
diverge
drop,
v1,
alpha,
2
support.
A
Yeah,
well,
it's
reasonable
and
yeah.
I
don't
want
to
act.
What
elana
says
like
oh
high
performance
customers
like
the
a
lot
of
hyper
ones,
customers
already
switched
to
continuity,
so
that
may
be
I
mean
we
might
affect
people
who,
like
kubernetes,
the
most.
A
Okay,
next
item
is
mine.
I
wanted
to
just
advertise
this
caps
that
I
wrote
for
test
label
cleanup.
I
already
presented
the
document
like
as
it
was
in
google
doc,
and
then
I
took
some
time
to
write
the
cap
because
other
priorities
but
yeah.
If
you
have
cycles
to
review
some
of
the
cleanup
proposals,
please
do.
A
I
would
really
appreciate
it
and
it's
written
as
cab
for
tests
seek
testing
mostly
because
it
started
as
a
sig.
Not
only
cleanup
and
we
didn't
want
to
do
any
caps
or
any
clarification,
but
investigation
shows
that
we
may
extend
it
a
little
bit
more
and
that's.
Why,
like
it
is
a
cap,
so
we
can
raise
awareness
across
other
sticks
as
well.
A
Okay
and
the
last
one
is
mark
mark
and
ravi.
I
Yeah
I'm
asking
on
behalf
of
ravi
who
couldn't
make
it.
We
were
just
wondering
if
the
the
node
cubic
serial
tests
it
looks
like
so
we
added
some
tests
to
that
and
at
least
the
last
time
I
checked
they
were
timing
out
pretty
regularly.
A
So
some
of
the
improvements
I
can
highlight
here
is
we
get
a
little
dynamic,
compute
config
in
tests,
so
some
topology
manager
tests
were
affected
and
it
was
fixed
and
then
we
been
doing
some
like.
We
removed
actually
removed
dynamic,
config
tests
from
a
test
suit
because
they
were
taking
a
lot
of
time
and
they
were
flaky.
So
now
it's
supposed
to
be
way
greener
and
if
you
interested
join
our
ci
signal
meeting,
it's
typically
at
thursdays
or
like
wednesdays.
A
At
that
same
time-
and
sometimes
it's
8
am
it's
thursday,
but
this
week
it
will
be
tomorrow
at
the
same
time.
So
you
can
join
this
meeting
and
discuss
all
the
test
failures
and
what
you're
doing.
A
I
Okay,
thank
you.
That
was
my
concern.
A
Okay,
I
want
to
remind
everybody
that
code
freeze
is
november
16th,
so
if
you
have
your
favorite
bug
that
needs
to
be
fixed
or
some
japanese
studies
need
review,
please
pay
attention
and
help
each
other.
I
D
I
Yeah,
I
think
they
want
the
prs
reviewable
by
the
23rd
and
merged
by
the
20
or
by
the
30th.
D
I'll
make
sure
to
add
an
announcement
for
next
agenda.