►
From YouTube: Kubernetes SIG Node 20201214
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
Hello,
it's
a
signal,
ci
weekly
meeting,
it's
december
14th,
let's
get
started
first
topic
was
how
to
increase
team
velocity
on
issue
response.
Can
I
talk
about
it.
B
Yeah
sure
so
we
have
been
tackling
some
node
conformance
debugging
last
week,
and
this
raises
it
to
my
mind
like
how
can
we
organize
better
these
efforts
on
this
group
and
how
to
have
a
better
tracking
of
the
issues?
Each
one
is
working
or
the
distribution
of
tasks,
because,
from
the
experience
like
we
had
a
lot
of
direct
messages
or
different
channels
and
different
scopes,
maybe
it
would
be
good
to
centralize
like.
B
I
think
the
problem
is
like
how
to
how
to
improve
the
efforts
and
of
the
team
and
make
it
more
accurate
and
and
get
some
velocity
and
how
to
spread
the
knowledge
of
what
we
are
doing.
C
B
Like
maybe
we
could
centralize
in
one's
like
channel
or
maybe
the
alerts
and
and
the
meetings
are
being
enough.
I
don't
know.
A
I
have
the
same
exact
question:
how
how
to
get
knowledge
spread
and
we
can
like,
if
slack
is
the
answer
we
can
use,
seek
not
slack.
I
mean
it's
not
very
high
traffic,
so
we
will
we
can.
We
can
discuss
everything
there.
A
So
this
is
the
issue
like
I
have
both
issues
like
I
understand
which
issues
are
being
worked
on
and
like
what.
What
is
what
is
currently
need
to
be
worked
on,
and
we
typically
try
to
bring
it
into
this
meeting
and
find
somebody
to
work
on
it.
At
the
same
time,
ongoing
investigations
are
typically
happening
in
private,
as
I
understand
and
like
some
people
like
pair
up
and
try
to
investigate.
So
maybe
we
can
improve
this
part
and
like
do
it
more
openly
in
signot
channel.
B
C
To
that
I
think
either
we
need
to
you
know,
decide
that
we're
comfortable
having
all
these
conversations
inside
of
sig
node,
and
you
know
it's
probably
fine
for
for
that
to
happen.
I
think
we
just
need
to
make
it
happen
there.
I'm
also
fine
with
the
separate
slack
channel,
but,
as
you
say,
sig
note
isn't
super
busy,
so
that
might
be
that's
probably
fine.
A
B
Yeah
cool
about
the
visibility,
we
have
the
alerts,
but
we,
we
almost
know
think
what
each
one
is
working
besides
the
calls
so.
A
D
Actually
use
it
is,
and
if
people
actually
use
it,
is
that
helpful
or
do
we
need
a
or
should
we
think
of
on
of
something
other
than
the
bra
or
other
than
the
github
project
board?.
C
Well,
I
think
the
problem
with
that
now
is,
it
seems,
like
the
project
board
is
out
of
date.
Like
seems
like,
we
need
to
make
it
a
little
bit
more
manageable
to
what's
actually
being
worked
on
and
tracked,
and
then
maybe
then,
maybe
that
will
be
a
more
useful
tool.
A
Yeah
project
board
requires
a
lot
of
attention.
I
think
I
mean
from
from
my
interactions
with
project
boards
before
it.
It
works
really
nice
when
you
track
specific
projects-
and
you
literally
like
use
it
in
daily
stand-ups
and
update
bugs
on
the
stand-up,
and
I'm
not
sure
whether
everybody
has
permissions
to
update
bugs
here.
D
So
it
is
a
throwing,
a
proposal
if
we
committed
to
keeping
up
the
project
board
up
to
date.
You
know
if
we
can,
if
we,
if
we
can
do
it
as
sync
or
on
an
or
on
another
meeting,
but
if
we
could
commit
to
once
per
week,
we
just
go
to
the
project
board
and
move
things
around
update
things
to
you
all
and
assuming
that
everyone
on
this
call
had
proper
access
to
do
all
of
those
things.
A
C
Well,
maybe
the
board
we
can
keep
updated
this
part
of
this
meeting.
If
we
use
like
the
this
meeting,
is
kind
of
more
of
a
you
know
around
the
project
board
a
little
bit
more
and
then
you
know
keep
it
up
to
date.
As
part
of
that,
then
maybe
that
will
work.
C
I
mean
it
looks
like
it
looks
like
there's
not
too
many
issues
on
it
right
now,
so
so
it
I
guess
we're
not
in
as
bad
for
places.
I
thought
we
were
but
yeah.
A
Now,
keeping
action
atoms
is
clearly
a
good
idea.
Like
I
mean
I
lost
track
of,
what's
going
on
with
faking
numa,
for
instance,
or
what's
going
on
with
this
docker
tab
duplication.
A
I
remember:
we've
been
discussing
it
for
a
while,
and
we
didn't
have
anybody
from
docker
reply
to
us,
so
we
decided
to
remove
it
and
I
lost
track
of
like
whether
we
did
it
or
anybody
like
taking
it
at
all.
So
project
board
would
definitely
help
to
keep
like
to
get
some
closure
on
issues
like
you
will
know
where
the
issue
resolved
itself
or
it's
still
active
when
we
just
stopped
paying
attention
on
it.
A
A
A
Is
around
next
week
it
will
be
14,
it
will
be
christmas
week
right
in
the
u.s.
A
I
also
like
the
proposal.
If
you
read
this
proposal
from
voytech
from
reliability,
working
group
he's
putting
together
a
proposal.
To
I
mean
the
main
idea
of
the
document
he
wrote
is:
all
prs
should
be
stopped
if
cia
signal
is
broken
and
ci
in
a
bigger
sense.
So
if
there
are
flakiness
and
test
or
it's
failures,
starting
happening
in
critical
tests
in
this
case,
all
prs
should
be
stopped
unless
fakeness
or
failure
is
addressed.
A
So
in
this
proposal
I
mean
there's
like
very
drastic
and
dramatic
proposal,
and
not
everybody
agree
with
that.
So
it's
still
under
discussion,
but
one
of
the
items
in
this
proposal
is
to
have
a
direct
link
from
test
grid
to
the
issues
that
discuss
in
this
test
failure.
So
that
may
be
a
very
nice
thing
to
track
items
as
well.
So
you
just
go
to
test
matrix
and
great
and
know
which,
like
for
every
failure
where
this
failure
being
discussed,
so
you
can
join
the
discussion.
A
Okay,
so
if
we
take
we'll
figure
out
how
to
build
it
and
improve
this,
it
will
clearly
improve
collaboration,
because
now
you
you
know
where
the
issue
is
discussed
and
you
can
join
the
discussion
anytime
and
see
the
current
status,
but
it's
artagon
of
the
project
board.
It's
another
way
to
get
into
the
list
of
active
items
anyway.
So
let's
try
it
this,
like
sig
note
for
discussions
and
update
project
port
starting
next
week
match
you
do
you
want
to
go
next.
C
Yeah
so
last
week
I
took
a
look
at
the
node
conformance
or
a
node,
no
kublai
conformance
test
failures,
and
so
a
couple
things.
So
this,
basically
speaking
of
issues
that
have
been
kind
of
like
languishing
for
a
while,
the
the
node
kublet
master
and
node
kublet
conformance
seeming
like
duplicates
so
in
this
issue.
C
Basically,
what
I
found
is
that
when
you
set
the
like
the
test,
suite
conformance
flag,
then
it
kind
of
takes
its
own
little
path
and
as
as
we
discussed
before,
basically
uses
docker,
but
what
it
also
does
is
it
ignores
the
ginkgo
flags
that
you
set
and
it
automatically
selects
the
conformance
flag.
And
so,
as
a
result
of
this,
the
node
conformance
tests
actually
don't
run
the
node
conformance
test.
C
They
just
run
the
conformance
tests
and
and
as
a
result
of
that,
this,
this
test
that
was
failing,
wasn't
actually
intended
to
be
added
to
the
node
conformance
test
in
the
first
place.
So
it
never
should
have
ran
so
so.
Basically,
it
kind
of
brings
us
back
to
not
having
closed
the
loop
on
what
we
were
going
to
do
about
the
conformance
test,
because,
basically,
where
that
was
at
for
what
I
remember
is
sent
an
email
regarding
on
what
to
do
about
it
and
never
got
a
response.
So
so
I
don't.
C
I
don't
know
if
we
decided
exactly
what
we
were
gonna
do,
but
basically
our
options
in
this
case.
Are
we
as
a
first
step,
to
make
the
test
pass?
We've
removed
the
test
conformant
test,
suite
conformance
flag,
which
will
just
run
the
node
conformance
test,
but
will
basically
be
just
like
the
node
kublet
master,
and
then
we
make
a
decision
after
that
or
we
remove
the
node
kublan's
conformance
tab
altogether
or
we
fix
it
and
fixing.
C
It
will
be
basically
making
sure
that
the
ginkgo
flags
get
passed
in
and
then
kind
of
tracking
down
this,
this
spot,
where
ginkgo
ends
up
flipping
back
to
the
conformance
flag
or
the
conformance
tag
rather
than
the
node
conformance
tag.
C
C
Yeah,
so
that's
that's!
That
was
that
was
my
problem
in
terms
of
now.
What
to
do
like
this
will
fix
the
test,
but
it
won't.
It
won't
leave
things
in
a
state
that
we
love,
I
mean.
Currently,
then
the
kubelet
conformance
tests
are
not
actually
testing
what
we
want.
Anyway,
I
mean
they
are
running
in
docker,
so
there's
that
part
of
it,
but.
C
A
B
C
So
and
I'm
I'm
happy
with
that
as
a
first
step.
The
question
is,
then:
how
do
we
like
given
given
we
kind
of
lost,
didn't
gather
much
steam
on
our
previous
path
like?
What
do
we
want
to
do
next
to
kind
of
make
a
decision
on
this.
C
I'm
also
would
be
okay
saying:
well,
we
don't
have
anyone
currently
advocating
to
keep
these
so
why
don't
we
just
kill
them,
and
you
know
see
if
anyone
objects
to
that.
D
On
the
notes,
the
first
issue,
where
we
started
talking
about
how
the
both
of
these
are
duplicates,
there
is
a
super
super
super
old
and
document
that
was
sent
to
us
by
dan.
I
think
they
were
it's
like
the
original
proposal
for
why
a
node
conformance
test,
where
were
added
as
a
first
step
and
just
to
make
sure
that
we
keep
track.
We
keep
track
of
this
and
we
don't.
We
don't
lose
it
again.
D
What
would
you
all
think
of
joel's
going
through
that
doc
again
and
then
creating
an
update,
an
update
for,
for
what
is
a?
What
is
the
current
state,
the
things
that
were
the
things
that
we're
doing
and
if
we
could
also
document
everything
everything
that
you
just
said
in
one
place
where
we
can
find
it
that
that
isn't
an
issue
I
think,
based
on
that
documentation,
wise?
That
will
be
good
and
also,
I
think
it
might
provide
a
more
context
for
us
to
make
a
plan.
A
It
all
sounds
good.
We
clearly
need
to
document
it
and
try
to
fix
the
communication
out
of
that
original
document.
The
problem
is
like,
even
with
this
document,
everybody
read
it
and
like
I
still
not
clear
why
we
need
not
conformance
and
what
is
different
from
regular
conformance
and
like
where
it
is
it's
intended
to
run
that
kind
of
questions.
C
A
D
The
other
quick
thing
on
that
is
that,
if
I
recall
correctly
in
the
super
old
talk
that-
and
that
is
part
of
the
thing
yeah
I
might-
I
might
be
remembering
this
wrong.
I'm
looking
for
the
issue
right
now,
but
I
think
that
there
is
a
line
somewhere
in
the.
Why,
in
the
why
we
why
we
are
doing
this,
where
it
says
that
the
node
conformance
tests
are
meant
to
be
run
within
the
node
test
suite,
which
is
everything
that
uses
a
which
a?
D
Which
is
the
thing
that's
under
test
dash
the
test
note,
and
so
I
think
it
was
a
way
of
separating
which
tests
are
going
to
a
which
test
developed
by
signal
are
meant
to
be
run
by
the
node
test.
Suite
versus
which
tests
are
versus
the
tests
are
supposed
to
be
run
with
a
as
normal
kubernetes
tweet
test,
which
are
in
the
the
which
are
all
placed
together
under
the
other
directory
in
kubernetes.
A
D
Something
if,
if
we
call
correctly,
I
think
that
was
the
aim
of
it
so
again,
just
to
just
just
to
try
to
draw
a
mental
picture.
If
you
go
into
kubernetes,
you
have
the
two
directory
in
the
under
test.
You
have
a,
I
mean
at
least
two
directories
that
we
care
about
test
dash,
node
and
then
just
test
everything
on
their
test.
They
run
on
a
they
run
as
a
cluster
e
tweet
test
everything
under
test
at
a
underscore
node,
they
run
with
our
node
the
test
suite
and
the
confi.
D
The
node
conformance
tag
was,
I
think,
was
a
way
of
making
sure
that
we
could
specify
which
test
is
supposed
to
be
run
on
by
which
no
test,
by
which
a
suite
a
weather,
node
test
suite
or
the
cover
or
the
cluster
test
suite,
and
the
thing
that
will,
I
think
the
thing
one
of
the
things
that
will
be
useful
to
know
is
whether
we
have,
after
so
many
years
of
that
decision
been
made,
and
we
have
actually
just
clustered
together,
all
the
no
all.
D
A
A
D
A
B
Yeah,
this
is
kind
of
a
confusion,
that's
happening,
so
the
question
is
like
what
this
test
should
be
running
right
now.
Only
node
conformance.
B
A
I
know,
but
I
mean
to
the
point:
node
and
regular
tests
should
be
like
run
a
little
bit
differently,
so
adding
not
conformance
tag
to
both
may
be
confusing
and
maybe
leading
to
failures,
because
if
you
pick
all
the
note
conformance
from
different
folders
and
it
maybe
may
confuse
the
execution,
okay.
C
Yeah,
I
think
another
aspect
to
that,
though,
is
how
the
tests
are
run
because,
like
the
conformance
tests
are
run
differently
than
say,
the
kubelet
master
tests-
and
I
just
don't
know
like
is
that-
is
that
important
for
the
conformance
test
to
run
differently.
Or
can
we
just
run
the
whatever
tag
we
decide
on
and
be
happy
with
that.
A
A
A
I
don't
know
whether
it
was
the
same
was
a
plan
for
not
conformance,
but
it
seems
that
nobody
owns
not
conformance
except
us,
and
we
need
to
decide
what
to
do
with
that.
C
Well,
it's
like
it's
like
node
conformance,
was
kind
of
like
you
know,
maybe
like
90
finished,
and
then
we're
trying
to
figure
out
the
last
10
percent
and
whether
or
not
we
really
want
to
make
that
investment.
C
Anyway,
I
think
I
think,
or
his
proposal
to
make
make
a
doc
make
sense,
and
you
know
I
can.
I
could
probably
take
a
first
crack
at
that
and
then
send
it
to
everyone,
and
people
can
add
comments,
questions
and
then
once
we're
kind
of
feel.
Okay
about
that,
you
know.
Maybe
we
can
maybe
get
dawn
or
someone
to
to
take
a
look
at
it
too.
A
C
Yeah,
I
think
I
think
a
document's
going
to
be
better
it'll,
be
easier
to
ping
people
and
have
a
conversation,
because
clearly
the
email
didn't
go
anywhere.
You
know,
I
probably
didn't
write
it
actually
enough,
but
also,
I
think
it's
not
a
good,
not
a
great
forum
for
conversation.
A
D
D
D
A
There's
no
more
topics;
let's
call
it
today.
Thank
you,
everybody
for.
D
Joining
actually,
I
asked
big,
I
asked
victor
for
access
to
the
to
the
project
of
the
project
board,
so
sergey
you're,
an
admin
now
and
if
any,
if
anybody
needs
access
to
it,
because
they
cannot
issues
or
move
things
around
it
just
ping
and
thank
you
we'll
get
you
set.