►
From YouTube: Kubernetes SIG Node 20220628
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20220628-170315_Recording_640x360
A
All
right
well
welcome
everyone
to
the
June,
28th
Sig
node
meeting.
A
B
Yes,
hi
our
direct
I
think
yeah
though
I
looked
at
I
was
away
for
the
last
couple
of
weeks.
There
was
a
conference
last
week
in
Austin
I'm,
now
back
for
one
week
and
I
fixed
the
the
issue
that
you
had
found
in
the
unit
test
and
also
the
CRI
the
spurious
field
there
was
there
that
Mike
identified.
That
was
something
we
put
in
into
the
cap
and
the
initial
version
of
the
code
before
120,
where
I
believe
the
windows
containers
came
in
and
I
missed.
B
Looking
at
that
one,
while
I
was
sporting
things
over,
so
we
can
remove
that
safely
without
any
issues.
I've
already
done
that
now,
what
remains,
in
my
opinion,
is
identifying
the
interaction,
the
question
that
you
had
with
the
CRI
interaction
on
the
resize
status,
how
it's
generated
I,
went
back
and
did
verified
with
the
test
that
with
dockershim,
let's
see
the
transitions
that
I
like
and
what
I
need
to
add
this
to
that
we
can
currently
close
the
loop
until
we
have
the
containerdy
change
in,
but
probably
a
partial
test
as
possible.
I'll.
B
Look
into
that.
The
other
comment
which
is
which
I
think
we
should
nail
down,
is
about
the
expected
behavior
of
the
runtime
I
think
there
is
still
some
fog
around
what
the
current
time
is
expected
to
do.
I'm
trying
to
understand
myself
whether
what
we
get
today
when
we
query
when
we
look
at
the
C
group
stats,
is
that
the
cash
value
or
is
that
the
enforced
value,
because
our
test
currently
looks
at
the
C
group,
it's
invasive.
It
shouldn't
be
doing
that.
B
But
in
the
absence
of
having
the
container
status
implementation,
we
are
verifying
that
the
update
has
been
enforced
by
looking
at
the
values.
That's
configured
on
the
C
group.
So.
C
I
don't
know
winter
is
here
yeah
when
I
am
yeah
I'm
here
to
Peter
S2,
so
I
think,
while
looking
into
the
rancy
behavior
right
like
there
was
a
Delta
between
V1
and
V2
yeah.
But
what
we're
trying
to
do
is
if
the
update
succeeds,
then
we
can
assume
that
the
update
went
through.
Otherwise,
the
runtime
will
throw
an
error.
That's
okay
right!
Then
you
don't
need
another
loop
to
go
and
figure
out
whether
it
was
applied
or
not.
A
Okay,
so
make
sure
I
heard
that
properly.
You
know
how
my
audio
hooked
up,
so
the
question
I
had
on
there
was
if
the
update
action
was
Atomic
or
not
Atomic
from
the
perspective
of
the
caller
you're
saying
the
desired.
Behavior
would
be
that
it's
Atomic,
but
right
now
on
B1
it
might
not
be,
and
in
B2
it
is
so.
B
Yes,
the
memory
example
I
put
in
there
was
because
it's
the
most
explicit
way
of
seeing
what
happens
and
I
believe
that's
what
I
demoed
in
the
last,
the
kubecon
Barcelona
when
I
showed
the
earlier
design
of
this.
So
you
try
to
run
a
stress
test
that
allocates
beyond
the
limits
that
you
have
and
that
the
home
killer
comes
in
wax
it
now.
B
That's
that's!
Okay,
but
I.
B
D
C
E
C
B
Yeah
no
I'm
thinking
long
term
so
for
the
we
should
probably
look
for
a
behavior,
that's
consistent!
That's
the
asynchronous
seems
to
be
the
in
my
mind,
the
more
reliable
Choice
here,
which
is
what
I
got
from
you
cash
and
then
you
apply
that's
what
I
I
think
Peter
mentioned
in
that
comment,
and
that's
fine.
As
long
as
when
we,
when
you
query
back,
it
should
tell
us
what
the
enforced
value
is
for
limits.
B
It's
one
thing,
but
for
requests
today
we
have
requests,
we
are
locally
checkpointing
it
and
that's
what
we
use
is
okay.
This
is
the
amount
of
memory
we
have
reserved
for
your
pod
and
that
could
change
to
okay,
we'll
get
that
information
observed
from
what
the
what
the
runtime
is
telling
us
now
then
I
think
it's
important
more
important
for
it
to
be
true,
as
opposed
to
a
cash
value
that
we're
going
to
apply
this.
That
will
probably
result
in
better
Behavior
or
the
correctness
of
the
that's.
B
What
I'm
more
in
C
group
V2,
where
we
have
memory
requests?
That's
where
I'm
getting
a
little
more
concerned
about
what-
and
this
is
something
we
probably
will.
Also
make
it
as
a
guidance
for
other
runtime
implementations
as
well.
So
we
should
probably
think
through
this
a
bit
more.
A
Yeah
so
I
guess
my
bias
would
be
that
the
keyboard
can
make
an
update
request
and
if
it
succeeds,
the
Assumption
from
the
qubit
was
that
it
did
succeed.
I'm
not
left
in
a
in
a
big
state.
If
I
am
left
in
a
big
state,
then
I'm
even
more
wanting
the
Callback
from
the
runtime
to
tell
me
how
I'm
in
a
vague
state,
so
I
can
make
a
call
to
update
again
to
reconcile
so
I'm.
A
B
B
That's
yeah,
that's
that
would
be
desirable,
but
for
now,
as
far
as
the
update
container
requests,
the
behavior
goes.
I
think
I
tried
this
before
this
is
more
applicable
or
relevant
when
there
is
a
series
of
like
a
pod,
has
multiple
containers
and
we
are
increasing
the
memory
on
one
container
and
decreasing
it
on
the
other.
In
that
case,
we
order
it
such
that
you
know.
Let's
say
we
do
the
decrease
first
and
then
the
increase.
B
So
even
for
a
brief
moment,
we
are
not
overshooting
the
total
net
end
result
memory
and
if
one
of
those
fails
we
bail
out
at
that
point,
we
and
then
come
back
and
try
the
series
again
later
so
that
we're
not
trying
to
apply
something.
That's
Downstream
that
requires
an
increase
when
a
decrease
has
failed,
so
that
behavior
is
there
currently
in
in
how
the
multiple
containers
update
is
being
processed.
B
It's
for
retaining
that
behavior,
where
I
prefer
at
least
CPU
I
realize
it's
easier
to
manage,
but
for
memory
at
least
we
should
see
if
we
can
do
it
synchronously
at
least
try
and
then
fail.
If
it
succeeds,
then
great.
A
B
G
A
When
a
you
and
Bernal
like
get
a
comment
on
the
pr
that
says
like,
in
my
view,
it'd
be
good.
If
we
can
make
the
update,
call
transactional
for
the
impacted
resources,
so
CPU
and
memory,
and
then,
if,
if
we
know
that
that's
not
fully
achievable
in
run
C
today
then
like
get
that
enumerated
as
a
as
a
beta,
blocker,
I
guess,
but
I,
wouldn't
necessarily
do
it
as
an
alpha
blocker
but
yeah.
A
Plan
to
expand
this
Beyond
CPU
and
memory,
although
I
think
it's
good
to
think
through
it,
but
even
memory
limits
today
on
V1
I
think
we
still
hit
this
problem
like
you.
We
let
you
change
either
value,
so
huge
Pages
aren't
over
committed
on
a
node
and
are
not
resizable
in
the
current.
B
A
Even
be
managed
by
run
C
so
yeah,
let's
treat
that
separately.
I
guess.
C
B
And
I
agree:
this
is
not
an
alpha
alpha
blocker,
although
we
should
resolve
it
before
beta.
It's
feature
gets
it
turned
off
by
default,
it's
not
going
to
harm
anyone
and
we
can
always
constrain
it.
Okay,
we'll
take
it
one
at
a
time.
Instead
of
you
know
doing
a
series
of
containers
at
a
time,
we
can
always
do
that
as
a
fallback.
So.
A
B
F
E
Right
well,
I'll
take
a
look
at
that.
Can
you
put
it
in
the
cry
API
too,
while
you're
ready.
B
If
we
need
to
change
sequence,
yes,
once
we
identify
the
exact,
it
should
be
like
four
or
five
short
sentences.
I
want
to
get
to
that
and
then
yeah.
So
all.
A
I'll,
look
at
the
other
changes.
I
think
we're
getting
close
on
this
one,
and
this
is
obviously
important.
So
great
yeah.
Another.
B
Logistic
more
housekeeping
logistical
question
here
is
this:
Gap?
Is
it's
sprawled
all
over
the
place?
I
think
we
have
API
goodness
from
ngtm
from
Tim
and
I,
want
to
talk
to
the
six
scheduling
and
see.
Should
we
break
the
scheduling
piece,
it's
a
very
small
piece:
should
we
break
it
out
into
its
own
PR
so
that
it
makes
it
easier
to
get
the
LG
TMS
to
merge
this?
Otherwise
we
probably
need
at
least
three
different.
We.
A
B
No
for
the
pr
to
merge,
because
it's
touching
it's
touching-
it's
quite
fingers
everywhere
in
kubernetes
I,
think
so
any
any
file
at
touch
that
doesn't
there
is
a
owner
for
that.
That
needs
to
like
six
scheduling
needs
to
your
GTM
We.
A
B
No,
no,
no
I'm
getting
to
the
logistical
part
of
how
to
who
all
to
you
know
best
to
get
this
merged
and
then
okay.
It
would
be
easier
if
it
was
a
separate
PR
for
at
least
for
the
scheduling
it
reduces.
The
number
of
LG
teams
needed
to
merge
this,
and
that
should
that
should
be
ready
and
it
should
come
in.
It
won't
be
able
to
merge
until
this
is
in
it's
good.
That's
how
it's
going
to
flow
yeah.
A
So
I
was
good
with
the
API
and
quota
pieces
and
the
scheduler
piece
I
agree.
Wasn't
that
complicated,
so
yeah?
If
we
nail
down
the
last
set
of
a
note
stuff,
then
I
think
maybe
yeah
a
rapid
fire
breakup
of
like
discrete
PRS,
would
be
quick.
B
A
All
right:
well,
let's
get
a
comment
on
there,
just
describing
the
runtime
behavior
and
a
comment
on
the
CRI
itself.
That
says
yeah.
A
Recommended
order,
okay,
all
right!
Well,
thanks
so
much
for
now
and
Manuel
and
Peter
and
others
Mike
for
joining
us.
Thank.
B
A
E
Great,
so
just
a
little
bit
of
background
here,
the
special
resource
operator
is
meant
to
manage
how
to
treat
kernel
modules
for
kubernetes
for
us
as
well,
in
the
open
shift
space.
But
we
have
got
approval
from
sick
node
last
year
to
create
a
repo
and
then
from
there
work
on
transitioning
a
code
base
into
that
space.
In
order
to
continue
with
that
freedom
development.
E
E
So
the
requests
for
the
meeting
today
is
to
see
if
there
are
any
objections
to
renaming
that
repo
to
from
the
special
resource
operator
to
the
kernel,
module
management
operator
and
once
that
rename
takes
place,
then
we
can
start
pushing
our
code
base
that
we've
been
developing
into
that
space
and
again
began
working
out.
If
they're,
like
okay
and
just
wanted
to
put
that
out
as
a
proposal,
not
very
technical.
But.
A
Really
get
everybody's
thoughts
on
that
my
first
ask
would
be
if
I
recall,
it
was
folks
across
in
Via
Red
Hat,
maybe
others
who
were
working
in
the
community
for
this,
and
we
had
a
presentation
from
svanko
in
the
video
on
like
what
the
operator
as
envisioned
was
going
to
be
I,
guess
I'm,
trying
to
figure
out
if
the
name
change
implies
a
change
in
vision
and
if
there's
like
a
representative,
read
me
that
you
could
provide.
A
That
explains,
explains
the
change,
because
I
guess,
aside
from
the
rename
it's
not
clear,
if,
like
the
ask,
is
changing
scope
of
any
kind.
Does
that
make
sense.
E
It
does
the
scope
of
what
we're
looking
to
do
with
this
operator
actually
reduces
input
print,
and
the
idea
behind
this
was
to
simplify
the
code
base,
make
it
more
friendly
to
use,
but
for
those
who
may
not
know
the
historical
background
of
SRO,
it
was
primarily
home-based
and
the
original
idea
behind
SRO
was
to
use
that
as
a
stepping
stone
to
then
instantiate
other
partner
Solutions
inside
of
kubernetes,
and
so
as
we
started
to
reverse
that
path.
E
We
realized
that
that's
not
a
sustainable
support
experience
and
it's
not
something
that
would
become
over
long
term
an
easy
way
to
manage,
and
so,
as
we
were
looking
to
push
the
code
Upstream,
we
were
removing
all
references
to
partner,
specific
Helm
charts
to
deploy
their
Solutions
and
we
changed
our
consumption
model
to
be
something
more
along.
E
The
lines
of
we're
just
going
to
deploy
and
manage
the
life
cycle
of
your
kernel,
module
and
device
plug-in
inside
of
kubernetes,
and
so
the
partner
in
themselves
would
build
their
orchestration
piece
inside
of
their
operator,
which
would
then
have
SRO
as
a
dependency.
As
we
made
that
strategic
change,
we
then
decided
to
you
know
hey.
This
is
an
opportunity
for
a
rename
and
an
opportunity
for
us
to
simplify
things.
E
A
So
is
it
possible
I
know
you
have
a
link
to
I
guess
the
project
meeting
that
was
being
maybe.
E
Because
we
have
a
link
into
your
community
meeting
notes
in
there,
where
we've
discussed
the
proposals
with
the
change,
the
remains
and
agreements
that
took
place
there.
I
don't
have
a
specific
readme
there
today
that
describes
the
differences
between
what
SRO
original
proposed
versus
what
we're
doing
with
kmmo
kmmo
itself
is
it's
just
a
fraction
of
what
SRO
was
intended
to
do
from
a
health
perspective,
so.
A
I,
that's
fine,
I
think
I.
Just
it's
it's
important.
This
is
like
understood
or
transparent
and
like
if
we
deviate
from
what
we
originally
presented,
we
clarified.
So
would
you
be
kind
enough?
Maybe
the
folks
that
were
participating
in
the
community
meeting
to
like
write
up
that
read
me
and
send
it
to
the
mailing
list
and
folks
have
a
chance
to
review
it.
I
guess
in
the
same
way
that
we
had
a
chance
to
review
the
original
presentations
from
smoko.
E
Absolutely
and
quick
news
on
the
call
with
us
today
is
our
lead
in
that
community
space
and
he's
also
got
some
slides
that
we
can
share
around
kmfo
the
design
behind
Cameron
MO
and
the
use.
A
All
right:
well
thanks
Brett
and
the
group
that
was
exploring
the
space,
and,
let's
just
do
that
as
a
step
forward
before
proceeding
to
make
sure
there's
no
disagreement
on
folks.
If
it's
substantially
changing
the
nature
of
the
project
does
presented
sure
all
right.
So
moving
up
next
Adrian
looks
like
you
are
ready
to
be
merging
your
implementation
together.
Is
that
right,
yeah.
C
G
No,
that's
that's
exactly
it.
The
the
the
there
are
a
couple
of
reviews.
Positive
reviews
have
have
been
done,
and
so
now
the
final
approval
is
is
missing.
Waiting
for.
That's
that's
all
there
is
currently
yes.
A
Okay
and
then,
since
it
came
up
in
the
cap,
review
I
guess
this
exposed
the
new
endpoint
on
the
cubelet
server
process
like
I,
guess,
I,
don't
know
if
you
can
just
make
sure
that
it's
not
open
like
that.
I
guess:
I
forget
what
we
said
for
securing
that
endpoint,
but
that
would
probably
be
what
I
would
focus
on.
A
Yeah,
like
I,
thought
this
had
a
a
new
rest
endpoint
you
could
hit
on
the
cubelet
server
process.
That
said,
do
the
checkpoint
right,
we're
not
mistaken
yep,
yeah
and
I've
I
thought
Tim
o'clair
had
some
questions
on
how
it
was
secured,
so
I
don't
know
if
we've
deviated
or
anything
on
that
so
I
don't
know.
Just
look
at
that
closely.
I
guess.
F
D
Hi,
can
you
help
me
yeah?
Okay,
so
this
is
related
to
topology,
where
scheduling
work.
We
had
had
a
discussion
back
in
2020
to
get
a
repo
created
for
populating
crd
based
API,
that
is
consumed
by
the
two
components
that
are
part
of
topology
about
scheduling.
D
I
had
proposed
a
PR
to
do
to
kind
of
populate
that
repository
with
the
feedback
at
the
time
that
we
got
was
that
it'll
be
better
to
pursue
these
components
out
of
tray,
and
that
is
what
we've
been
doing
so
far.
So
we
have
nft
topology
of
data
component,
which
is
part
of
NFD,
which
is
consuming
this
API
and
topology,
where
scheduler
plugin,
which
is
in
the
scheduler
plugins
repository.
So
both
these
components
are
part
of
projects
that
are
under
kubernetes
sake,
umbrella
and
we've
been
like
they
are
consuming
API.
D
That
is
part
of
an
external
GitHub
organization,
which
is
what
we
created
to
unblock
ourselves.
So
I
just
wanted
to
bring
this
discussion
back
to
signal
to
see
if
it
makes
sense
to
to
maybe
pursue
the
direction
again
and
populate
these
apis,
or
this
API
again
and
I
think
it.
The
issue
has
been
linked
as
part
of
the
agenda
and
I
have
a
bunch
of
PRS
as
well,
but
I
just
want
to
see
if
it
makes
sense
to
go
ahead
in
this
direction.
D
Is
there
anything
I
can
do
to
help
that?
Well.
A
Maybe
others
on
the
call
have
a
fresher
memory.
I
recall
we
so
the
flow
on
this
was
we.
We
had
apis
that
allowed
you
to
introspect
qubit
assignment,
and
then
the
cups
had
explored
building
layers
on
top
to
do
technology.
We're
scheduling,
I,
don't
recall
if
we
had
the
intermediate
step.
That
said,
should
we
create
that
as
a
repo
in
case
eggs
or
not,
or
is
the
ass
that
we
did?
We
create
the
repo
and
the
repo.
D
Just
populated
exactly
so,
we
we
got
approval
to
create
the
repo,
but
at
the
time
we
were
proposing
that
the
scheduler
plugin
be
within
kubernetes
itself
as
an
entry
plugin.
So
he
was.
It
was
suggested
that
you
know
we
explore
these
two
components,
which
is
one
component,
is
the
component
that
exposes
the
information
on
a
per
numer
basis
and
the
other
one
is
the
scheduler
plugin
that
consumes
this
information
and
in
order
to
make
a
topology
where
scheduling
decision.
A
D
Kind
of
both
I
think
we
didn't
have
capacity
to
pursue
this,
and
the
other
reason
was
that
previously
we
didn't,
we
didn't
have
the
component
per
se
to
that
were
consuming
apis
and
they
were
mature
enough.
It
was
just
early
phase,
essentially
consuming
apis
that
were
created
on
like
random
folks
and
things
like
that.
D
Then
we
created
like
a
dedicated
GitHub
Organization
for
topology,
where
scheduling
work
and
the
API
has
been
relatively
stable
since
and
we've
had
out
of
three
compute
components
that
have
made
their
way
into
appropriate
repositories,
one
of
them
being
NFD
and
the
other
one
being
a
scheduler
plug-in
Repository.
A
Yeah
I
I,
don't
know
how
other
things
feel
I,
don't
see
a
reason
to
deviate
from
what
was
already
I
guess
thought
through
and
but
my
memory
is
a
little
week
right
now
on
this,
as
does
anyone
else
have
opinions
on
this.
F
I
think
it
would
be
good
to
move
those
API
definitions
out
of
external
or
optimization
to
kubernetes
six,
because
that
means
we
can
use
both
all
cncf
infrastructure
for,
like
approvals,
review
or
streams
to
automatic,
not
just
and
so
on.
So
it's
a
good
step
forward.
I
think.
D
Right
yeah,
so
the
football
the
proposed
API
would
be
within
the
kubernetes
project
would
be
in
staging
and
then
it
would
be.
The
publishing
bot
would
create
a
mirror
of
it
in
under
kubernetes
organization.
F
D
Again,
I'm
not
sure
previously
we
were,
it
was
suggested
to
us
that
the
cre
base
apib
part
of
kubernetes
organization
I'm,
not
sure
how,
if
we
were
to
propose
it
under
kubernetes,
we
we
would
run
into
circular
dependencies
because
we
are,
we
have
those
components
already
under
kubernetes
sick
and
then
they
be
component
they'd
be
consuming
an
API
within
the
kubernetes
state.
I
believe.
F
D
G
G
A
Yeah
yeah,
so
my
it
looks
like
we
had
discussed
this
back
in
November
2020.
A
So
it's
I
think
it's
fair
that
each
of
us
just
takes
a
moment
to
refresh
what
my
thoughts
were,
but
I
guess
my
own
feeling
in
this
body
was
like
it's
been
a
weird
few
years,
and
so
it's
good
that
people
are
able
to
pick
this
up
now
and
thanks
Alexander
for
so
spawning.
It
I'll
just
quickly
look
through
on
what
the
history
was,
but
it
seems
fine
to
me
that
we
should
populate
it,
particularly
folks
in
the
community,
we're
like
willing
and
able
to
work
on
it.
A
A
E
A
Is
the
staging
directory
itself
will
require
some
higher
level
approval,
so
we'll
probably
need
to
find
somebody
outside
of
just
within
the
Sig
at
top
level,
and
then
maybe
the
ask
would
be
in
the
interim.
If
there's
it
looks
like
you
have
yourself,
and
at
least
one
other
individual
is
a
security
contact.
If,
if,
if
this
list
is
up
to
date
or
if
others
want
to
be
at
it,
that
would
probably
another
thing
I
would
look
at,
but
yeah,
maybe
Alex.
A
If
your
timer,
maybe
you
can
help
out,
may
just
make
sure
that
we're
doing
the
right
things,
but
it
looks
like
seems
fine
to
me,
so
we
can.
F
A
A
D
A
Object
in
to
keep
Cube
and
now
link
to
like
a
cut
template,
and
we
just
had
the
enhancement
freeze
and
that
whole
thing,
since
this
will
be
derived
from
a
staging
directory
within
KK
itself,
I'm
just
trying
to
think
through
up.
There
was
a
any
thing
we
need
to
do
with
respect
to
the
enhancements
process,
to
make
sure
that
Sig
release
is
Happy.
A
So
maybe,
if
we
can
also
before
we
merge
it,
get
a
release
lead
to
come,
and
if
there
was
something
special
here,
we
needed
to
do.
Okay,.
D
G
F
A
Try
yeah
yeah
I
just
want
to
make
sure
we're
doing
the
right
things
and
nothing
else
to
be
undone
or
look.
A
Look
that
incorrectly
I
guess
given
all
of
us
getting
up
to
speed
on
what
we
thought
in
2020.,
so
yeah
with
that
I
think
that's.
Why
just
give
us
some
time,
maybe
today
or
tomorrow,
to
refresh
and
then
we'll
comment
on
the
pr
and
then
make
sure
the
release
team
was
good.
A
All
right:
well,
thanks,
so
much
for
those
who
brought
topics
forward
and
we'll
see
you
all
I
think
next
week
might
be
the
Fourth
of
July
holiday
in
the
U.S.
Maybe
we
should
decide
if
we.
A
Or
not,
yeah
I'm
not
sure
how
many
people
will
be
here
or
not
either
way.
Well,
I!
Guess
we'll
play
it
by
year
on
that
Tuesday
morning.
So
for
folks
who
are
here
next
week,
we'll
see
you
next
week
bye
everyone.