►
From YouTube: 2016-09-15 Kubernetes SIG Scaling - Weekly Meeting
Description
2016-09-15 Kubernetes SIG Scaling - Weekly Meeting
A
Great,
so
this
is
the
public
meeting
of
committees,
6k
laying
September,
15,
2016
and
I
think
we
were
just
about
to
discuss
agenda
item
so
so
so
one
item,
one
item
is
that
I
think
will
towards
the
end.
David
wanted
to
give
a
demo
of
the
staff
dump
look
we're
working
on,
and
then
tim
has
a
Kim
at
an
item
about.
He
wanted
to
talk
about
just
now,
which
was
splitting
performance
tests
separately
from
functional
tests.
Perhaps
would
be
the
way
to
say
it
well.
B
That
the
intent
test
suite
is
basically
like
a
lump
of
things.
That
kind
of
has
a
roll
up
of
everything,
and
we
did
it
for
expedience
in
the
past.
But
the
question
I
wanted
to
raise
was
whether
or
not
we
wanted
to
have
a
separate
set
of
test
suite
specifically
geared
towards
these
longer-term
performance
tests,
because
right
now
we
only
have
a
small
subset
of
things
right.
B
We
haven't
really
added
much
sense
over
the
last
couple
of
these
cycles,
but
we
would
like
to
add
more
and
we
don't
necessarily
think
the
existing
in
ten
test.
Suite
is
the
place
to
add
them,
because
we
don't
want
them
executed
on
a
/
PR
basis,
it's
kind
of
like
how
note
n
tends
broke
off
their
own
thing.
It's
a
similar
question,
I
guess
I.
C
D
My
thoughts
about
it
is
that,
like
basically
performance
tests,
we
can
run
them
on
very
small
cluster,
which
actually
doesn't
make
much
sense,
and
we
can
draw
out
at
random
a
large
cluster
which
is
like
way
too
expensive
to
optimal
every
single
PR.
Yes,
so
basically
we
have
like
internally
suits
that
are
running
performance.
That's
obviously
like
there
are
not
many
of
them,
and
if
we
have
more
of
them,
it
would
be
great
and,
like
day
should
be
blocking
merges
soon.
D
C
D
Other
words
like
bjork,
like
kindred,
is
already
like
part
of
like
it's
running
every
whatever
hour
or
something
like
that,
and
it
gives
pretty
pretty
good
results
like
basically
and
they
it's
part
of
like
it's
non
blocking.
But
it's
like
unmarked
you
you
can
like
look
there,
look
at
the
results
from
this
for
in
the
merge
queue
or
submit
q
page
so
I
think.
C
Part
of
it,
if
we
don't
do
it
on
every
PR,
though
doing
something
such
that
when
it
does,
you
know,
go
above
some
threshold,
we
actually
started.
Learning
people
I
think
would
be
useful.
Also
I
mean
otherwise.
It's
too
easy
to
ignore
that
stuff.
I
mean
that
the
nice
thing
about
going
in
every
PR
is
that
if
stuff
starts
break
in
like
people
notice
cuz,
they
can't
get
work
done.
No
I
think
like
marriage
about
actually
is
filing.
E
B
E
B
F
F
F
F
C
C
C
C
G
H
I'm
going
to
start
from
it.
Well
sorry,
the
first
thing
I'm
going
to
do
is
define
my
environment
is
briefly
one
of
the
things
to
note
about
the
finding
your
environment.
Is
it's
really
important
to
this
that
you
capture
the
start
and
stop
time
of
the
run?
The
reason
is,
is
if
you
query
past
or
before
the
start
time
or
pass
the
end
time,
and
your
window
is
too
large,
it
will
actually
prepare
no
data.
H
H
C
H
Okay,
so
you
can
see
it's
up
and
it's
flaking
metrics
as
of
a
couple
seconds
ago,
great
so
here
I
document
how
to
configure
the
database.
You
want
me
to
do
that
because
earlier
so
the
next
thing
we
want
to
do
is
actually
capture
the
data.
So
first
you're
going
to
stop
ref
do
this
by
just
sending
the
signature
to
dot
5
container.
G
H
C
H
G
H
H
H
So
the
next
part
is
we
actually,
we
query
that
database
with
our
spark
lines,
and
we
end
up
with
we
end
up
with
a
JSON
record
that
contains
values
which
are
a
list
of
lists.
Each
one
contains
a
timestamp,
add
value
and
in
this
case,
for
just
squirting
process
resident
memory.
Ok,
so
we've
saved
that
in
a
file.
H
Okay
and
then
we
can
open
that
file
and
process.
It
using
you
know
very
short,
pipe
on
notebooks,
so
in
this
case
we're
using
pandas.
We
can
basically
just
load
that
JSON
file
online
and
then
using
Boko.
We
can
plot
it
in
a
single
line.
In
this
case,
we
don't
have
a
particularly
interesting
graph
with
rolling.
H
Over
one
hour,
one
hour,
the
averages,
but
it's
linear.
So
so
that's
a
that's
in
an
ad
hoc
way
to
be
able
to
do
this
analysis
in
the
future.
We,
so
there
are
basically
three
ways
that
we
we
viewed
as
data
being
used.
One
is
once
that
is
backed
up
to
be
able
to
view
its
using
Ravana.
Again,
there
are
a
couple
of
caveats
you
need
to
know
about
trying
to
do
with
Ravana
on
a
backup,
theist
or
one
is
that
the
time
has
to
be
specified
properly.
H
So
you
need
to
remember
the
time
we
back
up.
Another
is
that
profondo
may
not
be
aware
of
Prometheus
restarting
so
you
may
need
to
be
start
or
fauna
in
order
for
its
recognize,
the
broken
connection
and
other
than
that,
you
should
be
able
to
be
used
for
fauna
to
to
view
those
real-time
dashboards
that
you
do
normally.
If
you
want
to
do
with
you
more
complicated,
we
have
just
what
I
just
showed,
which
is
a
simple
ipod,
ipod
notebook,
racking,
similar
value.
H
Since
the
data
frame
you
could
add
additional
columns
and
then,
finally,
you
could
use
something
like
a
help.
Staff
or
something
else
to
do
more,
sophisticated
searching
which
miss
does
not
allow,
and
then
my
Ling,
if
you
want
to
see
the
code
that
actually
emits
what
I
intended
to
demonstrate
their
watched
it
once
that
it's
here
there's
a
pull
request
from
Bracken,
and
it
contains
all
the
sense
that
I
have
just
I
thought
did
only
it
uses
to
control
instead
of
offer
and
then
finally,
the
this
dashboard
is.
The
dashboard
was
shown
in
the
past.
H
Dashboard
is
available
in
the
pull
request
for
cracking
services.
Here
we're
going
to
check
that
into
Griffin
about
net.
They
have
a
dashboard
pasa
for
e,
so
you
can
either
get
that
JSON
from
the
pull
request
or
see
it
show
up
on
the
phone
about
that.
So
that's
that's
all
I
had
for
today
are
there
any.
C
H
So
that's
the
ultimate
goal.
Right
now,
the
one
sees
I
showed
the
pool
request
once
those
floor
requests
are
merged,
there's
another
full
request
for
our
CI
system,
but
once
all
of
the
four
requested
our
side
are
emerging,
the
Kraken,
then
every
time
we
run
density
testing,
it
will
automatically
upload
your
fifth
data
as
part
of
our
test
results.
I
think
the
hope
is
that
we
also
up
late
upload
that
by
four
plot,
therefore,
a
federated
testing
as
well,
so
the
part
of
the
Federated
test
was
ultimately
share,
I
think
it
incorporating
it.
H
C
Okay,
if
you
run
this
pod
and
cube
system,
it's
able
to
actually
throw
it
in
any
Cooper
Nettie's
cluster
and
it's
able
to
actually
discover
enough
to
start
collecting,
interesting
data.
And
then
you
know
at
the
end,
you
tell
it
where
to
throw
that
data,
and
it
can
be,
you
know,
cloud
storage
pocket
or
you
can,
you
know,
have
it
go
into
some
sort
of
like
you
know,
you
know,
terminated,
waiting
for
download
state
where
it
serves
it
up
on
an
HTTP
endpoints.
C
H
C
Even
without
a
persistent
volume,
I
mean
you
could
use
it,
you
could
use
it
using
an
empty
directory
and
then
have
it
so
that
you
can,
you
know,
tell
it
to
stop
and
then
have
at
our
everything
up
and
then
just
wait
to
serve
that.
So
you
can
just
hit
it
to
download
it
and
then
and
then
then
have
it
quit
itself
out
right
sure
we
consider
doing
that.
H
C
Would
view
it
I
mean
I
would
view
it
as
as
maybe
as
a
as
a
as
a
job
right
I
mean
this
is
a
run
once
type
of
thing.
You
can
run
it
as
a
job
where
it'll
run
for
a
certain
amount
of
time
or
until
you
sort
of
poke
it
and
say:
hey
you
you're
done
now.
You
know
package
things
up
for
so
that
I
can.
I
can
get
it
you
know
and
do
analysis
later
now
we
can
take
it
offline,
just
some
ideas,
I'm
sort
of
like
you
know.
C
B
Is
the
reason
for
the
munching
because
we're
serving
up
Prometheus
metrics
in
the
Prometheus
matrix
format?
So
it
does
its
own
time
series
database
versus
json.
If,
if
we
were
to
serve
metrics,
be
a
JSON
which
is
totally
inefficient
but
useful
for
data
analysis?
Would
that
potentially
be
more
helpful
for
the
long-term
analytics
perspective?
So.
H
H
B
Yeah
I
was
taking
the
man
on
the
middle
so
instead
of
querying
prometheus
to
get
the
json
data
just
like
what
happens
if,
if
Cooper
Nettie's
itself
was
bring
up
json
base,
metrics
that
you
could
just
scrape
and
store
directly
into
something
like
elastic,
search
or
whatnot.
So
that
way
you
can
do
your
analytics
directly.
Would.
H
That
be
helpful,
this
is
a
question.
I
think
it'd
be
helpful.
The
only
thing
I
worry
about
is,
if
we're
duplicating
effort,
not
just
previous
but
keeps
dirt
so
part
of
the
advantage
of
using
something
like
keeps
produces,
that
you
get
metrics
that
perhaps
are
unrelated
to
Cooper
identities,
but
still
in
it
back
to
perform
to
the
system.
Yeah.
B
We
have
we
have
this
weird,
an
assistant
wide
level
like
there's.
There's
this
whole
meeting,
that's
after
this
meeting,
which
is
about
this
stuff.
We
have
this
whole
weird
many
metrics
problem,
that's
like
MacGyver.
Actually,
if
you,
you
combine
all
the
ways
we're
collecting
data
across
the
cluster,
so
I
I
almost
want
to
attend
the
next
one,
just
to
see
how
that
one's
shaping
up
right
now,
yeah.
H
C
H
C
Well,
very
cool:
are
you
thank
you
about
five
minutes
left
here.
Let's
see
so
Bob
I
know
that
you
are
going
to
be
disappearing
for
a
couple
of
weeks
into
stuff
in
Korea
right
that
is
correct
and
so
I
I'll
be
you
know.
I'll
still
be
around.
I
may
be
a
few
minutes
late
though.
So,
if
I
am
you
guys
can
feel
free
to
start
without
me,
I
have
to
drop
the
kiddo
off
and
I
have
to
run
back
home.
After
doing
that,
so
it's
a
close
thing.
The
bus
is
late.
C
C
So
that
a
note
on
zoom
is
that
if
you
log
in
from
the
web
and
then
launch
zoom
from
the
web,
it's
sort
of
like
forward
your
login
information
to
the
account
to
the
to
the
to
the
installed
app
right.
So
you
can
be
like
logged
in
on
the
app
using
one
account.
But
then
you
can
be
logged
in
on
the
web
using
a
different
account
and
when
you
launched
a
meeting
from
the
web,
it's
the
web,
one
that
wins
it's
very
confusing
that
make
sense
at
all.
It.