►
From YouTube: Kubernetes SIG Testing 2019-08-13
Description
A
Okay,
hi
everybody
today
is
Tuesday
August
13th
and
you
are
at
the
brand-spanking-new
bi-weekly.
Every
other
weekly
can
burn
any
state
testing
meeting
I'm
your
host,
Aaron
cig
beard
and
you
are
all
being
publicly
recorded.
You
will
find
yourselves
on
YouTube
later,
where
you
can
watch
yourselves
adhere
to
the
kubernetes
code
of
conduct.
By
being
your
very
best,
selves
I
wanted
to
try
something
slightly
different
with
the
meeting
agenda,
since
we've
changed
up
our
meeting
schedule
today
by
taking
some
time
to
welcome
any
new
attendees.
But
I
know
everybody
here.
A
A
So
in
the
recurring
topics,
section
I'm
linking
out
to
the
sub
projects,
so
if
I
click
on
time,
for
example,
I
can
go
see.
That
kind
is
this
thing
here
lives
in
this
repo,
this
slack
channel,
and
if
you
want
to
go
to
the
con
meeting,
here's
their
agenda
so
I
could
stock
them
and
give
them
their
own
update
if
their
meeting
agenda
is
up
to
date.
A
So
that's
what's
going
on
with
the
kind
similar
deal
for
testing
Commons
testing
Commons.
Is
this
not
project?
That's
all
about
like
we
want
to
sort
of
improve
the
code
structure
and
layout
of
the
way
that
tests
are
written.
There's
a
lot
of
work
going
on
these
days
around
sort
of
refactoring
the
e
to
e
framework
and
making
it
more
reusable
for
people
I,
don't
know
why
I
dropped
all
the
way
to
the
bottom
of
the
dock.
A
A
Same
thing
for
proud,
specifically,
I
still
believe
that
we
have
plans
of
sort
of
breaking
prom
up
into
its
own
separate
code
base
at
the
very
least,
separated
proud
code
from
the
proud
config.
So
if
you're
interested
in
just
working
on
proud,
related
things
here
are
the
issues
in
our
current
milestone
that
are
just
related
to
proud.
A
This
maybe
gets
into
the
conversation
of
how
we
have
like
a
bunch
of
labels
for
different,
proud
sub
components
like
Dec
and
hook
and
other
stuff,
and
it's
unclear
to
me
how
useful
that
is
for
people
to
understand
like
what
needs
work
and
what
are
we
working
on
so
with
that
I
think
I'm
gonna
move
over
to
the
open
discussion.
Unless
anybody
has
any
questions
on
that
stuff
and
the
first
part
of
open
discussion
would
be
Miranda.
B
C
C
C
C
It
would
give
you
a
command
that
you
could
paste
into
the
terminal
if
you
had
cluster
access
and
if
you
didn't
have
cluster
access,
you
had
to
ask
someone
who
did
to
run
it
for
you,
and
so
I
have
been
working
on
improving
that
to
where
now,
let's
see
if
my
animation
works,
if
you
click
the
rerun
button,
the
job
runs
directly,
and
so
this
doesn't
actually
work
for
everyone.
We
have
a
permission
system
set
up
so
basically
at
least
on
Kate's
prowl.
C
This
next
point
is
not
actually
deployed,
yet
it
will
be
soon,
but
the
same
logic
slash
test
will
be
used
for
P
submit.
So
that
means
any
pre
submit
job
that
has
the
okay
to
test
label
can
be
rerun
by
anyone
or
if
you
could
apply
the
okay
to
test
label.
If
your
trusted
user,
then
you
can
rerun
any
pre-summit
job.
We
also
have
the
option
to
specify
job
specific
config.
C
So
if
you
think
that
a
specific
github
team
should
be
able
to
rerun
a
specific
job
or
that
you
individually
should
be
able
to
rerun
a
specific
job,
you
can,
let
me
know
on
slack
and
I
can
update
the
config.
So
you
can
rerun
that
job
and
if
you
have
your
own
Pro
instance,
you
can
set
this
up
as
well
and
use
that
same
permission
system
and
the
instructions
for
setting
that
up
are
in
the
design
dock,
which
is
linked
in
page
so
I'm.
C
C
C
So
if
your
rerunning,
a
job
and
the
reps,
have
changed
since
the
original
run,
just
like
a
pop-up
that
asks
you,
whether
you
want
to
resolve
those
graphs
and
if
anyone
has
any
ideas
through
anything
that
they
want
to
add
on
you're,
welcome
to
at
bat
I
think
at
this
point
the
people
who
know
my
project
best
are
Cole
and
Eric.
So
if
you
have
any
questions
about
that
after
I
leave,
they
would
be
good
people
to
talk
to
you
and
I
just
want
to
say
thanks
to
everyone
who
helped
me
out,
reviews.
A
A
A
It's
not
like
we're
gonna
say
you
have
to
have
written
this
many
PRS
that
are
this
big
in
order
to
become
a
member,
it's
more
than
we
want
to
make
sure
you're
actually
willing
to
stick
around
and
do
some
work,
but
for
those
people
who
are
not
or
members,
it
was
very
important
for
us
to
have
a
publicly
auditable
version
of
our
teams
so
that
people
would
see
that
really
do
you
have
an
example
of
the
config
that
we
could
you
just
share
with
us,
so
we
can
start
to
see
how
it's
configured
today.
A
Because
I,
like
I
personally,
know
I've,
heard
requests
for
this
from
city.
He
showed
dims
as
an
example.
In
there
I
know
people
from
the
Cates
infrastructure
working
gir
have
a
number
of
different
jobs
related
to
container
image.
Promotion
that
are
implemented
has
post
submits
where
it's
like.
Ordinarily,
the
only
way
they
trigger
is
upon
emerge,
and
so,
if
that
one
trigger
fails,
we'd
look
for
some
way
to
rerun
that
it
seems
like
I
mean
you
tell
me,
it
seems
like
we
don't
really
have
people
to
ask
for
periodic
stew,
get
ready
triggered
all
that.
A
C
C
A
So
I'm
just
sharing
my
screen,
so
we
can
take
a
look
at
that.
So
does
it?
What
would
it
look
like
if
I
wanted
to
like
add
the
ability
for
certain
people
to
trigger
certain
jobs?
Is
that.
C
C
C
A
A
E
All
right
so
I
think
like
okay,
what
am
I
gonna
do
that's
great
so
recently,
like
we
got
actual
progress
made
on
open
sourcing
test
grid,
instead
of
being
in
the
kind
of
awkward
position
of
exactly
what
are
we
open
sourcing,
how
etc?
We
are
actually
like
full
go
ahead
on
updating
the
test.
Great
updater
will
determine
more
on
the
front
end
later,
but
for
now
the
updater
is
gonna,
be
a
substantial
amount
of
work
anyway.
So
I
posted
an
update
in
the
open
source
issue.
E
That
is
actual
like
plans
for
what
we
want
to
do
in
later
this
year.
So
currently,
those
plans
include
mostly
like
uploading
or
sorry
open
sourcing
parts
of
the
updater
itself.
Things
like
the
jobs
that
run
post
update,
like
people
are
probably
familiar
with
summarizer
and
alerter
as
things
that
make
the
summary
and
the
things
that
email
some
people.
The
important
part,
though
that
I
want
to
poke
about
is
this
part,
which
is
in
order
to
kind
of
clarify
what
test
grid
is
for.
E
I
would
like
to
propose
moving
the
like
grade
code
that
we
have
existing
into
its
own
repository.
There
is
a
existing
repository
that
we
can
now
use,
which
is
under
I,
think
I
need
to
say
right,
like
yeah,
it's
under
Google
cloud
platform,
slash
test
grid.
We
have
very
basic
stuff
there,
but
I
would
like
to
actually
move
this
stuff
from
test
infra
over
to
that
new
repo,
the
process
and
whatnot
for
everything
should
be
about
the
same.
E
We're
gonna
be
using
prowl
for,
like,
probably
goodness,
the
like
code
itself
should
just
be
forked
off
with
the
existing
stuff.
We
still
plan
on
making
sure
that
it
works
with
prowl
making
sure
that
it
works
for
kubernetes,
making
sure
that
the
kubernetes
instance
is
all
good,
but
mainly
I
just
want
to
make
it
clear
that
it's
not
a
like
kubernetes
only
thing
and
also
like.
Actually
that's
that's
mostly
it
there's
some
other
things
with
it.
E
E
E
E
That
can
like
read
results
from
a
bucket
translate
them
to
test
good
state
show
up
on
the
actual
test
grade
dashboards
I
think
we're
gonna
be
trying
to
move
as
close
to
that
as
possible,
but
I
don't
want
to
target
like
given
that
we're
halfway
through
August
I'm,
not
sure
about
end
of
September
right
now,
because
there's
like
some
existing
stuff
that
we're
discovering
is
like
oh
yeah,
we
totally
assumed
for
like
internal
google,
with
some
hacks
on
top
to
make
it
work
for
external,
like
kubernetes
instance.
D
Happy
to
try
out
the
developers
for
our
project
are
waiting
for
test
grits
and
right
now
we
basically
happen
to
back
lock,
maybe
put
a
entry
onto
the
kubernetes
test,
great
dashboard.
Then
we
see
it
there,
but
if
we
just
wait
another
month
or
two
and
can
say
that
we
can
move
on
to
our
own
desperate,
that
won't
be
even
better
yeah.
E
E
E
D
A
I'm
trying
desperately
until
I
candle,
the
mic
and
stuff
so
I
have
I've
two
thoughts.
One
thought
one
question
on
this,
so
the
question
is
right:
now
we
have
a
lot
of
tests
that
run
against
our
tests,
great
config
and
our
proud
jobs
to
kind
of
enforce
some
common
conventions
between.
We
also
have
some
tests
that
make
sure
that
the
test
grade
conveyed
is
like
valid
and
wouldn't
blow
up
test
great.
B
A
E
Yeah
so
and
John,
if
you
want
to
speak
to
this
a
bit
as
well
feel
free,
but
mostly
like
I,
was
like
the.
There
are
some
prints
that
are
like
more
related
to
the
kubernetes
configs,
like
around
the
ammo
files
around
these
things,
we're
kinda,
proud
jobs,
which
I
think
could
go
either
way
they
can
stay
in
the
Cates
repo
I
was
like
eh.
E
A
A
I
feel
like
I,
want
some
tool,
utility
or
tests
to
tell
me
about
those
basics,
but
then
kubernetes
probably
cares
about
like
every
cron
job
should
have
an
Associated
tests
group
and
like
test
groups
or
and
then
like
dashboard
tabs,
should
only
fall
within
this
naming
convention
or
like
we're
allowing
test
dashboard
tabs
for
cigs
and
companies
who
are
members
of
our
community,
and
so
those
conventions
I
want.
You
know,
tested
sort
of
downstream
of
test
grade
in
our.
E
E
F
Colbert
and
again,
I
think
that
depends
on
our
like
our
users,
because
I
know
that
there
are
people
who
aren't
kubernetes
who
want
to
use
test
grid.
Yes,
I,
don't
know
how
many
people
that
aren't
using
prowl
don't
want
to
use
test
grid.
So
if
we
have
a
bunch
of
different
users
for
a
bunch
of
different
posit
or
ease
that
also
use
prowl
than
our
crowd,
cuneta
test
grant.
Integrating
tools
will
be
released.
One
yep
and.
A
Thanks
the
other
random
thought
I
had
so,
if
there's,
you
may
not
necessarily
be
able
to
stand
up
your
own
instance
of
test
period
today
or
within
a
quarter
from
now,
maybe
by
the
end
of
the
year.
But
what
this
will
empower
is
people
who
want
to
change
things
or
streamline.
Certainly,
user
experiences
with
test
grid
should
be
capable
of
doing
that
as
we
bring
more
components
online.
So
if
there
are
ways
where
like,
for
example,.
A
To
add,
like
timezone
localization
to
test
grid
and
I
would
love
for
some
other
person
within
the
community
who
doesn't
live
in
the
Pacific
time
zone
to
remind
us
that
there
are
other
time
zones
in
the
world
by
contributing
something
that
supports
time
zone.
Localization
I
know,
I
was
reminded
of
it.
Every
time
I
went
out
to
the
east
coast
of
the
United
States
to
visit
my
folks
or
whenever
I
happen,
to
be
in
Europe
for
a
kubernetes
conference,
so
I
sympathize
with
that
plight.
But
this
is
about
sort
of
growing
the
pool
of
people.
A
You
can
make
those
kinds
of
contributions
to
test
grid
another
and
so
I
feel
like
people
who
are
on
the
release
team
or
who
are
very
interested
in
helping
out
the
kennedys
release.
Team
might
want
to
check
this
stuff
out
when
it
comes
to
like
improving
the
relevance
of
the
summarizer
or
the
metrics
that
we're
looking
at
or
so.
If
those
are
all
things
that
can
be
on
the
table
down
the
block
yeah.
E
I'm,
pretty
excited
for
some
reason
to
learner
I
think
are
gonna,
be
some
of
the
first
things
out
there.
Another
person
on
the
team
has
already
done
like
a
good
amount
of
work.
If
anyone
knows
funny
has
done
a
good
amount
of
work
on
like
trying
to
get
our
existing
summarize
our
work
and
then
like
there's
still
a
bit.
E
Do
on
that,
but,
like
it'd,
be
great
to
see
some
more
complicated
things
happen
in
summarizer.
That
can
then
be
used
in
other
places
and
whatnot
so
saying
for
alerter
like
if
we
want
better
email
alerts
in
general,
like
the
thing
someone
was
mentioning
or
like
you
can
get
an
overall
view
for
like
a
the
summary
or
the
alert
for
a
dashboard
instead
of
every
single
dashboard
tab
that
you
want
to
subscribe
to
under
a
dashboard,
which
can
be
literal.
E
A
A
New
job
health
dashboards,
so
I'm
going
to
take
a
little
bit
longer
than
just
jumping
straight
to
the
dashboard,
because
I
want
to
sort
of
demonstrate
how
this
data
gets
here,
how
I'm
querying
it
and
then
what
I'm
doing
with
this
data
I
understand
that
this
is
useful.
So,
broadly
speaking,
when
I
was
released,
lead
for
114
I
put
in
place
a
number
of
criteria
for
whether
or
not
the
job
could
be
blocking.
I
will
start
to
go
to
that
thing
now.
A
B
A
B
A
Must
have
passed
seventy-five
percent
while
the
runs,
but
we
have
not
historically
measured
or
enforced
this
stuff.
Also,
we
recognize
that
humans
kind
of
need
to
take
a
look
at
this
to
understand.
Maybe
there's
a
reason.
This
is
happening
now
and
it
will
eventually
be
fixed.
A
So
there
is
data
that
we
have
available
today
when
we
look
at
all
jobs,
not
just
data
that
contest
grid
has
but
also
data
that
ends
up
in
a
query.
The
data
gets
into
bigquery
by
way
of
this
program
called
kettle.
It's
basically
just
a
bunch
of
Python
that
periodically
scrapes
all
of
our
GCS
buckets
and
dumps
that
data
into
bigquery
and
then
also
sets
up
something
that
listens
to
pub
sub
events
and
puts
that
data
into
the
bigquery
data
set
and
so
I'm.
Looking
at
a
table
called
week.
A
There
are
also
tables
called
date
which
represent
all
of
the
builds
for
the
last
day.
There's
also
the
all
table,
which
is
all
of
our
builds
ever
when
we
set
this
up,
which
is
at
least
two
years
worth
of
data,
so
I
point
out
the
day
and
week
things
because
I
can't
stress
enough.
This
is
a
publicly
queryable
dataset,
so
anybody
is
capable
of
running
queries
against
this
dataset
and
it's
really
easy
to
run
against
sort
of
the
day
and
week
tables
and
not
use
up
a
whole
bunch
of
data.
A
B
A
B
A
B
A
Of
the
let's
order
by
dropcam's,
asking
back
so
I
can
see
like
what
are
all
of
the
jobs
that
end
up
in
this
bigquery
table,
literally,
all
of
them
I,
don't
care.
What's
running
in
my
commentary,
how
they're
kicked
off
and
cool
now
I
can
see
that
we
have
you
know.
In
the
past
week
we've
had
a
couple
thousand
runs
of
many
jobs
that
have
the
word
kubernetes
in
them,
and
one.
A
A
The
number
of
past
runs
of
each
job,
staying
for
tests
and
tests
with
tests
and
tests
the
field
within
each
job.
To
finally
give
me
things
like
the
failure
rate
of
jobs
and
the
failure
rate
of
tests
within
a
job,
this
was
based
on
work
that
Cole
did
with
his
metrics
thing.
So
again,
Burnett
he's
testing
for
metrics
you'll,
see
a
big
query.
That
looks
a
little
bit
like
that
as
an
example
of
there's.
A
So
we
then
have
this
thing
called
Bella
germ,
which
is
a
girl
fauna
instance
pointed
at
the
influx.
Db
instance
store
all
that
data
into,
and
this
is
the
dashboard
that
everybody
looks
at
today
and
it
can
show
us
things
like
in
theory
how
flaky
is
a
pull
request
in
theory,
what
are
the
pull
request?
Jobs
have
been
feeling
the
longest
for
the
flaky
aspo
request,
jobs
and
which
ones
have
the
most
actual
flakes.
A
So
this
can
teach
people
like
they
want
to
make
the
biggest
difference
to
the
project
right
now
and
improve
everybody's
marriage
velocity
that
you
can
figure
out
why
the
test
volume
provision
test
is
failing
or
flaking.
Getting
rid
of.
This
would
make
everything
better
fact
that
everything
else
is
staged
and
timeout
is
not
super
actionable
by
our
contributors
and
something
I
would
like
to
improve,
but
certainly
is
a
sign
to
us
that
something
about
our
set
up
test
infrastructure
prior
to
creating
a
cluster
isn't
working
very
well
so
on
and
so
forth.
A
So
using
the
horrible
query
that
I
constructed
I
wanted
something
that
was
a
little
more
relevant
to
the
release
team
to
show
stuff
right.
That's
where
it's
blocking
stuff
that
is
released,
blocking
and
so
I
have
sort
of
the
failure
rates
for
all
the
jobs
that
are
on
the
release.
Blocking
dashboard
I
have
at
the
moment,
hard-coded
what
this
list
of
jobs
is
here
into
this
drop
down.
But
this
is
something
that
Cortana
could,
in
theory
like
query
an
endpoint
to
get
a
list
of
jobs.
A
This
threshold
line
is
a
failure
rate
of
25%
just
based
on
the
release
blocking
criteria.
I
said
earlier:
if
this
fails
over
20
five
percent
of
the
time,
it's
not
really
meeting
its
criteria
as
a
release
blocking
job
theory
that
should
be
a
failure
rate
over
a
time
period
and
right
now,
I'm.
Just
looking
back
at
the
last
30
days,
I
could
look
back
at
the
last
90
days
and
see
something
that's
hopefully
a
little
bit
more
charitable,
no,
not
really
still
pretty
much.
A
So
again,
I
can
tell
that
the
integration
master
job
seems
to
be
the
current
most
flakies
job
between
these
two
and,
if
I
go
back
to
just
see
all
the
jobs
I
can
see
that
it's
still
the
flakies
job
out
of
everything
followed
by
these
next,
something
that
looks
similar
to
the
last
thing,
a
list
of
all
of
the
flakes
for
all
time
released
blocking
jobs,
which
one
has
the
most
flakes
and
that's
where
you
can
make
the
biggest
difference
by
fixing
a
given
thing
and
finally,
some
stuff
that
is
two
autographs
that
relate
to
released,
walking
durations.
A
One
shows
the
99th
percentile
of
the
duration
of
the
job
and
tells
me
that,
like
this,
this
GCE
serial
job
is
taking
almost
ten
hours,
not
quite,
but
almost
that
doesn't
seem
great
if
I
remove
that
the
Alpha
features
job
is
also
taking
somewhere
up
to
three
hours
to
finish
its
run.
So
maybe
that's
something
we
should
also
consider
kicking
out.
The
slow
job
is
also
pretty
close
to
that.
Once
I've
done
this,
these
are
all
the
jobs
that
actually
fall
under
the
threshold
of
maximum
duration.
A
A
So
this
is
actually
telling
me
like
roughly
how
often
in
are
things
getting
committed
into
kubernetes,
because
the
table
only
gets
kicked
off
as
a
host
admit
from
commit
lands,
which
is
this
is
basically
showing
the
weekends
is
the
TLDR.
But
if
I
get
rid
of
those
things
you
can
see-
and
I
get
rid
of
the
serial
job,
because
it's
taking
forever
to
run
and
see
most
everything
else
falls
under
the
threshold
of
its
gets,
kicked
off
at
least
every
three
hours.
B
A
It
is
slightly
different
metrics
than
the
first
dashboard
that
I
showed
you,
because
it
turns
out
the
first
dashboard
cared
about
how
many
pull
requests
ended
up
linking
I
only
care
about
how
many
indications
of
the
job
ended
up
flaking,
but
I.
Think
of
most
interest
here
might
be
like
which
pull
requests.
A
Jobs
are
taking
it
entirely
like
way
too
long
like
apparently,
most
people
at
least
99
percent
of
people
are
waiting
about
two
hours
for
this
job
to
finish
on
their
pull
requests,
if
they're
not
waiting
for
that
they're
waiting
about
two
hours
for
this,
like
hundred
node
scalability
job,
to
finish,
if
they're
not
waiting
for
that
they're
waiting
about
100
minutes
for
the
end-to-end
job
to
finish
so
I'm,
hoping
that
with
a
dashboard
like
this,
we
can
kind
of
get
a
better
idea
of
our
tests.
Really
helping
us
out.
A
Are
they
actually
being
meaningful
and
because
we
just
talk
about
tests
great
a
lot.
It's
kind
of
unclear
Nia
how
much
of
this
should
continue
to
live
in
a
dashboard
like
this
versus
how
much
of
this
should
be
actionable
intelligence
that
comes
from
a
tool
like
test
period,
but
this
is
you
know.
This
is
sort
of
the
thing
that
developed,
because
the
summarizer
was
closed
source
and
we
wanted
to
make
sure
that
the
community
was
empowered
to
have
like
whatever
queries,
whatever
metrics,
that
they
want.
A
A
A
The
last
thing
I
had
on
the
agenda
was
to
talk
about
coop
concessions.
The
maintainer
tract
gives
every
cig
the
ability
to
have
an
intro
session
and
a
deep
dive
session.
Something
that's
newer.
This
year,
though,
is
we
may
be
able
to
do
deep
dive
sessions
or
individual
sub
projects.
So
I
was
thinking.
It
might
be
a
good
idea
to
have
an
intro
session
and
I
have
a
deep
dive
session
for
prowl
and
have
a
deep
dive
session
for
kind
and
like
I,
was
talking
with
the
folks
from
the
testing
common
sub
project.