►
From YouTube: SIG - Performance and scale 2023-06-23
Description
Meeting Notes:
https://docs.google.com/document/d/1d_b2o05FfBG37VwlC2Z1ZArnT9-_AEJoQTe7iKaQZ6I/edit#heading=h.tybh
A
Okay,
so
it's
six
scale,
it's
June,
22.
2023,
use
that
yourself
as
an
attendee
all
right.
Let's
start
off
with
this
issue
that
Brian
reported,
so
we
were
seeing
some
timeouts
with
the
performance
Lane.
It
looks
like
we're
able
to
get
to
the
bottom
of
this.
We
this
issue
is.
A
Oh
no,
this
is
it
okay,
so
the
this
issue,
I
guess,
is
tied
to
oh,
okay,
Brian
changed
it
I
think
yeah
I
was
edited.
Okay.
There
was
another
pull
request
in
here.
That's
what
I
was
confused.
Okay,
there
was
the
soap
perfect.
Okay,
it
looks
like
it's
been
diagnosed
so
and
I
think
this
is
probably
the
alternative.
A
No
maybe
not
okay,
but
anyways.
It
looks
like
this
has
been
diagnosed.
Basically,
what
was
happening
was
the
the
the
Qbert
test
or
the
performance
test
is
timing.
Out,
like
you
can
see
here,
the
test
was
taken
21
minutes
and
then
also
went
to
45
minutes.
So
I
had
some
heads
I
didn't
dive
into
this
too
much,
but
had
something
to
do
with
the
way.
We're
cleaning
up
events
so
looks
like
this
core
Quest
will
will
handle
it.
So
that
way,
we're
not
timing
out
constantly.
A
A
All
right
La,
what
do
we
have
left
for
this?
A
bunch
of
things
merged.
B
Yeah
so
I
think
we've
marched
the
periodic
jobs
for
scraping
the
data
which
is
in
the
nice
to
have
section
0.1.
B
B
So
something
happened
with
the
run
on
zero,
six
fourteen
that
it
had
to
do
it
twice.
That
is
when
Daniel
was
running
this
thing
manually,
so
I
assume
it
was
some
failure,
but
from
there
we
had
the
first
successful
run
on
Tuesday
last.
A
B
Yeah,
so
that
part
of
automation
is
working
as
expected,
so
we
are
getting
the
data
into
this
repository
now
up
next,
what
we
need
well
before
we
go
to
the
next
I've
also
took
the
time
to
set
up
the
GitHub
Pages
for
this,
so
the
the
links
below
yeah
those
are
actually
redirected
from
the
past
scale.
Repository
and
index.html
is
what
is
being
rendered.
B
It
yeah
it's:
if
you
go
to
the
weekly
section
and
then
yeah
the.
B
The
data
okay,
so
if
you
notice
this
is
from
two
weeks
ago,
so
what
is
happening
currently
is
that
the
automation
is
only
doing
part
of
the
job
which
is
scraping
the
data.
We
need
one
more
set
of
automation
to
plot
graphs
from
this
script
data,
so
that
is
the
next
part
that
will
need
help
from
as.
A
B
Yeah
so
I
think
that's
the
updates.
I
have
up
next
I
will
I
think
next
week.
I
will
work
on
screenshotting
these
data
manually
and
putting
it
into
the
document.
Repository
in
keyboard
should
open
a
PR
sometime
next
week
for
us
to
review.
A
B
Okay
and
one
more
thing
I
wanted
to
bring
up,
is
that
in
my
local
development,
environment
I
have
the
plots
up
to
June
12th.
So
what
I
was
thinking
is,
if
you
go
back
to
that
performance,
Repository
and
then
one
of
the
weekly
index.html.
B
Yeah
so
I
have
data
up
to
June
12th,
which
was
right
before
the
branch,
and
what
I
can
do
is
instead
of
this
index.html,
which
will
be
the
current
main
branch.
Tracking
I
can
do
a
V1,
Dot
index.html
and
commit
it
there.
So
that
way,
it
will
still
be
available
via
this
GitHub
Pages
website,
and
we
should
have
both
main
as
well
as
version
plots
going
forward.
A
Okay,
so
we
can
just
we
can
Index
this
with
a
with
a
V1,
okay
yeah.
So
what
we
were
saying
is
like
we
have
you
create
a
new
directory
right
and
then
bv1.
A
That
render
still
in
the
in
the
will
that
surrender
in
the
git
page.
B
Yeah,
we
would
have
to
explicitly
stay
V1
dot
index.html,
so
we'll
have
to
do
like
fully
qualified
path,
but
that
would
run
right.
C
B
A
I
guess
that's
okay,
I
mean
the
other
way.
Was
it
would
be?
Okay,
I
mean
I,
don't
know,
I,
don't
know
if
it
really
makes
matters,
but
like
you
could
do
a
you
could
have
your
your
directory
with
the
one
in
here
and
then
just
tag
it
in
the
next
HTML
too,
and
then
we
just
leave
one
of
the
top
level
for
the
latest.
A
I
guess
what
I
think
about
is
like
if
we
got
10
of
these
I
mean
it
works.
I
don't
know
like
it
doesn't
matter,
and
this
is
just
to
a
preference,
I
think
like.
C
A
Because,
let's
put
it
this
way,
I
mean
very
minor
but
like
if
I
were
to
go
to
this
webpage
like
and
I
wanted
to
go
to
the
V1
thing
like
yeah
I
mean
I,
guess
I
would
just
do
this,
yeah
I,
don't
know
I
mean
you
could
still
do
your
way
too
right,
which
just
means
we'll
do
yeah.
B
A
Let's
keep
it
around
for
sure
I
guess
it
doesn't
matter
whatever
you
want
to
call
it's
fine.
We
can.
We
find
a
problem
with
it.
We
can
always
move
it
into
a
directory
yeah
if
we
don't
like
it.
So
it's
fine,
okay,
cool
all
right,
so
we've
got
some.
So
we've
got
our
data
all
right,
so
cool!
That's
that's!
Some
good
progress!
A
Okay,
so
these
for
these,
for
the
documents
could
ideally
we'd
get
this
in.
So
we
want
to
get
this
in
we're
going
to
get
in
before
the
release,
because
otherwise
it's
going
to
get
into
like
a
it,
would
be
in
the
next.
The
next
one
like
it
would
be
in
Well,
we'd
have
to
cherry
pick
it
back
and
then
it
would
be
and
then
another
tag.
So
we
want
to
be
it.
We
want
to
get
it.
We
want
to
do
the
back
Port
before
the
before
the
1-0
tag.
B
That
should
not
be
a
problem.
All
okay
I
would
hopefully
have
it
for
us
before
the
next
Community
call
this
one.
A
C
A
Sooner
you
get
this
like
Monday
Tuesday
next
week.
Let's
blast
this
around
and
I
think
next
Wednesday
I'm
talking
with
the
some
of
the
maintainers
so
I
have
this
on
my
list
for
everyone.
I'm
pretty
sure
right
did
I
put
this
on.
C
A
P1
I
think
I
do
and
as
long
as
it's
there
yeah
here,
we
go
okay
as
long
as
it's
here
then
I'll
mention
this
as
well,
so
so
try
to
have
this
before
I
think
it's
Wednesday
and
we
were
talking
to
the
maintainers
okay,
yeah.
B
Community
call
next
Wednesday.
C
A
Yeah
bring
if
you,
if
you
want
to
bring
it
up
there,
go
ahead
like
but
I'll
I'll
talk
to
like
a
like
Roman
I
should
be
I
should
be
talking
to
Roman
and
than
probably
David,
and
so
we
should
be
able,
if,
if
we
don't
have,
if
it's
not
approved
by
Wednesday
I
think
you
know,
I'll
mention
it
and
get
it
approved
really
quickly.
D
A
All
right
anything
else
to
lay
first
scale,
V1
I
think
we
were
looking
good
like
I,
think
the
screenshots
right.
That's
all
we
wanted
and
then
in
the
blog
as
well,
I
still
I
have
not
I,
don't
think
anything's
been
a
lot
has
been
written.
So
we
can.
Let's
collaborate
on
this,
probably.
A
After
the
fourth,
like,
it's
gonna,
be
after
the
release
that
we
want
to
have
this,
that
I'll
double.
Let
me
double
check,
because
I'm
I'm
at
least
I,
don't
think
this
is
gonna
go
out
the
same
day.
Let
me
just
double
check,
but
that's
the
case
and
then
we'll
figure
out
what
we
need
to
talk
about
this.
B
A
B
Yeah
I,
don't
think
that's
needed
for
for
the
V1
release,
so
we
still
have
time,
but
I
wanted
to
put
it
on
the
radar
so
that,
as
as
they
have
time,
they
can.
You
know,
help
us
yeah.
A
B
C
A
Cool
okay,
well
we're
close
to
the
to
having
the
to
having
this
in
V1.
This
is
exciting,
so
it's
awesome
to
see
all
right
all
right.
We're
gonna!
Do
this
again!
I'm
going
to
talk
about
these
phase
transition,
timestamp
document,
so
we're
gonna
present
this
afternoon.
I
thought
we
were
gonna
present
two
weeks
ago,
but
I
think
that
it
wasn't
on
the
schedule
long
enough
in
advance,
so
people
didn't
show
up
to
the
meeting.
A
So
now
we
know
it's
on
the
schedule
for
this
Thursday
I
even
sent
over
to
towards
Texas
to
give
them
a
heads
up
too.
So,
hopefully
we
get
a
good
attendance
and
we
can
get
some
feedback.
A
I
made
some
changes
pretty
much
like
the
the
focus
has
shifted
a
little
bit
and
and
instead
of
centering
around
like
I
think
before
we
talked
about
like
I.
Let's
talk
about
volumes
and
other
things
like
I'm,
just
centering
it
around
the
the
idea
of
the
phase
transition
time
stamp
and
really
the
difference
between
this
phase
transition
timestamp
and
the
existing
metrics
I.
A
Think
that
what
really
highlights
the
points
that
we're
trying
to
do
here
so
I'm
just
going
to
go
to
that
section,
because
I
think
that's
really
the
the
meat
of
this.
So
when
you
look
at
the
metric
like
pod,
start
a
lot
of
durations
seconds,
it's
very
focused.
A
It's
captures
the
the
critical
phases
of
the
Pod
startup
time,
so
those
are
like
the
things
that
we
believe
are
going
to
influence
the
part
of
the
Pod
startup
time,
but
are
in
control
of
kubernetes
like
that
are
totally
within
the
code
base
within
the
cubelet
and
whatnot,
and
it's
not
influenced
by
outside
things
like
pulling
images.
It's
not
it's
not
influenced
by
things
like
any
containers
and
other
stuff.
So
now
that's
now
that's
important
right.
That's
what
sort
of
makes
this
useful
for
for
isolating
the
the
Pod
start
time
within
a
component.
A
What
we're
proposing
with
phase
transition
timestamps
is
about
talking
or
exposing
the
the
high
level
I
guess
you
could
say
transitions
an
object
goes
through
and
and
how
it's
affected
by
all
of
the
outside
forces,
so
that
someone
with
a
custom
cluster
can
understand
what
it
is.
Their
product
is
going
through
where
it's
slow,
where
it's
fast,
and
so
they
can
understand
how
to
adjust
things.
A
So
things
like
use
cases
would
be
like
we
have
a
hardware
problem
that
can
be
a
very
easily
thing.
That's
diagnosable!
When
you
see
that
okay,
we
are
taking
a
long
time
to
and
I'll
say
it
was
something
to
do
with
any
containers
to
start
to
start
our
inner
containers.
Because
of
this,
this
phase
transition
right,
that's
something
we
wouldn't
see
in
this
in
this
SLA,
but
we
want
to
see
in
these
phase
transition
time
stamps
yeah
go
ahead
and
check.
D
Yeah
I
think
your
explanation
makes
sense,
so
I'm
just
trying
to
understand
the
new
metrics
that
we're
proposing
pop
face
transition
time
from
equation
seconds
Does.
It
include
like
the
like,
like
the
outside
forces
that
you
mentioned
previously,
such
as
Plumbing
images
like
I'm,
just
trying
to
understand
because,
like
on
a
like
on
a
first
paragraph,
I'm,
seeing
that
the
part
the
past
start
SLI
duration
seconds
does
not
does
not
like
it's
not
influenced
by
forces
outside
of
the
control
of
kubernetes
like
pulling
images.
D
So
as
a
contrary
to
this
statement,
the
new
metrics
should
consider
these
forces
right
so
I'm,
just
so
I'm
just
trying
to
make
sense.
How
is
the
new
metrics
part
phase
transition
time,
foundations
we'll
consider
these
forces
if
we
are
like
if
we
are
pulling
the
above
paragraph
right
next
to
this
part,
new
Matrix
down
below.
C
A
So
things
are
pending
and
like
these
phases,
this
stuff
is
like
this
is
like
the
Pod
getting
ready
like
it's
not
scheduled,
or
anything
like
that.
So
this
should
include
things
like
the
inner
container
pulling
images
all
this
other
stuff.
A
The
scheduler
hasn't
worked
on
it.
Yet
anything.
Any
of
this
stuff,
like
from
pending
to
running,
is
going
to
conclude
all
of
that
stuff
that
where
we
have
to
pull
the
invention
running.
D
D
So
from
my
impression
of
of
the
name
of
the
new
Matrix
that
we're
proposing
this
Matrix
might
not
like
it
might
not
be
able
to
capture
stuff
like
pulling
images
at
a
very
at
a
very
granular
detail,
right
like
which
is
fine,
because
you
know,
because
the
scope
of
this
Matrix,
as
it's
just
by
name,
probably
won't
cover
these.
D
But
if
we
are
going
to
explicitly
mention
that
we
want
to
consider
forces
like
pulling
images,
but
the
new
Matrix
doesn't
doesn't
immediately
address
this
problem
and
I
concern
that
the
reaction
from
Community
would
be
confused.
D
Just
you
know
just
like
similar
to
how
I
reacted
saying
that
okay,
we
are
proposing
this.
This
new
metrics
as
like
as
a
way
to
solve
the
like,
like
the
statement
that
you
propose
in
a
previous
paragraph
such
as
you
know,
you
want
to
see
the
time
in
images,
but,
however,
this
new
Matrix
does
not
show
on
that.
So
perhaps.
D
A
A
Part
because,
like
I,
think
the
the
so
what
what
exists
today
like
this
is
where,
like
we
do,
have
a
way
to
measure
how
long
it
takes
to
pull
the
image
today,
I,
we
didn't
find
anything,
wait
how
well?
How
do
you?
What
do
you
do.
D
It's
not
really
a
measurement,
so
when
you
do
Coop
CTO
disk
light
pod,
if
like,
if
the
pawn
needs
to
pull
the
image,
it
should
show
on
the
event
but
I'm
not
sure
if
that's
a
metrics,
that
we
are
publishing.
A
Right.
Okay,
so
that's
that's!
Actually
what
that's
exactly
the
point
that,
like
what
did
you
have
to
do
to
figure
this
out
right?
You
had
to
then
run
a
a
cube,
a
client
command
reach
out
to
the
API,
scrape
it
and
then
and
then
then
what
then
you
have
to
what
put
it
into
an
Excel
spreadsheet
and
then
do.
A
Yeah
exactly
so
so,
like
you
see
where
this
is
becomes
a
problem,
so
now
this
isn't
specifically
about
pulling
image
time.
It's.
That
is
one
example
that
is
not
included
and
there's
in
terms
of
looking
at
the
overall
intent
time
and-
and
so
my
point
is,
is
that
all
those
little
pieces
right
we're
not
including
them?
So
what
we
can
do
is
we
can
include
them
and
what
we
must.
We
are
able
to
include
them.
Now.
A
What
and
we
have
the
metrics
to
expose
this,
we
can
start
giving
the
user
areas
that
they
can
focus
their
attention
to
so
it
could
be
like
oh
I
can
I
see
like
shang's
cluster,
his
shang's
homeless
collab
is
really
slow
from
from
pending
to
running.
So
what
happens
in
pending
to
running
like
we
can
list
those
things?
Maybe
it's
five
things:
okay,
he's
pulling
images
in
a
container
whatever
other
stuff
right.
A
So
now
we've
actually
isolated
this
down
more
than
what
we
were
doing
before,
which
is
which
is
what
like
I,
was
just
I,
would
have
to
watch
every
pull
every
container
in
my
cluster
and
try
and
figure
out
where
the
bottleneck
is
it's
not
really
scalable,
it's
not
even
I'm,
not
gonna.
It's
not
gonna
be
useful.
So
what
this
will
do
is
right.
A
You
could
say
like-
and
I
mentioned
this
in
the
definition
in
that,
where
phase
is
is
specific
to
status
space
field
but
and
the
reason
we
went
this
way
is
because
it
worked
really
well
with
Qbert
right
all
of
the
it
isolated
the
difference
between
cube
roots
control,
plane,
kubernetes
control
plane.
So
it
worked
really
well
for
solving
that
which
was
valuable
for
us,
but
it
may
not
be
that
valuable
for
some
of
the
core
apis,
in
which
case
this
needs
to
be
expanded,
so
I
totally
understand.
D
Yeah
yeah
I
understand.
B
D
Value
of
like
adding
these
metrics
but
like
I,
think
my
nitpick
was
you
know
like
because
previously
before
I
read
about
the
statements,
my
focus
was,
you
know
completely
on
the
volume
phase
transition
time
right,
but
by
saying
stuff
like
pulling
like
the
time
to
pull
images
like
from
the
from
the
paragraph.
That's
where
my
thoughts
start
to
think
hey
should
we
maybe
perhaps
try
to
include
more
as
well.
You
know
that
kind
of
distracted,
my
thoughts
of
like
focusing
on
part
a
little
bit.
D
So
so,
if
it
was
me
you
know
perhaps
I
wouldn't
I,
wouldn't
I,
wouldn't
like
mention
explicitly
on
like
on
stuff
like
pulling
like
images.
Just
I.
Don't
know
like
try
to
replace
it
with
something
like
generic,
such
as
you
know,
like
the
like
the
time
spent
before
buying
attachments
or
or
like
something
more
generic,
so
that
we
can
be
more
focused
on
the
like
on
the
Pod
timestamps.
Sorry
like
on
the
volume
time
steps.
A
Yeah
so
I
I
understand
like
we,
we
do
want
to
do
volume
stuff.
So
the
reason
I
mentioned
it
because
this
explicitly
says
it
does
not
include
the
stuff
where's
this
excluding
pull
images,
running,
containers
and
other
stuff
right.
It's
it's
explicitly
excluding
the
stuff
so
I'm
just
trying
to
highlight
the
contrast.
It's
like
we
we're
saying
we
don't
want
to
do
that
so
yeah
I
understand
where
you're
going
so
here's
shank,
where
I'm
thinking
like
to
your
point,
which
is
like
yeah.
A
We
want
to
expand
this
I'm
trying
to
keep
this
like
really
simple,
because
once
we
start
getting
into
like
like
I
I
could
see
this
this
column
expanding
quite
a
bit.
We
can
get
to
volumes
and
other
stuff,
but
I
want
to
see
if
we
can,
if
this
makes
sense,
just
for
the
base
case
of
of
a
pod
and
and
just
explaining
it.
A
This
way,
let's
see
if
Upstream,
can
can
at
least
attach
to
the
idea-
and
let's
see
if
we
get
some
traction
that
way,
because
I
think
if
we
can
get
it
some
traction
this
way,
I
think
he
really
opens
the
door
for
us
to
look
at
this
and
other
perspectives
like
including
volumes
and
other
stuff
and
I
I.
Think
there's
a
lot.
There's
like
a
huge
number
of
things
that
we
can.
We
can
expand
this
to
yeah.
B
That
makes
sense,
so
Ryan
I
heard
some
more
thoughts
on
this,
so
I
I
just
pasted
a
link
in
the
chat,
Cube
straight
metrics
is
and
a
project
which
already
has
a
coupon
status
phase
metric.
B
If
you
scroll
down
yeah
there,
it
is-
and
this
one
has
all
the
phrases
so
pending
running
completed
all
of
those
it's
in
the
right
section,
the
the
right
most
column.
So
questions
from
this
is
that
have
you
had
a
chance
to
explore
this
whether
this
works
for
us?
C
B
B
Okay,
even
if
this
goes
up
and
down
that's
what
will
help
right
now,
so
we
could
get
like
a
rate
of
pods
in
pending
State
and
rate
of
parts
in
running
State
and
if
the
rate
is
going
down,
that
means
pods
are
transitioning
to
running.
Instead,
there's
the
like
I'm
trying
to
think
how
the
proposed
metric
is
different
from
from
this.
D
If
you
are
creating
stuff
like
in
the
background,
so
let's
say
you
want
to
see
the
rate
of
going
from
one
state
to
another,
but
there
could
be
some
outside
forces,
that's
influencing
a
radar.
So,
for
example,
you
want
to
see,
like
the
rate
from
from
Penning
state,
to
schedule
state,
for
example,
but
let's
say
there's
a
background
test.
That's
constantly
deleting
the
pots
the
entaco
student.
A
Yeah,
but
that
I
think
that
can
happen
in
all
cases,
though
I
think
that
the
problem
is
that
we
have
to
figure
out
so
the
rate
going.
So
the
rate
that
this
is
increasing
are
decreasing.
A
B
Yeah,
so
you
do
not
give
us
like
P95
of
creation
to
running
like
we
get
in
keyboard,
okay,
so
that
makes
sense.
Then
the
next
question
is
that
the
the
phases
of
a
bar
are
only
restrictive
to
pending,
running
and
and
failed,
which
is
very
high
level.
So
are
you
proposing
that
the
metric
will
have
much
more
fine-grained
fine
grain
labels,
which
which
include
other
details
like
image,
pooled
scheduled?
A
Yeah
I'm
not
I,
think
the
way
I'm
looking
at
this
is
actually
to
go
about
this
as
the
eye
level.
I
think
that's
to
me.
That
seems
to
be
the
easiest
on-ramp.
However,
if
if
it's,
if
it's
not
useful
enough-
or
we
just
think
we
can
do
better,
then
we
can
do
better.
I
mean
I.
This
is
really
easy
to
expand
this
idea
to
to.
Like
think
of
this
way,
it's
really
easy
to
expand
this
idea
to
actually
replace
this.
A
Right,
because
this
is
this
is
exactly
what
we're
proposing
this
there's
actually
no
difference
between
this
and
this.
The
only
thing
that
this
does
is
this
is
isolating
one
little
critical
point
in
time.
We
wanna
we
wanna.
What
we
couldn't
technically
do
is
is
put
time
stamps
on
all
of
the
critical
points
in
time,
which
would
include
this
one.
A
So
I'm
saying
the
critical
points
in
time
or
the
phase
transitions,
but
maybe
that's
not
granular
left,
I
I,
think
it
decently
I
think
it's
decently,
granule
enough,
like
I,
think
it's
I
think
it's
pretty
helpful,
but
you
know
I,
think
it
just
like
at
least
the
way
I'm
approaching.
This
is
that
this
doesn't
prevent
us
from
being
more
granular.
It's
just
sort
of
the
ideas
is
I
think
makes
sense,
speak
from
from
a
user
perspective.
Users
are
familiar
with
these
phases.
A
I
think
I
think
there's
value
in
seeing
the
transition
between
them,
but,
like
I,
said
it's
not
useful
for
every
API,
maybe
maybe
it's
not
server
API
but
I
think
for
pods.
It
would
be.
B
I'm,
not
sure
if
we
can
find
that
detail,
because,
okay,
that
we
could
see
that
the
board
spent
more
time
in
pending
phase
because
it's
pulling
the
image
but
pending
phase
could
have
all
the
other
things
it
needs
to
do
where
the
time
was
spent
right
or.
A
Could
have
been
you're
right,
and
so
when
I'd
say
is.
That
is
that
that,
yes,
you,
you
can't
isolate
just
the
to
the
granularity
level
of
how
long
it
takes
the
pulling
an
image.
However,
you
can,
if
you
you
could
lower
the
you
can
isolate
the
the
things
that
could
be
down
to
a
much
smaller
list.
A
If
you
noticed
tending
to
running
time,
was
your
bottleneck,
there's
only
so
many
things
that
are
happening
there,
and
so,
if
you're,
the
user
like
this
is
one
of
the
places
you
could
look
and-
and
this
is
where
I
think
it
would
get
obvious
where
like.
If
you
start
seeing
this,
oh
okay,
this
is
taking
a
long
time.
A
Let's
start
investigating
a
few
things,
let's,
let's
say
they
have
a
lot
of
change
to
a
local
registry.
You
want
to
say
that's
a
big
Improvement.
It
should
be
noticeable
right.
We
should
see
the
pending
to
to
running
time.
Go
down,
so
we
should
see
some,
so
we
can
already
see
the
Improvement.
So
that's
that's!
Where
we'll
see
the
feedback
so
I
agree
with
you,
you're
not
like
going
to
get
the
granularity
that
it's
obvious
to
the
user.
I
guess
maybe
that's
the
point.
A
B
Yeah
I
I
understand
that
part,
but
the
problem
with
phase
is
that
going
from
spending
to
running
there's
just
one
transition
right.
So
let's
say
if
your
overall
metric
is
creation,
time
stamp
to
running
you,
which
is
60
seconds
and
then
creation
time
stamp
to
pending
and
then
from
pending
to
running,
then
then
that
will
also
be
60
seconds
right.
So
from
creation
timestamp
to
pending
will
be
zero
because,
as
soon
as
a
pod
is
created,
it
is
accepted
as
impending
State
and
then
from
there.
It
will
go
to
running
state.
B
So
what
I'm
trying
to
figure
out
is
what
is
the
value
add
in
in
this
additional
pending
state?
If
all
that
it
means
is
that
it's
capturing
one
more
phase,
but
but
the
actual
value
will
be
the
same.
A
C
A
Yeah
I
mean
I
think
what
you're
saying
is
that
it's
not
it's
not
granular
enough
to
it's,
not
granule
enough
I
mean
maybe
there's.
A
There's
like
other
stuff
yeah
like
the
scheduler
posts,
something
when
it
says
it's
actually
done
scheduling.
It's
not
really
a
it's
like
a
I,
don't
know
yeah,
it's
not
really
a
it's,
not
in
the
phase.
B
D
I
feel,
like
scheduling
stage,
should
be
included
in
the
face
so
that
we
can
have
some
granite
granularity.
Well,.
A
So
I
yeah
I,
agree,
I,
I
actually
think
this
is
the
discussion
we
want
to
have.
Okay,
I.
Think,
like
you
know
what
I
mean
like
I
think
I.
This
is
exactly
the
discussion
I
want
to
have
with
in
the
in
the
in
the
Upstream
sixth
scale,
because
to
me
this
is
like,
like
we're
getting
opinions
here
from
like
how
granular
this
should
be,
which
is
where
we
want
to
go
I,
I,
guess
what
I'm
trying
to
say
is.
This
doesn't
have
to
be
perfect.
A
A
B
Yeah,
okay,
so
I
think
that
perspective
makes
sense
just
wanted
to
know.
What's
our
opinion
right,
so
what
I'm
trying
to
do
it
is
between
the
three
of
us
or
or
between
this
community,
try
to
align
on
end
opinion,
so
we
could.
We
could
present
that
as
well
along
with
this.
So
at
least
my
understanding
is
that
we
should
identify
the
big,
the
the
biggest
things
that
we
need
right,
so
volume
attachment
time
scheduling,
Time
network
attachment
time.
B
Those
are
like
three
I
could
think
of
right
at
the
top
of
my
head
and
find
a
way
to
add
that
somewhere
in
this
in
this
metric,
adding
if
we,
if
we
have
a
way
to
filter
that,
then
it
will
be
much
more
valuable
metric
for
for
breaking
down
this
start.
Sli
duration,
yeah.
A
No
I
agree
that
makes
perfect
sense
to
me.
Maybe
that's
what
you're
saying
earlier
saying
is
that
you
wanted
to
you
wanted
to
see
like
we
wanted
to
get
to
a
point
that
we
start
seeing
the
volume
attachment.
D
Here
and
and
I
kind
of
have
a
feeling
that
see
that
we
proposed
this
and
then
we
go
ahead
and
propose,
we
should
add
more
faces.
So,
for
example,
perhaps
we
can't
even
tell
the
community
or
even
propose
to
the
community,
think
that
you
know
we
need
a
scheduling
phase
we
need
I,
don't
know
like.
Maybe
we
need
like
an
image,
Plumbing
piece
for
example.
Then
then,
one
of
the
possible
reactions
that
I
can
anticipate
from
the
community.
D
Is
that
say
if
you
want
to
know
the
scheduling
time
thoughts
in
general
and
you
can
just
scrape
the
scheduling,
metrics
right,
you
can
just
scrape
the
metrics
from
scheduler
and
see
the
scheduling,
metrics
around
schedule,
and
perhaps
similarly
they
will
also
say.
If
you
want
to
you,
know,
see
the
volume
attachment
metrics
they
can
be
like
there.
You
can
you
know,
then
you
can
pull
the
metrics
on
your
CSI
and
then
the
CSI
should
tell
you
all
these
measures.
B
Sure
so
I
think
there
is
one
gap
which
those
metrics
don't
address,
so
the
CSI
will
give
you
metrics
for
binding
the
the
or
for
actually
provisioning
the
volume
right,
but
it
does
not
have
Well
I.
This
is
an
open
question.
Does
it
have
visibility
on
how
much
time
cubelet
takes
to
actually
Mount
that
volume.
D
No,
but
like
my
point,
is
that
you
know
the
community
and
like
like
the
community's
reaction,
can
can
be
like
instead
of
adding
these
metrics
on
the
kubernetes
core
projects
such
as
party
stuff,
they
can
be
like
you
know,
we
can
add
these
metrics
to
the
third
party
plugins
that
we
are
doing,
and
then
we
can
piece
these
metrics
together
and
then
that
can
give
us
something
similar
to
what
we
want.
D
So
you
know
so
so
to
answer
your
question
directly
CSI,
you
know
they
know
how
long
it
takes
to
provision
to
to
permission
the
volume,
but
it
doesn't
really
have
visibility
on
the
API
service
side
or
on
a
Google
site,
but
the
command
that
the
community
can
be
like.
You
know
you
can
like
you,
can
have
the
assigned
Matrix
on
one
side
and
then
you
can
have
complete
or
API
server.
You
know
like
metrics
on
the
other
side,
if
you
piece
them
together,
then
you
can
have.
D
B
Yeah
I
I
see
your
concern.
I
think
I
think
we
can.
We
might
be
able
to
address
that
if
we
identify
this
Gap,
so
I
think
what
what,
at
the
end
of
the
day,
what
we're
trying
to
do
is
enhance
tubelets
performance
right.
B
How
fast
can
cubelet
go,
can
take
a
part
and
go
make
it
into
running
state
and
the
way
we
are
trying
to
do
that
is
by
identifying
or
giving
visibility
to
users
into
some
metrics.
So
if
we
can
share
this
goal
to
the
scalability
Community
call
and
then
from
that
goal,
explain
that
these
are
the
gaps
in
The,
cubelet
Matrix
or
in
in
X
Matrix.
That
would
really
help
achieve
this
goal.
I
think
we
we
could,
you
know
convince
the
community.
C
A
So
we
said
there
early,
it's
like
these
are
the
gaps
right,
the
that
that
is
what
the
message
I
want
to
convey
here
is
like
the
example
I'm
using
is
pulling
images,
but
I
don't
know.
Maybe
it's
a
better
way
to
say
this,
or
maybe
the
phase
transition
part
is
confusing.
I
I,
don't
know
like
that,
but
that's.
A
That
is
what
we
want
to
go
like
at
least
the
message
and
the
details
of
this
stuff
like
this
is
loose
like
I
was
saying
up
in
the
definitions:
we're
not
tied
to
phase
we
want
to
what
we
want
to
do
is
I.
Think
a
better
way
to
put
this
is
expose
the
gap
between
something
like
this
and
the
rest
of
the
stuff
that
we're
missing,
which
is
like
pulling
images
of
stuff
like
we're
missing.
All
of
this.
A
A
D
Oh
yeah,
I
kind
of
just
want
to
throw
it
out,
like
maybe
an
alternative
idea
on
how
we
can
approach
this
so
instead
of
proposing
a
new
metrics,
do
you
think
it
will
be
like?
Can
we
perhaps
get
more
attractions
if
we
propose
new
faces
first,
so
yeah.
A
Because
that's
going
to
be
that's
gonna
be
hard,
I
I,
don't
think
that
would
be
a
ton
of
work.
I
think
like
all
right,
all
right.
First
yeah,
all
right,
I
think
what
we,
if
we
I-
and
this
is
I-
think
this
is
sort
of
the
this
is
like
we're
getting
to
the
pitfall
of
using
face,
which
is,
which
is
why
I
have
a
definition
up
there,
because
it
is,
it
is
very
even
to
Lay's
point
right
like
pending.
The
scheduling
is
going
to
be
like
99
of
the
time
right.
A
So
what
is
the
point
right?
So
it's
not
very.
These
phases
may
not
suffice
in
terms
of
what
we're
trying
to
accomplish.
So
maybe
we
need
to
look
at
something
other
than
phase,
and
that's
okay,
but
I
I,
don't
think
the
path
of
going
creating
more
phases
is
the
right
thing.
I
think
what
we
can
do
is
sort
of
create
artificial
phases
and
be
like
hey
like
this
is
a
phase
right.
This
is
a
odd
start,
SLA
phase
or
about
sort
of
Select
duration
phase
right.
B
What
I
was
trying
to
say
earlier
was
very
similar
along.
This
line
is
that
there
are
two
things
that
convey
information
in
the
Pod
API.
One
is
this
space,
which
is
high
level
thing,
and
then
the
other
is
other.
Two
things
are
conditions
and
events,
so
those
actually
to
Shanks
Point
those
end
up
being
in
cube
cutter
describe
output.
B
So
if
we
can
find
a
list
of
all
the
events
or
conditions
that
appear
before
pod
goes
to
running
State
and
just
plug
our
transition
time
or
metric
into
those
into
those
State
change,
then
I
think
we
should
be
able
to
achieve
the
level
of
granularity
we
want.
So
what
I
was
trying
to
say
is
if
we
can
go
through
those
conditions
and
and
events
and
find
out
like
four
or
five
important
ones,
we
can
bring
it
as
potential
gaps
and
and
propose
this.
A
Yeah,
okay,
so
maybe
what
I
can
do
is
like
so
I
I
think
what
what
I
want
to
do
with
this
one
is
like
I,
I
I
think
this
illustrates.
At
least
there
is
a
gap
between
there's
a
difference
between
these
two
things
right.
This
is
a
little
too
high
level,
I
think
what
we're
getting
at
and
I
think
we're
we're
sort
of
proving
that
how
we're
proving
that
out
here.
This
is
too
low
level.
A
So
let
me
see
if
I
can,
like
you
said,
let
me
see
if
I
can
grab
some
conditions
and
I'll.
Let
me
just
add
them
as
a
list
of
here
as
suggestions
that,
like
or
I
guess,
alternatives
to
phase
that
we
could
look
at
and
then
maybe
that
can
be
sort
of
the
way
we
can
springboard
the
conversation
past
phase.
If
we
get
stuck
here,
you
know
on
these.
C
A
Something
like
that,
because
I'm
not
gonna
have
enough
time
to
go
through
and
like
deep
dive
into
all
these
things
and
get
like
all
of
them,
so
I
I
I'd.
Rather
we
like
when
we're
on
a
key
hold
on
to
phase
the
way
it
is
now
we
can.
You
know
we
can
adapt
all
right.
Let
me
have
a
section
for
this.
I
think
this
should
be
easy
to
get
we'll
just
get
some.
Let's
grab
some
conditions.
A
D
B
Yeah
they're,
not
unlike
Facebook
conditions,
are
more
State
machines,
but
for
events
we'll
have
to
infer
so
the
code
path
that
resists
those
events
will
have
to
infer
somehow
these
trade
transition,
so
the
implementation
will
be
challenging
but
I.
This
conveys
the
idea.
I
guess.
A
B
C
D
A
B
Then
you
already
have
the
add
interface,
then
I
see
pulled
so
that's
image
pulled
right
and
created
and
started.
A
Something
like
that:
okay,
yeah
and
then
okay,
so
that
would
be
so
that
probably
isn't
running
phase
either.
That's
probably
we
could
probably
need
running
to
on
the
end
of
this.
So.
A
A
Okay,
so
it's
already
all
right
so.
A
B
Okay
and
then,
if
you
want
to
capture
the
conditions
there
are
couple
here
as
well
to
be
initialized
is
when
the
edit
container
completed.
A
A
B
Ready
so
I
think
that
is
for
the
board.
Okay
and
then
board
scheduled.
D
The
conditions
are
strictly
in
order,
but
the
events
are
not
strictly
over
so
for
events,
I
think
I
think
these
these
events
can
happen
at
any
order
before
the
plot
goes
to
red.
B
A
I
guess
well,
so
if
these
aren't
ordered,
then.
A
Yeah
it
actually,
it
doesn't
well,
essentially
the
order
doesn't
necessarily
matter
I
guess
as
long
as
we
don't
go
backwards.
As
long
as
we
don't
go
from
scheduled,
successful
volume
attached
to
like
edit
interface
back
to
this
one,
it
doesn't
really
matter
because
we're
just
going
to
get
the
time
spent
in
each
of
them
and
then
so
that
actually
doesn't
make
a
difference.
D
A
Okay,
this
is
good
I
think
this
gives
us
like.
So
if
we
need
to
go
to
this
little
granularity
here
here,
we
go
as
another
example:
yeah,
okay,
cool
all
right,
I
think
this
is
good
all
right.
Well,
so,
let's
we're
a
time.
So
this
is
what
the
plan
will
be
for
this
afternoon.
We'll
talk
about
this
and
see
what
we
get.