►
From YouTube: Kubernetes SIG Node 20230117
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20230117-180545_Recording_2010x1120.mp4
A
A
Welcome
everybody
today,
I
want
to
start
with
our
typical
PR
Trends
analysis,
so
we
have
200
217
PRS
right
now
we
don't
close
and
merge,
as
actually
as
we
would
expect,
and
also
we
start
working
on
enhancements,
so
I
think
it's
a
stage
of
a
project
when,
like
people,
mostly
looking
at
their
reviews
and
writing
enhancements
and
doing
PR
reviews,
but
if
you
have
Cycles
please
get
on
it
and
help
us
move
project
alone
and
keep
your
number
healthy.
A
B
Yeah
I
was
so
yeah.
Can
we
drill
into
that
issue.
B
So
this
is
for
the
local
storage
capacity.
Isolation
feature
it's
Alpha
currently
and
there's
some
problems
with
it.
There's
a
few
issues
open
for
it
like
this
one
and
others,
and
the
question
is:
do
we
want
to
keep
the
feature
around
and
graduate
it
to
Beta
or
deprecated
out?
B
C
C
Is
this
something
we
can
check
with
the
kernel
file
system
teams
and
see
if
they
can
help
out
here.
C
D
So
the
the
feature-
maybe
I,
can
add
a
little
bit
back.
What
the
context
the
the
feature
is
like
non-dual
feature.
What
do
we
want
to
do
because
we
don't
have
efficient
way
to
track?
This
is
the
kernel
feature
I,
think
that
maybe,
like
the
even
like
15
years
ago,
I
already
sent
this
request
to
Nina's
Community.
D
So
we
don't
have
efficiently
tracker
the
disk
usage
and
so
there's
the
feature
long
do
in
the
kernel
side.
They
have
the
this
quarter.
They
used
because
this
quota,
then
the
this
is
the
second
version
of
server.
Wasn't
I
forgot,
so
so
so
when
we
first
have
the
kubernetes
start.
So
we
are
not
also
have
this
kind
of
problem
and
which
is,
we
have
to
use
in
a
really
heavy
way
to
track
of
the
disk
usage.
D
So,
luckily,
right
now,
a
lot
of
the
usage
is
using
the
pde,
remote
storage,
all
those
kind
of
things
not,
but
on
the
local
storage
side.
Today
we
still
have
a
little
bit
problem.
I
mean
not
the
need
of
a
problem.
If
a
customer
using
having
it
on
the
local
storage,
we
cannot
really
efficient
to
track
off
the
image
usage,
the
login
usage,
all
those
kind
of
things
and
not
really
efficient
to
charge
to
the
user.
D
So
so
this
is
the
time
we've
been
promised
by
the
kernel
folks,
they
are
going
to
give
us
not
perfect
way,
but
this
is
better
could
be
connected
to
the
second
instance
like
the
process
right
per
process,
those
things,
and
so
so.
This
is
why,
after
this
third
washer
or
something
exciting
implementation,
so
we
founded
this
effort
in
the
kubernetes
community.
D
I
I
haven't
looked
at
it,
but
I
know
that
when
we
review
in
this
community
meeting-
and
we
did
the
thing
about
the
kernel-
implementation
still
is
a
little
bit
different
from
what
original
thought,
but
the
I
I
agree
with
the
menu.
What's
the
real
problem,
it
is.
Maybe
this
is
the
good
way
for
us
to
send
those
requests
to
the
kernel.
Folks.
D
No
matter
CPU
and
memory
actually
is
because
how
we
are
using
those
containers,
then
we
send
you
those
requests
so
like
this
MCG
memory,
V2
like
the
usernand
username,
the
handling
actually
request
from
us
more
than
like
around
15
years
ago.
So
that's
why
I
think
this
also
could
be
the
similar
way.
B
So
I
wanted
to
start
the
process
of
maybe
deprecating
this
feature
since
there
isn't
really
an
efficient
way
of
doing
it.
That's
cross-bought
form.
Are
there
any
objections
of
doing
that.
B
Yeah
I
I
think
yeah
on
the
on
the
pr
or
issue
that
I
create.
I
can
summarize
the
status
and
we
can
have
a
discussion
there
on
it.
If.
B
C
Yeah
yeah,
once
you
have
an
update,
we
can
again
discuss
here:
okay,
just
like
yeah.
A
F
And
so
just
quick
question
for
this
feature
without
it
Google
Tracks
file
usage
with
like
du
right,
just
like
okay
got
it,
because
the
other
thing
I
would
recommend
we'd
look
into
I
think
we
also
need
to
support
it
on
the
container
on
time
side,
because
container
runtimes
also
Support
over
the
CRI.
The
report,
you
know
overlay
file,
system
usage,
basically
right,
and
they
also
do
this.
So
I
think
would
have
to
we'd
have
to
think
about
that
as
well.
B
B
Update
the
issue
with
the
collected
issues
from
all
the
other
other
issues
on
this
topic,
and
we
can
have
another
discussion
about
it.
Thanks.
A
Yeah-
and
this
is
one
of
the
those
in
like
infinite
alphas
and
infinite
battles
that
we
need
to
get
rid
of
so
General
mandate
is
if
we
have
something
that
never
graduates
so
past
Alpha
Beta,
it
needs
to
be
deprecated,
so
I'm
not
saying
that
we
need
to
force
it
on
this
specific
case,
but
it's
something
we
need
to
actually
look
into.
A
Okay,
Renee
I,
think
I
saw
you
in
a
call.
E
Yeah
I'm
here
so
in
the
In-Place
part.
The
update
here
is
that
the
API
PR
Tim
Hawkins,
is
concerned
about
the
gap
between
merging
the
API
PR
and
then
a
week
later,
following
up
with
the
implementation
PR
rebase
to
the
merged
API
PR.
The
concern
is
that
if
there
is
any
anything
that
comes
up
that
would
require
you
to
unwind
the
whole
feature,
the
worst
case
scenario.
E
Then
it
will
be
very
difficult,
especially
if
other
peers
interview
intervening
peers,
have
picked
up
on
the
API
changes
and
then
we're
gonna
have
to
run
through
resolving
Airy
conflicts.
I
think
it's
a
reasonable
argument.
I
don't
have
any.
My.
My
main
reason
to
separate
them
out
was
that
these
are
there's
a
big
change
and
it
would
be
easier
for
in
posterity.
If
someone
is
looking
at
it.
Just
look
at
the
API
changes.
It's
just
one
commit
there
and
then
the
implementation
is
a
separate
commit.
E
That
was
my
main
reason
and
then
a
secondary,
auxiliary
reason
here
is
that
it'll
help
me
it'll.
Give
me
the
time
to
bring
in
the
periodic
CI
jobs
which
we
have
disabled
and
ensure
that
they're
running
clean
and
they're
doing
no
Ops
until
the
implementation
merges
and
the
implementation
goes
in.
They
continue
to
remain
green.
It's
not
a
big
deal.
The
I
think
tense.
E
Point
stands
despite
these
two,
so
I
have
no
concerns
I'll,
always
we
can
always
add
the
periodic
CA
jobs
afterwards
and
then,
if
there
is
any
issues,
then
we
will
iterate
on
it
and
fix
it,
hopefully
fairly
quickly.
E
E
So
it
I
think
at
this
point
we
want
direct
and
Tim
to
you
know,
go
in
there,
I
just
rebase
the
pr
and
then
updated,
checked
the
pull
request.
The
pull
job
for
In-Place
resize
ran
it
multiple
times.
It's
again,
it's
established
a
history
of
running
green.
E
We
just
want
both
team
and
direct
to
slap,
their
LG
TMS
and
approves
and
get
this
in
and
watch
over
it
for
the
next
week
or
so
and
then
bring
the
other
CI
jobs
in
one
of
the
change
that
we
discussed
in
the
context
of
that
API
PR
is
a
small
name
change
to
the
resize
policy,
to
structure
it
better
to
allow
for
different
policy
types
to
be
appended
today.
We
just
have
resize
policy
under
that
we
have
a
policy,
no
restart,
restart,
not
required
and
restart
required
it.
E
What
he
said
is
it
might
be
better
to
name
that
as
restart
policy,
so
that
it's
very
specific
on
what
it
is.
What's
the
meaning
and
then
not
required
and
restart
container
and
potentially
in
the
future,
have
something
like
a
restart
pod.
This
could
be
for
some
kind
of
a
VM
container
which
requires
you
to
run
through
the
init
processes.
Init
containers
once
again
to
provision
it,
and
there
is
no
other
way
to
do
this
other
than
have
Google
support
it.
So
that's
a
plausible
use
case.
E
E
I
saw
your
question:
did
you
mean
scheduler
1
20
of
API
server
129,
or
did
you
mean
119?
You
asked
a
question
on
the
on
the
cap
update
that
I
kept
on
kept
update,
PR.
E
Okay,
yeah
the
there
is
a
versions,
Q
document
that
I
found,
and
they
have
very
specific
reasons
to
allow
only
certain
versions
and
I
think
with
the
scheduler
and
cubelet.
Let
me
just
post
it
here
in
the
chat
with
scheduler
and
Kublai,
with
scheduler
and
API
server.
The
scheduler
must
not
exceed
the
API
server
version,
but
it
can
be
behind
by
one
that's
what
they
have
in
here.
So
this
is
the.
E
So
that's
the
reason
I
drove
the
table
to
see
you
know
what
combinations
make
sense
and
what
we
need
to
support,
and
this
is
going
to
be
a
follow-on
PR
again,
because
the
sphere
has
already
been
reviewed
and
approved
by
direct
I.
Don't
want
to
touch
even
to
change
a
comment
at
this
point
or
resetting
reviews.
The
only
changes
I've
been
doing.
That's
are
the
ones
that
are
forced
upon
me
by
rebasis.
A
E
E
E
Yeah
I'm
hoping
it
will
be
done
this
week-
I
was
hoping
Derek
will
be
here
today
and
I
can
paint
them
as
soon
as
Derek's
concerns
are
addressed,
I
don't
know
if
he
still
wants
the
API
PR
merge
first
and
then
just
go
on
it.
Hopefully
you'll
see
our
notes,
we'll
put
some
notes
in
the
reading
on
the
meeting.
Doc
and
I'll
update
it.
Foreign.
G
Yes,
excuse
her,
so
here
just
an
update
on
the
cap,
so
I've
update
the
cap
based
on
on
the
feedback
and
comments,
but
in
the
past
so
I
guess.
The
two
main
concerns
in
the
past,
but
especially
the
kind
of
for
The
annotation
based
Bridge
Gap
qx.3
proposed
in
the
in
the
cap,
but
now
I
did
that
completely
and
kind
of
put
in
the
in
the
first
implementation
paste
that
that
we
already
go
straight.
G
Try
to
kubernetes
API
with
the
changes,
so
no
no
button
location
but
annotations
would
be
involving
that
at
all.
And
the
other
kind
of
question
has
been
popping
up
many
many
times.
Is
that
isn't
there
a
mechanism
for
limiting
the
usage
of
some
classes
so,
for
example,
being
able
to
say
that
only
two
users
of
this
high
priority
class
on
this
note
can
be?
G
G
Yes,
yeah
yeah,
yes,
scheduler
would
know
about
that
so
yeah,
so
I
can
show
a
short
demo
if
you
want
to
see
how
how
good
kind
of
work
in
practice
I'll
look
for
you,
how
the
user
interface
good
looking
local
practice,
so
I
could
I
could
yeah
yeah.
A
I
think
we
have
time.
So
if
you
have
it
ready,
let
me
know
yeah.
G
A
G
G
Okay
cool,
so
I
have
a
one
one
note
cluster
running
on
the
kind
of
pretty
recent
version
of
kubernetes
and
and
a
cryo
content
container
runtime
touched
to
support
the
Curious
clusters
as
well.
So
let's
take
a
look
at
how
the
node
node
looks
like
so
in
here
we
have
kind
of
enabled
container
level
curious
class
resources,
so
they
say:
block
IO,
like
three
classes:
high
priority
low
priority
and
normal
and
and
now
there
are
two
dummy
classes
that
don't
do
anything
just
for
my
testing
and
demo
purposes.
G
Then
there
is
automatic
rdt
class
rdt
resource
with
four
classes,
bronze
called
Silver
and
system
report,
and
we
have,
in
this
demo,
have
just
put
put
some
capacity
into
these
classes
to
demonstrate
that
so
we
have
kind
of
infinite
as
well.
It's
kind
of
universal
that
would
be
nice.
You
know
practical
in
real
life,
but
High
priorities,
capacity
and
low
priority
has
a
positive
one
and
normal,
like
two
users
can
be
at
the
same
product,
for
example,
and
then
in
the
north
status.
G
We
also
see
the
kind
of
usage
usage
of
this
of
this
pure's
resources
and
if
you
take
a
look
at
the
demo
pod,
we
would
have
a
simple
Port
here.
That
basically
does
nothing,
but
it
has
two
containers:
reverse
container,
put
a
request,
early,
the
class
code
and
local
plus
high
priority,
and
the
second
container
would
request
only
because
low
priority.
G
We
can
see
in
the
not
status
now
that
that
actually
block
our
class
high
priority
and
low
priority
are
both
kind
of
one
instance
is
reserved
from
these
classes,
and
our
data
classes
runs
on
gold
as
well
are
kind
of
so
the
gold
gold
plus
would
be
fully
fully
occupied
at
the
moment,
and
we
have
like
second
container
and
it
tries
to.
It
also
has
two
containers.
G
First,
one
only
requires
requests,
rdpt
class
bronze
and
the
second
order
class
called
and
Clock
Plus
low
priority.
Now,
if
we
try
to
run
this
one.
G
Status,
we
can
see
that
it's
pending,
because
blocklayer
plus
low
priority
is
not
available.
G
So
yeah
now
it
notice
running
and
then
well
the
node
status
kind
of
reflects
the
changed
allocation
of
resources
as
well
Oculus
resources
as
well.
G
H
G
Just
to
extend
the
resource
quota
mechanism
to
to
support
these
curious
Resource
as
well,
so
I
can
quickly
show
that.
So
you
would
have
a
quota
here.
Let's
say
well,
for
a
container
of
resources
or
did
the
class
runs
like
two
instances
are
allowed
in
in
this
default
namespace
and
then
for
Block
IO,
we
don't
put
any
we
allow,
plus
plus,
is
normal
and
low
priority,
but
don't
put
any
capacity
minutes
there
before
the
atomic
one
resource.
We
also
put
some
limits
capacity
limit
to
class
class
D
from
now.
G
You
get
get
the
status
of
the
resource
code.
We
can
see
that
there
are
now
some
some
quota
in
effect
in
in
the
default
namespace,
because
we,
as
we
specified
so
for
this
already
they
will
put
in
this
quote
also
a
kind
of
limit
clinical
values.
G
A
Being
deleted,
can
you
comment
on
how
it
was
configured
like?
Did
you
configure
nodes
first
with
specific
resources,
and
then
they
Auto
Discover
it
somehow
like
which
classes
exist,
on
which
nodes.
G
Yeah
in
the
skept,
the
kind
of
management
of
these
resources
is
handled
in
the
runtime.
So
so
those
resource
resources
are
configured
and
managed
by
the
runtime
and
then
the
runtime
reports,
through
the
runtime
status
message
to
the
to
keyboard.
What
is
available
on
the
nose
and
thank
you,
but
let's
test,
updates,
notes,
tattoos
and
the
schedule
gets
that
that
gets
that
from
there
kind
of
their
availability.
What
is
available
on
which
nodes?
G
Basically,
it's
depends
on
the
resource
I
get
well
and
it's
kind
of
in
the
kept
its
it's
part
of
the
kind
of
status
information
at
the
Discovery
Place
of
the
of
the
resource.
So
some
some
curious
resources,
maybe
maybe
immutable.
So
you
cannot
change
it
after
the
content
or
report
has
been
created,
but
it
is
possible
to
plug
it
as
as
mutable
as
well
so
yeah
I
guess
the
main.
G
Reason
for
immutability
is:
could
they,
for
example,
in
in
some
cases
for
for
like
B
and
B
and
best
runtime?
So
you
cannot
can
maybe
use
cases,
but
you
cannot
really
really
change
it
after
the
something
has
been
allocated
by
the
way,
but
it
it
depends
on
the
kind
of
resource
and
it's
it's
shown
in
the
or
it's
a
statement,
kind
of
discover
this
resource,
Discovery
Place.
A
Yeah
I
need
to
read
through
cap,
but
I
think
today,
nodes
are
have
static,
CPUs
and
static
memory,
because
of
all
the
caching
that
you
do
in
scheduler.
So
there
will
be
no
confusion
like
you
cannot
update.
No,
the
result
not
about
resources
in
runtime,
so
I
wonder
if
it
will
be
new
pattern
with
resources.
G
Okay,
yeah
yeah,
you
mean
immutable,
it
kind
of
what
is
available
so
yeah
yeah
I
got
like
two
two
mute
abilities.
So
one
is
that,
is
it
possible
to
yeah
update,
update
the
kind
of
resource
assignment
of
running
containers,
so
yeah
that
depends
on
yeah
on
the
resource,
but
kind
of
nothing
prevents
from
the
kind
of
API
point
of
view
to
to
change
the
kind
of
available
resource,
local
resources
on
the
Node,
but
that
yeah.
So
from
the
API
point
of
view.
That
is
not
like
restricted
in
any
way.
I
And
Sergey
I
actually
were
immutable,
node
resources,
it's
artificially
only
for
memory
and
CPU.
So
if
we
think
about
extended
resources
on
one
out
or
device,
plugin
provided
resources,
the
capacities
are
updated
based
on
the
state,
so
scheduler
properly
handles
yeah.
A
Yeah
and
I'm
glad
you
all
just
thought
about
the
port
in
place,
update,
I,
think
what
VNA
work
is
showing
that
this
is
a
request
feature
so
it'll
be
interesting.
G
E
And
to
add
some
more
context
to
this
I
looked
at
this
cap
as
well
from
the
perspective
of
adding
the
capability
for
reporting.
Let's
say
you
have
a
network
device,
Network
cni,
which
is
capable
of
offering
different
qos
levels
for
Network
traffic
or
even
bandwidth
limits
and
requests
we
have
limited
today,
but
focusing
just
on
qos
like
traffic
from
part
A
is
high
priority
or
container
a
and
body
is
high.
Priority
container
B
is
low
priority
that
I
don't
know.
E
If
we
can
do
it,
but
for
between
different
parts,
we
can
definitely
differentiate
and
implement
qos.
We
can
give
some
ports
high
priority
like
if
you
have
a
real-time
application
running
in
the
Pod,
then
that
would
require
low,
latency
Network
Pathways
and
that
we
can
make
that
happen
using
avpf.
E
This
feature.
From
that
perspective,
it
makes
it
easy
to
advertise
Qs
levels
in
the
network
traffic
and
then
different
values
that
you
can
have.
Let's
say:
Network
us
and
high
priority
or
expedited
or
best
effort.
You
can
have
these
classes
and
you
can
go
further
Beyond
it.
So
from
my
what
I
saw
I'm
a
huge
plus
one
for
this
feature.
G
E
G
E
We'll
have
to
work
out
how
I
think
it
will
require
cni
extension
to
discover,
capabilities
and
report
that
report
the
extended
capabilities
or
something
another
thing
that
was
going
on
I
saw
on
the
network.
Sig
was
that
the
possibility
of
extending
CRI
to
today
we
have
set
up
pod,
sandbox,
tear
down
pod
sandbox,
explicit
apis
for
setup
or
network
dead
on
board.
Network
I
found
that,
as
a
haven't
figured
out
what
its
advantages
for
Google
to
directly
manage
Network
would
be,
but
there
might
be
some
Advanced
use
cases.
A
E
You
can,
let
me
let
me
just
let
me
just
share
it
in
the
chat.
C
A
Okay,
why
are
we
sharing
the
link?
Let's
go
to
the
next.
I
A
A
Now,
if
you
have
any
quick
updates
or
quick
thoughts,
please
share
otherwise
I
will
go
forward.
A
Okay,
then
yeah
next
item
I
wanted
to
share,
is
Bartosh
requesting
to
be
a
reviewer
and
I'm
fully
supportive.
If
you
have
any
concerns,
please
voice
it
here.
Otherwise,
I
think
it's.
It
should
be
good
to
go.
So
don't
direct.
If
you
can.
Oh
don't
there
is
not
here.
Oh,
don't
is
already
lgtm,
so
we'll
wait
for
that.
I
can
we'll
have
one
more
reviewer.
Hopefully.
J
Thank
you
very
much,
first
of
all,
to
Kevin
and
to
the
people
who
vote
for
me.
I
I
appreciate
this
and
will
hope
to
do
my
best
in
this
role.
Thank
you.
A
I
can
call
you
and
I'll
try
to
remember,
but
yeah
I'm
always
matching
it
to
GitHub
handle
and
sometimes
hard
to
switch
Yeah.
A
Thank
you,
sidecar
sidecar
update.
We
had
we've
been
running
a
sidecar
working
group
for
more
than
a
month
now,
and
we
get
to
the
point
when
we
have
cap
that
almost
fully
fleshed
out
and
we
want
to
move
it
to
GitHub.
Hopefully
tonight,
if
you
have
any
comments
to
the
Google
Doc,
you
can
leave
comments
today
or
tomorrow.
You'll
have
opportunities
to
do
it
on
GitHub
we
I
can
give
more
update
once
you
have
once
you
have
it
on
GitHub,
so
it
will
completely
flushed
out.
A
So
maybe
next
time
I
can
do
small
explanation
in
the
presentation
about
it.
So
yeah.
If
you
have
comments
right
now,
please
comment
it.
There.
A
If
no
questions,
let's
go
to
the
next
item,
next
meeting
for
work
for
plugin
for
Google
plugin.
H
We
will
have
next
meeting
in
two
weeks
from
now.
We
we
had
today
the
the
last
session.
Basically,
it's
we,
we
presented
our
approach.
Basically,
there
was
a
feedback
passed
in
the
last
session,
the
previous
session,
which
we
tried
to
cover
it.
We
presented
a
possible
architecture,
called
how
to
deal
with
that
and
yeah.
We
are
proceeding
with
that
this.
In
next
meeting,
we
will
go
through
more
details
about
the
cap
kind
of
fill
out
with
information,
and
we
will
continue
from
there.
A
They
said
the
meeting
was
today:
can
you
share
recording
so
we
will
have
it
published.
H
Recording
this
with
my
colleague
Catherine,
he
might
be
offline
already
today
latest
tomorrow
morning.
We
will
send
it
to
you
yeah.
Thank
you.
A
Okay,
we
reached
the
end
of
the
agenda
today.
Is
there
any
other
topics,
if
not,
let's
get
20
minutes
back
to
to
do
more
work.
Thank
you,
everybody,
bye-bye.
Thank
you.
Bye.