►
From YouTube: Kuberentes SIG Node 20201005
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
A
First,
I
want
to
thank
george
for
keep
adding
tests
into
critical
marking
them
with
a
mail
list,
so
we
will
have
more
notification
that
something
is
not
healthy.
Specifically,
this
pull
request
that
you
started
and
looking
at
it.
I
I
see
this
container
deconformance
test
flaky.
There
are
like
one
flaky
test
that
we
need
to
take
a
look
something
about
resource
management,
so,
let's
start
receiving
notifications
and
make
sure
that
we
react
on
them
and
fix
tests.
B
B
C
B
C
A
And
local
looks
good,
I
mean
I
don't
see
any
big
concerns.
Maybe
some
extra
information
on
the
workflow
may
be
increasing,
so
I
I
didn't
know,
for
instance,
whether
you're
supposed
to
remove
ports
or
not
supposed
to
remove
ports
when
that's
complete,
but
I
mean
it's,
maybe
some
two
minutes
of
detail.
B
Yeah
and
okay,
and
actually
that
will
be
also
a
very
good
which
I'll
make
I'll
make
an
issue.
Only
someone
wants
to
beat
me
to
it,
but
the
thing
that
you
just
mentioned-
and
that
is
technically
managed
by
cube
test
and
there
is
very
little
to
no
documentation
on
how
a
cube
test
interacts
with
the
node
test
runner,
and
so,
if,
if
anybody
wants
to
tackle
that,
that
will
also
be.
That
will
also
be
an
amazing
contribution,
but
yeah
other
than
that.
A
And
it
will
set
our
precedence
where
to
put
all
the
documentation,
because
one
of
the
action
items
from
last
time
was
morgan,
wanted
to
put
information
about
the
fact
that
you
can
specify
test
set
in
image
config
and
there
is
no
place
where
you
can.
I
mean
I
didn't
find
any
good
place
for
that.
So
if
you
start
doing
that,
maybe
this
will
be
a
proper
place
to
put
this
information
so
what's
happening
here.
D
A
B
So
my
opinion
I'll
leave
it
up
to
I
mean
because
I
just
added
like
some,
I
just
reviewed
and
added
a
minor
things,
but
I
think
the
document
it's
it's
right
right
now.
I
think
the
document
is
good
by
itself
and
you
know
like
everything
like
everything
we
do.
It
could
always
be
better,
but
I
think
it
is
ready
for
the
beta
release.
A
A
A
A
A
A
E
E
A
A
E
A
E
More
than
just
one
folder
actually
yeah,
I
this
there's
some
risk,
but
I
think
as
overall
it
should
be
okay.
Maybe
we
will
first
do
the
renaming.
It's
just
a
service
change
right,
make
the
community
aware,
of
course,
and
the
second
we
can
and
do
the
second
one
is
move
in
the
same
folder
and
even
change
some
code,
because
the
code
someplace
maybe
break.
E
E
A
A
So
we
still
didn't
have
time
like
right
now,
it's
a
hot
period
because
everybody
tried
to
squeeze
their
caps
into
into
the
120
milestone.
So
we
still
didn't
discuss
this
action
item
on
signals
meeting.
I
don't
expect
we
will
do
it
tomorrow
because
it's
like
last
day
for
caps,
sorry,
but
we
will
try.
F
So
on
this
issue,
I
added
I
added
some
more
detail
to
the
to
the
issue
itself,
which
I
will
post.
But
basically
what
I'm
wondering
is,
if
so,
in
a
nutshell,
the
the
node
conformance
tests
are
intended
to
be
cloud
agnostic,
os
distribution,
agnostic,
container,
runtime
agnostic,
yet
they've
run
in
docker
and
they're
expected
to
pass
for
every
pr.
And
so
I
took
a
little
further
look
into
this
and
it
turns
out
that
they
do
run
for
every
pr,
but
they
just
don't
run
in
docker.
So
I
don't
there.
F
Might
there
might
be
some
other
differences
between
what's
running.
So
I'm
just
wondering
if,
rather
than
keep
trying
to
bring
this
up
in
the
meeting,
if
we
should
just
propose
how
we
what
we
want
and
then
put
up
a
pr
and
then
have
the
discussion
there,
rather
than
bring
it
up
in
the
in
the
meeting,
and
so
we
could,
we
could
just
make
them
look
just
like
the
the
ones
that
run
with
the
pr
or
use
the
pr
configuration
directly
and
and
make
that
change.
F
Well,
I
well
so
I
don't
if
it's
intended
to
be
container
runtime
agnostic,
I
don't
I
don't
know
what
running
in
docker
buys
you
like.
I
don't
know
if,
like
I
haven't,
found
any
documentation
as
to
why
that's
desired.
It's
just
stated
that
that's
what's
happening
and
it
seems
like
it
seems
to
me,
like
the
the
ones
that
run
in
the
pr
and
the
ones
that
run
in
in
our
other
dashboards
should
just
be
the
same.
B
I
think
I
think
I
think
a
lot
of
this
work
is
going
to
be
particularly
tricky
because
it
was
the
sign
and
someone
had
a
plan
in
mind,
but
they
might
move
on
to
another
area
of
kubernetes
or
they
you
know,
maybe
they
off
kubernetes
completely.
So
what
a
whatever
we
and
we
should.
We
should
definitely
come
up
with
a
plan
and
put
it
somewhere
for
future
generations.
A
D
D
It's
got,
it's
got
to
run
something
yeah,
so
there's
docker,
there's
container
d
and
there's,
like
you,
know
a
bunch
of
other
run
times
that
I
don't
think
we
test
at
all.
But
you
know
here
it's
primarily
docker
container
d,
maybe
creo
in
some
places,
but
I
doubt
that's
a
standard
thing.
I
think
that's
got
its
own
buckets.
D
D
A
Fastest
yeah,
I
saw
this
note
conformance
test.
I
have
built
into
containers.
There
is
a
definition
for
container
somewhere
so
and
there
is
a
documentation
on
kubernetes
that
io
how
to
run
conformance
tests.
So
I
was
wondering
like-
and
this
is
the
communication
basically
saying
like
take
this
container
and
run.
F
A
A
F
B
You
know
this
is
a
little
bit
tangential,
but
you
know
what
would
be
a
really
good
place
to
also
maybe
have
this
conversation
in
the
sig
architectures
conformance
is
conformance
meaning,
doesn't
it?
Does
anyone
attend
that
or
you
know,
if
we
don't
want
to
attend
another
meeting,
we
could
just
start
the
conversation
with
this
a
with
sick
architecture.
B
B
B
Maybe
maybe
maybe
the
mailing
list
just
to
store
it
for
a
future
reference,
but
I
I
think
I
think
it
might.
I
think
it
might
be
good
if
we,
I
don't
know
if
we
have
explicit
answer
for
what
is
the
difference
between
conformance
and
noise
conformance,
but
it
might
be
handy
to
get
a
signal
and
seek
architecture
to
maybe
have
this
conversation
again
if
they
already
had
in
the
past.
A
B
B
I
mean
I
mean
ultimately
sig
architecture,
you
know,
even
even
though
the
cubelet
can
be
a
thing
of
its
own.
Apart
from
the
rest
of
kubernetes
I
have
to,
I
will
have
to
out
venture.
I
guess
a
seeker
architecture
will
have
will
have
to
have
some
knowledge
or
overview
or
of
what
note
conformance
was
serious.
B
It
might
also
be
useful
to
figure
out
what
just
maybe
maybe
also,
instead
of
trying
to
figure
out
what
people,
what
a
what
the
layout
was,
the
last
time
that
someone
worked
on
node
conformance,
it
might
be
good
to
take
a
step
back
and
ask
what
exactly
do
we
want
to
know
conformance
to
be
so
besides.
So,
besides
asking
like?
Does
anyone
know?
What
is
what
this
is
supposed
to
be?
Maybe
maybe
it
will
also
be
good
to
chat
with
conformance
and
see
what
node
conformance
could
provide.
F
Yeah,
it
sounds
like
they
might
be
a
good,
a
good
point
here,
because
I
do
agree
that
just
doing
what
was
intended
two
years
ago,
probably
isn't
doesn't
make
sense.
So
if
we
can
kind
of,
you
know,
take
take
that
and
see
what
the.
If,
if
you
know
more
recent
conformance
guidance
suggests,
then
maybe
we
can.
We
can
figure
out
where
they
should
be.
B
F
F
B
A
A
A
B
That
it
just
came
to
mind-
and
I
forgot
to
add
it
to
the
meeting.
This
is
a
super
big
question,
but
but
I'm
gonna,
I'm
gonna
tell
you
a
brief
story.
So
essentially
you
know
the
way
that
we
develop
things
in
kubernetes.
We
write
a
cap,
we
send
it
to
the
enhancements,
we
track
it.
We
track
it
until
the
cap,
it
becomes
implemented,
ga
and
everyone,
and
everyone
is
happy
and
some
some
caps
have
actually
all
the
caps.
B
As
of
recently,
they
have
a
small
section
where
you're
supposed
to
in
some
way
mention
what
test
you
the?
What
test
you
created
to
actually
make
sure
that
your
cap
is
working
as
intended
and
and
that
exists
from
the
other.
From
the
other
perspective,
usually
the
people
who
check
on
this
who
check
on
the
who
check
on
the
caps
other
than
the
people
who
alter
it.
Are
they
our
members
of
the
kubernetes
release
team?
B
They
checked
all
the
sections
are
filled
out.
They
check
that
everything
that
everything
is
up
to
date
and
the
release
team
also
constantly.
As
a
as
we
have
already
seen.
They
have
essentially
a
copy
of
a
lot
of
e3
jobs,
so
whenever,
whenever
they
break
they,
they
go
to
them
and
see.
What's
working,
what's
not
working
and
what's
now
based
on,
what's
not
working,
they
they
figure
out
who
to
pay
who
to
ping
and
a
and
they
like,
want
you
wanting
them.
B
B
B
B
It
should
be
part
of
release
blocking,
so
there
might
be
the
possibility
that
we
have
a
lot
of
tests
that
are
really
crucial
and
we
are
not
checking
open
or,
and
no
and
no
one
actually
and
no
one
actually
knows
where
there
are
a
lot
of
things
that
I
that
I'm,
that
I'm
pretty
sure
that
we
don't
know
that
they
are
supposed
to
be
running.
We
don't
know
where
they
were.
They
are
running,
so
I
just
kind
of
wanted
to
throw
it.
B
I
just
kind
of
wanted
to
draw
a
that
one
out
there
for
people
to
think
on
and
ponder
because
I'm
yeah,
I
think
I
think
I
think
there
has
to
be.
I
think
there
has
to
be
some
some
science
or
some
more
to
what
we
at
what
we
actually
run.
Instead
of
like
randomly
creating
a
test
and
saying
this
is
gonna,
be
in
a
cubelet
master.
B
B
So
yeah
something
something
like
that.
You
know
it's
like
essentially
the
essentially
the
big
question
that
came
to
mind
is:
how
do
we
know
what
we
are
supposed
to
be
testing?
You
know
the
cuba,
the
cube
that
has
had
hundreds
of
flags
and
comparing
things
that
you
can
configure.
Most
of
them
have
to
be
related
to
some
feature.
B
B
D
Where
you
can
understand
what
is
like
the
question,
what's
going
to
run
when
I
mean
what
do
I
mean
when
I
say
conformance
is
well,
it's
whatever
happens
to
run
when
you
specify
focus
and
skip
xyz
and
so
yeah.
I
you
know
I
don't
want.
I
want
to
avoid
a
bunch
of
churn
while
we
figure
out
what
things
should
be
tagged,
but
the
the
quick
yeah,
if
we're
gonna
say
a
cap
has
to
have
a
test.
Well,
then
tie
the
test
to
the
cap.
D
A
They
have
startup
prop
in
a
description
of
the
test,
but
they
don't
have
the
stack
saying
that
the
feature
I
I
was
kind
of
questioning
this
in
my
head,
but
I
see
that
oh
other
features
are
doing
this
the
same
way.
So
do
you
think
we
need
to
preserve
those
feature
flags
and
like
try
to
split
all
the
tests
into
features.
B
B
Maybe,
and
then
you
know
back
in
the
cap,
we
can
mention
the
this
tag
exists
and
everything
with
this,
and
this
tag
is
supposed
to
have
a
x
number
of
tests
and
x
number
of
tests
are
supposed
to
be
for
blah
blah
blah.
I
have
no.
If
a
I
don't
know
how
useful
that
is.
I
don't
know
if
that
will
be
the
perfect
solution
to
this.
F
B
I
think
at
least
the
answer
to
that
last.
The
last
thing
that
you
mentioned
is
nope.
As
far
as
I
know,
not
a
not
in
nowhere
in
the
whole
kubernetes
organization.
Is
there
any
documentation
of
what
should
we
release
vlogging,
because
I
think
I
think
specifically,
that's
been
left
off.
I
mean
it's.
It's
kind
of
it's
kind
of
a
harp.
It's
kind
of
a
hard
thing
to
create
guidelines,
for
the
only
places
where
release
blocking
is
actually
mentioned
is
by
the
release
team,
where
they
want
to
just
you
know
it.
B
They
just
want
to
know
if
kubernetes
is
working
or
not,
but
how
to
figure
out
whether
kubernetes
is
working
or
not.
It
is
better
left
to
the
sixth,
because
you
know,
for
example,
no
one
is
going
to
know
more
about
the
cubelet
than
sig
node.
So
it's
like
what
features
do
we
do?
We
think
that
should
be
released
blocking
and
that
should
be
documentation.
What
what
cubelet
features
or
something
or
something
like
signal
maintains,
should
be
release
blocking.
B
A
I
don't
think
it's
pessimistic,
I
think
it's
very
valuable.
We
just
I
I
mean
every
meeting
we're
discussing
how
hard
it
is
to
understand,
what's
going
on
and
like
what
tests
are
actually
facing
and
whether
they
supposed
to
run
in
like
one
environment
or
another
environment,
so
having
some
having
some
special
tags
that
will
at
least
refer
back
to
documentation
is
definitely
helpful.
So
when
you
look
at
tests,
you
at
least
can
go
back
and
check
like
what
is
cap
meant
to
do
so.
This
is
great.
A
I
think
you
just
need
to
understand
what
what's
the
right
way
to
do
that,
and
can
we
like
yeah?
We
just
need
to
set
up
a
structure
and
the
more
we
discuss
the
more
we
learn
about
kubernetes,
whether
it's
like
more.
We
learn
about
tests,
whether
we
can
define
it.
I
really
like
this
angle
with
caps.
I
haven't
thought
about
it.
B
B
If,
if
not,
if
not,
then
at
least
some
place
for
improvement,
you
may
be
to
actually
try
to
try
to
create
some
guideline.
You
know
for
ask
try
to
answer
this
question
then
think
about.
I
think
about
this
one
right.
When
writing
your
cap,
try
to
probably
try
to
provide
some
help
for
for
authors
of
features.
F
B
D
I
think
we
need
to
focus
on
completed
caps
for
now
and
as
as
they
come
up,
maybe
we
can
suggest
well,
you
know
people
are
going
to
do
the
work
separate
from
separate
from
us
and
separate
from
the
kep
itself.
So
it's
it's
hard
to
maybe
follow
along
with
with
the
existing
ones,
but
I
think,
in
terms
of
completed
caps,
it
would
be
good
to
focus
on
those,
especially
because
you
can
ask
okay:
did
the
club
kept
cam
claims
to
be
implemented?
It
claims
to
have
tests.
D
How
do
we
verify
the
the
veracity
of
these
claims,
and
if
I
want
to
do
this
in
an
efficient
way,
that's
not.
I
already
know
the
answer
to
what
the
test
is
named.
What
would
be
an
easier
way
to
run
these
tests
and
say?
Yes,
it
works
over
here.
It
works
over
there
and
so
that
that's
a
good
way
to
inject.
D
D
B
C
D
A
A
D
D
You
know
if
we
look
at
the
document,
it's
a
couple
years
old,
so
I
think
all
of
the
tags
and
our
concept
of
tags,
sort
of
I
know
caps-
are
they
they
sort
of
pre
pre-date?
The
existence
of
of
you
know
most
caps,
so
this
is
sort
of
definitely
an
update
to
be
current,
with
the
current
existence
kind
of
a
kind
of
work
to
do
it's
not
it's
not
a
thing
that
existed
because
it
didn't
exist
before
right.
It's
sort
of
self-defining.