►
From YouTube: Kubernetes SIG Node 20211027
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
Good
morning
it's
october
27
2021,
it's
a
signal.
Ci
sub
meeting
welcome
everybody
yeah
today
agenda
manu.
You
asked
a
question
yesterday
on
slack
and
welcome
to
the
meeting.
Let's
discuss
what
you
have
to
ask.
B
Yeah
so
essentially,
I
was
working
on
removing
like
a
performance
bottleneck
for
six
storage
and
that
particular
feature
is
available
only
on
like
the
system
policy
available
only
on
linux,
kernel,
5.6,
plus
what
I'm
one
of
the
asks
on
the
pia
until
like,
since
we
were
talking,
was
basically
to
figure
out
a
way
to
write
end-to-end
tests
with
the
latest
kernel.
B
Yeah
here,
but
this
morning,
jan
essentially
told
asked
me
like
if
we
can
write
unit
tests
by
marking
the
kernel
system
calls
what
I
even
what
I
wanted
to
understand
was
like
if
there
is
a
possibility
of
like
just
getting
like
a
latest,
cos
beta
or
91
or
92,
and
write
like
tests
that
can
using
gingko
but
specifically
for
the
module
rather
than
like
providing
a
pod
spec
or
not.
A
B
So
this
code
path
will
will
run
every
single
time
if
you
have
a
persistent
volume
or
any
volume.
For
that
sake,
not
just
persistent
volume.
B
Yeah,
that
is
one
way
to
look
at
it.
The
thing
is
that
it
also
this
particular
function
also
has
like
a
fallback
to
support
like
older
kernels,
so
we
won't
really
know
like
which
code
path
it
is
going
through.
B
Another
thing
is
that
if
we
run
like
all
the
six
storage
tests
on
the
latest
kernel,
I
it
would
slow
down
the
entire
test
suite
for
others
also
like
even
now.
It
takes
probably
like
two
hours
or
three
hours
right,
two
hours
to
run
the
entire
test
suite,
so
I'm
not
sure
like.
If
that
is
something
like
the
entire
ci
would
slow
down.
B
A
I'm
not
sure
what
you
mean.
Why
is
it
slower.
B
B
Test
for,
like
both
the
older
kernels
and
also
the
newer
kernels,
you
cannot
like,
since
a
majority
of
our
users
are
probably
on
like
5.4
or
4.1
before
today
and
most
so.
We
do
need
to.
I
think,
like
removing
those
tests
is
not
a
good
idea,
so
you
have
to
like
either
duplicate
those
tests
or
something
else.
A
So
yeah
one
option
is
just
like
next
items
that
I
put
here
cos.
81
is
currently
is
already
out
of
end
of
support,
so
what
we
can
do
is
to
bump
coso
81
to
some
other
cause,
and
let
me
know.
A
This
is
a
course
version,
so
81
is
out
of
support.
Already
85
will
be
out
of
support
december
2021,
so
maybe
you
can
just
switch
to
cos
89
for
cos
version
1
and
cost
93
for
other
one.
So
you
run
all
the
tests
in
two
flavors,
of
course,
and
this
one
is
below
5.4
kernel,
and
this
is
about
5.4
kernel.
A
A
Six:
okay,
okay,
then
yeah.
If
you
will
just
switch
to
cos
89
and
cos
93
as
two
flavors,
of
course,
that
you
test
on
it
will
cover
your
scenario
right.
It
will
okay
and
yeah.
Let's
take
a
look
at
this
grid.
Do
you
know
which
tests.
B
C
B
Six
storage
cube-
and
it
is
it
was
in
cuban,
it
is
slash
six
storage
and
testing
from.
A
C
A
Yeah.
I
think
once
we'll
switch
to
these
versions
like
it's
89
and
cost
93
you'll
get
at
least
these
tests
to
run
on
both
versions.
A
Okay,
yeah,
I
don't
know
how
to
ensure
that
we'll
keep
go,
keep
happening
going
forward
because
you
like
test
coverage
for
this
feature,
will
be
heavily
reliant
on
which
course
images
we
picked
for
you.
So
I
I
think
from
six
storage
perspective,
you
need
to
put
some
kind
of
guards
and
understand
whether
you
run
all
the
tests
or
haven't
run
the
test.
A
The
problem
is
like,
let's
say
tomorrow:
we
switch
to
course
89
and
cost
93,
and
you
you
test
your
feature
very
well,
but
then
going
forward,
like
maybe
cos
89
will
update
the
kernel
version
to
5.6.
So
all
the
cost
versions
we
test
with
already
have
like
already
have
cos
kernel
version
larger
than
5.6.
A
So
we
are
losing
test
coverage
for
older
versions
of
kernels.
B
B
B
No,
I
think
your
suggestion
of
moving
to
like
lts
93,
as
the
second
cost
makes
perfect
sense.
I
don't
know
like
how,
like
google
does
like
cos,
girls,
because
I
don't
think
so
they're,
like
probably
change
kernel
version,
that's
my
instinct
for
a
specific
course
version.
B
So
only
when
they
cause
versions
get
out
of
support.
We
we
could
say
like
okay,
that's
the
case.
So,
for
example,
what
I
I'm
thinking
right
now
is
like
a
four
dot.
We
start
by
maintaining
two
last
two
or
three
stable
kernel
versions
by
cos,
so
5.4
and
5.10
lts
versions
could
be
a.
It
could
be
a
release
thing
where
we
guarantee,
like
some
sort
of
stability
test
guarantees
like
4.14,
is
moving
out
of
lts,
so
we'll
probably
remove
it
as
a
community.
A
I
mean
in
general,
we
were
trying
to
like
why
we
used
two
close
versions
is
one
is
for
latest
and
one
is
for,
like
oldest
so
at
the
time
we
used
81
and
89.
I
think
so.
It
was
like
latest
available
and
like
earliest
available.
So
that
was
the
idea
behind
it.
A
Yeah
I
mean
whatever
the
case
like
I
don't
know
how
long
do
you
want
to
keep
this
fallback
logic
in
in
couple
years
it
may
be
like
not
needed
any
longer.
It's.
B
I
think
it
would
be
there
for
like
at
least
five
or
six
years,
at
least
because,
like
a
lot
of
providers
are
relying
on
like
kubernetes
and
what
happens
now
is
like
they
sometime
can
build
their
own
cubelet
and
like
put
it
into
an
older
kernel,
just
because,
like
of
their
use
cases,
I've
seen
or
heard
about
this
at
least
so.
B
I
I
think
like
it
would
be
there
for
a
long
long
time.
We
may
not
test
it
because,
like
those
kernels
are
out
of
date,
but
we
may
not
be
able
to
remove
that
piece
of
code
just
because
that
would
mean
like
that,
would
basically
break
its
cubelet
completely.
A
D
I
have
a
suggestion
here,
I
think
from
the
pr
it
looks
like
the
functionality
is
the
same
across
both
kernels,
except
it
takes
a
fast
path
and
a
slow
path.
B
D
B
Yeah,
so
I
can
add
to
that
actually
a
bit
more,
so
we
were
talking
about
this
on
the
pr.
B
I
think
what
would
be
the
next
step
would
be
to
like
carry
all
of
that
unit
tests,
regardless
of
fast
path
or
slow
path
and
because
we'll
have
like
so
that
would
ensure
that
things
are
things
are
not
breaking
from
a
customer
point
of
view
and
because
we'll
have
like-
and
I'm
just
thinking
right
now,
probably
and
correct
me
if
I'm
wrong
now
that
we'll
have
two
stable
kernels
one
with
like
less
than
one
on
5.4
and
one
on
5.10,
we'll
be
able
to
test
both
of
them
and
that
should
not
break
anything
that
should
help
not
break
anything
for
the
customer,
regardless
of
whatever
time
it
is.
D
I
guess
my
suggestion
is
that
we
could
take
the
more
modern
os
with
the
latest
kernel
and
test
both
passes
with
the
slow
one
and
the
fast
one.
So
you
don't
have
to
run
them
twice.
Well,
run
them
on
each
kernel
once,
but
we
could
just
pick
the
latest
kernel
to
run
both
sets.
B
B
Yeah
yeah,
I
see
what
you're
saying
that's
how
the
unit
tests
have
been
written
right
now,
so
I
would
basically
add
up
one
more
function.
That
does
not
really
care.
I
can
share
my
screen
if
you
want,
but
essentially
yeah.
I
think
we
are
on
the
same
page
like
one
test
path
would
cover
both.
We
would
not
even
care
about
slow
or
fast
path
and
the
other
one
would
care
only
about
the
fast
part
was
what
I
was
thinking.
D
Yeah,
I
was
thinking
like
a
slow
pass
function
and
then
a
fast
pass
function
and
then,
depending
on
the
kernel
that
you
have,
one
of
them
would
be
skipped
or
both
of
them
would
run.
B
Yeah,
the
okay:
the
thing
is
that
even
the
fast
path
is
also
heuristics.
All
we
say
is
that
if
it
is
a
mount
point
or
not,
if
it
is
not
a
mount
point,
we
fall
back
to
do
more
heuristics
on.
D
B
To
read
proc
notes,
basically
to
determine
if
it's
it's,
if
it's
actually
a
noun
point
or
not,
so
that
makes
it
a
bit
more
complicated
there.
B
A
Yeah
we
can
take
it
offline
and
like
comment
on
this
pr,
but
yeah
good
news
is
once
you
upgrade
the
course
versions
to
93
and
you'll.
Have
your
test
pass
on
latest.
B
Yeah
I
can
take
up
as
the
next
action
item
on
that.
If,
if
that
sounds
good
to
you,
I
need
some
help
on
how
to
do
that,
but
yeah
I
I.
B
A
A
C
A
Okay,
yeah,
and
with
that
I
suggest
we
go
to
backtrack.
Is
there
any
more
topics
on
the
test
part
of
the
meeting.
A
E
Via
extra
cubic
extra
arguments,
and
currently
it
fell
into
like
two
parts
because
he's
trying
to
like
to
post
all
all
arguments
under
the
single
under
the
single
key,
because
it's
like
cube
text
arguments,
it's
map
from
string
to
string,
so
he
cannot.
He
can
provide
like
reserved
memory
multiple
times,
because
it
will
just
override
the
same
thing
and
he
is
trying
like
to
provide
all
arguments.
E
All
reserved
memory
under
the
single
under
the
single
string
and
like
our
parsing
logic
under
the
kubrick
cmd,
doesn't
know
how
to
parse
it
correctly
and
from
it.
It's
like
it
is
failing
in
general.
I
think
it's
a
bug
in
our
parsing
project.
He
can
work
around
it
with
a
kubrick
config
file
or
with
additional
request
under
the
cube
admin,
but
I'm
still
thinking
it's.
It's
a
bug
way.
A
A
A
B
A
Yeah
this
seems
pretty
specific
and
straightforward.
So
even
like
link
to
the
code,
somebody
wants
to
take
a
look.
Why
we
don't
respect
configuration.
B
A
A
Yeah,
I
don't
know
how
much
it
is
it's
ignored
and
how
much
of
it
this
epic.
D
A
Yeah,
but
how?
How
will
we
differentiate
on
api,
or
maybe
like
only
pset,
it
has
to
be
definition.
D
C
B
A
Yeah,
I
wonder,
would
be
the
right
seek
for
that.
Is
it
api.
A
Yeah,
I
just
I
just
want
to
apply
another
proper,
seek
to
decide
what
needs
to
be
done.
So
I
think
it's,
I
would
say
it's
api
machinery.
Do
it?
C
A
E
A
Okay,
it's
not
a
bug.
E
C
A
A
A
A
Yeah,
I
I
was
searching
for
capabilities
test,
but
you
don't
have
many.
You
just
desert
reset
capability,
so
I
assume
it
should
be
enough.
They
think.
E
A
A
A
C
C
A
Or
just
for
security
yeah,
I
cannot
triage
it.
Let's
keep
it
okay,
then
we
have
five.
Six
minutes
left
almost
a
time.
Any
other
topics
for
today.
Any
suggestions,
comments.