►
From YouTube: Kubernetes SIG Node 20201124
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
All
right
well
welcome
everyone
to
the
november
24th
sig
node
meeting.
We
have
probably
two
things
one.
I
don't
know
sergey
if
you
had
a
chance
to
get
the
update
on
where
we
were
with
prs.
But
if
so,
you
want
to
talk
through
that
and
then
take
the
agenda
for
your
item.
B
Yeah
prs
looks
good,
I
actually
expected
worse
with
the
freeze,
but
we
immersion
quite
a
lot.
So
it's
good.
I
didn't
have
time
to
review
the
how
to
separate
signal
prs
from
non-signal
prs
but
yeah
something
I'm
working
on
in
the
background.
B
So
I
wanted
to
bring
this
topic
of
conformance
testing
I
so
I've
been
working,
this
runtime
class,
ga
functionality
and
part
of
this
ga
we
g8
api
for
runtime
classes
and
apparently,
like
I
didn't
know
that
apis
have
been
conformance
tested
and
there
is
a
metric
tracking
how
many
apis
cover
this
conformance
testing.
So
how
like
specifically,
every
api
needs
to
be
called
during
the
test
that
is
marked
specifically
as
a
conformance
so
like
some
tests
covers
this
apis.
B
Just
by
chance
like
there
is
a
test
that
calls
apis
to
do
something
on
on
this
api
and
like
this
hits
an
endpoint
and
it
works
great.
But
some
tests
are
basically
crude
test,
create
a
remove
for
update
delete.
So
I
mean
this
is
this
test,
so
it's
basically
like
hitting
api
endpoints
explicitly,
and
I
mean
the
the
only
thing
they
test
is
actually
that
api
works.
B
So
the
feedback
was
that
we
need
more
tests,
more
conformance
tests
for
the
feature,
and
I
was
trying
to
wrap
my
head
around.
What
is
conformances.
What
are
the
limitations,
and
I
wanted
to
discuss
it
here.
So
one
example
I
wanted
to
walk
through
is
like
why,
for
instance,
there
is
a
like
p
limiting
feature,
and
is
it
needed
to
be
conformance,
tested
or
not
because
it
doesn't
hit
any
apis.
B
Is
it
still
required
to
be
conformed,
testing
or
like
desire
to
be
conformance
testing
tested,
or
it's
something
that
we
cannot
conform
stats,
because
it's
very
close
to
the
hardware
to
like
how
how
many
on
or
not
hardware,
like
very
close
to
like
how
exactly
speed
limiting
works
and
yeah.
So.
A
B
So
there
is
a
runtime
class
api
that,
like
runtime
class
features
that
we
want
to
test
and
feature
like
consists
of
multiple
pieces
like
how
we
schedule
node
ports,
how
we
create
runtime
classes
and
create
random
handlers,
so
all
like,
and
all
this
aspect
needs
to
be
conformance
tested.
B
No,
let
me
put
it
this
way.
I
I'm
not
sure
which
aspects
of
this
feature
needs
to
be
conformance,
tested
and
pete
limiting
uses
a
example,
a
feature
that
doesn't
yeah
that
we
just
g8
and
we
didn't
conformance
test
and
it
doesn't
affect
any
apis.
So
I
wonder
if
it
doesn't
affect
any
apis,
doesn't
need
to
be
still
conformance
tested
or
it's
impossible
to
conform
as
tests,
and
I
just
use
the
example
as
a
proxy
to
understand
how,
like
what
features
of
runtime
class,
I
need
to
test
with
conformance
tests.
A
Yeah,
so
I
think
let
me
try
to
give
the
best
guidance
I
can
give
here
so
for
features
that
touch
the
end
user
facing
api.
So
what
a
typical
user
of
a
cluster
could
see
given
a
cube
config,
those
apis
should
have
basic
crud
level
tests,
so
things
like
runtime
class.
A
I
think,
even
when
I
looked
at
your
pr
before
you
had
create
update
list
delete
and
then
I
think,
if
I
look
at
aaron's
comment
there,
he
might
be
suggesting
some
additional
ones
like
to
ensure
a
pod
could
potentially
be
scheduled
to
with
an
associated
runtime
class
or
that
maybe
some
other
criteria
fail.
A
So
I
think
the
guidance
he
gave
at
the
end
of
your
linked
pr
is
is
accurate,
so,
like
the
minimal
set
for
an
end
user
facing
eye
should
be
the
crud
testing
and
then
up
beyond
that,
it's
testing
the
ability
to
consume
that
api
without
having
to
pre-declare
define
how
the
cluster
was
maybe
configured.
A
So
some
of
his
examples
here
were
like
create
a
pod
with
a
non-existent
runtime
class
like
I
think
that
that's
a
good
test
right
and
we
should
see
what
happens
if
it
wasn't
in
there,
creating
it
with
an
existing,
that's
a
good
test
as
well,
so
his
four
that
he
enumerated
are
all
good
extensions
and
if
we
map
that
back
to
things
like,
I
don't
know,
quota
like.
A
If
you
look
at
the
conformance
test
for
quota,
we
have
create
quota
list
quota,
update
quota,
get
quota,
and
then
we
have
a
couple
quota.
Specific
conformance
tests
like
can.
We
do
object,
count
quota
with
an
arbitrary
crd,
for
example,
or
something-
and
so
I
think,
aaron's
feedback
here
is
good
on
maybe
the
four
tests
that
he
recommended
calling
out
and
then
his
secondary
feedback
here
on
saying,
which
was
my
original
feedback
on
your
pr,
which
was
like
we
couldn't
put
into
conformance
the
behavior
associated
with
any
particular
handler.
A
I
think
he's
echoing
that
same
statement,
so
I
would
contrast
this
with
the
pids
feature
in
the
sense
that
the
pids
feature
didn't
change
the
end
user
api.
It
only
changed
with
the
cubelet
sandboxed
and,
as
a
result,
it's
not
necessarily
elevated
up
into
the
api.
Conformance
definition
of
are
you?
Are
you
not
a
kubernetes
cluster.
A
A
That
would
be
expected
to
be
surfaced
up
through
conformance
and
would
need
to
fail
gracefully
if
a
node
did
not
advertise
like
a
quantity
of
pids.
B
So
there
is
a
feature
for
beat
available
eviction,
so
this
is
this
can
be
configured
right.
So
is
it
something
that
we
need
to
conform
test,
as
opposed
to,
like
I
understand,
like
yeah,
so.
A
Conformance
test
is
not
typically
touching.
The
conformance
tests
are
intended
to
operate
on
a
level
above
the
configuration
of
a
given
discrete
component,
so
the
conformance
tests
are
intended
to
pass.
A
For
any
cluster
that
the
operator
may
have
put
together
without
having
to
require
those
tests
to
know
how
to
change
the
cubelet
eviction
parameters
or
a
particular
controller
manager
flag,
where
there
are
specific
tests
that
are
in
the
nbn
suite
that
might
depend
on
a
particular
controller
manager,
flag
being
set.
Those
tests
are
perfectly
fine
to
write
but
they're,
not
tests
that
can
be
elevated
into
conformance,
because
people
can
choose
to
enable
or
disable
that
particular
flag.
B
A
Right
that
would
be
a
good
example,
and
so
then,
like
I
think,
on
the
feedback
there
it's
like
if
there
was
a
particular
handler.
That
said
this
turned
on
g-visor
or
this
turned
on
kata,
or
something
like
that.
A
That's
something
that
we
couldn't
put
under
conformance,
but
we
should
at
least
know
if
a
paw
got
scheduled
as
an
example
onto
another
could
happen
so
trying
to
think
where
there
are
other
examples
like
if
dynamic
public
config
ever
got
promoted
to
ga,
we
would
be
in
a
tough
spot
to
work
out
how
to
properly
do
conformance
testing
on
that.
But
I
think
right
now,
given
our
plan
was
not
to
do
that
like
that,
would
have
been
the
tricky
one.
B
Of
other
features
that
we
just
promoted
to
ga
and
we
have
this
startup
appropriate
promotion
and
I'm
not
sure
whether
the
startup
prop
was
tested
in.
A
C
A
C
A
C
A
follow-up
pr
that
just
adds
the
probe
timeout
test
to
conformance
or
node
conformance.
I
don't
know
what,
if
there's
a
distinction
between
like
do,
you
know
conform
to
that
just
go
into
regular
performance.
I'm
talking
about.
B
So
startup
prof
was
also
promoted.
J,
so
android
feature,
which
is
exact.
A
timeout
is
one,
but
we
also
promoted
startup
probe
as
a
as
a
part
of
like
I
mean
startup
wasn't
ga
before
it
was
beta
feature
yeah.
A
If
it
appears
in
the
pod,
spec
and
a
user
could
consume
it,
and
it's
not
tied
to
a
particular
hardware
profile
of
that
node.
Then
we
should
look
to
get
coverage
within
conformance
as
a
project.
We
know
we're
not
perfect
on
this
right
now,
but
like
it's
possible,
we
had
an
error
or
a
mission
on
that
one
and
we
need
to
go
back
and
correct
it.
But
for
that
one
very
clearly,
yes,
we
we
can
go
back
and
check
if
we,
if
we
did
the
right
thing
or
not,.
B
Okay
and
for
entry
point
about
node,
conformance
versus
regular
conformance
for
exact
timeout.
Is
there
a
difference
between
node,
conformance
and
regular
conformance.
A
Yeah,
so
regular
conformance
is
basically
what
what
drives
the
cncf
trademark
usage.
It
does
not
pick
up
from
node
conformance
right
now.
What
we
had
labeled
node
conformance
was
intended
to
be
tests
that
would
have
been
appropriate
for
wherever
a
cubelet
is
running
without
any
particular
hardware
profile
configuration
so
like
sc
linux
test,
I
don't
think
got
labeled
node
conformance
because
you
might
be
running
on
an
app
armor
environment
as
an
example,
but
other
more
generic
tests,
I
think,
were
labeled
node
conformance.
A
I
can
go
back
and
try
to
find
where
we
defined
the
definition,
but
it's
not
tied
to
cube
project-wide
conformance
suite.
A
Yeah
and
then
the
one
issue,
which
was
only
with
the
docker
runtime,
something
wasn't
being
respected.
That
would
be
an
outlier,
but
for
the
other
two
for
sure.
A
A
pod
spec
is
a
good
guidance,
so
for
your
pr
here
then
sergey.
Are
we
going
to
be
able
to
address
the
feedback?
I
guess
in
time
for
the
release
or
are
we
having
to
move?
I
think
we're.
B
Good
for
the
release,
because
we
are
green
on
api
scoop.
I
I
hope
that
we
can
move
this
18
more
tests
into
121.
So
to
minimize
the.
B
Possible
problems
on
breakage,
I
mean
I
don't
want
to
push
another
pr,
promoting
some
tests
right
now
on
a
short
schedule
and
potentially
break
something.
If
it's
okay,
I
can
do
it
in
one
switch.
One.
A
Yeah,
I
think
that
makes
sense.
Okay,
all
right.
Well,
thanks
for
bringing
up
the
topic,
and
hopefully
those
who
are
going
through
their
first
ga
promotion.
Here
we
can,
we
can
share
our
past
learnings.
I
didn't
see
anything
else
on
today's
agenda
and
I
have
a
conflict
in
a
few
minutes
with
dims
to
help
teach
a
class
about
kubernetes.
So
were
there
other
topics
that
people
wanted
to
raise
now?
Otherwise
we
could
adjourn
for.
D
If
I
could,
this
is
hippie
hacker
and
I
work
with
the
cncf
on
the
conformance
program.
I
wanted
to
take
a
quick
tour
and
it
doesn't
have
to
be
the
answers
back
now,
but
we
have
the
the
website
api,
snoop,
dot,
cncf,
dot,
dot,
io
and
on
on
there
we
have
our
list
of
apis.
D
I
wanted
to
go
beyond
right
now.
If
you
go
to
stable
and
click
on,
node
you'll
see
the
work
that
sergey
did
for
that
promotion.
D
I
suspect
there
may
be
other
apis
that
are
either
beta,
alpha
or
hidden
underneath
one
of
those
groupings,
particularly
in
core
that
could
possibly
be
stewarded
and
and
and
owned
by
signo,
that
I'm
not
aware
of
the
relationship
with
it's
hard
to
track
down
so,
particularly
in
inside
of
stable,
core
and
I'll
drop
that
link
into
the
channel
as
well
and
back
into
the
doc.
D
If
I
could
get
some
ideas
of,
if
any
of
those
remaining
particularly
the
ones
in
gray,
should
be
owned
by
signode.
That
would
help
us
to
collaborate
on
helping
get
those
endpoints
tested
because
node's
been
around
since
the
beginning.
A
Yeah
so
just
pulling
up
the
links
now,
at
least
on
the
first
may
look
under
note-
it's
just
capturing
the
node
api
resource
itself
for
the
other
ones.
Here
I
can
go
through.
D
There's
another
more
just
a
list
and
I'll
drop
this
here.
This
is
a
list
that
currently,
as
of
120,
there
are,
they
are
completely
untested,
and
so
that
list
it's
quite
long,
but
this
is
the
remaining
debt.
A
And
just
for
my
own
recollection-
and
this
is
only
this
is
only
capturing
if
we
call
that
api
endpoint,
but
is
unaware
of
the
actual
communication
on
that
endpoint
right.
So
we
don't
know
if
it
exercises
every
feature
associated
with
a
resource.
D
D
These
particular
ones
are
completely
unhit
and
the
definition
of
hit
is
the
ede
dot
test
user
agent
hitting
the
api
server
itself
in
the
context
of
an
ede
test
run
because
we
updated
the
framework
to
include
the
test
that
is
currently
getting
executed
in
the
user
agent
and
that's
logged
in
the
api
server's
audit,
logs
and
included
in
this
database.
A
D
A
Go
ahead,
no,
it's
fine!
I
was
just
trying
to
like
the
second
list
you
sent,
which,
like
talks
about
untested
endpoints,
then
so
like
deleting
the
node
collection
that
stands
out
as
something
that
we
could
go
and
write
the
tests
for
to
ensure
that
that
yep
doesn't
actually
happen.
D
Read
core
status
and
node
status,
read
and
replace
are
are
somewhat
difficult
to
hit
via
the
kate's
api
or
via
the
golang
library.
You
may
have
to
we've
hit
a
lot
of
these.
You
may
have
to
go
a
little
extra
step
to
be
sure
and
hit
and
replace
those
from
the
ede
binary,
but
that
would
give
us
three
more
points
that
are
that
are
definitely
within
sig
nodes
operations
that
are
publicly
exposed
in
core
that
every
provider
should
be
able
to
ensure
that
is,
is
tested.
A
Yeah
so
like
replace
core
v1
node
status,
I
guess
for
that
one
we'd
have
to
do
some,
maybe
at
best
we
could
do
negative
testing
because
in
theory
only
the
cubelet
agent
itself
should
be
allowed
to
update
its
status.
So
we
could
that
that's
one.
We
can
follow
up
on
I'll,
take
a
note
and
then
but
yeah.
I
appreciate
that
bring
this
list
forward.
I'll.
D
Take
a
look,
thank
you,
a
question
from
andrew.
It
can
show
those
tests,
but
it
right
now.
We
only
show
it
at
the
top
level.
So
if
you
go
and
explore
that
area
to
see,
if
there's
an
api,
only
integration
test,
it'll
just
show
like
on
the
top
front
page,
if
you
scroll
down
it'll,
show
new
promotions
within
this
release
and
it'll,
say,
tested
or
conformance
tested,
you
can
actually
scroll
down
and
see
that
flow
control.
D
Api
server
has
normal
in
a
test,
but
no
no
conformance
test,
so
they
haven't
added
the
conformance
bracket
to
it
as
far
as
integration
test.
If
that's
not
the
same
as
e-e,
I
may
be
misunderstanding.
A
Cool
well,
thank
you
hippie
for
sharing
the
information
here
and
then,
hopefully
sergey.
You
at
least
have
a
understanding
on
next
steps
forward
and
with
that
are
there.
A
All
right:
well,
thanks
again
everybody
and
talk
to
y'all.
There
have
a
good
thanksgiving
for
those.
Let's
celebrate
bye.