►
From YouTube: Kubernetes SIG Node 20210519
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
So
hello,
it's
may
19
2021
and
it's
a
ci
subgroup
of
sig
note.
We
just
discussed
the
meeting
time
and
it
feels
like
we.
Okay
with
the
time,
let's
see
how
it
works
for
asia
contributors.
A
Yeah,
I
think
I
only
have
one
follow-up
from
last
meeting
I
was
I
mean
we
have
some
internal
dashboards
on
code
coverage
in
google
and
I
was
like
looking
inside
like
trying
to
understand
how
people
will
check
code
coverage
improvements.
This
is
for
like
first
good
issue,
kind
of
issues
that
we
discussed
last
time,
but
then
I
found
this
dashboard
in
open
source.
We
also
have
code
coverage
dashboard.
Oh
I
don't
sure.
Let
me
share.
A
A
Okay
yeah,
so
apparently
there
is
a
code
coverage
dashboard
and
we
can
see
improvements
here.
I
I
mean
I
filtered
like
kublet
already
and
it
doesn't
seem
too
bad.
So
it's
reasonably
high
numbers.
A
I
found
couple
examples
like
if
you
look
closely
I'm
using
like
22.6,
like
it's
kind
of
low
number
that
maybe
worse,
invest
into,
and
it
can
make
a
good
first
issue
to
contribute
to
that
like
12
yeah.
So
I
listed
two
examples
here
that
I
found
interesting
like
runtime
go.
It
only
has
some
feature
like
functions
to
convert
one,
a
container
id
to
start
to
like
another
container
id
or
the
string
status
to
port
status
of
this
jazz.
So
it's
super
trivial
to
cover
and
it
has
a
very
low
coverage.
A
It
does
have
its
own
test
file
and
this
one
is
a
certificate
bootstrap.
It's
just
reading
certificates
from
a
file.
It
has
a
lot
of
it
has
some
code
coverage,
so
there
are
functions
written
to
that
set
up
everything
like
writing,
file
and
stuff.
So
once
you
have
this
setup
complete,
adding
new
test
cases,
typically,
not
that
complicated.
A
A
Okay
and
then
okay
yeah,
I
thought.
B
B
I
don't
know
if
you've
seen
some
of
these,
but
so,
for
example,
when
I
did
the
structured
logging
migration,
I
had
this
giant
list
of
files
and
then
every
time
someone
migrated
what
I
would
check
off
a
file
and
there's
like
similar
ones,
for
you
know,
linting
migrations,
and
that
kind
of
thing,
with
this
big
umbrella
issue
and
then,
as
things
get
completed,
we
check
off
the
boxes.
A
I
see
that
sounds
cool
good
yeah,
I'm
thinking
like
do
we
need
to.
We
make
a
issue.
We
probably
may
declare
some
threshold
for
code
coverage
like
maybe
fifty
percent
would
be
a
good
threshold.
B
One
of
the
things
I'm
a
little
bit
concerned
about
having
like
run
through
a
bunch
of
the
cubelet
code,
is
there's
probably
stuff
that
like
have
coverage
right
now
in
the
unit
tests,
but
it's
like
it's
effectively.
Integration
coverage
so,
like
it's
possible
that,
like
you,
know
all
of
the
code
paths
or
many
of
the
code
paths
are
being
exercised,
but
it's
not
like
isolated
function
to
function.
B
So
it's
hard
to
make
targeted
changes
and
like
see
what
happens
and
I'm
like
I'm
thinking
of
cubelet
underscore
pods
dot,
go
in
particular
where
it's
like
there's
some
like
very
basic
phase,
changey
stuff
in
there.
B
But
there's
not
a
lot
for
like,
for
example,
there's
nothing
for
converting
api
statuses,
which
I
have
found
frustrating
when
I've
been
poking
around
in
there
and
trying
to
make
changes
because
it's
like
well
now
do
I
have
to
go
back
and
like
write
all
of
this
coverage
for
these
things
that
are
untested.
Currently,
I
don't
know.
A
C
Yeah,
I
just
wanted
to
add
some
part
of
the
code
is
difficult
to
write
unit
test
for
because
you
have
like
all
those
signals
that
are
coming
from
everywhere
and
then,
if
you
really
want
to
exercise.
D
B
Well,
really,
I
think
the
problem
is
that
the
code
was
not
written
in
a
way
that
was
unit
testable
and
now
in
order
to
unit
test
it.
We
would
either
have
to
re-architect
it
or
do
a
huge
amount
of
work
to
like
add
you
know,
mocks
and
all
that
sort
of
things
it's
yeah.
It's
not.
I
mean
this
is
what
happens
you
inherit
technical
debt?
It's
not
like
a
great
status
quo.
B
It
does
make
me
wonder
like
if
you
know
adding
unit
tests
to
the
existing
stuff
is
the
right
thing
or
if
we
should
look
at
some
of
that
re-architecture,
but
sometimes
you
need
the
tests
first
and
so
yeah.
I
don't
know,
there's
open
questions.
Yeah.
C
A
Yeah
so
one
thing
forcing
the
architecture.
Sometimes
it's
I
remember:
we've
been
fixing
how
fast
test
run
and
every
time
you
don't
use
fake
clock.
You
have
a
problem
because
you
need
to
have
timeouts,
so
that
kind
of
forcing
you
to
use
fake
clocks
and
it's
easier
architecture,
because
in
pro
in
production
code
pass
code
is
exactly
the
same.
So
it's
not
that
dangerous,
but
yeah.
I
agree.
Okay,
I'll
create
a
mega
issue
to
try
to
consolidate
things.
E
Sorry,
hey
sorry
process
question.
We
understand
that
increasing
the
test
coverage
is
important,
but
I
already
see
this
work
fall
into
the
backlog
area,
so
I
wonder,
process
wise.
E
B
I
think
that's
mostly
so
it's
true
that
anything.
That's
like
improving
test
coverage
would
be
considered
a
sort
of
backlog
thing,
because
it's
not
release
blocking
right.
It's
important
it's
good
to
have,
but
it's
not
release
blocking.
So
I
don't
think
in
general,
like
I
don't
discriminate
personally
as
a
reviewer
against
like
stuff
that
are,
like
you
know,
priority
backlog,
but
if
I
see
like
an
xxl
backlog
pr
I
might
like
you
know,
leave
that
one
in
my
triage
backlog
until
later.
D
B
I
think,
like
part
of
this,
I'm
hoping
that
you
can
get
like
reasonably
sized
things,
one
of
the
things
that
I
tried
to
do
for
the
structured
logging.
Migration
was
really
strongly
encourage
people
to
cap
their
pr
sizes
at
like
no
more
than
like
40
lines
of
migration,
because
otherwise
it's
just
impossible
to
review.
I
would
say
that
might
be
a
useful
thing
to
include
in
our
umbrella
issue
like
say:
yes,
we
want
this
unit
test
coverage.
A
B
Yeah,
unfortunately,
though,
it's
really
hard
to
tell
if
a
test
is
flaky,
if,
like
you're,
only
doing
the
one
pr
thing
and
then
you
know
we
have
to
go
back
and
catch
it
later.
So
I
wouldn't
say
it's
like
I
mean
it's
there's
also.
The
risk
of
somebody
goes
and
adds
tests,
and
they
document
through
those
tests
behavior
that
we
didn't
actually
want,
but
happens
to
be
the
current
behavior
and
then
somebody
goes
back
and
says.
Well,
this
is
like
you
know,
it's
canon.
B
It's
been
documented
in
the
tests
and
then
it's
really
hard
to
fix
it.
So
it's.
I
think
that
like
this
is
why
backlog
is
appropriate
for
this
sort
of
thing
and
if
there
are
specific
things
that
like
would
potentially
be
blocking
for
some
reason
we
might
want
to
like
set
the
priority
higher,
but
I
don't
I'm
hoping
like.
I
don't
think
that
this
will,
especially
if
we
have
like
a
tracking
issue
where
we're
like.
Yes,
we
want
to
make
sure
this
is
happening
as
part
of
this
release
cycle.
B
I
don't
think
we'll
have
too
too
much
difficulty
trying
to
get
reviewer
and
approver
eyes
on
it.
Like
I
know,
marinol,
for
example
like
he
is
approving
backlog
stuff
all
the
time
for
like
sorts
of
cleanupy
things.
It's
definitely
true
that,
like
some
of
the
like
super
big
drawn
out,
needs
a
lot
of
reviewer
brain
power.
Backlog
stuff
is
not
gonna
be
as
easy
to
get
in,
but
I
don't
think
we're
necessarily
at
risk
of
that
here.
A
Yeah
and
I
think
the
main
driver
for
creating
this
is
our
team
brought
up
that
some
contributors,
like
new
contributors,
wanted
to
have
easy
to
start
with
work
items,
so
this
is
targeted
for
those
like.
I
don't
think
we
will
forcefully
assign
anything
on
this
meeting
it.
Just
I
mean
we
don't
I
mean
it's
just
a
backlog.
A
So
I
don't
have
any
other
agenda
items
if
anybody
else
has
it,
otherwise
you
go
to
triage
into
the
board.
Anybody
has
something:
okay
is
the
archon
around
archon.
I
think
there
was
an
item
artem
on
you
last
time
on
yeah.
G
B
Oh
yeah,
actually,
as
an
agenda
item,
do
we
have
a
plan
for
how
we're
going
to
deal
with
the
failing
serial
tests
because
that
came
up
at
signode
and
it
sounds
like
it's
a
problem
right
now.
G
Yeah,
it
counters
the
status
that
it's
like
failed
after
the
timeout,
like
it
run
around
five
hours
and
it's
not
enough
to
finish
ocl
tests.
So
probably
someone
need
to
take
the
responsibilities
to
run
locally
and
start
just
to
test
like
test
tests,
one
by
one
to
see
where
the
issue
additional
stuff
that
we
can
check.
It's
like
timeouts
under
tests,
not
the
like
global
timeout,
but
the
timeouts
on
the
test,
maybe
like,
because
some
tests
have
a
big
amount,
just
in
total,
it
failed
because
of
timeout.
G
So
it's
a
additional
like
action
item
that
we
can
do
but
yeah
like
someone
should
take
it.
I'm
personally
want
to
take
it.
But
currently
I
don't
have
time
because
I
believe
it
will
take
one
two
days
to
dig
into
it
like
it's,
not.
I
believe
it's
not
some
issues
that
we
can
fix
on
glands.
You
know
because
we
already
fixed
such
issues
as
like
cpu
problem,
cpu
manager,
problems
or
lack
of
memory
and
out
of
memory
problems,
but
we
still
have
a
problem
with
the
serial
drop.
B
We
have
any
volunteers
who
would
want
to
dig
into
this
as
like
a
sort
of
multi-day
project,
and
then
I
think
what
we'd
want
as
an
outcome
of
this
is
we
know
that
the
tests
are,
you
know,
timing
out
and
or
failing
and
or
failing
because
of
timeouts.
So,
like,
I
guess,
picking
up
this
issue
which
will
get
filed
and
then
trying
to
determine,
like
you
know,
go
through
the
list
of
everything
there
see.
E
B
We
do
have
a
few
new
faces
on
the
call.
Would
any
of
our
newcomers
be
interested
in
some
of
this
stuff
new
to
me?
Possibly,
I
missed
you
last
week.
H
I
mean
I'm
not
sure
how
hard
this
is
for
anyone,
oh
but
yeah
I
can.
I
can
give
it
a
shot
as
well.
That
can
help
with
anything
here.
B
Yeah,
I
don't
know
what
matthias
and
dd
have
on
their
plates,
but
yeah.
I.
C
So
I
volunteer
too,
to
add
some
coverage
actually
and
also
some
end-to-end
coverage
as
well.
I
think
we
discussed
last
week
with
savvy
okay.
I.
C
A
D
B
A
F
C
I
think
it's
also
important
to
pick
people
that
already
run
end-to-end
tests
locally,
because
you
need
to
set
up
some
some
things
in
order
to
do
this
and
you
need
a
reasonably
powerful
computer
as
well.
That
is
on
all
the
time
and.
E
E
G
In
general,
impossible
to
run
like
e2e
node
test
locally
without
any
gc
instance.
Stuff
like
this,
and
if
I
remember
correct.
G
A
Okay,
then,
thank
you,
everybody,
oh
for
this.
A
Yeah
this
is
making
just
working.
I
think
we
need
to
assign
to
ben
just
to
include
it
into
pre-submits
right.
B
A
D
Yeah,
what's
your
question
yeah
so
like
there
are
two
things
and
cubelet
with
which
you
can
provide
configuration.
One
is
the
component
config
and
flags,
so
I
we
had,
I
mean
from
cluster
life
cycle
and
cubed
game.
We
have
had
this
feedback
that,
like
cubelet,
was
the
first
one
to
adopt
component
config
and
there
are
lots
of
flags
that
we
have
deprecated
and
we
are
adding
new
flags
so
like
what's
our
approach
should
be
here
to
like.
Should
we
avoid
adding
new
flags
to
cubelet
or
like.
B
Yeah,
I
think
we're
we
want
to
avoid
adding
new
flags
to
cubelet
those
should
go
into
the
cubelet
config.
This
is
probably
a
better
topic
for
a
wider
sig
node
meeting,
because.
D
D
B
A
D
D
Okay
I'll,
then
I
will
summarize
things
in
a
dock
and
then
I
will
discuss
in
these
meetings.
A
You,
okay,
I
think
we
done
with
this
triage
and
I
suggest
we
switch
to
product
cache,
so
whoever
not
interested
in
product
triage,
you
can
drop
off
and
I
will
stop
recording
now.