►
From YouTube: Kubernetes SIG Node 20200831
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
it's
almost
31st
and
it's
a
signal.
Ci
subgroup
meeting
welcome
everybody.
Let's
get
started
so
we
have
few
topics
for
today.
First,
I
wanted
to
review
action
items
from
last
meeting.
We
had
two
identified.
First,
we
wanted
to
discuss
whether
we
need
not
couplet
master
and
not
kublet
conformance.
A
I
had
morgan
brought
up
and
I
created
an
issue,
but
I
don't
think
anybody
looked
at
it.
So
it's
not
moved
any
anywhere
morgan.
Do
you
want
to
talk
about
it?
If
you.
B
Yeah,
sorry,
I
didn't-
I
didn't
see
this
until
now.
I
guess
sorry
for
missing.
Last
week
the
so
I
was
basically
looking
at
basically
what
tests
run
and
looking
at
the
you
know
the
job
definition
for
each
of
those,
and
they
seem
very,
very,
very
similar
such
that
it's
basically
it's
doing,
they're
both
doing
like
99
of
the
same
work
and
I'm
wondering
why
they
both
exist
and
so
like.
I
can
write
down
the
I
I'll
all
right
I'll.
B
I
can
be
more
explicit
and
I'll
write
down
the
differences
between
the
two,
which
are
very
very
minimal,
but
I
was
just
hoping
basically
most
of
the
time
when
I
bring
something
up,
I'm
just
trying
to
hope
to
either
have
somebody
else,
explain
it
to
me
or
put
it
out
there
and
see
if
anybody
recognizes
why
you
know
what
what
the
intent
is
behind
a
lot
of
these
things,
because
we
didn't
the
intent
of
why
these
tests
exist
is
not
written
in
a
lot
of
places.
A
Yeah,
I
feel
the
same
way,
sometimes
just
confusing
me
how
everything's
structured,
so
anybody
on
the
call
knows
why
this
conformance
and
master
tests
are
same
but
different.
A
Okay,
can
we
get
somebody
on
the
call
like?
Maybe
somebody
else
want
to
assign
this
issue
to
themselves
and
investigate?
I
think
it's
important
for
us
to
minimize
number
of
tabs,
so
we
know
where
to
look
anybody
else
in
the
call
wants
to
take
ownership.
B
I'll
add
some
more
information
to
it
and
try
to
find.
C
A
Yeah,
ideally,
we
need
to
have
a
description
if
those
tabs
are
intentionally
different.
We
need
to
have
a
description
that
explains
why
they
are
different,
so
I
would
think
either
we
resolve
it
and
say
we
don't
need
both
and
we
remove
one
of
them
or
we
say
we
need
both
and
then
we
just
add
description,
maybe
in
form
of
comment,
but
maybe
in
form
of
actual,
like
description
tag
on
a
dashboard
or
a
tab.
That
will
explain
why
we
need
that
one
and
why
we
need
this.
A
C
A
Okay,
do
you
want
to
just
to
assign
here,
or
can
you
do
it
yeah
I'll,
take
care
of
it?
Thank
you
appreciate
it.
So
next
one
is
removing
alpha
serial
alpha
tab.
So
once
we
we
like
cpu
manager
test
was
the
last
serial
alpha
test
here
and
they're,
not
here
any
longer,
so
we
can
eliminate
the
stop
completely.
So
I
have
a
pull
request
for
that
and
if
you
have
time
just
review,
we
already
have
ogtm
tag.
So
it's
fine.
A
We
just
need
the
oh
man,
I'm
sorry,
my
when
I
breathe
on
my
screen.
It's
touch
screen.
It
reacts
on
it,
so
I
need
to
breathe
this
way
so
yeah.
So
there
is
a
pull
request
to
remove
it
and
you
just
need
a
proof
tag
and
it
will
be
resolved
any
questions
about
either
of
the
stuff.
A
Okay,
then
done
so
now.
Morgan
your
agenda
item.
B
Yeah,
this
is
a
basically
a
long-running
question.
I've
had
the
intention
of
la
so
I've
gone
back
through
the
history
of
a
lot
of
these
jobs.
You
know
back
before
they
were
even
in
test
infra
and
it
seems
like
some
of
them
exist
implicitly
not
explicitly
described
to
basically
either
test
different
versions
of
docker
and
maybe
different
versions
of
container
d
and
all
these
other
lower
level
pieces.
B
But
there
doesn't
seem
to
be
any
concrete,
explicitly
written
down
goal
of
we're
trying
to
sort
of
test
the
matrix
of
these
things,
and
so
I'm
just
does
anybody
sort
of
have
explicit
knowledge
of
that
written
down?
And
if
not,
you
know,
do
we
think
it's
a
good
idea
to
write
that
down
and
then
the
last
question
would
be.
Where
can
I
write
that
down?
If
I
were
to
brainstorm,
you
know
a
proposal
of
we
should
be
covering
xyz
because
of
qrs
kind
of
again
intention
writing
down
the
intention.
D
Can
I
ask
you
a
question
on
this,
so
the
test
you're
talking
about
current
all
of
these
layers
are
it's.
They
are
the
same
end
to
end
the
test
with
those
details,
as
you
think,
of
the
black
box
testing,
or
is
that
the
white
box
testing.
B
I'm
I'm
just
tr,
I'm
trying
to
basically
understand
yeah
that
the
the
existence
of
a
lot
of
these
tests
were
sort
of
implicitly
dependent
on
the
fact
that
we
were
using
different
images,
and
so
it
would
nice
to
be
either
explicit
about
okay,
we're
installing
docker
version,
one
point:
whatever
container
d
version,
1.3
and
cri
version
this
or
that
now
maybe
we
can
ignore
most
of
the
sort
of
run
c
versions
and
stuff
like
that.
B
So
again,
I
want
to
reduce
this
dependence
on
tests
that
just
happen
to
run
for
a
while
and
then
well.
They
don't
run
anymore
and
we
just
remove
them
without
really
understanding
why
we
were
testing
them
in
the
first
place
right,
so
one
of
the
goals
seems
to
have
been
sort
of
this
matrix
of
covering
different
runtimes.
Is
that
an
explicit
goal
of
the
group
here
or
or
are
we
ignoring
it?
E
C
E
Oh
cool,
that's
a
cool
block.
You
know,
like
you,
said,
there's,
there's
different
cri
versions,
the
api,
there's
different
runtime
versions
and
so
on.
There's
different
kernel
versions,
there's
different
versions
of
modules
within
those
kernels
or
so
I
think
it
might
be
a
little
bit
too
much
for
us
to
go
track
that
and
give
guidance
to
end
users
on
what
they
should
use.
E
E
B
Yeah,
I
want
to
avoid
explosion,
but
we
I
have
to
kick
back
a
little
in
that
in
that
some
of
you
know,
there's
a
lot
of
users
out
there
using
docker
still
basically-
and
the
docker
right
now
is,
I
believe,
is
still
deployed
with
container
d
1.2
and
so
we're
all
the
way
up
to
container
1.4.
B
And
you
know
we
have
that
minimal,
1.2,
1.3,
1.4
kind
of
thing
to
target
plus
docker
the
docker
shim
involved
in
there
some
way,
and
now
we
do
have
the
way
to
pull
the
docker
shim
out
and
compile
without
it.
But
I
don't
think
we're
actually
testing
that
right
now,
and
so
I
ye,
I
guess,
if
we're
going
to
do
this,
I'd
like
to
either
explicitly
do
it
and
yes
constrain
it
to
a
minimal
set
of
things
and
yeah.
If
we
can
do
that
by
using
specific
images,
I'm
all
for
that.
E
Yeah,
no,
I
think
that's
fair.
I
think
it's
fair
to
say
we
want
to
support.
I
mean
this
actually
brings
up
a
separate
question
of
how
many
container
d
versions
or
docker
versions
do
we
want
to
support.
Do
we
want
to
keep
it
last
three?
Do
we
want
to
track
whatever's
in
cost,
in
which
case
we
lose
a
little
bit
of
the
obligated
aspect
within
this
group?
E
Fine
with
anything,
but
I
think
some
of
the
newer
cast
images
have
container
d13.
I
think
cos.
Roy
might
know
this,
but
I
think
cost
81
is
one
three
and
upcoming
85
will
be
one
four.
So
as
soon
as
we
pick
them
up,
we
should
get
coverage,
at
least
in
one
three
and
one
four.
E
A
F
Basically,
the
8384
is
mostly
just
a
dive.
I
think
now
the
81
lts,
mostly
next
one
is
85.
F
B
B
And
I
don't
know
who
we're
waiting
on,
but
that
those
this
is
a
version
of
the
tests
like
well,
the
art
hell
one's
on,
but
these
are,
these
are
uploaded
by
docker
and,
yes,
they
haven't
been
upload,
updated
in
a
long
time
and
no
results
have
been
uploaded
in
a
long
time,
and
so
I
have
a
pr
to
just
totally
remove
that.
F
So
if
we
remove
that
doing,
that
means
the
signal
that
I
know
the
car
was
a
darker
test.
No.
B
The
default
still
is
to
run
things
with
docker,
so
when
you
run
just
the
basic
like
the
pr,
I
believe,
still
runs
on
docker
the
sig
node
master
runs
on
docker.
It's
only
when
you
get
to
the
the
container
d
tabs
that
containity
starts
becoming
involved
directly
under
the
cri,
though.
F
B
Okay,
I
I
haven't
seen
that
I
know
I'd
like
to
see
that
then
we
need
to
establish
probably
explicitly
docker
runtime
test
to
ensure
that
it's
still
working.
F
B
F
D
A
B
I
think
I
mean
yeah,
it
was
coming
at
june,
9.
yeah.
I
missed
this.
I
missed
this
but
yeah.
I
guess
we
could
bring
it
up
tomorrow
and
get
higher
level
one
more.
A
Yeah,
so
a
few
mergers
need
it
and
yeah
I
mean
roy.
A
I
think
we
just
need
to
comment
on
like
this
is
docker
needed,
and
this
pr
is
actually
for
many
months
now
and
if
they
were
worried
about
it,
I
don't
know
who
we
can
include
to
ask
if
they
really
want
to
rewire
this
test.
E
We
maybe
involve
sick
conformance,
some
classic.
A
Okay,
so
I
think
yeah,
sorry
for
technical
travels,
yeah.
I
think
we
can
take
it
as
action
item
and
follow
up
on
on
this
pull
request,
so
either
it
will
be
more
so
you'll
find
somebody
who
cares
about
it
enough
to
fix
it,
but
I
think
we
still
need
to
resolve
this
question
on
which
run
times
we
test
on
not
on
this
tab,
but
all
other
tabs
as
well
right.
F
Yeah
this
is
why,
from
the
the
blog,
maybe
we
check
the
down
to
see.
Maybe
she
knows
history
right
if,
like
or
analyze,
he
has
a
connect
connection
with
like
a
darker
community.
They
want
because
now
everything's
not
maintained,
maybe
we
can,
after
consulting
the
people,
know
the
history.
Maybe
we
can
delete
it
if,
if
no
people
upstream,
the
darker
wouldn't
like
maintain
even
upload
the
results
right.
A
B
Because
this
is
an
external
bucket,
so
it's
it's
probably
difficult
to
manage
the
storage,
because
I
don't
have
access
to
that.
I
don't
know
how
to
manage
that,
so
that
might
be
difficult
from
a
perspective
of
managing
the
infrastructure
and
and
yeah
this.
This
pr
is
actually
probably
incomplete
in
terms
of
going
and
deleting
the
the
bucket
but
nobody's
putting
results
from
externally
into
the
bucket.
So.
A
A
A
Do
we
need
another
word
doc
or
we
better
keep
it
in
source
controlled
place.
B
Source
control
somewhere,
because
I
I
again
I
I
happened
to
find
this
doing.
Re
like
this
is
a
like.
It's
like
a
document
from
like
four
or
five
years
ago,
and
so
I
happened
to
stumble
upon
it.
So
it's
it's
not
discoverable
and
I
would
propose
we
move
it
somewhere,
guess
you
know:
sig
node,
community,
ede,
test
md
or
something
like
that,
but
I
was
wondering
if
that's
a
thing
that
is
like
intended
to
be
used
first,
because
basically
they
we
tag.
B
It's
sort
of
the
job's
sort
of
half
done
in
that
there's.
There
still
exists
this
orphan's
job,
which
literally
exists
because
things
are
not
classified
according
to
that
document.
B
So
I'm
not
sure
if,
like
we
started
moving
to
the
document
or
we
didn't
or
you
know,
is
it
does
it
have
any
force
of
force
of
implementation,
so
I
mean
like:
do
we
need
to
write
up
a
cap
and
put
it
in
a
gap
and
then
move
it
to
our
actual
documentation?
A
B
B
Yeah,
if
that's
part
of
it
or
or
the
the
markdowns
and
the
city
community
thing.
A
I
think
they
move
and
seek
community
markdowns
to
kubernetes
that
they
have
something
like.
B
A
A
I
think
for
people
on
this
call
who
haven't
had
read
it
just
this
document
describes,
I
think,
the
state
of
art-
I
don't
know
how
long
ago,
but
sometimes
ago,
yeah
2018,
and
at
that
time
there
was
an
issue.
I
understand
that
tests
were
not
categorized
well
enough
and
needed
to
improve
categorization,
so
improved
categorization
that
was
proposed
is
implement.
Not
conformance
tag
then
have
a
node
feature
and
not
alpha
feature
as
well
as
not
special
feature
for
things
that
is
like
when
no
feature
not
alpha
feature
is
kind
of
clear.
A
It's
something
that
hidden
under
feature
flag
or
argument,
parameter
with
specific
name
and
alpha
is
to
identify
that
it's
not
stable
yet
and
then
no
special
features
for
things
like
benchmarking
or
something
that
needs
special
setup.
So
we
can
filter
them
out
quite
easily
and
provide
a
special
setup
in
terms
of
images
or
number
of
vms
and
stuff
like
that.
A
So
that
was
a
proposal
and
there
is
a
more
text
about
it.
We
also
also
reusing
common
tags
like
flaky
and
serial
serial
to
indicate
the
test
cannot
run
in
parallel
and
the
flag
key
to
indicate
that
the
test
needs
to
be
worked
on
so
yeah.
I
think
that
that
was
all
the
proposal,
and
I
really
like
the
structure.
I
when
I
read
this
document,
I
finally
understood
what
was
the
intent
of
some
of
these
tags.
So
it's
great.
A
And
yeah
so
just
to
overview
morgan
is
it?
Do
you
have
the
same
feeling
you
just
need
to
move.
B
Yeah,
that's
basically
the
feeling
is.
I
found
this
and
I
I
kind
of
skimmed
it
the
first
time
and
then
maybe
a
month
later,
I
came
back
and
I
read
it
like
top
to
bottom,
and
I
was
like
oh
that
actually,
this
actually
makes
a
lot
of
sense
and
I
get
it
now
now.
I'm
not
sure
I'm
not
sure
I
totally
agree
with
the
yeah.
We
should
be
using
regex
tags
to
figure
out,
you
know,
that's.
B
B
B
A
B
Before
I
don't
want
to
write
down
the
process
and
enforce
it
on
everybody,
without
people
having
a
chance
to
agree
to
it,
that's
fair.
A
Is
it
what
you
may
need
to
do.
B
Yeah
I'll
look
into
this
kubernetes
dev
thing
and
if
not,
if
I
can't
figure
that
out
I'll
at
least
put
it
where
I
know
there
is
existing
node
e
to
e
tag
definitions.
So
when
somebody
else
wants
to
do
it,
I
don't
I
don't
mind.
I
like
the
documentation
so.
A
A
A
Okay,
so
morgan
for
this
issue
that
we
discussed
and
like
we
already
have
node
blocking
tab-
and
this
is
great-
we
have
a
initial
tab
that
we
can
look
at
and
check
for.
The
node
is
stable,
node
and
then
we
discussed
which
test
to
move
next.
So
last
meeting
last
week
on
this
meeting,
we
discussed
that
the
old
test
needs
to
strive
to
be
there.
A
So
we
need
to
try
to
be
to
move
as
many
as
possible,
but
we
need
to
be
careful
like
on
what
we
commit
right
now
on.
So
my
suggestion
was
to
take
some
tests
that
seemingly
critical
and
we
want
to
care
about
them
and
start
moving
one
by
one
and
while
moving.
I
also
want
to
make
sure
that
we
add
in
enough
description
for
the
test
case
or
like
test
tab
to
understand
what
this
desktop
intend
to
test.
A
So
we
clearly
identify
like
this
is
what
we
want
to
test
and
that's
why
it's
moved
here.
So
I
wanted
to
start
making
this
process
of
moving
test
by
one
by
one,
and
I
was
thinking
to
create
an
issue
for
every
single
test
that
we
have
and
start
assigning
to
people.
A
So
whoever
wants
to
take
this
can
take
alternative
is
to
just
do
bulk
migration,
but
I
think
bulk
migration
wouldn't
work.
I
mean
it
will
need
to
review
too
many
tests
and
add
too
many
descriptions
what
people
on
the
call
thinks
like.
Are
we
all
ready
to
start
taking
one
by
one
like
test
one
by
one?
A
Do
we
need
to
have
example
of
migration
like
I
can
probably
take
first
one
and
show
how
to
migrate,
and
then
we
can
allocate
like
associate
assign
issues
to
other
people
as
well.
So
we
can
distribute
this
effort.
B
A
Okay,
I
will
put
an
extra
item
on
me
to
move
first
test
and
then
next
week
we
can
start
allocating
like
assign
it
to
more
people.
If,
if
there
are
some
somebody
who
wants
to
take
some.
A
Okay
and
last
one
I
wanted
to
show
the
statistics
and
we
can
compare
it
to
last
week:
statistics
six,
five,
fifty
seven,
four
three.
A
Six,
seven
yeah:
we
improved
a
little
bit
on
how
many
prs
immersed
in
kubernetes
area,
so
in
kubernetes
repository
because
of
this
1.19
log
down,
some
of
them
was
waiting
as
approved.
Now
we
decrease
this
number
a
little
bit,
so
I
want
to
encourage
people
to
start
reviewing
this
pull
request.
How
does
this
pull
request?
A
Few
out
of
this
53
few
pull
requests
already
approved,
but
they're
waiting,
for,
I
think
some
of
them
even
waiting
for
lgtm,
and
some
of
them
are
actual
test
fixes
that
we
may
want
to
take,
but
they
need
to
have
like.
We
need
to
clearly
review
like
what
what
was
intention
and
what
do
we
need
it.
A
If
you
know
that
pr
is
not
needed,
please
indicate
it
somehow,
maybe
shrug
you
know
like
as
a
slash
track,
so
we
can
reviews
us
and
propose
to
close
them
if
you're
not
feel
comfortable
to
close
it
yourself
just
propose
to
close
it,
and
then
we
can
review
it
together
and
understand.
I
just
want
to
get
down
to
like
small
numbers
of
prs
and
issues
everywhere,
so
we
can
and
like
have
a
actionable
issues
list
every
time
to
to
look
at
so
yeah.
A
A
Okay,
any
other
topics
today.
A
They're
supposed
to
go
to
youtube
but
derek
needs
to
press
a
button.
So
maybe
you
can
poke
him
tomorrow
to
actually
press
a
button.
A
Okay,
so
we
getting
20
minutes
back.
Thank
you.
Everybody
for
attending
it
was
nice
talking.
Bye,
have
a
good.