►
From YouTube: Kubernetes SIG Node 20230207
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20230207-180533_Recording_640x360.mp4
A
Hello,
hello,
it's
Wednesday,
no
Tuesday,
February,
7th
2023,
it's
signaled
weekly
meeting
welcome
everybody.
I
want
to
start
with
highlight
that
cap
freeze
very
soon
Andrew
this
week
we
have
27
caps.
We
see
not
label
on
it.
A
There
are
a
few
from
other
like
primary
Sig,
but
mostly
like
many
of
those
27
are
actually
signaled
caps
that
are
being
worked
on.
It's
a
very
big
number,
comparing
to
other
releases,
so
many
agenda
items
today
are
related
to
this
caps.
So
let's
Dive
Right
In
Rodriguez.
Do
you
want
to
update
on
username
spaces.
B
Yes,
hello,
so
the
pr
is
there
linked.
I
think
it
just
needs
approval,
because
I
have
addressed
several
comments
already
from
manual
and
team
honking.
Already
look
good
to
decided,
look
because
looks
good
to
him
and
yeah.
So
yeah
I
was
curious.
If
there
was
some
other
concern
missing
that
I
can
talk
to
address
or
or
yeah
I
should
expect
it
for
this
to
be
approved,
approved
soon
or.
A
So
this
cap
stays
in
Alpha
right,
so
it's
just
yeah.
Is
there
any
PR
if
you
needed
with
regard
to
upgrade
like
how
it
would
be
like
whether
customers
will
experience
any
trouble,
sub
paging.
B
Not
really
I
mean
so:
where
are
we
working?
How
I
demand
bounce
will
work
underneath
so
I
will
need
other
changes
in
container
runtimes,
so
yeah,
this
new
version
won't
work
unless
you
have
a
container
runtime
that
adapted
these
changes,
that
this
is
the
only
drawback
that
I
think
it's
visible.
A
D
But
yeah
I
know
it's
like
Ed
said:
I
made
two
agenda
items,
one
of
them
it
looks
like
he's
already
been
taken
care
of,
and
the
second
one
is
just
to
get
approval
on
on
the
kept
it's
listed
there.
From
my
perspective,
it's
it's
mostly
Reddit.
D
There's
one
small
comment:
I
think
that
needs
to
be
addressed
still,
but
if
we
could
get
the
approval
with
maybe
a
hold
on
it,
I
can
make
sure
that
last
thing
gets
addressed
before
giving
it
an
LG
TM
so
that
it
can
be
merged
yeah
and
that's
it.
D
F
Comment
so
thanks
for
yeah
I
know
it's
not
time
perfect
for
you
so
yeah
question
on
this
one.
So
that's
why
I
kind
of
hold
on
the
approval?
So
so
because
the
so
the
type
itself
it
is
no
risk
for
sure,
because
the
read
only
try
to
try
to
mostly
is
for
monitoring
right.
So
you
have
that.
C
F
Along
with
those
kind
of
things-
and
then
you
want
to
so,
we
can
know
what
it
is
dynamic
allotted
resource
and
who
is
consumed,
which
one
is
a
locatable
which
one
is
consumed,
so
all
the
different
things
it
makes
sense
to
me.
The
problem
is
in
the
type
didn't
tell
me
the
all
those
kind
of
the
workflow
there,
for
example,
Dynamic
allocate
the
resource
that
dra
that
driver
could
be
died,
could
be
even
rescheduled,
not
the
other
node,
so
that
to
get
is
the
pulling
method.
F
It's
not
posted,
so
how
we
are
going
to
keep
that
is
up
to
date,
so
you
could
connect
it.
How
often
we
are
going
to
call
that
get
and
how
to
avoid
those
risk
condition
make
that
it
is
up
to
date
and
if
it's
not
accurate,
to
show
current
situation.
I
understand
this
is
monitoring,
but
monitoring
sometimes
also
cause
some
certain
problem
right
for
debugging
and
for
support
so
so
confusing.
So
that's
why
I
connect
the
this
is
why
I
haven't
to
approve,
because
I
read
this
whole
type.
F
I
have
a
bunch
of
questions,
but
I
read.
Oh
I
think
it
is
like
the
last
week
and
because
I
know,
people
still
reveal
so
I
think
immediately
add
a
comment
before
this
chapter
for
other
work.
So
but
this
is
the
the
reason
but
I
reviewed
the
today's
all
the
comments.
I
noticed.
Nobody
even
asked
that
question.
So
that's
why
I
can't
hold
approval.
D
Yeah,
no,
that
makes
sense,
I,
think
and
then
what
you
said
is
it's
actually
valid
because
in
the
case
of
say
the
existing
device,
plugin
API,
you
know
the
plugins
advertise
the
devices
to
the
kublet,
and
then
it
keeps
all
that
state
internally.
So
it's
very
obvious
when
and
how
you
would
you
know,
delete
these
devices
from
the
list
that's
associated
with
the
container,
because
the
Kubler
knows
about
them
and
stores
that
information
locally,
whereas
the
dra?
That's
that's
not
the
case
right.
D
All
of
these
all
this
device,
information
is
only
pulled
at
the
time
that
the
container
is
is
started,
and
then
it's
forgotten
by
the
kuboot.
So
yeah
it
is
a.
It
is
a
valid
concern
and
it
didn't
come
up
I
think
mostly
because
I
was
but
I
was
reading.
It
I
was
thinking
in
terms
of
you
know
what
we
do
currently
and
how
the
flow
is
is
somewhat
very
obvious,
and
so
that
would
be
the
same
thing
going
on
with
with
with
maintaining
these
these
dra
devices
as
well.
D
But
no,
the
point
you
bring
up
is
actually
valid,
so
yeah
if
you
could
drop
so
I'm,
not
the
one.
That's
right
in
this
cup,
it's
a
it's
another
guide
and
video
that
I've
been
helping
along
with
this.
So
if
you
leave
that
comment
me
and
him
can
sit
down
tomorrow
and
and
try
and
address
that
in
the
cup,
so
that
you
can
get
a
chance
to
look
at
it
again
tomorrow
during
during
your
day
time
sure.
C
C
F
I
I
didn't
yeah
I
will
so
hopefully
we
can.
So
that's
the
only
concern
I
have
because
I
read
off
the
API.
Of
course
the
API
there
maybe
have
some
detail,
but
I
think
about
you
have
no
experience
than
me
to
say.
Oh,
that
cover
all
those
characteristics
about
dynamic
or
allocated
resources.
So
I
like
the
goal,
but
the
whole
flow
is
unclear
to
me.
So
that's
why
I
hold
the
approval
just
okay.
D
F
A
Thank
you
Kevin.
Now
we
all
know
what
kind
of
phone
you're
using
you're
showing
his
eye
on
there.
My.
A
B
B
G
B
One
one
thing:
I
forgot,
because
I
just
went
out
to
buy
dinner
and
I
arrived
just
in
time
for
the
meeting
is
that
it
seems
manual
already
look
good
to
meet
the
pr.
So.
B
Missing
approval,
I
think
and
Eric's
not
here
Don,
can
you
have
a
look
to
approve
the
APR.
B
F
G
To
continue
their
the
the
kept
needed,
a
template,
update
and
I
added
that
that's
a
PR
number
3845
in
enhancements
don.
Could
you
please
I,
don't
I
think
either
you
are
direct,
could
approve
this
one.
It's
a
small
change,
just
adding
integration,
Test
Section,
which
we
don't
have
plans
for
at
this
point,
but
that
might
change
before
beta.
G
We
in
fact
most
likely
we
will
be
having
that
and
they
just
needed
a
section
to
catch
up
with
the
templates
and
then
I
added
one
another
line
for
node
scalability.
That's
about
it!
Please
review
that.
F
Oh
okay,
so
I
think
oh
yeah
I
did
a
pool
and
a
review,
but
for
the
implementation,
because
we've
been
talked
during
many
planning,
so
dark
volunteered
to
review
code.
Manu
warranty
review.
So
I
don't
want
like
the
other
side,
because
without
a
clear
handoff
and
because
your
your
personal
really.
F
Then
that's
that's
too
sure
for
the
type
I
definitely
can
because
I
remember
all
the
design,
all
those
things,
but
the
implementation
I
just
kind
of
feel
like
the
other
side,
if
I
prove,
because
we've
been
talking
about
the
submit
the
API
change
and
also
implemented
it
together
right,
so
that's
why
you
you
see
that
I
always
keep
silent
because
I
don't
want
to
network
without
the
clean
handoff.
So.
G
G
G
G
We
are
on
the
same
page
with
that,
the
in
fact
there
are
actually
two
different
things:
the
enhancements.
This
is
for
the
K
enhancements
repo,
so
that
one
needed
a
small
update
which
is
to
catch
up
with
the
latest
templates.
They,
the
release,
has
marked
it
as
risk.
So
please
take
a
look
at
that
one.
As
for
the
main
PR,
yes,
we
are
waiting
for
direct
I'm,
not
gonna
have
asked
you
to
take
that
burden
or
he's
already
taken
a
lot
of
pains
to
review
it.
F
B
G
G
It's
just
a
process
thing
yeah,
the
main
PR.
What
we
have
is
Tim
looked
at
it,
the
102884.
The
plan
is
to
merge
that
in
its
entirety
and
he
has
lgtmed
the
the
API
changes.
That's
there
with
a
couple
of
follow-up
action
items
that
I
have,
which
is
to
do
the
resize
policy
name,
restructuring
and
Port
qos
class.
This
is
a
this.
These
two
are
small
changes,
but
they
affect
across
the
code
base.
G
So
I
don't
want
to
reset
the
reviews
at
this
point
to
try
to
bring
them
in
what
we
really
need
is
direct
to
look
at
it.
Give
one
more
look
because
since
they
last
approved
the
pr
there
was
a
November
15th
last
year,
the
only
things
that
have
changed
are
some
rebase
catch-ups,
so
I
have
left
I've
squashed.
G
The
API
commits
I've
left
the
Google
It
commits
as
it
is
so
that
they
can
have
a
look
at
it
and
if
he
wants
to
look
at
the
commit
history
and
nothing
has
changed
to
verify
and
then
all
we
need
is
for
him
to
reapprove
re
and
GTM,
and
then
the
market
is
ready
to
approve
it.
That's
the
current
status
is
mrinal
here.
I
thought
I
saw
him
around,
but
I
don't
see
him
anymore.
G
I
know
Derek
is
not
here,
I'm
wondering
if
anyone
can
ping
him.
Someone
is
Derek.
F
F
G
A
Risky-
and
we
also
want
to
start
working
on
side,
cars
and
there's
in
the
remain
good
yeah
sooner.
H
H
Just
a
short
notes
to
reviewers
we,
we
did
a
small
kind
of
break
of
our
PR
when
we
were
squashing.
Our
kind
of
commits
I
just
reopened
a
new
PR
and
pointed
to
the
old
one
as
a
reference.
So
just
just
to
let
all
the
reviewers
know
it.
The
new
PR
is
all
squashed
with
in
terms
of
commits
it's
the
same
state
and
yeah.
Basically,
with
squashed
commits
and
working
in
in
terms
of
regular
comments,
we
got
some.
C
H
Good
comments:
there
were
some
concerns
regarding
scheduling
if
we
are
covering
basically
resource
allocations
on
the
scheduling
side.
This
is
currently
not
an
objective
for
the
cap.
We
we
put
it.
We
extended
the
nongols
the
just
to
make
that
clear
that
we
will
not
cover
the
scheduling
site.
We
are
basically
on
boat
solution.
After
scheduling,
we
will
be
looking
in
better
phase
for
the
fragmentation
approach,
approaches
how
to
avoid
fragmenting,
basically
the
resources
on
the
Note.
H
H
H
So
just
to
answer
to
Kevin's
comment
there.
Yes,
resource
classes
can
be
an
option
for
us
also
if
we
can
associate
CCI
drivers,
basically
with
Bots
one
kind
of
concern.
What
we
have
is
that
resource
classes
require
claims
they
require.
They
are
bounds
to
the
array,
so
the
question
there
is:
if
we
can
somehow
somehow
use
the
resource
classes
without
this
requirement.
Maybe
it's
something
where
we
have
to
sync
with
Kevin
to
see.
H
If
this,
this
can
be
an
option
to
avoid
any
pot,
spec
kind
of
options,
introducing
new
options
in
pod
spec.
Thank
you.
C
H
Good,
what
what's
Kevin
and
Kevin
Gavin
is
suggesting,
but
yeah
it's
it's.
The
question
is
if,
if
there
is
a
requirement
that
this
has
to
be
used
with
claims
or
dynamic
resource
or
location
claims,
the
other
concern
was
policy.
We
were
suggesting
in
the
cap
to
introduce
a
new
policy
which
will
manage
bridging
CCI
drivers
and
CPU
manager.
H
The
the
the
reason
for
that
it's
new
new
functionality,
it's
really
Bridging
the
CPU
manager
and
and
and
and
drivers,
and
also
we
we
got
the
request
from
Kevin.
If,
if
this
can
support
more
or
less
current
non-uh
policy
and
static
policy,
we
still
want
to
keep
it
separate
policy
as
because
of
the
bridging
Concepts,
and
we
don't
want
to
add-
or
basically
we
know
that
a
lot
of
users
are
already
there
using
non-policy
and
and
static
policy.
We
don't
want
to
break
it
in
Alpha.
H
I
hope
this.
This
helps
then
yeah
I.
Think
from
from
that
perspective,
we
we
try
to
answer.
There
was
a
question
in
our
community
meetings
about
some
of
the
flaws
with
with
the
plugins
I
added,
an
illustration
which
shoots
a
little
bit
hopefully
brings
some
light.
What
happens
when
the
the
driver
dies
basically
and
you
try
to
to
start
a
bot
which
relies
on
the
driver
I
try
to
describe
that
Center
those
scenarios
a
little
bit
in
the
cap.
H
Let
me
know
if
this
is
sufficient.
We
can
improve
if
the
information-
if
that
that
was
not
clear,
there
was
also
a
good
comment
that
a
misunderstanding
that
or
we
were
not
clearly
saying
what
happens
if
the
driver
dies,
so
our
kind
of
behavior
will
be
if
the
driver
dies
and
you
want
to
start
a
pot
which
relies
on
it.
The
pots
will
fail.
So
we
we
are
not
not
searching
at
this
point
for
any
kind
of
backup
options
to
do
use
some
sort
of
standard,
CPU
manager
mechanism
as
a
backup.
H
A
Thank
you
so
I
remember,
we've
been
discussing,
who
will
be
a
program
reviewer
on
this
cap,
I
see
a
bunch
of
reviewers
specified
in
capiamo
right
so.
H
A
And
typically
you
you
find
people
who
who
say
in
that
they
will
be
reviewing
and
ogtm,
and
then
approvers
will
be
approving
this.
H
Okay,
yeah
I
included
for
now
all
the
reviewers
who
are
basically
on
the
pr
but
yeah
happy
to
adjust
to
one.
E
Sorry
sorry
I
volunteer
to
take
a
look
at
this
cap,
so
I
intend
to
do
that.
I'm
just
a
bit
behind
so
I
will
hopefully
take
a
look
at
it
today
or
tomorrow.
H
I
I
E
F
We
had
a
hold
of
Derek,
so
I
I,
I,
I'm.
Sorry
thanks!
This
vaity
volunteer
to
be
the
one
of
the
main
reviewer
I
hope
that
is
right
here
and
the
cabin
anyway.
Both
they
are
adding
wow
a
lot
of
those
resource
allocation
in
the
many
other
discussions.
F
So
I
hope
they
are
the
main
reviewer
then
Direct
Connect
can
be
the
fellow
approver
is
that
okay,
and-
and
so
so
so
sweaty,
if
you
are
finished
and
I
hope
Kevin's
still
here
so
can
can
review
no
matter
what
I
believe
Kevin
will
review
this
one
anyway,
let's
go
so
that's
right!
F
So
so
can
we
have
you
you
too
and
that's
the
main
reviewer
and
I,
especially
if
there's
some
like
the
CII
special
change,
then
I
hope
next,
the
circuit
and
the
menu
can
review,
but
at
so
far
I
didn't
say
anything
there
most
too
special
and
just
so
that's
why
I
think
about
the
YouTube
would
be
okay
and
the
dark
and
I
still
will
be.
The
Final
Approach
is
that
okay,
so.
E
A
Okay,
moving
on
kernel,
Model,
Management,
I'm,
sorry
I'm,
not
aware
of
this
name,
whoever
added
current
Model
Management
topic
probably
speaks.
J
Hello,
everyone
so
color
module
management
is
a
project
that
we
created
inside
Sig,
node,
I.
Think
in
the
summer.
Really
it's
doing
pretty
well
I
think
it's
it's
in
a
working
state
right
now,
and
so
that's
my
usual.
You
know
call
for
for
sponsor
for
a
regular
contributor
in
the
project.
That's
nihilarious,
so
I'm
looking
for.
Basically
someone
to
you
know
sponsor
his
application
into
the
kubernetes
and
kubernetes
six
organizations
so
that
we
don't
have
to
slash
okay
to
test
on
our
PLS.
F
A
F
J
Yeah
yeah
yeah
I'm
really
happy
with
uh's
contributions,
so
Sergey
I'll
ask
him
to
mention
you
in
the
in
the
application
for
membership,
then
the
second
bullet
I
had
and
I'm
trying
to
be
quick
here
was
about
like
an
update
of
the
admins
and
maintainers
of
current
module
management.
So
what
happened
is
that
a
Canon
module
management
was
initially
created
as
SRO
the
special
resource
operator
that
that's
repository
and
those
teams
in
kubernetes
org
were
were
created,
but
but
we
actually
never
committed
the
code.
J
We
shifted
the
direction
we
we
decided
to
build
candle
module
management
instead,
and
so
so
the
admins
and
the
maintainers
Do
Not
reflect
the
current
contributors
or
project
leaders,
so
that
PR
is
there
to
to.
You
know
indeed
update
those
maintainers,
but
I,
don't
think
we've
heard
from
zronko.
We
would
like
him
to
approve
the
PR,
but,
like
he's
been
mentioned,
that
and
doesn't
reply
on
the
pr,
so
I
was
wondering
if
we
could,
just
you
know,
get
it
merged,
because
I'm
I'm
not
sure.
F
Yeah
I
I
think
we
discussed
this
before
right.
So
I
had
one
of
the
signals
we
decided
to
redirect
this
to
the
kernel
model.
I
I
think
I
saw
the
dark's
comment.
I
I
do
think
about
that.
It's
been
discussed
a
while
back.
So
that's
right.
Let
me
just.
J
Yeah
so
so
sonko
was
sunko,
wasn't
was
involved
in
you
know
creating
SRO.
What
was
the
you
know
the
initial
proposal,
but
but
he
he
never
contributed
to
calendar
module
management
and
so
yeah.
We
need
to
oh
I,
see
your
approach
done.
So.
Thank
you
very
much.
Thank
you.
That's
it
for
me
thanks
and
maybe
I
should
deliver.
You
know
a
deeper
update
about
like
what's
the
status
about
Canon
module
management,
because
it's
working
fairly
well,
I'm.
F
F
Yes,
yes,
can
we
put
that
in
our
agenda
because
we
do
have
a
lot
of
customers
at
heart?
Also,
you
like
open
source
usage
and
even
like
the
some
Google
vendor
and
people,
ask
us
some
how
we
plan
to
do
this
kernel
motor
management
and
because
different
offer,
different
digital,
have
the
different
customer
requirement
right.
So
so
the
kernel
a
lot
of
kubernetes
itself
didn't
really
have
the
specific
we.
We
have
the
really
simple
EO
system,
validator,
that's
the
really
long!
Long
time
ago
we
have
that.
F
Well,
so
we
have
the
basic
kernel:
module
basic
kernel
requirement,
but
now
to
really
reflect
up
to
date,
not
to
reflect
what
today's
customer
lead
back.
Then
we
basically
have
the
really
simple
workload.
Now
we
have
the
more
complicated
workload,
the
different
the
workload
have.
The
different
kernel
model
requirement,
different
kernel,
washing
requirement.
So
so,
if
we
could
have
the
diamond
from
you
and
your
team
and
it'll
be
wonderful,
so
then
that
will
be
make
a
lot
of
work
is
much
easier.
J
Sure,
absolutely
it's
an
active
development
but
I
think
we're
still
happy
with
the
current
state,
and
you
know,
as
you
said,
like
you
know,
Kmarts
are
quite
ubiquitous
these
days
we
have
CSI
vendors
that
are
using
kmm
and,
of
course,
you
know
Hardware
vendors
that
need
to
enable
the
hardware
without
electric
under
modules.
So
that's
yeah,
I
absolutely
have
scheduled
demo.
A
Yeah
just
mentioned
on
a
PR
as
well
one
concern
I
have
this
business
PR
is
that
it
changes
all
the
maintenance
to
be
from
the
same
company.
It's
not
ideal
to
have
this
situation,
so
if
you
can
like
I,
don't
think
it's
a
block
NPR,
but
if
you
can
actually
seek
for
somebody
who
is
ready
to
maintain
and
not
from
Red
Hat,
it
would
be
great.
J
So
we
are,
we
are
indeed
working
with
with
other
people
from
other
companies,
but
I
don't
think
anyone
right
now
is
willing
to
actively
contribute
code.
I'll
I'll
do
my
best
to
find
anyone
else
or
if,
if
anyone
in
Signal
wants
to
wants
to
also
be
maintainer
that
I
you
know,
I
would
be
really
happy
to
think
about
it.
K
Okay
cool,
so
for
me,
a
quick
ask
for
for
the
pr
the
with
the
cap
update
for
the
second
iteration
of
beta
yeah.
This
is
owned
by
a
signal
and
in
this
cat
we
need
to.
We
want
to
resolve
the
problem
of
pending
terminating
parts
that
are
owned
by
cubelet,
but
they
get
stuck
in
this
state
and
they
never
fail
and
yeah.
K
This
is
currently
problematic
for
for
controllers
laptop
controller,
which
uses
finalizers,
and
this
cap
has
already
been
like
a
couple
of
reviewers
left
the
remarks
and
been
reviewed
by
David,
who
left
lgtm
from
C
note,
but
yeah
I
would
like
to
to
get
like
final
approval
or
like
feedback.
If
something
more
is
needed
and
that's
what
my.
F
Understanding
your
PR,
because
we
know
it's
solve
real
problems,
so
it's
been
upfront
approval.
You
really
need
it.
It
looks
good
to
me
so
the
real
reviewer
look
at
the
content.
All
this
kind
of
detail
and
then
agree
on
that
is
good
thing.
I
saw
that
David
actually
spent
a
lot
of
time
to
review
this
one.
So
maybe
you
just
need
looks
good
to
me
from
David
and
then
we
can
pro
move
forward.
K
Yeah
yeah
sure,
but
well
from
seek
apps.
What
I
got
like
from
mache
is
that
he
would
be
like
more
comfortably
signaled
at
those
and
same
opinion
per
month,
so
it
would
be
nice
like
and
that
we
get
yeah.
I
Was
the
main
interviewer
and
we
went
through
some
generation?
Thank
you
for
all
the
updates.
I
think
it's
great
now,
but
maybe
we
need
the
signals
like
a
pervert
to
sign
up
on
it.
I'm,
not
sure
who
was
your
approver
for
the
alpha.
Was
it
honor
Theory?
It's.