►
From YouTube: Kubernetes SIG Node 20221115
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20221115-180257_Recording_640x360
A
All
right,
hello,
everyone-
this
is
the
November
15th,
I,
guess
2022
signode
meeting
so
I
know
where
the
agenda
today,
let's
just
get
started
first
topic
on
here-
was
from
Giuseppe
and
rata,
around
username
spaces
support
and
how
they
want
to
proceed
either.
You
want
to
come
forward
the
recommendation
or
thoughts,
and
we
have
a
discussion.
B
A
Yeah
I
guess
maybe
rodrigue
was
having
audio
problems,
but
I
would
recommend
it
be
a
separate
cap
and
separate
feature
gate
honestly.
B
A
Just
because
making
one
tied
to
the
other
is
probably
just
going
to
delay
the
core
use
case
that
we
started.
Making
progress
on
from
getting
through.
A
Can
chime
in
when
your
audio
is
fixed
or
if
you're,
fine
with
that
outcome,
that's
done.
D
Yeah
I
think
one
point
would
be
whether
you
want
to
GA
using
current
scope,
so
we
can
at
least
apply
like
force
user
namespace
on
very
simple
pods.
That
may
be
interesting
outcome
as
well.
D
A
Right,
yeah
I
think
give
a
second
for
Rico
to
get
back
here,
but
to
Echo
your
point.
We're
not
I
think
what
was
actually
put
in
Alpha
is
a
useful
Community
user
feature
that
assuming
we
have
no
issues
as
we
go
through
beta
should
graduate
I.
Think
stateful
support
is
a
separate
topic
and
we
can
explore
the
depths
on
that
and
lots
of
stateless
workloads
in
the
world
is
how
I
look
at
it.
So
and
maybe
wherever
you
go
when
he
comes
back
in
a
second,
can,
can
give
his
thoughts.
A
Or
maybe
Justin
I
don't
know
if
there's
any
vendors
or
users
who
wouldn't
find
interest
in
the
current
username
space
support,
as
it
is
stateless
but
I
know,
at
least
with
my
my
red
hat
hat
on
the
scope
of
the
existing
feature
is
useful
for
the
user
Community
we're
we're
serving.
C
F
A
F
Okay,
but
I
I
think
when
or
the
previous
PR
like.
F
For
example,
for
for
the
field
was
not
what
not
okay
to
depend
on
a
feature:
gate
I
think
Jordan
mentioned
that
so
like
that
right
now
we
are
only
adding
the
host
users
field
and
that,
if
you,
you
said
it
tutorial,
use
their
first
users
and
otherwise
you
use
a
different
username
space.
F
So
in
the
validation,
we're
checking
that,
for
example,
the
volumes
are
the
the
ones
supported
only
for
page
one,
there
are
complete
maps
on
this
ephemeral
kind
of
volumes.
A
C
F
A
Okay,
depending
on
where,
in
that
code
path,
it
was
so
if
you
have
a
pointer
to
maybe
Jordan's
comment,
we
can
maybe
get
some
clarification,
but
I
I
feel
like
my
own
memory,
going
through
this.
That
I
I
thought
that
if
this
wasn't
like
a
prepare
for
create
flow,
it
should
be
fine
or
prepare
for
update
flow.
F
Okay,
okay
and
the
other
thing
is
that,
during
the
like,
we
asked
for
an
exception
to
merge
the
the
VR,
and,
during
that
exception,
to
solve
some
concerns
from
six
storage.
We
ended
up
doing
things
like
using
FS
group
to
for
config
maps
and
secrets
to
have
the
proper
permission,
but.
F
F
In
kubernetes,
and
and
so
basically
with
the
solution
that
we
implemented
before
that
was,
the
secret
file
should
have
the
proper
owner
that
have
concerns
for
sex
stories,
and
then
we
have
FS
group.
Then,
if
we
continue
with
this
solution,
then
basically
you
cannot
have
files
like
SSH
Keys,
when
you
enable
username
spaces,
because
most
libraries
and
applications
check
that,
for
example,
the
permissions
of
the
private
key
are
only
like
are
only
for
the
user
and
not
no
there's
none
for
the
group.
F
So
what
what
I
was
thinking
in
that
regards
is
that
I
was
discussing
with
Giuseppe
that
basically,
the
only
easy
way
to
solve
all
this
concern
from
six
storage
is
to
rely
on
ID
Mark
Mouse.
There
is
a
kernel
feature
that
was
merged
in
515
for
but
requires
each
file
system
that
you're
using
to
support
it.
So
if,
if
we
just
change
our
implementation
to
to
require
idents
all
I
think
all
the
concerns
from
sync
storage
will
be
sold.
Even
if
we
regard
for
stateless
path,
the.
F
Of
course
is
that
we
need
kernel
changes
for
a
speculative
part,
but
we're
also
solving
other
issues
like,
for
example,
right
now:
Etc
cost
or
Etc
result.com
and
those
files
are
owned
by
root
on
the
cost.
So,
when
you're
running
with
user
namespace,
you
cannot
modify
those
files,
it's
not
a
big
deal,
but
it's
an
inconsistency
with
what
you
can
do
when
you're
not
running
with
running
spaces
and
if
we
add
up
also
I
didn't
announce.
All
of
those
concerns
should
be
solved.
F
B
I
think,
like
you
may
be
aware,
I
think
it's
ID
mapped
mounts,
aren't
enabled
in
Rel
and
Giuseppe
and
I
are
talking
with
the
kernel
Engineers
there.
So
they
have
expressed
some
security
concerns
and
we
are
trying
to
figure
out
like
if
those
can
be
addressed.
Upstream
but
I
mean
like
if
there
aren't
any
issues
like
ID
map
amounts
to
make
sense
to
solve
a
lot
of
the
cases
we
have
here.
G
C
A
I
guess
Rodrigo
one
like
thanks
for
all
the
the
background
and
I'm
glad
your
audio
got
to
work,
because
we
missed
that
in
the
beginning,
when
giving
our
initial
thoughts
I
think.
A
F
I
think
I
would
like
to
have
the
current
functionality
with
IBM
Applause
and
a
different
or
or
the
same
feature.
Gate
for
me
is
I.
Don't
have
a
strong
opinion
there,
whatever
it's
okay
for
the
like
for
the
technicalities
of
validating
the
fields
in
here
and
there
whatever
is
simple
or
whatever
is
possible,
but.
F
Take
storage
confirmed
that
this
solves
all
the
auditions
for
them.
I
would
like
to
to
implement
stateless
plot.
Support
with
I
did
not
want
to,
because
there
are
some
issues
that
we
have
today,
as
I
was
saying
like
if
you
see
cross
HTC
result.com
and
all
those
buy
mounts
that
it
will
be
very
a
lot,
a
lot
of
Plumbing
to
teach
the
cumulate
to
change
the
ownership.
F
F
Are
there
and
of
course
doing
this
right
now
will
not
close
the
gate
like
will
not
close
the
door
to
do
it
in
the
future?
If
we
say
yeah
we're,
gonna
backboard
I
did
not
bounce
to
some
kernel
that
we
really
need
to,
and
we
can
explore
this
all
this
lecture
fixes
or
or
having
some
limitations,
but
we
can
still
go
back
to
this
code
if
we
need
it
for
some
specific
use,
cases
I
think.
A
Right,
it
sounds
like
there's
a
set
of
four
discussions
that
need
to
happen.
Should
we
just
plan
to
revisit
this,
then
in
the
next?
What
three
weeks
or
so
yeah.
F
A
What
a
recommendation
would
be,
but
I
think
for
everyone
here,
we're
gonna
go
like.
A
I
think
to
the
macro
question
on
stateful,
pods
I
think
there's
large-scale
agreement
that
just
even
having
username
space
support
on
stateless
pods
is
a
very
beneficial
feature
for
the
community,
and
you
know
the
the
users
that
are
using
the
platform.
So
if
one
becomes
more
complicated,
I
think
we
should
still
look
to
satisfy
the
the
stateless
use
case
and
seems
like
that
was
generally
agreed
upon
when
I.
E
F
We
want
to
talk
about
this,
then
no,
no,
so
my
next
step
will
be
to
join
six
storage.
I
haven't,
checked
the
calendar
and
then
talk
with
them
and
come
back
to
here
with
my
findings.
C
C
You,
oh
there,
you
go
I
have
the
one
last
question.
Yes,
you
are
concerned
just
with
our
current
user
naming
space
support
we
promoted
by
the
unga.
Just
we
we
didn't
solve
this
as
stateful
set
issue
Parts
issue.
Do
you
have
any
concern.
F
Yes,
yes,
right
now,
there
are
a
few
limitations,
as
I
was
saying.
For
example,
some
files
like
Etc
host
or
Etc
result.com
are
owned
by
root
in
the
fast
when
you're
running
with
these
certain
spaces,
so
you're
gonna
change
them
even
if
you're
rooting
the
container-
and
this
is
I-
mean
consistency
with
with
what
happens
when
you're
running
without
a
certain
spaces.
F
C
F
Yeah
yeah:
it's
definitely
something
something
to
argue
about
right,
because
kubernetes
has
several
knobs
to
allow
you
to
change
it,
but
it's
also
an
so
you
can
say
if
you
want
to
change
it,
you
should
use
the
kubernetes.
F
Yeah,
it's
something
that
behaves
differently
when
you're
using
username
spaces
and.
C
F
We
are
relying
on
FS
group,
as
it
was
requested
by
SEC
storage
during
the
exception
period,
and
that
that
great
elimination,
because
all
the
files
like
from
taking
my
secrets,
files
that
are
mounted,
will
have
permission
for
for
the
group
and
that
doesn't
work
with
applications
like
SSH,
or
things
like
that.
So
and
even
if
you
specify
like
I,
want
this
file
to
have
this
specific
mode
in
a
configma
when
it's
mounted
it
would
not
honor
that
so.
I
think
this
is
something
we
should
think
about
before
migrating
into
beta.
F
No
I
think
I
only
captured
them
in
my
coupon
talk
on
cubecon
na
North
America,
but
yeah
I
can
update
the
cap.
Okay
with
this
thanks.
C
C
Luckily,
we
can
find
the
solution
also
can
address
together,
but
I
don't
think
we
can
giving
the
time
limit
guys.
C
F
In
any
case,
I
would
prefer
to
change
the
current
functionality
to
be
based
on
idea
Mouse
before
before
ga
I,
don't
carry
Foods
out
of
our
beta,
but
I.
Think
yeah
doing
that
is
good,
should
be
in
like
a
nice
planning
that,
and
it's
like
a
heavy
change
so
doing
it
in
Alpha
might
might
be
better
yeah.
A
And
then
there
was
nothing
today
in
the
current
feature
where
the
cubelet
advertises
that
it
could
support
username
space.
Remember
pods
right
so
like
yeah
I
guess,
let's
subtlety
here
is.
If,
when
moving
off
of
the
fs
group
to
ID
map
mounts,
we
may
have
to
find
ways
of
advertising
that
you
could
support
host
or
you
could
support
username
space.
Remapping
am
I.
F
Well,
I
think
it
might
not
be
needed,
because
industry
I
will
already
send
these
organic
space
with
the
mapping.
So
the
container
runtime
can
just
use
that
for
all
the
18
months
and
I
think
that
will
be
consistent
with
what
do
we
do
with,
for
example,.
F
Like
because
on
the
oci's
runtime
spec
in
the
capability
front,
we
allow
to
set
the
effective
the
ambient
and
the
the
bounding
such
capabilities
and
on
the
CRI
will
just
allow
one
set
of
capabilities
and
we
set
it
12
and
it
makes
sense
because
oci
needs
more
flexibility
and
equivalent.
We
don't
so.
This
array
will
already
have
the
mappings,
so
I
think
we
can.
We
don't
need
more
CRI
changes
and
we
don't
mind
me
to
advertise
anything
else
like
we
can.
F
Maybe
just
just
do
something
like
make
making
sure
the
mapping
has
two
entries,
because
that
is
something
that
contains
runtimes,
that
don't
support
volumes
will
not
be
able
to
handle.
So
in
that
case,
we,
whenever
we
add
supports
in
the
cubelet
options
main
developing,
have
two
entries
and
that
will
that
might
be
hot
and
yeah.
It's
not
pretty
I'm
not,
but
that
should
be
enough
and
we
don't
have
any
lingering
things
in
our
API
like
after
a
few
releases,
we
can
just
remove
it.
A
F
A
My
memory
was
slow
right
now
because,
where
I
was
going
on,
is
this
like?
If
our
implementation
depends
on
capability,
that's
only
available
and
a
certain
kernel
level
and
I
can't
remember
the
minimum
kernel
level
we
advertise
right
now
that
Cuba
would
work
with,
but
we
have
to
advertise
it
as
an
optional
thing
can
support
okay.
A
Right
does
the
scheduler
need
to
know
that
this
node
could
support
this
pod
or
couldn't
support
this
pod
and
right
now,
I'm
trying
to
look
in
I
think
we
say
our
am
I,
looking
at
the
right
spot
on
the
code
right
now,
I'm
just
grabbing
cube
right
now
to
find
the
men's,
supported,
kernel
version
and
I
find
a
variety
of
Fields
right
now.
So
just
a
thing
to
follow
up
on.
B
F
B
A
A
You
know,
Baseline
minimum
node
that
we
could
run
a
keyboard
on,
and
so
I
was
just
trying
to
figure
out
if
we
have
to
get.
If,
if
we
go
to
ID
map
balance,
will
we
have
to
account
for
being
able
to
advertise
that
this
node
could
support
this
concept
or
not?
And
you
know
with
that
comes
like
a
whole
host
of
other
complications.
A
But
if
we
report
the
kernel
version,
I'm,
not
I,
can't
my
memory
isn't
good
right
now
and
if
the
scheduler
even
makes
any
could
make
any
decisions
just
on
kernel
version.
If
you're
telling
me
it's
that's
not
even
the
Dependable
thing
to
key
on,
then
we
should
probably
figure
out
what
we
could
key
on.
C
I
guess
maybe
only
if
you,
if
vendor
no,
no
also
manage
their
opening
system,
so
they
may
be.
No
there's
the
kernel.
What
is
red
kernel?
Have
the
right
configuration
I
have
the
have
the
fixed,
so
then
we
they
only
can
do
it
is.
Maybe
runtime
class
can
advertise
this.
It
is
because
things
kernel
wash
is
not
dependable,
and
there
are
also
no
high
of
the
kernel
parameters
to
show
anything
kernel.
Config.
A
And
the
only
thing
I
was
thinking
on
this
from
a
Rigo
and
I
can't
remember
what
we
said
was
if
we
put
username
space
in
conformance
in
the
future,
it
probably
just
needs
to
be
able
to
Target
the
broadest
set
of
operating
systems
that
users
might
be
using
and
whether
that
I,
don't
whether
it's
an
old
New
or
Old
Ubuntu
or
a
new
world
Rel
or
Fedora
or
name.
Your
thing
I
was
just
trying
to
think.
A
If
there
was
any
subtlety
there
that
we
need
to
account
for
or
that
would
there
ever
be
a
benefit
to
just
fall
back
on
the
fs
group.
Implementation
I
had
those
known
limitations
for
that
class
of
user.
To
avoid
that
problem
so
by
the
way,
sounds
like
we
have
further
discussions
to
have
with
six
storage
before
we
can
answer
those
so.
F
Yeah
yeah
I
think
the
flow
block.
It
will
also
be
tricky
like
if
you
want
to
implement
the
flow
block.
It
will
be
tricky
because
we
need
to
also
discover
from
the
cubelet,
and
that
is
not
easy,
because
support
depends
on
that.
Like
each
file
system
needs
to
add
support
for
this,
so
you
need
to
prove
all
the
like.
F
F
But
in
in
that
what.
F
A
It
sounds
like
we
have
next
steps
and
I
think
we're
all
better
informed
or
reminded
of
the
issues.
So
thanks
a
lot
for
bringing.
A
Kevin
you
had
the
next
topic
on
the
dynamic
resource
allocation.
Do
you
want
to
share
wherever
that's
going.
E
Yeah,
so
just
a
quick
update
on
that.
You
know
we
merged
the
the
kept
for
this.
Just
before
the
125
enhancement
freeze
happened
and
we
decided
to
delay
the
implementation
to
126.
E
and
we
got
Nick.
We
weren't
sure
if
we
were
going
to
get
it
in,
but
last
Friday
we
got
an
extension
approved
and
it
finally
merged
as
an
alpha
feature
for
126.
E
and
as
part
of
this
new
staging
repo
has
been
created
with
a
set
of
helper
libraries
to
help
people
build
resource
drivers
against
the
dra
API
that
that
has
now
been
merged
into
into
the
core
and
we're
also
planning
on
creating
a
example,
driver
repo.
E
The
use
of
these
helper
libraries
to
show
people
how
to
go
about
building
one
of
these
drivers
against
the
dra
API
I
already
have
an
Nvidia
driver
that
that
we've
written
as
kind
of
in
lockstep
as
we
were
developing
dra
to
make
sure
that
a
real
resource
driver
could
actually
be
implemented.
E
I
demoed
that
here
a
couple
of
months
ago,
and
then
this
example
driver
will
be
kind
of
based
off
the
learnings
I
have
I've
had
in
in
building
the
the
GPU
driver
and
I
have
an
outstanding
request
to
create
that,
but,
as
part
of
creating
the
the
staging
repo,
the
GitHub
management
team
asked
us
to
associate
dra
with
some
official
signode
subproject
and
I
looked
through
the
list
of
sub-projects
that
we
have,
and
none
of
them
really
fit
for
what
Dre
is
and
so
kind
of
the
question
I
wanted
to
bring
to
this
meeting
is:
should
we
try
and
reuse
one
of
these
sub-projects
and,
if
not,
should
we
create
one
and
and
what
should
this
be
called?
E
One
thing
I
noticed
when
I,
when
I
was
looking
through
there's
some
of
them
that
are
either
outdated
or
not
maintained
like,
for
example,
the
one
near
the
bottom
node
resource,
topology,
Dash
API.
If
you
click
on
it,
when
I
open
that
repo,
it's
it's
just
an
empty
repo
with
nothing
in
it.
Yeah.
E
So
I
guess
what
I
was
kind
of
wondering
is
that's
the
one
where
I
mean
this
doesn't
fit
directly
into
that.
But
if
we
had
just
a
general
subject,
project
around
resource
management
or
something,
then
this
would
fall
in
that
so
a
dynamic
resource
allocation
so
with
the
stuff
that
Marlo
and
the
other
instrumental
are
working
on.
E
If
and
when
any
new
repos
Ever
Fall,
underneath
that
so
my
proposal
would
either
be
to
add
a
specific
Dynamic
resource
allocation
subproject,
just
like
these
others
or
have
a
general
Resource
Management,
one
that
listed
all
of
them.
A
A
So
yeah,
maybe
the
first
thing
like.
A
E
G
So
yeah
so
I
have
a
PR
open
that
kind
of
bootstraps
the
repo
per
se.
You
know
sets
up
all
the
things
that
you
need
for
Bots
populates
owners
and
everything.
So
that's
the
main
PR
that
we
need
to
merge
and
then,
following
that
we'll
have
to
merge
the
API
itself.
I
wanted
to
get
the
bootstrapping
API
merged
before
we
move
on
to
the
API
because
it
might
require
you
know
back
and
forth
and
API
reviews
so
I
can
I
can
just
paste
here
the
the
pr
if
people
want
to
have
a
look
yeah.
A
G
A
G
Find
out?
Because,
because
this
is
a
staging
repo,
we
have
to
create
PRS
directly
to
kubernetes
kubernetes
and,
and
we
can't
really
create
a
PR
directly
to
this
repo.
E
A
And
then
just
the
other
stuff
that
comes
with
being
a
sub
project
is
like
owners,
and
that
type
of
thing
like.
E
A
Assuming
Kevin
and
Swati
and
others,
maybe
we
could
you
could
iron
out
how
you
would
want
the
structure
there
to
be,
and
just
maybe
come
back
with
some
recommendation,
but
I,
don't
I,
don't
feel
I
need
to
be
involved.
I,
don't
think
Don
needs
to
be
involved.
It
feels
like
you
all,
are
capable
of
finding
the
right
outcome
on
that.
One:
okay,.
A
E
Yeah
I
think
that's
that's
what
he
was
mentioning
I
think
that's
somehow
embodied
in
these
PRS
that
she's
currently
blocked
on.
G
G
One
more
issue
with
this
PR
is
one
of
the
jobs
fails,
because
the
bot
does
not
take
into
consideration
the
pr
itself
and
I
think
this
was.
There
was
similar
issue
with
Dynamic
resource
allocation
yeah.
We.
E
Had
the
same
issue
with
dims
was
able
to
override
the
test
for
us
and
then
get
it
merged
and
then
do
some
magic
to
get
it
to
then
start
passing
tests
after
that
yeah.
G
A
Have
I
think
James
is
who
you
could
probably
best
work
with
you're
looking
at
a
program
staging,
but.
A
Okay,
okay:
I
didn't
see
that
on
there
all
right,
well,
I'm
glad
we
had
the
discussion,
so
we
could
unblock
your
sweaty
and
I'll
act.
C
A
D
Yeah,
thank
you.
We
we've
been
discussing
during
the
previous
release
that
we
want
to
start
a
side
cardboard
group
early,
so
we
can
get
a
proposal
approved
before
127.,
so
we
found
this
group
and
we
had
the
first
meeting
just
before
this
meeting.
Next,
we
think
will
be
the
same
way
like
Tuesday
at
9,
Pacific
and
yeah.
D
You
can
read
all
the
discussions
we
had
and
we
started
with
outlying
all
the
rejected
designs,
so
it
will
be
easier
for
us
to
design
something
new
and
propose
it
here.
So
yeah.
If
you
want
to
join
it,
please
join
attendance
was
amazing.
We
had
like
35
people
joined
that
meeting
it's
more
than
currently
on
this
call
and
a
lot
of
interest
to
the
topic.
A
A
Was
it
recorded?
I
I
have
a
a
week-long
event
here
at
red
hat
that
I've
had
to
step
out
of
for
this
one,
so
I,
unfortunately,
wasn't
able
to
step
out
for
two
hours,
but
if
I
wanted
to
catch
up,
was
it
recorded?
Yes,.
D
I
use
the
same
Zoom
account
but
a
different
meeting.
So
it's
amongst
the
recordings
all.
A
Right
so
I'll
get
through
as
I
upload
to
Youtube,
probably
next
week
and
catch
thanks
a
lot
all
right,
excellent
and
then
I
think
that's
it
for
topics
that
were
later
on
agenda
I,
don't
know
if
Renee
is
here,
I
did
get
through
his
In-Place
resizing,
PR
and
I
thought
it
appeared
to
meet
everything
that
I
had
previously
looked
at
and,
aside
from
Bobby's
last
comment,
which
I
think
could
be
handled
in
beta,
it
looked
okay,
so.
A
I'll
catch
up
with
the
name
on
that
one
separately,
but
hopefully
we
can
unblock
that
as
as
soon
as
possible.
Now
any
other
General
announcements
or
things
that
folks
want
to
bring
up.
D
And
next
week
is
a
short
week
in
the
U.S,
so
we
may
have
lower
attendance
than
usual.
We
might
like.
We
can
say
that
if
there
will
be
no
agenda,
maybe
we
need
to
cancel
and
okay
now
is
I.
Think
we
failed
to
do
analysis
of
all
the
Caps
are
going
before
code
fees.
So
maybe
we
cut
to
the
next.
You
can
go
through
the
capsule
126
and
see.
A
Foreign,
we
got
one
plus
one
to
cancel
for
next
week.
So
if
there's
no
strong
objections,
we
can
just
assume
that
and
I'll
make
the
update
all
right.
Well,
thanks
so
much
for
the
discussion
today
and
for
folks
in
the
US
have
a
good
holiday
and
we'll
see
you
back
in
I.
Guess
two
weeks
bye,
everyone.