►
From YouTube: Kubernetes SIG Node 20210616
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
Okay,
I
started
recording
it's
june,
16th
2021,
it's
a
ci,
a
subgroup
of
sig
signaled,
hello,
everybody.
This
is
our
wednesday
time
last
time.
It
was
thursday
time
and
we
will
keep
30
once
a
month
unless
we'll
see
that
so
widely
popular
and
we
need
to
do
it
more
often
so,
first
topic,
I
think
I
don't
know
whether
that
feature
versus
not
feature
not
not
not
a
feature.
A
So
there
is
a
suggestion
that
we
have
this
pattern
in
in
the
test,
tags
that
we
create
node,
feature
and
then
say
not
feature
full
and
then
sometimes
it
will
be
not
alpha
feature
or
node
beta
feature
with
the
same
name
plus.
We
always
keep
feature
full
as
a
additional
tag,
and
the
reason
for
that
is.
We
have
a
special.
A
For
alpha
features
specifically
where
we
enable
all
alpha
features
and
only
run
them
there,
and
we
also
have
other
dashboards
for
what
is
it
for
features
specifically.
So
I
don't
think
we
run
features
on
the
note
conformance,
so
that
makes
it.
I
mean
it's
really
hard
to
understand
how
to
promote
features
and
like
what
will
every
note
do
and
it's
a
little
bit
of
duplication.
So
suggestion
is
that
you
need
to
do
just
feature
something
and
then
indicate
alpha
beta
stage
with
additional
tag.
A
I
think
it
was
just
yeah.
I
wanna
suggest
to
discuss
that
so
what
I
did
before
I
was
looking
into
that
I
I
ran
some
analysis
on.
You
know
you
can
run
gingko
and
just
dump
the
list
of
tests,
so
I
analyze
the
tags
out
of
this
output
and
we
don't
have
many
features
actually
in
nodes
like
most
of
the
node
features.
A
My
main
question
was
always
do
you
want
to
keep
feature
tag
after
features
g8
or
we
want
to
just
remove
the
feature
that
completely-
and
this
is
the
main
question
for
me-
I
didn't
find
the
solution.
I
can
resolve
it
quickly,
so
I
didn't
proceed
with
that,
but
I
would
be
interested
to
hear
your
opinion
and
maybe
some
thoughts
about
it.
B
Hey
sorry,
I'm
late,
at
least
for
the
last
node
feature
that
I
worked
on,
which
was
like
adding
a
new
field
to
the
pod
spec.
I
think
I
used
a
feature
tag
and
not
a
node
feature
tag
for
that
one.
B
I
understand
the
like
value
of
being
able
to
like,
for
example,
select
all
node
features,
sort
of
thing
for
e
tests,
but
perhaps
there
are
like
better
ways:
we
can
do
that,
for
example,
like
looking
at
you
know,
test
tagged,
sig
node,
as
opposed
to
node
feature.
I
am
generally
not
in
favor,
I
think
of
having
our
own
like
node
tags,
because
it
just
adds
a
lot
of
complexity
and
they're.
Not
super
well
documented
in
terms
of
what
they
mean.
A
So
I
think
prefix
node
is,
I
don't
think
we
need
it.
Maybe
there
are
some
cases
when
it's
thick
storage,
but
it's
not
feature,
but
I
don't
think
it's
the
case
any
longer.
I
didn't
find
any
examples.
A
So
in
your
particular
feature,
I
think
once
g8
we
can
just
remove
the
feature
tag
from
a
test
right.
It
will
be
just
a
regular
test
for
and
just
regular
features
that
regular
test
that
doesn't
need
to
be
indicated
by
feature
right.
A
B
Honestly,
I
think,
in
my
experience,
going
through
a
lot
of
the
stuff.
I
think
it's
just
like
the
ci
is
kind
of
it's
not
the
first
thing
on
people's
minds
and
people
forget
they're,
like
oh
I've,
ga
the
feature,
and
then
they
don't
go
back
to
like
update,
for
example,
the
test
tags
or
to
update
the
ci
jobs,
and
I
think
that
that
is
part
of
the
the
issue.
It's.
A
B
C
Yeah
yeah,
sorry
for
the
question
are,
we
are,
we
is
the
the
takes
we
are
talking
about
in
other
future
effects
are
like
the
one
I
posted
in
the
chat,
because
I
was
not
completely
sure
I
was
on
the
same
page.
I
posted
an
example
which
is
dear
to
me
because
it's
alpha
so
then
the
serial
lane
doesn't
run
the
cpu
manager
test
and
when
we
were
talking
about
flags
this,
what
I
was
thinking
about,
but
I'm
not
sure,
is
the
right
thing.
A
I
think
one
optimization
this
issue
suggests
is
to
remove
node
alpha
feature.
Cpu
manager.
C
Okay,
okay
and
well,
I'm
not
really.
I
mean
I
don't
really
I'm
not
deep
enough
in
those
things
so
like
what
works.
For
me,
the
only
other
point
I
would
like
to
raise,
which
is
probably
tangential
but
still
is
that
we
need
to
up
to
run
probably
all
the
tests
and
make
sure
that
the
the
tags
are
up
to
date
because,
for
example,
sql
manager
is
beta.
So
it's
not
alpha,
which
is
should
be
like
what
elena
said.
If
I
understood
correctly
pretty
much.
B
Yeah
there's
like-
and
I
I
was
looking
at
for
example
like
I
didn't,
get
a
chance
to
add
the
like
the
probe
stuff
to
periodics.
It's
only
in
like
a
you
know,
pull
request
thing
right
now,
so
in
order
for
that
to
graduate
to
beta,
it's
got
to
be
running
and
periodics
and
so
on.
B
So
I
think
that,
like
sergey
one
of
the
things
that
I've
been
encouraging
internally
is
for
us
to
like
take
sort
of,
I
guess,
like
an
inventory
of
all
of
the
stuff,
that
we
want
to
test
in
cryo
and
then
try
to
figure
out
an
action
plan
for
all
of
those
jobs.
Do
we
have
something
like
that
for
all
of
signode,
because
we've
got
so
many
jobs,
and
I
know,
for
example,
we
have
that
what
was
it
like?
B
The
node
conformance
duplicate
test,
that's
like
failing
and
that
I
suggested
we
remove,
because
it's
failing
sims
was
like
no.
No,
we
might
be
missing
some
tests,
but
as
far
as
I
could
tell
we
weren't
missing
any
tests
so
like
do
we
want
to
do
that.
Would
that
be
too
much
work.
A
No,
it's
not
that
many
tests.
Actually,
when
we
started
this
group,
victor
was
trying
to
do
that
and
then
I
was
looking
into
that
and
you
quickly
realize
that
it's
not
too
many
just
I
mean
it's
a
reasonable
amount
and
I
think
I
understand
all
the
test
grids
like
what
they're
doing
and
accept
not
conformance,
not
confirm
still
a
mystery
for
me,
like
even
after
reading
causes
documents.
I
still
don't
understand
how
not
conformal
is
different
from
all
other
non-alpha
features.
A
D
B
B
A
So
what
I
can
do
I
can,
on
this
issue,
just
propose
a
plan
like
how
to
migrate
and
if
everybody,
okay,
that
we
can
execute.
A
B
Action
for
sergey
so
for
for
node,
conformance
versus
conformance.
I
threw
that
one
on
the
agenda
because
we
had
a
question
about
it
in
one
of
the
pr's
and
I
opened
a
thread
and
got
some
feedback
on
the
thread
in
the
kate's
conformance
channel.
On
slack.
A
So
assume
to
your
point
whether
any
feature
will
become
conformant.
I
have
only
one
example
in
my
mind
when
test
is
not
conformance,
even
though
it's
g8
feature
and
such
test
will
take
a
dependency
on
log
messages
like
if
you
relate
like,
if
you
took
a
dependence
on
specific
log
message,
that's
supposed
to
be
outputted
or
event.
That's
supposed
to
be
produced
then
likely
it's
not
not
conformance.
We
wouldn't
call
it
such,
but
I
don't
think
anybody
writing
this
test,
like
nobody
took
it
take.
It
depends
on
something
that
may
change.
B
So
this
is
the
thing
that
I
wanted
to
discuss.
So
conformance
has
a
very
narrow
view
like
in
terms
of
what
a
conformance
test
tests
and
conformance
tests
are
specifically
for
functionality
in
the
kubernetes
api.
If
it's
not
a
thing
in
the
api,
there
should
not
generally
be
conformance
tests
for
it,
and
so
like
there's
a
bunch
of
things
that
are
like
not
in
the
kubernetes
api
that
are,
for
example,
for
signaled
in
say
the
like
the
cri
api.
B
And
so
what
do
we
do
about
those
things
when
we
want
to
promote
things
to
ga
like
we
need
to
ensure
that
various
different
container
runtimes
are
meeting
some
sort
of
conformance
definition?
So
my
understanding
from
the
discussion
on
slack,
which
I
linked
there,
is
that,
like
obviously
not
everything
is
going
to
be
eligible
for
a
conformance
test.
B
So
there
are
some
things
that,
while
they
are
not
eligible
for
conformance
tests,
we
need
to
ensure
that
all
of
the
container
run
times
are
conformant
with
them,
and
so
node
conformance
is
specifically
for
container
runtime
conformance
like
cri
conformance.
That
was
my
understanding
from
the
discussion
in
slack,
and
this
is
not
documented
well
anywhere,
and
I
genuinely
had
no
idea
until
I
asked
dims,
so
I
think
that,
like
probably
an
action
for
that
one
is,
we
need
to
document
it
somewhere.
We
probably
need
some
guidelines
in
terms
of
like
what
is
in
node
conformance.
B
That
is
not
in
like
conformance
and
like
how
to
determine
between
like
regular
test
node
conformance
test
conformance
test
feature
test
like
we
don't
have
any
node-specific
guidelines
for
this
right
now.
So
I
think
a
lot
of
this
is
the
documentation
problem.
Like
nobody
wrote
down
what
these
things
mean
and
therefore
like
nobody's
really
quite
sure,
but
I
think
it's
a
solvable
problem.
B
I
don't
think
that
we
should
given
my
understanding
from
that
slack
thread,
be
getting
rid
of
node
conformance
in
the
same
way,
we
should
be
getting
rid
of
node
feature
it
like
seems
to
have
a
useful
purpose,
but
can
you.
C
B
B
Mean
that
might
have
been
a
mistake
and
like
that's
something
that
we
should
have
like
actual
documentation
like
detailing
and
setting
a
policy
for
that.
But
my
understanding
is
like.
It
is
certainly
the
case
that
conformance
is
only
applicable
to
a
very
limited
set
of
features,
and
so,
given
that
there
are
still
some
things
in
node
that
we
need
to
have
node
conformance
tests
on
to
ensure
light
consistency
between
different
cris.
A
So,
for
example,
all
the
probe
tests-
I
think
they
are
not
conformants
and
prop,
is
not
cri
related.
At
least
I
mean
not
directly.
Is
it?
Is
it
a
mistake
or
is
just
another
api
that
we
need
to
support
and
if
it's
another
api
that
we
need
to
support
as
not
conformance
and
like
pretty
much
every
test?
So
if
you.
A
B
B
But
for
example,
if
we
add
say
like
node
memory
swap
and
we
change
the
cri
api
and
we
have
some
like
conformance
tests
that
show
that,
like
we
are
able
to
in
the
cubelet
set
like
swap
allocation
for
memory
for,
like
that's,
not
going
to
be
a
conformance
test
because
there's
nothing
in
the
kubernetes
api
that
lets
you
do
that.
But
that
would
be
a
node
conformance
test,
because
it's
in
the
cri.
B
Yeah,
I
think
that's
definitely.
A
great
idea
is
try
to
get
inspiration
from
other
sigs
and,
for
example,
I
don't
know
what
stick
storage
does
either.
A
Yeah,
I
think
not
conforms,
are
specifically
done
for
nold,
and
maybe
it's
related
to
this
virtual
kubut
effort,
but
I
don't
know
it's.
There
is
a
document
linked,
like
I
think,
lantau
or
some
maybe
juju,
created
before
explains
not
conformance
motivation.
But
motivation
is
yeah
if
you
limit
it
to
cri,
it
makes
sense
to
me
if
we
expand
it
to
like
probes
and
other
apis
and
pretty
much
every
test
executes
one
of
the
apis.
So
every
test
is
not
confirmed.
B
Yeah
yeah,
so
that
one
doesn't
make
sense
to
me.
So
I
think
that,
like
in
the
case
of
for
example,
like
probe
behavior
like,
I
would
expect
that
regardless
of
you
know,
backing
kubernetes
distribution,
I
would
expect
everything
to
behave
the
same
way
given
like
a
definition
of
a
probe.
So
to
me
that
would
be
a
conformance
test,
because
that's
user-facing
in
the
public
and.
B
Yeah,
I
think
that
the
well
probably
the
the
node
conformance
it
might
just
be
a
convenient
selector
like
these
are
conformance
tests
that
we
also
want
to
make
sure
that
we're
running
on
every
api
like
that
may
be
have.
That
may
have
been
why
those
were
pulled
in,
in
which
case
there's
a
question
of,
should
we
be
running
all
of
just
the
regular
conformance
tests
on
each
cri
as
well
like
I.
B
Yeah,
I
don't
know
where
the
I
think
the
conformance
ones
are
just
periodics
right.
A
B
Yeah-
and
I
think
that's
in
part,
because
we
want
to
make
sure
that
you
know
the
whether
it's
like
docker
shim
versus
container
d
or
container
d
versus
cryo
or
whatever
that
were
not
breaking
things
yeah.
I
think
we
probably
need
to
get
more
historic
backgrounds
sergey.
How
do
you
feel
about
taking
this?
We
might
want
to
take
to
a
wider
sig
node,
because
I
don't
think
we
have
the
full
audience
for
this.
A
Doug
the
discussion
but
yeah
and
pretty
much
the
same.
I
it
was
the
same
idea.
So
we
we
have
this
not
conformance.
You
just
need
to
document
it
and
like
whenever
we
try
to
start
documenting
it.
It's
running
away
like
the
idea
of
it
is
not
very
clear.
So
I
don't
remember
who
was
the
last
person
trying
to
document
it?
Do
you
feel
yeah?
B
B
A
Is
a
very
good
idea,
I
think
it
still
benefits
like
it
will
increase
understanding
of
others.
A
lot.
B
B
Currently
we
have
no
one
signed
up
to
be
mentors,
so
I'm
gonna
make
everybody
who
is
not
an
approver
in
the
reviewer
approver
column
be
a
mentor
and,
or
I
mean
you're
volunteering
to
help
out
like
that
is
the
goal
of
mentors.
The
approvers
column
was
mostly
just
in
case.
People
are
submitting
prs.
Do
we
have
somebody
who
can
ensure
it
actually
merges,
and
nobody
in
those
columns
has
merge
access?
So
I
am
gonna
suggest
that
those
people
help
out
with
mentoring.
B
We
really
need
region
captains,
so
I
think
there's
nobody
currently
signed
up
for
europe
and,
like
you,
don't
have
to
be
available
every
single
hour
of
the
day
for
eight
hours.
That's
not
the
intent!
That's
why
we
have
two
of
them.
You
just
need
to
be
available
both
days
for
most
of
the
day,
so
you
can
coordinate
with
your
other
region
captain
just
to
make
sure
that
there's
always
someone
around
such
that
if
a
new
person
comes
like
you
know,
you
can
say
hey.
This
mentor
is
in
charge.
B
While
I
go
to
this
meeting
or
there
needs
to
be
somebody
making
sure
that,
like
everybody,
who's
joining
for
the
day
can
get
help.
So
we
don't
have
anyone
sign
up
for
europe
at
all.
We
will
need
people,
please
sign
up,
and
luckily
we
have
a
bunch
of
folks
who
are
signed
up
to
sort
of
help
out.
So
I'm
I'm
hopeful
that
it
will
be
a
great
event
but
yeah.
We
we
need
people,
please
sign
up,
especially
from
this
group,
so.
E
B
Yes,
okay,
yeah,
you
don't
have
to
be
there
working
on
it
the
whole
time
just
hopefully,
you
can
dedicate
enough
time
to
ensure
that,
like
you're
delegating
to
someone
and
the
event
does
not
go
off
the
rails,
and
that's
that's
mostly
the
reason
that
I
was
requesting
that
region
captains
are
available
for
both
days,
because
then
a
new
person
doesn't
have
to
like
completely
go
and
get
their
bearings
again
for
day.
E
Two:
okay,
I
I
could
be
a
captain
if
you,
if
you
want,
I
have
slack
access
zoom
if
I
need
in
the
office
during
both
days.
So
I,
if
you
explain
what
I
should
do,
I
can
do
it.
Yeah.
B
So
this
is
maybe
a
new
thing
for
a
lot
of
people,
so
we
will
have
a
bunch
of
documentation
which
sergey
and
I
are
currently
working
on
and
I'm
hoping
maybe
we
can
like
have
it
done
and
out
for
a
review
by,
if
not
the
end
of
the
day,
certainly
by
the
end
of
this
week
and
like
they
will
tell
people
okay,
you've
never
like
worked
on
bugs
in
kubernetes
before
you've
never
worked
on
sig
node
before
well.
B
Here's
what
you
need
to
do
in
order
to
scrub
bugs
we
need
to
ensure
that
issues
are
still
relevant,
that
they're
filed
against
the
correct
components
that
they're
triaged,
correctly
and
so
on,
and
so
the
the
goal
of
having
a
region
captain
is
just
like
that
is
sort
of
the
event
coordinator
for
the
day
and
since
we're
doing
this
in
like
all
time
zones,
it
can't
be
me
because
I
can't
be
up
24
7..
B
So
I
need
some
folks
to
help
out
and
they're
just
going
to
ensure
that,
like
you
know,
everybody's
having
a
good
time
and
that
everybody
has
something
to
do
and
that
nobody
is
stuck
so
they're
not
going
to
be
working
with
every
single
person
hands-on
or
anything
like
that,
they're
just
going
to
be
making
sure
that,
like
you
know,
people
know
where
to
go.
People
are
paired
up
with
mentors.
A
Yeah,
I
want
to
add
that
elan
is
working
on
setting
up
triage
party.
This
is
like
web-based
applications
that
just
provide
the
views
on
bugs
and
by
different,
like
categories,
so
that
likely
will
be
separate
queues
of
bugs
for
every
region,
so
every
region
will
take
their
own
and
I
think
one
of
the
aspects
of
it
is
like
for
region.
Captain
is
to
ensure
that
people
working
on
like
bugs
in
that
queue.
I
mean
it's
fine
to
work
on
any
park.
I
think,
but
yes,
it.
B
Yes,
and
so
the
idea
is,
you
know,
so
triage
party
will
help
us
split
the
bugs
between
regions,
so
we're
not
stepping
on
each
other's
toes.
So
that
way,
for
example,
you
know
we've
got
about
like
say
four
mentors
per
region
kind
of
thing
and
we
have
three
regions.
So
that
means
that
we
can
run
triage
party
in
what's
called
12-player
mode
and
so,
for
example,
apac
takes
players.
One
through
four
emea
takes
players,
five
through
nine
or
whatever.
It
would
be.
B
I'm
bad
at
math,
one
through
four
five
through
five
six,
seven,
five
through
eight
and
then
like
nasa,
would
take
the
rest
and
then
like
each
region.
Captain
would
be
like
okay,
who
are
the
mentors
I
have
today.
You
know
so
and
so
you're
responsible
for,
like
the
player,
one
view
so
and
so
you're
responsible
for
the
player
to
view
and
so
on
and
so
forth,
and
that
way
like
we
can
kind
of
just
we
don't
have
people
being
like.
B
I
don't
know
what
I'm
supposed
to
work
on
and
there's
so
many
bugs
and
which
should
I
look
at
so.
Basically,
the
problem
is
that
I
trio
party.
Actually
needs
to
be
hosted
somewhere
to
work,
and
I
have
been
waiting
on
working
group
infra
to
set
one
up
for
me
and
it
doesn't
exist
yet
and
so
basically
like
until
it
exists.
I
cannot
show
you
the
software
that
we're
going
to
be
using,
but
it
will
be
quite
straightforward
and
then
it's
just
going
to
be
like
standard
normal.
B
Yeah
just
leave
like
at
any
other
event.
You
know
if
you're,
if
you're
holding
a
party,
you
want
to
make
sure
that,
like
everybody's
got
food,
everybody's
got
drink
everybody's
having
a
good
time,
there's
not
one
person
sitting
in
the
corner
and
they're
sad.
Everybody
participates
and
has
an
enjoyable
time
so
and
so
yeah
sergey,
I
think,
is
pulling
up
the
hack
md
that
we
created.
So
these
are
some
docs
that
were
hopefully
gonna
merge
into
the
community
repo.
B
But
if,
if
we
can't
get
it
into
the
community
repo
in
time
because
nobody
has
approver
there,
we
will
just
work
out
of
the
hack
empty,
and
this
will
be
our
docs
for
the
event,
and
I
was
gonna
clean
this
up
a
little
bit
just
to
make
it
for
people
who
are
new.
There's
a
lot
of
text
here
so
maybe
have
like
the
sort
of
tldr
section
and
then
linking
to
all
of
the
later
things.
A
Yeah,
ultimately,
you
want
to
close
as
many
boxes
possible
that
are
either
not
relevant
or
it's
a
feature
request
that
may
not
be
interesting
or
will
never
be
implemented,
as
we
think
so.
There
are
some
recommendations
there,
some
bugs
metadata.
Maybe
you
can
categorize
them
better
and
especially
for
first
contributors.
We
want
to
highlight
issues
that
are
like
suitable
for
first
contributors
to
address.
We
have
many
people
who
want
to
help.
A
They
don't
know
how
so
like
one
of
the
ways
to
their
issue
is
provide
a
great
instruction
how
to
fix
it,
even
though,
if
you,
even
if
you
don't
have
time
to
fix
it,
you
just
provide
enough
instructions,
good
issue
and
then
maybe
resolve
bugs
by
either
fixing
them
or
providing
some
documentation.
Many
bugs
can
be
just
addressed
as
a
workaround
in
our
documentation.
B
We
also
have
a
categorization
issue
so,
like
I
suspect,
if
we
look
at
this,
a
very
large
portion
of
our
bugs
are
going
to
be
filed
against
the
wrong
component,
a
feature
request,
a
support
request
and
so
on
and
so
forth,
and
so
for
a
lot
of
those
we
can
like
close
them
or
handle
them
pretty
quickly
like
as
far
as
anything.
That,
like
is
say,
a
support
request.
Generally,
that's
not
going
to
be
something
that
sig
note
is
going
to
work
on
and
a
lot
of
those.
B
If
it's
like,
for
example,
a
support
request
for
an
unsupported
version
of
kubernetes,
we
can
disclose
that
and
if
it's
a
feature
request,
you
know
we
can
very
quickly
triage
and,
like
say,
oh,
you
know
this
is
already
being
worked
on
in
this
cap
close
or
if
it
is
a
a
feature
request
for
like
a
really
big
thing.
That
would
be
important
but,
like
you
know,
isn't
getting
attention
from
the
sig
right
now
somebody
can
say
hey.
B
I
found
this
like
big
thing:
we're
not
talking
about
it
in
sig
node
at
the
next
sig
node
meeting.
Raise
it
as
a
thing.
Is
anybody
like
working
on
this
is
this
on
road
maps?
Is
this
visible,
so
like
swap,
would
be
an
example
of
something
like
that
that
kind
of
sat
for
a
really
really
long
time
and
is
now
being
worked
on
but
like
had
you
know
this
200
item
discussion.
B
There
was
another
bug
that
I
worked
on
recently.
That
was
similar
where
it
was
like
300
people
all
with
like
different
problems,
but
very
similar
symptoms.
All
being
like,
I
have
this
bug.
I
have
this
bug.
I
have
this
bug
and
that's
completely
non-actionable,
like
they
all
have
different
environments,
different
versions
of
kubernetes
and
like
just
a
two-line
description
of
oh
yeah.
This,
like
thing
happens,
which
could
happen
in,
like
you,
know,
10
different
ways.
So
for
like
something
like
that,
I'd
say
close.
This
is
not
actionable.
B
You
know
we
need
like
an
up-to-date
bug
with
your
environment
on
a
supported
version,
and
then
we
can
actually
with
like
logs,
and
then
we
can
dive
in
so
yeah.
Another
key
thing
of
a
lot
of
these
is
probably
going
to
be
adding
like
awaiting
more
evidence
to
a
lot
of
these
bugs
and
if
anything
has
a
weighting,
more
evidence
on
it
and
people
are
taking
stale
labels
off
of
them.
We
should
just
be
closing
them,
like
anything,
that's
been
opened
for
six
months
with
no
updates.
B
That
is
like
there's
no
reasonable
reason
why
they
should
still
be
open.
Those
get
closed,
so
those
will
all
be
in
docs.
I
shouldn't
you
know
blab
on
too
long,
but
this
is
our
goal
is
to
try
to
get
this
500
issue
thing
down
to
something
more
manageable,
so
we
can
prioritize
what
is
important.
What's
not
important
are
things
getting
attention
and
so
on.
B
Yeah
and
if
we
split
like
say
130
bugs
across
two
days,
that's
maybe
like
65
bugs
a
day
across
four
people
per
region,
assuming
we
only
get
four
of
it
like,
but
across
four
people
per
region.
That's
you
know,
like
15,
bugs
a
person
a
day.
That
means
you
know.
You
have
like
quite
a
lot
of
time
to
work
on
those
bugs
like
half
an
hour,
a
bug
or
something
like
that.
B
We're
gonna
be
fine,
so
hopefully
everybody
will
get
a
chance
to
look
and
a
lot
of
the
bugs
will
be
you'll,
be
able
to
close
them
much
faster
than
that.
So
for
like
old
things,
I
definitely
see
a
lot
of
issues
with
when
I
was
doing
the
pr
triage
initially
for
like
the
coupe
that
node
wide
board,
I
must
have
closed
at
least
a
dozen
prs
where
it
was
like
needs.
B
Rebase,
nothing
could
be
done
on
it
and,
like
somebody
just
kept
removing
the
snail
label
because
they're
like,
but
I
really
want
this
thing.
I
was
like
that's
nice
and
I
appreciate
that,
but
unless
you're
willing
to
actually
make
the
pr
merchable
nothing's
gonna
happen,
so
we
have
to
close
it
and
like
there's,
no
reason
in
keeping
it
open
on
our
backlog
if
it
can't
be
actioned
so
making
sure
things
are
actionable,
that's
the
key
thing,
I'm
sure
that
we're
probably
gonna,
I
bet
we
can
close
at
least
a
hundred
bucks,
not
even
joking.
A
Okay,
we
can
go
to
triage.
A
Time
I
didn't
charge
this
column,
I
didn't
have
time,
but
we
can
do
it
together.
B
We
had
some,
which
were
that
we
got
them
running,
which
was
exciting,
and
the
issue
that
we
encountered
was
that
the
francesco
found
that
the
eviction
tests
were
like
timing
out
after
24
hours
or
something
like
that,
and
they
were
basically
holding
up
the
whole
serial
job.
So
we
split
the
eviction
test
out
into
a
separate
job.
So
now
somebody
can
figure
out
why
the
eviction
tests
are
like
they're,
probably
just
blocking
forever,
like
no
testing.
C
C
D
B
Now,
at
least
we
have
the
like,
we
have
the
job
that
we
can
run
on
the
pull
request
to
see
if
it
actually
fixes
it,
because
we
didn't
have
that
before.
So,
it
was
just
like
merge
and
prey.
A
And
so
this
is
cryo.
A
A
A
A
B
D
B
B
B
A
A
Performance
may
not
pick
up
all
the
tests
from
from
this
folder.
B
A
A
That,
because
I
also
think
that
it
likely
can
be
moved,
I
don't
know,
I
don't
know
how
it
runs.
It
doesn't
need
any
special
environment
to
run.
B
It
needs
nodes
that
I
think
have
the
feature
on
it.
I'm
not
sure
if
this
is
something
that
needs
to
be
enabled
with
this,
this
cuddle
or
what
exactly.
But
this
is
like
a
weird
linux
memory
thing.
B
A
It
might,
but
typically
it's
not
as
approving
that
it's
just
like.
B
Yeah,
that
was
one
of
the
so
currently
we're
skipping
them
now
on.
I
think
that
one
needs
an
approver,
we're
skipping
them
now
for
the
like
container
d
ones,
but
not
in
the
cryo
job.
So
I
think
that's
why
it's
failing
on
the
cryo
jobs
and
then-
or
maybe
this
is
just
for.
Is
it
just
system
d?
I
can't
see
what
the
test
is
getting
changed.
B
I
know
at
some
point
it
wasn't
mentioned.
It
was
yeah,
it's
the
cryo
ones.
So
I
think
the
one
comment
that
I
made
on
that
one
is,
I
don't
know
if
we
need
to
split
that
into
a
separate
test
for
cryo
the
same
way
that
we
split
it
for
the
other
ones.
The
node
serial,
which
I
think
dims
had
also
mentioned.
I
think
that
the
serial
ones
are
running
on
docker
shim,
not
container
d.
So
that's
also,
maybe
something
we
need
to.
A
C
Yeah
sure
not
can
say
when,
though,
but
how
do
we
want
to
okay-
let's
do
like
this
put
that
on
me,
but
how
I
mean
take
me
there
an
issue
whatever
or
maybe
yeah.
Maybe
an
agenda
item
could
work
yeah.