►
From YouTube: Kubernetes SIG Node 20200804
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
B
Thanks
yep
so
dawn
and
derek
and
seth,
and
I
chatted
about
sort
of
what
we
think
some
of
the
most
important
things
are
for
the
sig
and
one
of
the
things
that
came
up
is
that
as
a
first
step,
we'd
like
to
have
a
better
idea
of
how
we're
doing
in
terms
of
reviewing
pull
requests
that
come
into
the
sig.
B
B
B
B
Some
of
the
other
interesting
bits.
If
I
look
at
the
workload
we
we've
had
a
pretty
steady
workload
over
the
past
year.
They
do
have
this
cool.
Let's
see,
where's
the
reviewers.
B
This
is
the
number
of
sig
reviewers,
so
you
can
actually
see
that
we
had
a
drop
off
in
the
number
of
reviewers
over
the
same
period
of
time
that
we
saw
an
increase
in
the
number
of
open
prs.
So
that
probably
suggests
that
there
were
fewer
people
who
were
actively
reviewing
prs
during
the
early
months
of
2020.
B
The
other
links
I'd
like
to
point
out
these
probably
changed
since
I
looked
at
them
last
week,
but
here
are
some
hopefully
helpful
links
to
prs
that
need
approval
for
those
of
us
who
are
approvers
in
signode,
as
well
as
those
that
are
open
and
are
looking
for
review
and
are
tagged
with
node.
So
if
you're
looking
for
a
place
to
to
get
started
or
to
find
more
prs,
then
the
bot
auto
assigns
you
from
being
on
the
reviewers
list.
C
I
got
a
random
one,
usually
in
depth
stats
you
can.
You
can
also
see
how
much
people
are
contributing.
Do
we
know
how
much?
How
active
approvers
are.
I
I'm
asking
because
just
to
give
more
context,
I'm
asking
because
it's
usually
it
is.
It
is
the
case
that
people
get
overloaded
or
they
switch
jobs
and
they
like,
and
people
who
are
approvers
in
some
places.
They
still
they
stay
as
a
progress,
but
they
are
not.
Actually,
they
are
not
actually
as
active,
yeah
fun
fact.
C
If
anyone
is
actually
interested
in
going
through
a
lot
of
owner
files
in
covert
and
kubernetes,
it's
like
joe,
better
still,
that
is
still
an
appropriate
and
he
is
still
a
requested
for
review
and
approval
and
a
lot
of
pr's,
even
though
he's
not
actually
he's
not
actively
contributing
to
the
brilliant
project.
Anymore,
yep.
B
It
doesn't
so,
I
think
there
were
25-ish
open
pr's
that
needed
approval
right
now
that
are
tagged
with
sig
node
and
all
of
those
had
a
an
approver
from
don
derek
myself
or
seth
assigned
and
looked
like
they
were
making
progress.
So
it
didn't
look
like
any.
B
At
least
any
of
the
prs
that
were
eligible
for
approval
right
now
were
blocked
on
us.
I
looked
at
the
dev
stats.
I
found
something
interesting,
which
is
that
it
didn't
seem
to
have
all
of
us.
I
could
find
myself,
I
could
find
derek,
I
could
find
seth,
but
I
couldn't
find
dawn
for
whatever
reason
and
I
couldn't
find
a
number
of
the
of
the
other
approvers
that
are
perhaps
less
active
today.
B
So
I
don't
know
if
we're
just
missing
stats
for
particular
people
or
what
the
what
the
deal
is,
but
I
know
don
approves
prs,
but
she
didn't
show
up
in
in
devstats,
so
I
can
try
and
it
does.
I
don't
know
if
it
does.
I
think
I
only
looked
in
kubernetes.
B
Kubernetes,
okay,
cool!
Well
thanks
for
the
the
points
what
I've
done
actually
so,
hopefully
we
can
make
this
sort
of
a
two-minute
or
shorter.
You
know
kind
of
piece
at
the
beginning
of
sig
meetings,
I've
added
a
sig
health
portion
of
the
meeting
notes
at
the
top.
B
Four,
I
think,
that's
so
there's
a
question
from
morgan.
If
there's
only
four
approvers
which
to
reiterate
our
dawn,
derek
myself
and
seth,
can
we
shadow
along
to
become
approvers
eventually.
B
D
Yeah,
so
there's
actually
probably
still
some
other
approvers
who
might
be
taking
either
temporary
assignment
elsewhere
or
I'm
not
sure
if
they
will
be
coming
coming
back
in
the
near
term,
but
have
a
large
like
historical
knowledge
of
the
code
base.
So
we'd
have
to
fault
with
some
of
those
individuals
and
I
think
among
the
group
of
us
here
we
can
kind
of
take
a
health
check
assessment
on
what
their
near-term
assignments
are.
D
D
The
only
caveat
on
that
is
like
we
want
to
make
sure
that
people
have
some
historical
knowledge
to
the
project
to
know
past
decisions.
Well,
so
the
most
recent
enhancements
for
seth
and
david
to
get
elevated
kind
of
captured
their
long-term
engagement
and
so,
but
for
anyone
who
who
wants
to
help
get
on
board
with
approving
and
and
getting
that
historical
context.
I
think
all
of
us
would
love
to
help
facilitate
and
accelerate
that.
B
The
other
thing
I'll
point
out
is
just
that:
approver
isn't
generally
a
binary
for
the
sig
that,
if
you're
really
experienced
in
a
certain
smaller
area
the
code
base,
it's
not
we've.
Definitely
given
out
approver,
for
example,
to
the
the
container
manager
like
topology
and
cpu,
pinning
section
of
the
code
base
to
people.
Who've
worked
on
that
a
lot,
so
I
think
that's
also
a
good
strategy
for
being
able
to
unblock
smaller,
more
focused,
prs.
D
Yeah
so
kevin
if
clues
from
nvidia
has
approved
a
rights
on
a
number
of
sub
elements
in
the
trade.
So
yeah
really
here
we're
just
talking
about
top
level
approval
to
cubelet
and
command
cubelet
and
probably
test
ede
node.
A
I
just
want
to
add
it
in
the
past.
We
actually
successfully
grow
a
lot
of
the
people
from
to
the
reviewer
and
then
to
the
approver.
We've
been
doing
this
constantly
and
also
I
personally
actually
kind
of
like
the
on
purpose,
try
to
not
use
thing.
My
approval
power
until
deleted
recently,
there's-
maybe
a
lot
more
leader
than
compared
to
before,
but
over
time,
actually
a
lot
of
time.
A
I
don't
need
to
perform
my
approval
power
because
we
do
have
a
many
of
the
approver
in
the
signal
the
community
in
the
past,
so
we
so
now
we're
starting.
I
will
use
the
starting
on
the
reviewer
because
most
of
the
approver
and
also
other
reviewer
now
we
can
actually
want
to
grow
more
on
the
both
reviewer
and
also
approval
just
to
share
with
the
team
here.
Yeah
and
there's
another
question
from
the
theme
and
didn't
want
to
see
the
regular
tragedy
meeting.
Yes,
we
are
agreeing.
I
think
this
is
exactly
we.
A
I
asked
david
to
take
the
15
minutes
initially,
because
we
we
asked
you
talk
about
how
we
have
the
regular.
What's
the
procedure
and
the
process
to
have
the
regular
charge
meeting
and-
and
we
have
to
make
the
final
decision
here
so
this
is
why,
like
the,
there
is
today's
kind
of
initial
topic
today,
yeah
dark,
do
you
want
to.
D
Yeah,
so
I
think
calendaring
is
hard
and
we
had
a
number
of
activities
that
we're
trying
to
get
ramped
up,
that
we
didn't
want
to
kind
of
take
away
the
momentum
on
any
of
them.
I
guess
I
would
view
right
like
so.
D
We
have
the
ci
health
activity
that
we'll
talk
about
afterwards
and
then
I
had
originally
proposed
the
dedicated
triage
meeting,
but
then
we
thought
well,
let's
just
make
a
standing
15
minutes
on
this
meeting
weekly
to
at
least
go
through
and
report
if
anything
stalled
and
not
be
so
oriented
towards
new
feature,
discussion
or
issue
discussion
that
type
of
thing
so
the
moment
I
think,
across
david
myself
and
stuff
getting
our
calendars
right.
E
D
Yeah,
I
think
that
would
be
great
right,
so
just
we're
all
here
right.
So
it's
a
good.
We
just
want
to
have
a
standing
block.
15
minutes
talk
about
helpless,
again,
issues
that
are
being
stalled
or
or
needing
attention.
E
Right
yeah:
let's
just
do
it
that
way,
we'll
ask
people
if
they're
stuck
then
come
here,
add
it
to
the
agenda
and
then
the
initial
15
minutes
and
we'll
usually,
if
we
do
it
at
the
end
most
of
the
times
they
we
don't
get
around
to
it
right
so
and
it
falls
off.
That's.
D
Why
yeah,
even
even
just
getting
it
linked
in
here
as
a
thing
to
call
out,
took
a
look
at,
is
often
a
helpful
product,
far
more
than
an
email
for
me.
So.
A
A
So
we
we
want
to
take
that
utilization
15
minutes
at
the
beginning
of
the
meeting
and
then
quickly
turn
around
and
find
the
reviewer
and
find
what
is
the
block
and
our
review
process
or
the
approval
process,
and
not
really,
unless
there's
the
technical
attention
like
that
we
need
discussing,
then
we
connect
that
will
be,
but
that
15
minutes
most
is
for
the
get
people's
attention
right.
A
Yeah,
I
just
don't
want
to
just
connect
the
set.
I
just
hope
we
can
set
expectation
correct
here
so
so
directly,
and
I
will
talk
about
more
because
we
last
time
we
last
week
we
meet
and
we
haven't
finalized
those
process
yeah.
But
this
week
we
we're
going
to
continue
that
that
and
discuss
because
last
week
we
put
more
effort
and
discussing
on
the
ci
project.
B
C
I
got
one
last
question,
so
it
was
mentioned.
It
was
mentioned
that
it
will
be
ok.
It
will
be
okay
with
y'all
to
to
to
shout
at
the
shadow
of
proverbs
in
order
to
become
reviewers
and
proverbs
in
different
different
areas.
What
would
a,
how
would
you
recommend
that
people
actually
go
about
that.
D
I
think
there's
been
a
few
folks
that
been
trying
to
mentor
via
slack
so
just
reaching
out
to
one
of
us.
One-On-One
is
actually
really
helpful.
I
think
we'd
be
happy
to
facilitate
that
one
of
the
things
like
if
I
was
to
be
completely
honest,
we
have
a
lot
of
folks
who
will
look
at
code
and
have
a
in
some
ways.
D
A
D
And
say
actually,
no,
and
so
what
I
would
find
interesting
is
like
if
there
are
folks
who
are
reviewing
prs.
D
That's
like
the
key
skill
I
feel
like
it's
hard
to
grow
in
the
community,
but
I
feel
like
it's
a
skill
that
I
know
both
seth
dawn
and
david
and
others
who've
worked
in
here.
I
think
we
feel
like
is
really
needed
to
get
into
that
approval
right.
So
there's
a
lot
of
folks
who,
who
will
say,
hey,
I
lgtm
a
lot
of
these
pr's
and
I
did
all
these
reviews.
But
then,
when
I
look
in
the
details
of
the
review,
I
never
see
any
actual
constructive
criticism
beyond
generally
this.
D
This
seems
pretty
good
right,
so
I
think
what
I'm
looking
for
is
like
how
do
we
get
constructively,
provide
criticism
and
are
comfortable
saying
no
as
a
as
a
thing,
because
ultimately,
it's
our
job
as
top
level
approvers
to
ensure
that,
like
our
scope,
doesn't
go
and
brown
unbounded,
and
so
if,
if
folks
have
been
participating
in
entertainment
prs
and
they
want
to
talk
about
things
that
they
think
may
or
may
not
have
been
right
or
that
type
of
thing,
I
think
all
of
us
would
love
to
have
that
discussion.
D
A
Yeah
sex
there
dar
could
share
this
one,
and
I
I
also
wanted
to
hear
in
the
past
we
did
a
10
down
song
approval
and
because
just
two,
less
and
and
and
because
sometimes
I
I
personally
feel
like
the
really
proud
it
is
in
the
past
six
years.
I
I
constructively
turned
down
a
lot
of
project
and
another
project.
When
I
look
back,
I
do
think
about
it.
Is
damage
could
be
damaged
or
community?
A
Could
then,
if
you
are
signal
the
reliability
and-
and
so
so,
that's
really
key
and
important
pieces
about
being
a
leader,
technical
leader
here,
and
I
it's
easy
to
agree
and
without
question
and
without
the
challenge.
So
that's
why
that's
the
kind
of
the
key
part
that
we
tried
to
looking
for
to
become
to
off
the
approval,
different
and
different
from
the
reviewer
yeah.
So
thanks
derrick
brought
this
up
yeah
because
it
actually
used
to
be.
We
have
this
many
discussing
before.
A
So,
let's
move
to
next
topic
and
the
circuit
and
victor:
do
you
want
to
talk
about
last
week
a
few
of
us
get
together
talk
about
the
ci
and
and
signal
the
reliability
project,
and
then
at
the
end
we
decided
to
name
it
is
as
the
signal
the
circle
project
and
and
the
second
and
the
and
the
victor.
Do
you
want
to
driving
the
discussion
here
and
share
the
doc
with.
F
Us
hi,
I'm
sergey,
I
I'm
I'll
start
and
victor
jump
at
any
moment.
We
didn't
sync
up
this
mention
of
the
document,
but
yeah.
I
think
we
can
just
figure
it
out
as
we
go
so
sig
note.
Ci
group
is
not
something
new,
it's
a
effort
that
already
been
started
before
and
we've
been
when
we
say
we
it's
like.
I
joined
quite
late,
but
I've
been
running.
F
We
said
with
test
fixes
and
stuff
like
that
for
a
while,
and
the
big
reason
for
that
is
that
tests
for
signal
specifically
started
degrading
and
just
natural
causes
of
degradation,
and
it's
nothing
that
something
bad
was
happening.
It's
it's
a
life
and
our
goal
for
this
group
is
to
be
proactive
and
proactively,
maintain
our
test
cases
and
keep
the
healthiness
of
code
base.
So
this
wouldn't
be
a
challenge
any
longer.
F
F
We
want
to
improve
test
coverage,
so
more
features
will
be
covered
this
test
and
we'll
be
more
confident
in
contributions
that
coming
into
signaled,
and
we
also
want
to
fight
the
natural
causes
of
test
degradation,
namely
os
image
support.
So
whenever
new
os
image
comes,
we
need
to
support
it.
We
need
to
adjust
to
the
changing
nature
of
life
and
what
images
being
used
widely.
F
What
tools
are
installed
on
the
nodes
and
stuff
like
that,
and
we
also
want
to
improve
test
roi,
so
we
want
to
make
sure
that
whatever
test
we
run,
we
know
why
we
run
this
test
and
we
have
a
clear
understanding
how
we
benefit
from
running
this
test
and
spending
both
like
machine
time
and
people
time,
maintaining
those
tests
active
and
healthy.
F
So
from
execution
standpoint,
we
want
to
restart
our
regular
meetups
right
now.
This
plan
is
to
do
it
monday
at
10
a.m.
So
it's
a
time
synchronized
with
east
coast,
and
europe
are
a
little
bit
mostly
with
europe,
not
asia.
We
want
to
triage
issues.
We
want
to
do
some
pull
request,
reviews
and
bring
to
attention
some
reviews
at
a
stale.
F
F
We
want
to
both
increase
it,
where
we
need
to
increase
it
and
cut
tests
that
are
not
testing
anything
that
may
be
just
running
cpu
cycles
and
don't
bring
actual
verification,
and
we
plan
to
work
on
some
automation
and
tools
to
help
our
life,
namely
like
alerts
when
our
release
blocking
tests
fail
failing.
We
want
to
do
some
dashboards
to
fast
to
better
track
pr,
pull,
requests
and
understand
the
code
coverage
for
our
tests.
F
And,
finally,
we
want
to
improve
the
communication,
so
every
new
contribution
will
be
easy
and
we
want
to
make
sure
that
we
know
what
that's
doing.
We
have
an
easy
way
to
figure
it
out
easy
way
to
support
it
and
easy
way
to
onboard
new
members
to
this
effort
yeah.
So
I
think
the
actual
call
out
here
is
to
join
join
this
effort,
try
to
contribute
in
the
stability
of
signal
and
yeah.
We
welcome
everybody
victor
want
to
add
anything.
G
Yeah
yeah
sure
thank
you
sergey.
That
was
a
really
good,
really
good
introduction
to
the
you
know
the
the
new
testing
effort
I
wanted
to
just
say
thank
you,
ning
ning
and
you
know
sergey,
and
I
think
rory
and
quran
also
and
probably
david
met,
and
you
know,
did
a
lot
of
work
on
this
document,
which
was
really
sort
of
picking
up
some
of
the
ci
efforts.
G
We
had
started
early
on
and
sort
of
they
had
sort
of
held
off,
and
so
this
is
a
formal
effort
to
restart
that,
and
I
think
that's
great
one
of
the
things
I'm
not
quite
sure
of
you
know
when
we
look
at
this
is.
It
seems
like
this
is
a
formal
charter
thing
and
I
think
there
has
to
be
some
probably
review
an
approval
process
and
I'm
not
quite
sure
how
to
move
forward
on
that,
but
yeah.
This
is
this
is
good.
So
can
we
speak
to
that
for
a
minute,
dawn
and
derek?
A
Actually,
I've
been
involved
from
the
beginning
when
thing
and
the
victor
have
this
idea.
So
I
already
reviewed
the
dock
and
I
already
packed
it
to
the
last
week.
I
basically
yeah
there's
the
review
process
like
the
pro
like
before
we
want
to
make
this
a
formal
sub
project
and-
and
we
also
want
to
eliminate
elected.
A
I
think
we
already
elected
of
the
like
the
like
the
leading
lead
leader
and
drive
that
the
two
project,
and
but
derrick
and
also
derek,
is
looking
into
this
one
and
the
derek,
and
I
is
going
to
discuss
this
one
and
derek:
do
you
want
to
point
more.
D
There
is
some
eyes
and
t's:
we
have
to
dot
and
cross
to
go
through
the
formal
subproject
process,
but
this
is
really
covering
things
that
are
related
to
like
testing
of
the
cubit
sub
project
itself,
but
then
some
of
the
supporting
machining
around
it
that
we
can
get
the
the
paperwork
stuff
settled.
I
think
I'm
I'm
understating
how
happy
I
am
to
see
the
help
in
getting
this
brought
forward.
D
So
much
of
what's
been
identified
here
is
fantastic
and
I'm
hoping
that
this
can
prove
successful
and
can
provide
a
daily
readout
on
they're,
not
a
daily,
I'm
sorry,
a
weekly
readout
on
how
we're
tracking
those
in
the
world
sick
with
with
health.
On
this,
the
only
thing
I
was
thinking
about
after
this
is,
if
some
of
the
other
subprojects
that
were
listed,
there
could
get
better
integrated
in
this
process
so
but
don,
and
I
can
can
trace
that
down
afterwards.
But
I
think
this
is
long
overdue.
A
I
think
some
of
the
old
several
projects,
maybe
can
consolidate
or
maybe
deprecate
it.
So
we
can
we
direct
and
I
go
across
process
those
things
together
after
smoking.
So
then,
then
we
will
report
back
to
the
community.
A
If
we
do
things
and
but
yeah,
that's
the
sum
of
the
paperwork,
we're
going
to
pick
up
and
then
drive
through
offline,
and
so
maybe
we
also
need
to
see
that,
what's
the
how
often
the
sub
project
should
be
reported
back
to
the
signal
directly,
we
used
to
have
like
the
other
sub
project
regularly,
like
the
monthly
or
something
it
is
like
the
evening
by
weekly
report
back
to
the
signal.
Maybe
we
also
need
to
finalize
that
process
and
they
used
to
be
like
the
a
little
bit
negative
menu.
A
We
poke
up
the
people
say.
Oh,
please
come
back
to
the
signal
and
and
the
sound
is
just
nature
because
invaded
in
the
signal,
the
community
meeting,
because
it's
kind
of
daily
stuff,
like
container
runtime
interface,
used
to
be
every
week
there.
They
have
the
updated
status
and
because
everyone
pay
attention
so,
but
the
zombie
is
a
little
bit
like
the
ad
hoc,
like
the
node
problem
detector
and
I
have
to
manually
to
poke
engineers
say:
oh,
come
back
to
signal
at
least
like
the
monthly
to
report.
A
D
Reported
back,
I
think,
for
how
david
presented
the
overall
health
metrics
for
the
primary,
like,
I
guess,
top
level
project
of
the
sig.
D
I
think
it'd
be
good
to
pair
up
this
group
to
output
the
current
status
in
the
beginning
of
every
sid
call
and
we
can
adjust
as
things
go,
but
that
seems
to
work
just
fine
for
me,
some
of
the
other
ones
like
cri
and
stuff
they've.
Well,
they
need
to
get
out
of
this
perpetual
alpha
state
they've
also
are
seeing
less
less
churn,
whereas
this
is
just.
Are
we
continually
healthy.
G
One
comment
I
would
make
is,
I
think,
in
the
previous
meeting
about
the
sub
project
for
ci,
we
had
sort
of
said
that
the
group
would
meet
once
every
two
weeks
and
maybe
if
we're
going
to
you
know,
give
an
update
every
week,
we
might
need
to
change
that
to
weekly
yeah.
That's.
D
Just
the
thing,
so,
I'm
still
hoping
we
can
like
resurrect
some
of
the
supporting
tooling
we
had
like
if
we
regressed
on
a
performance
like
we
had
a
performance
dashboard.
That
was
being,
I
think,
don
you
had
an
intern
or
something
that
built
that
at
one
time.
Yes,
so.
G
D
G
Of
the
effort,
okay,
yeah,
I
think
we
maybe
found
that
graph
where
it
was
spinning
up
cubelet,
pods
and
seeing
how
long
it
took
them
to
spin
up
and
stuff
like
that.
Is
that
the
graph
you're.
A
Referring
to
yes,
that's
the
load,
the
level
of
purple
test,
build
by
my
intent
and
then
my
turn
by
the
google
nerd
in
the
past
and
but
recently
last
half
last
one
year
almost
like
that.
Nobody
really
mentioned
that
one.
So
that's
right!
Yeah.
G
Yeah,
I
think,
morgan,
I
think,
was
the
one
that
sort
of
found
that,
and
you
know
we
were
asking
questions
like
who's
looking
at
this
thing
and
before
we
make
changes
to
test
code,
let's
understand
so
that's
good
and
that
that'll
be
good
to
get
that
revolved
and
you
know
start
looking
at
that
to
see
how
changes
improve
or
hopefully,
don't
decrease
performance.
So,
okay,
good.
I.
A
Just
want
to
share
like,
in
the
past
the
coup,
a
lot
of
the
kubernetes
resource
leakage
issue
and
a
docker
performance
related
issue
actually
is
founded
by
that
dashboard,
and
we
even
find
like
the
one
of
the
remember,
it's
nectar.
We
need
couple
release,
blocker
related
to
the
storage
and
the
the
walnut
mountain
and
I'm
unking,
also
founded
by
that
dash
dashboard
yeah.
So.
F
There
was
a
question
on
chat
from
jorge,
I
think,
asking
whether
we
can
have
a
doodle
for
meeting
time
meeting
times
are
hard
to
schedule
across
such
a
big
community.
So,
let's
victor,
let's
chat
about
like
meeting
time,
and
maybe
we
need
to
sign
a
doodle
and
collect
more
feedback
on
on
the
timing.
F
I
think
10
p.m
and
monday
worked
before.
We
need
to
check
whether
we
want
to
change
it.
G
You
mean
it
was,
I
think,
10
a.m,
pacific
time,
which
would
be
like
one
eastern
time
and
sure.
Maybe
we
can
start
with
that
and
we
can
start
out
and
see
if
that's
a
good
time
and
folks
can
give
us
feedback.
Otherwise,
we
won't
ever
have
a
meeting.
A
Maybe
we
have
the
form
and
ask
the
people
like
that
they
just
sign
on
and
they
put
it
up
extra
time
and
the
majority
when
that's
easier
and
who
wants
to
participate
and
promo
and
pro
we
can
propose
several
times
and
ask
people
to
vote
that'd
be
easier.
Otherwise,
arbitrary
is
hard
for
us
to
decide.
It.
A
A
Oh
god
circuit,
can
you
do?
Can
you
try
to
do
that?
I
I
noticed
that
my
my
laptop
is
just
dyed
too
hot
right
now.
I
A
A
H
So
the
I
have
put
that
on
google
drive
and
the
signo
dock
has
a
link
to
it.
If
you
can
pull
it
up
and
share
your
screen,
that
also
works
I'll
just
talk
through
it.
A
Circuit
can
you
share
because
my
my
laptop
is
frozen
yeah
yeah?
Can
you
help
to
share
those
the
slides.
H
Perfect,
okay,
so
I
think
david
and
tim
have
been
discussing
this.
I
was
looking
into
some
other
work
for
a
little
bit,
and
I
came
back
to
this.
If
I,
if
I
summarize
correctly,
it
looks
like
there
are
two
tracks:
two
train
trains
of
thought
that
are
going,
one
is
to
move,
revert
back
to
an
earlier
state
where
we
had
where
resources
allocated
the
kubelet
does
some
checkpoint.
H
Maintaining
this
is
kind
of
we
discussed
this
about
three
weeks
ago
as
a
potential
option
where
cpu
manager
is
already
doing
it,
and
other
train
is
that
we
have
preferred
resources,
a
new
field
in
the
api
port
spec,
and
that
would
enable
the
feature
where
you
have.
Okay.
This
is
the
minimum
resources
I
need
to
be
able
to
run,
and
this
is
my
ideal
resources.
So
I
think
it's
an
impact.
H
We
are
at
an
impasse
whether
we
should
go
with
that
or
whether
we
should
have
a
checkpoint.
As
far
as
tim's
point
of
view
is
concerned,
david,
is
that
accurate
summary.
B
H
Yeah,
I
thought
already
read
as
much
into
it
so
anyways
I
kind
of
looked
at
that
google
checkpointing
code.
I
didn't
get
into
deep,
deep
details
or
try
it
out
yet,
but
it
seems
like
it's
you
you
create
a
structure
around
it
and
there's
a
backing
file
you
it
saves
to,
and
this
seems
to
be
some
caching
mechanism.
Please
let
me
know
if
I'm
mistaken
about
any
of
these,
so
based
on
that
what
I
saw,
I
think
I
was
looking
at
the
following
flow.
H
We
can
previously
did
this
in
an
earlier
iteration
where
resources
allocated
was
in
status,
but
we
did
not
have
a
way
to
recover
if
it
was
lost.
But
let's
say
we
go
with
the
approach
of
having
a
checkpoint
in
the
couplet
similar
to
the
cpu
manager.
The
way
it's
doing
so,
essentially,
when
a
pod
gets
added,
we
store
the
part,
its
name,
its
containers
and
what
its
resources
are
at
the
time
of
admission,
and
that
is
your
allocated
now
we
reflect
that
back
into
the
the
status
contains.
H
The
container
status
contains
two
fields.
One
is
the
resources
which
is
the
actual
running
state
of
the
container,
and
there
is
the
resources
allocated
a
resources
list,
a
resource
list
type,
which
is
the
reservation
that
we
agreed
to
based
on
the
admission
being
successful,
so
that
would
be
persisted
in
the
state
file
and
reflected
by
into
the
st
status
allocated
field
from
so
in
this
would
yeah
it's
a
patch
that
happens
in
sync
pod.
So
immediately
as
we
determine
that
you
know,
this
is
possible.
H
The
container
the
runtime,
the
runtime
manager,
has
a
pod
compute
pod
actions
and
sync
pod,
where
it
looks
for
what
the
code
is
doing
today
using
the
spec
field,
resources
allocated,
it
does
the
same
checks
and
it
goes
through
breaks
down
the
updates
that
it
needs
to
do
orders
them
correctly
and
all
that
stuff
and
then
calls
the
cri
update
container
resources
where
necessary
and
the
container
status
api
will
respond
with
the
updated
resources,
the
actual
resources
that's
configured
configuration
on
the
container
by
the
runtime
and
that
gets
reflected
into
the
pod
status
and
the
update
that
goes
to
the
api
server.
H
H
So,
to
summarize,
I
think
the
changes
that
we
are
looking
at
here
is
api
pod
spec.
This
is
the
this
is
what
this
is
fundamental.
We
have
the
containers,
resources
it
becomes
mutable
we
control
to
see
that
only
cpu
and
memory
are
allowed
to
mutate.
At
this
time
we
have
a
new
object
resources
allocated
in
of
type
resource
list
in
container
status,
and
this
is
rediscovered
from
the
state
checkpoint
state.
In
case
the
status
were
lost,
so
it's
something
that
we
can
recover
and
we
have
the
resources.
H
What's
already
there
today,
resources
field
in
the
status,
which
is
the
actual
running
the
configured
configuration
on
the
container
as
reported
by
the
runtime.
So
this
I
think
this
include
this
would
report
the
runtime
of
today
would
report
cpu
reservation,
requests,
cpu
limits
and
memory
limits.
We
get
the
memory
requests
from
the
state,
so
that's
the
little
detail
there
and
about
handling
coupe,
let's
start
restart.
When
we
get
a
new
part,
we
come
into
handlebar
edition
and
we
use
a
checkpoint
state.
H
If
part
is
found,
then
we
use
the
resources
allocated
value
that
was
saved
persisted
if
not
found.
Then
we
do.
The
standard
can
admit
part
and
then
admit
to
reject,
as
we
are
doing
today
and
scheduler
would
have
to
use
max.
I
believe
we
can
get
away
with
using
status
or
resources
allocated
alone,
but
I'm
not
I'm
not
sure
if,
if
the
status
is
not
available,
what's
gonna
happen
during
the
time,
maybe
we'll
have
to
limit
the
user
from
modifying
the
resources
on
a
part.
H
That's
not
running
yet,
but
that's
not
a
great
idea
to
me
because
in
our
earlier
prototype
one
of
the
things
that
the
jd.com
and
the
companies
that
took
our
prototype
and
worked
with
it
did
is
they
looked
to
see
what
pods
were
not
were
pending
because
of
resources
tried
reducing
it
while
it's
spending.
So
that's
something.
It's
a
use
case
that
we'll
have
to
say
goodbye
to.
If
we
did
just
resources
allocated,
we
can
go
with
this.
For
now
tim.
H
There
is
a
corner
case
where
a
malicious
user
can
game
the
system
and
get
more
without
paying
for
it.
I
could
have
documented
that,
in
the
thread
that
we
are
going
with
tim
on
the
revisit
of
the
spec
of
the
cap,
so
I
do
not
david
if
had
a
chance
to
read
through
that.
B
I
didn't
read:
I
I
looked
at
it
briefly.
I
didn't
actually
try
and
reason
through
it
myself,
yeah,
but.
H
It's
a
fairly,
I
think
it's
not
a
big
concern
in
today's
kubernetes,
where
you
know
the
entire
cluster
is
owned
by
one.
So,
if
they're
doing
this
they're
only
hurting
themselves,
the
cluster
is
hurting
their
their
own
usage.
But
if
we
had
a
true
multi
something
we've
been
working
on
a
true
multi-tenant
kubernetes
system,
where
the
service
provider
has
tenants
using
a
single
cluster
and
you
need
strict
isolation,
then
this
would
become
a
concern.
H
H
A
Do
we
improve
really
thank
you
for
your
share
with
this
one
yeah
and
the
team,
and
I
have
been
discussed,
I
I
understand
where
he
came
from
and
after
he
told
me
because
he
mostly
is
like
the
concern.
A
This
is
the
he
wanted
to
dedicate
of
the
powders
back
to
represent
the
user
configuration's
user
requirement.
Yeah.
That's
why
he
is
concerned
about
this
resource
located,
is
kind
of
the
generator
automated
by
system
and
mess
up
the
user
config.
A
I
I
buy
that
intention,
but
and
it's
like
the,
but
the
problem
is
today's
protospec.
Actually
I
already
have
a
lot
of
things
is
defaulting
by
the
system
and
the
generated
by
the
automated
by
the
system.
A
So
so
so
so
so
so
it's
kind
of
the
I
I
like
to
move
towards
that
direction,
but
on
other
hand
to
for
this
particular
using
that
this
particular
field
using
that
one,
I'm
not
sure,
because
I
want
to
see
the
all
the
other
complexity
generated,
but
I
want
to
ask
you
one
thing
why
we
absolutely
need
the
checkpoint.
I
think
we
talked
about
this
before,
but
can
you
help
me
refresh
the
memory
on
this?
H
I
think
the
the
concern
here
is:
let's
say
everything
is
stable.
Where
you
have
added.
Let's
say
you
have
a
a
pod
which
has
four
cpus
available
as
a
node
with
four
cpus
available,
and
then
you
have
one
port
that
uses
three
and
then
another
part,
that's
using
one.
You
have
these
two
parts.
So
now
the
kubelet
dies
and
during
the
time
cubelet
is
offline.
The
first
part
which
is
asked
for
3
goes
to
3.5,
and
then
you
come
back
up.
H
If
you
don't
have
a
way
to
recover,
know
what
it
was
admitted
at
the
resources
allocated.
That
is
essentially
where
it
is.
If
we
don't
know
this,
then
we'll
say:
okay,
p1
3.5,
I
have
capacity
I'll
admit
it.
P2
comes
and
it
asks
for
its
one
where
it
was
admitted
at
initially
we
say
we're
going
to
reject
it
because
we
don't
have
any
room.
So
that's.
B
H
Right,
so
this
is
the
need.
This
is
the
reason
why
it
needs
to
be
persisted
somewhere
where
you
can
have
a
source
of
truth.
This
is
what
it
was
and
by
putting
it
in
the
pod
spec,
we
had
a
single
source
of
truth,
the
aps
server,
which
tim
is
against,
and
the
other
option
is
to
use
the
checkpoint
mechanism.
That's
there
in
kublet
today
and
achieve
the
same
goal
by
moving
this
resources
allocated
field
to
status.
In
fact,
the
naming
of
resources
allocated.
H
If
you
recall
it,
was
initially
in
status,
and
at
that
time
we
didn't.
We
weren't
aware
of
the
need
for
handling
the
case
where
status
is
lost.
That
came
up
during
one
of
the
discussions,
and
then
we
moved
it
to
spec,
and
I
just
didn't
take
the
time
to
rename
it
to
something
more
appropriate,
because
resources
allocated
is
more
of
a
status
sounding
kind
of
thing.
Rather.
A
B
B
H
Cubit
yeah
we
had
max
in
the
in
the
earlier
iteration
of
the
cap.
We
had
max
for
resource
quota
as
well,
but
figured
david
kind
of
identified.
We
didn't
need
it.
There
shouldn't
be
an
extended
period
of
time
where
the
cluster
resources
you,
if
you
were
to
go
with
just
the
resources
allocated,
you
would
end
up
in
a
situation
where
you're
giving
more
than
the
resource
quota
allows
for
an
extended
period
of
time.
H
So
the
there's.
H
Right
go
ahead.
Sorry,
yeah,
the!
If
we
allow
this
okay,
I'm
just
resource
quota
being,
like
the
literal
cube,
object
resource
right
right.
If
two,
two
very
successive
okay,
I
see
the
point
who
have
to
revisit
this
david.
B
Yep
so
derek,
but
you
can
think
about
it.
Two
different
ways.
One
is
that
if
you
enforce
quota
on
the
what
essentially,
what
the
user
has
asked
for,
and
only
that,
then
there
is
a
race
where,
for
example,
I
lower
the
lower
the
desired
resources
for
pod
a
and
then
increase
the
desired
resources
for
pod
b
and
those
are
not
rejected
by
the
quota
controller
or
by
quota,
because
you
did
one
and
then
the
other.
B
But
my
contention
is
that
it's
generally
a
benign
race
and
we
we
don't
expect
the
cubelet
to
reject
changes
to
resource
requests
that
are
downward.
We
ex
we
expect
those
to
be
admitted.
The
alternative
is
that
we
could
use
max.
The
only
thing
that
that
introduces
that's
a
little
bit
strange
is
that
then
you
could
have
the
cubelet
have
status
updates
be
rejected
because
it
would
violate
quota.
B
B
B
D
I
agree
the
cubelet
will
accept
downward
changes,
but
it
can't
always
realize
those
downward
changes.
B
Yes,
that's
only
for
limits
right,
so
requests
can
always
be
realized,
at
least
like
cpu
request
changes.
B
Of
that
cube
right
yep,
that
is
so.
I
I'll
also
say
that
right
now
we
allow
we
don't.
So
we
have
two
options.
We
can
either
try
and
serialize
runtime
changes
with
admission,
which
I
think
would
make
the
cubelet
hard
to
reason
about,
but
that
would
be
one
option
is
to
say:
okay,
actually,
the
cubelet
can't
determine
whether
or
the
cubic
can't
fully
admit
you
until
it's
ensured
that
it
can
actuate
this
resource
resize.
B
The
current
design
essentially
says
that
we'll
admit
you
at
a
certain
set
of
resources
and
use
the
it's
like.
There
are
two
there's
actually
two
benign
races.
One
is
a
race
between
propagating
requests
to
resources
allocated
like
there's
the
race
during
admission
that
I
talked
about
previously,
there's
also
one
during
actuation,
in
which
it's
possible
that
the
container
runtime
could
reject
or
just
be
unavailable
or
something
and
not
be
able
to
okay.
D
D
H
Okay,
cool
so
david.
There
is
a
case
where,
let's
say
it's
one,
not
one
downward
and
one
upward,
but
two
upward
increases
coming
in
quick
succession
before
the
cubelet
on
say
the
first
part
it
both
are
acceptable
to
the
two
parts
p1p2
on
two
different
nodes
and
both
are
acceptable.
Just
looking
at
raw
capacity.
H
There
is
enough
capacity
for
that
and
your
p1
comes
and
the
kubelet
grants
it,
but
it
hasn't
had
a
chance
to
write
to
resources
allocated
yet
because
there's
some
delay
in
the
watch
due
and
a
second
request
for
p2
increase
comes
if
we're
strictly
looking
at
resources
allocated
we're
going
to
let
it
through,
whereas
we
should
really
not
be
right.
B
H
Maybe
we
can
break
it
down.
Well,
it's
simple
to
just
use
max.
D
Yeah,
I
know
we're
at
time
yeah
just
the
I'm
trying
to
make
sure
I
get
the
iteration.
This
is
going
so
we're
saying
we
want
to
put
allocation
under
status
and
absence
of
that
status.
Qubit
would
still
do
local
checkpointing.
H
Was
what
in
in
case,
we
lose
the
resources
allocated?
If
we
don't
know
what
it
is,
let's
say
it's
in
status,
but
we
lose
the
status
it
gets
wiped.
Then
we
don't
have
a
way
for
if
cubelet
were
to
restart,
we
don't
have
a
way
to
bring
it
back
to
the
state
of
pre-restart.
H
And
resources
allocated
was
lost
because
status
was
wiped,
so
there
is
a
couple
of
fairly
low
probability.
What
to
me
seems
like
low
probability,
ifs
there
that
are
going
in,
but
we
are.
I
think
the
principle
is
that
if
we
didn't
have
a
checkpointed
way
of
recovering
we're
violating
api
api
guidance.
D
H
Yeah
you
mentioned
that
and
I
looked
into
that
manager
so
yeah.
I
am
okay
with
either
approach
this
or
the
preferred
that
david
brought
up
and
tim.
I
think
we
are
kind
of
undecided.
Tim
was
wondering
how
to
break
this
impasse.
H
Should
we
get
a
sig
a
lead
from
signor
lee
to
come
and
explain
why
that
feature
is
so
useful
or
should
we
get
a
third
reviewer?
That's
the
questions.
Tim
is
asking
right
now
so,
but
I
just
wanted
to
present
this
approach
and
see
think
through
it
like
get
you
on
it
and
I've
not
prototyped
the
checkpoint
part
of
it.
So
I
don't.
H
I
can't
speak
very
confidently
right
now,
but
it
looks
like
it
might
work
it's
plausible,
but
you
you
look
at
the
approach
and
see
if
it
if
there's
any
holes,
that
you
can
poke.
Let's
get
this
right.
A
Here's
what
I
and
here's,
what
I'm
thinking
and
to
unblock
this
project,
because
it's
always
important
many
many
people
waiting
for
this
for
a
while
and
it
goes
through
actually
the
checkpoint
and
the
discussion
also
is
proposed
initially
also
and
and
also
we
are
clearly
told
community.
A
A
A
We
put
off
the
spec
to
deprecate,
is
much
harder
put
into
include
into
the
checkpoint,
implement
of
the
checker
point
and
put
it
into
its
status
at
least
there's
the
way,
because
we
clearly
clearly
currently
tell
please
don't
depend
on
the
status
to
the
community.
More
people
violate
that
all
the
time,
but
at
least
we
document
that
and
the
clearly
total
community
so
to
unblock
this
conversation,
I'm
totally
okay
with
the
checkpoint.
D
I'm
I'm
fine
with
the
checkpoint.
Just
we
need
to
ensure
we're
graceful
about
not
failing
in
the
absence
of
a
checkpoint,
because
that's
the
only
painful
things
we've
had
in
the
past:
around
checkpoints
but
yeah.
I
think
I
like
the
checkpoint,
probably
better
than
the
earlier
iteration,
I'm
fine
with
having
it
in
status.
I
think
it's
it's
a
nice
user
touch
to.
Let
me
know
what
the
keyboards
actually
acknowledge
and
it's
not
actually
live
usage.
So
it's
it's
low
right.
D
So
at
least
what
you
have
here,
I
think
it's
fine,
the
thing
that
bugs
me
a
little
bpa
is.
I
is
it's
right
now:
it's
cpu
and
memory,
but
in
the
end,
I'd
like
to
be
able
to
like
grow
it
to
be.
You
know,
other
counted,
resources
on
the
node
like
pids
or
similar
yeah,
and
so
I'm
just
looking
at
this
thinking
is
there
any
detriment
to
that
and
I
can't
think
of
any
so
in
general.
I
think
we've
got
it
here.
H
As
long
as
it's
one
of
the
supported
fields
in
the
resource
list,
we
should
be
able
to,
and
even
for
extended
resources
at
some
point
it
can
be
added.
I
just
didn't
see
a
need
for
it,
and
I
believe
this
question
was
asked
in
kubecon
and
piata
mentioned.
There
was
no
asks,
no,
nobody
was
asking
for
it,
so
they
were
not
doing
it.
A
B
H
H
I
know
I'm
exceeding
your
time
but
yeah,
please
think
through
this
look
at
the
design
and
I'm
gonna
go
through
more
details
and
if
there
is
anything
I
see
any
fishy
things
I'm
to
surface
it
immediately.
A
Really
can
use
what
we
agreed
today.
I
could
work
yeah,
so
we
can
unblock
and
and
and
so
team
also
ping
pokney
and
a
couple
times
to
say.
I
A
H
H
Yeah,
I
think
what
we
we're
looking
at
doing
right
now
is
using
a
node
local
checkpointing
mechanism
to
persist,
cpu
requests
and
cpu
res
and
memory
resources,
and
so
that
when,
if
in
order
to
restart
we
have
that
information
available-
and
we
can-
you
know
converge
to
that-
and
we
reflect
that
into
status,
container
status,
dot
resources
allocated
the
agreement
that
we
have
okay.
H
This
is
what
we're
going
to
provide
in
terms
of
requests
and
the
container
status
resources
continues
to
present
information
that
we
query
from
the
cri.
H
So
I'll
look
into
the
details
of
the
checkpointing
mechanism,
the
file
format
and
things
like
that
over
the
next
few
weeks
and
work
on
it
start
working
on
it
at
least
but
yeah.
I
think
we
can
let
tim
know
we'll
try
this
approach.
This
doesn't
rule
out
having
preferred
resources
at
some
point.
We
can
always
bring
that
in
the
future
if
we
need
it,
but.
A
H
Better,
we
do
it
now,
rather
than
later,
if
that's
the,
if
that's
the
desired
way
to
do
it,
because
you
know
already,
there
are
three
fields
that
are
resources
and
the
whole
prospect
is
spec:
dot,
resources
and
status,
dot,
resources
allocated
and
then
status
resources.
We
don't
want
one
more.
It
kind
of
starts.
Looking
a
little
weird
at
the
point.
B
A
It's
okay,
so
so
thank
you.
Everyone
attended
today's
meeting
and
see
you
folks
next
week.