►
From YouTube: Kubernetes SIG Testing 2017-11-21
Description
Meeting notes: https://docs.google.com/document/d/1z8MQpr_jTwhmjLMUaqQyBk1EYG_Y_3D4y4YdMJ7V1Kk/edit#
A
This
computer,
okay,
hi
everybody
I'm
here,
okay,
this
is
snake
testing
our
weekly
meeting.
It
is
Tuesday
December
12.
Thank
you
all
for
joining
this
meeting
is
being
publicly
recorded
and
will
be
posted
to
YouTube.
Shortly
today
on
our
agenda,
we're
going
to
talk,
we're
gonna,
have
a
little
demo
and
talk
about
coop
spawn
we're
going
to
talk
a
little
bit
about
the
organizational
structure
of
this
sake
and
kind
of
the
changes
going
forward
and
if
there's
any
interest,
I
can
recap
those
slides
I
presented
at
Q
Khan.
A
B
Thanks
yeah,
my
name
is
Chris
I'm,
her
Moz
small
company
in
Berlin
called
kinfolk.
You
may
know
us
remember
code
and
rocket
and
yeah,
so
we
in
the
course
of
doing
our
work
on
kubernetes.
We
created
a
tool
that
is
similar
and
go
to
mini
cube
where
you
have
a
local
kubernetes
clusters.
However,
it
does
things
quite
differently.
It's
also
one
of
the
main
features.
B
B
You
could
pass
that
to
keep
spawn
and
it
will
boot
into
that
kubernetes
clusters
and
one
of
the
cool
things
you
can
have
multi
multi
node
clusters,
so
you
can
give
them
names
just
like
you
would
give
a
get
in
branch
a
name,
and
so
you
can
test
side
by
side
the
cluster
with
the
fix
and
without
the
fix.
Now
we
do
not
use
V
ohms
to
do
this
and
we
do
not
use
app
containers
to
do
this.
B
So
this
is
quite
different
from
mini
cube,
which
uses
a
VM
or
is
just
on
the
host.
If
you
choose
that
flag-
and
it's
quite
different
from
you-
know
the
doctor
and
our
solutions
which
use
a
container,
so
we
use
OS
containers
and
these
are
based
on
system
DN
spawn.
So
you
can
basically
set
up
a
five
to
three
to
five
node
cluster
for
about
the
same
resource
usage
as
you
can,
with
a
mini
queue.
B
We
last
week
right
before
Q
Klein.
We
went
through
all
the
certification
stuff,
so
we
are
actually
a
certified
kubernetes
distro.
But
the
cool
thing
is,
you
can
not
only
test
your
apps
on
it.
You
can
actually
test
the
changes
on
Cooper
days,
so
we
talked
to
quite
a
few
people
at
UConn
and
we
were
basically
told
we
should
talk
to
the
sick
testing,
because
there's
I
think
you
all
are
looking
for
a
solution
to
easily
test.
B
I'm
kubernetes
changes,
and
so
one
of
the
cool
things
we
think
you
know
Q's
comm
can
be
used
for
is
to
have
a
highly
dent.
You
know
it's
gonna
be
you
can
use
it
like.
I
said
you
can
do
multi
multi
node
clusters,
and
so
you
can
have
a
very
dense
test
environment
on
a
kubernetes
certified.
You
know
kubernetes
cluster,
so
yeah.
So,
oh,
my
yeah.
I've
had
up
to
11
node
clusters
running
and
it
works
just
fine,
it's
quite
quite
nice,
so
I
don't
know.
B
If
that's
I
mean
we
were
told
to
come
here
so
and
then
we
or
our
own
test
purposes,
for
example
the
rocket
lit
which
we
released
about
two
weeks
ago,
a
first
version
of
rocket
lit
the
CRI
implementation
for
rocket.
We
tested
with
that
pretty
much
exclusively
out
of
the
box
that
just
use
it
to
normal,
a
darker
stuff,
but
we
do
actually
have
support
for
running
mutations
and
I.
B
A
Is
really
cool
and
actually
been
joined
because
so
define
discussions
multiple
times
about
finding
a
way
to
run
in
Denton
tests,
but
on
a
much
lower
fidelity
cluster.
Some
kind
of
some
people
are
trying
to
shut
back
into
the
box
of
integration
tests
for
basically
like
much
lower
resource
usage,
I'm
running
all
the
kubernetes.
A
Node
and
we've
taken
a
couple
stacks
of
this
I.
Don't
actually
know
enough
about
the
Patel.
The
other
steps
we've
taken
to
understand
how
what
you're
talking
about
differs,
but
the
fact
that
it's
been
certified
as
conformant
sounds
really
cool
to
me.
I
think
Meru
and
then
probably
know
more
about
this
than
I
do.
If
you
guys
want
to
comment
on
it
at
all.
A
B
B
D
A
That's
all
good
I
mean
yeah
and
we
run
it
in
a
container.
The
reason
we're
asking
is
because
we're
trying
to
live
in
a
breaking
world,
where
every
single
test
that
we
run
is
itself
a
pot
that
we
run
on
a
kubernetes
cluster,
and
so
the
approach
that
Ben
has
been
taking
is
to
trying
is
trying
to
use
sort
of
a
docker
in
docker
based
solution
to
accomplish.
D
D
Is
that
not
just
that
we
run
tests
as
a
pod,
but
since
we
can
run
tests
as
a
pod,
when
the
builder
test
is
done
it
just
you
know:
Carini's
tear
down
all
the
resources,
so
we
very
much
would
love
solutions
that,
let
us
do
this
lower
fidelity
testing,
but
we'd
really
hope
to
be
able
to
like
toss
them
in
a
cobra,
Kenny's
pod
and
have
everything
clean
itself
up
when
the
pot
is
deleted.
I
mean.
E
D
Is
go
ahead.
Sorry,
sorry,
sorry,
punky!
Oh
there's
one
other
key
thing
that
I
haven't
seen
any
other
solutions.
That
has
been
a
reason
that
I
might
want
to
leverage
Quinton
specifically
for
CI,
which
is
that
when
it
builds
this
tool
it
takes
available
and
it
packs
all
of
the
binaries
and
things
you
need
already
into
the
image
so
that
when
you
boot
this
thing,
it
doesn't
need
to
go
like
downloading
any
of
the
crew,
nase
components
or
anything.
It's
all
just
like
baked
into
our
container.
You
can
run
yeah
this.
A
Like
this
was
using
hypercube
to
effectively
accomplish
something
similar,
so
I
think
like
to
give
us
some
time
to
talk
about
the
other
stuff
all
right.
This
sounds
like
if
you
were
able
to
really
test
out
rocket
with
this.
That
sounds
like
pretty
impressive
fidelity
and
I
think
what
I
have
heard
is
lacking.
A
Please
correct
me:
if
I'm
wrong
is
that
there
isn't
really
an
easy
way
to
locally
stand
up
and
reproduce
a
debug,
and
then
tests
like
the
local
provider,
isn't
a
thing
or
it
doesn't
work
well
or
something,
and
what
you're
talking
about
with
multiple
nodes
on
a
single
machine
sounds
really
useful
and
I'd
love
to
be
able
to
talk
about
this
as
like,
when
the
developer
comes
up
and
says:
hey,
how
can
you
refer?
This
I
can
say,
use
your
tool.
That's
super
awesome.
A
A
D
E
D
So
when
I'm
asking
these
questions,
I'm
not
asking
because
I
want
to
say,
let's
not
push
this
tool
I'm
asking
because
I
want
to
know
if
I
can
start
using
this
tomorrow
to
like
reduce
our
load.
If
it's
not
true,
it'd
still
be
awesome
to
say,
hey
developers,
you
want
to
run
these
end-to-end
tests,
but
you
don't
have
like
a
gke
cluster
use.
This.
B
B
D
So,
for
a
tiny
bit
more
background,
we
actually
do
do
some
docker
and
docker
for
some
test
stuff.
Today,
the
it's
not
too
bad
on
the
scene,
groups
and
things
the
pain
point
has
been
that
it
still
needs
things
like
farlap
docker
mounted.
So
we
wind
up
not
totally
container
izing
stuff
amount
of
volume
for
it
to
store
these
things.
But
it's
pretty
close
to
the
point
where,
when
a
test
exits,
its
resources
are
free,
which
is
the
idea
we
want.
So
we
can.
A
So
I
think
this
is
really
cool
and
I'd
love
to
see
more
discussion
about
this,
our
slack
Channel
to
figure
out
how
we
can
we
can
carry
going
forward.
I
mean
one
of
the
like
lower-level
things
like
I,
always
think
of
this
to
test
is
kind
of
artifact
of
single
tool
that
we
run
stand
up
a
cluster
contest
against
it,
tear
the
cluster
down.
We
have
what's
called
a
provider
sort
of
interface
where
we
use
like
cops
provider
or
kubernetes
anywhere
provider.
A
If
we
could
maybe
figure
out
how
to
hook
out
like
a
coop
coupon
provider,
then
that
can
provide
a
lower
friction
path
to
with
one
single
command
immediately,
repro
the
same
thing
that
we're
doing
in
CI,
environment
and
yeah
any
any
more
information
or
blogs
or
something
please.
Let's
continue
the
discussion.
B
B
B
F
Several
folks
have
been
chatting
either
back-channel
with
me
or
direct
face-to-face
with
me,
as
well
as
during
the
cocon
about
what
exactly
does
sig
testing?
Do
you
and
what
was
it
intended
to
do?
And
what
are
we
doing
currently?
And
there
was
a
lot
of
conversations
about
well,
it
does
test
them
for
mostly
today,
but
that's
not
the
way
it
used
to
be
right.
F
So
they
were
building
out
the
actual
tests
and
some
of
the
what
they
did
as
part
of
the
sig
was
to
find
Co
reviewers,
namely
Jeff
Forex
T,
as
well
as
Z
Merlin,
who
was
originally
round,
and
this
sig.
Then
they
would
tackle
and
address
items
as
part
of
the
release
process
right.
So
that
way,
it
was
constantly
moving
forwards.
The
tests
themselves
got
better
over
time
and
people
were
constantly
iterating
on
those
pieces.
F
Now
some
of
those
restructurings
still
occur,
but
they
don't
get
a
clearinghouse
and,
what's
going
to
happen
in
the
next
two
releases,
or
so
is
there
going
to
be
a
lot
of
changes
to
the
testing
structure
and,
as
a
point
of
order,
I
wanted
to
start
to
feel
out
the
idea
of
either
you
know,
there's
multiple
ways
to
handle
this
one
is
to
resync
things.
Some
people
are
pretty
adamant
against
that
idea.
F
The
other
idea
is
to
either
have
a
sub-project
who
focuses
directly
on
the
tests
themselves,
as
well,
as
you
know,
unit
integration,
performance
and
end-to-end
or
to
have
it
as
a
separate
working
group
and
I
wanted
to
talk
about
it
here
to
get
feedback
about
what
people
think.
The
reason
being
is
the
first
20
minutes
of
a
30
minute
conversation
were
devoted
towards
a
tool
which
is
around
testing,
which
isn't
bad,
there's
nothing
wrong
with
that.
F
But
if
we're
going
to
get
a
focus,
group
of
a
large
large
body
of
people
involved,
I
want
to
make
sure
we're
judicious
about
the
use
of
time
and
making
sure
that
we
a
lot
a
good
slot
of
that
to
people
who
are
going
to
be
executing
against
deliverables
within
a
given
milestone.
So
with
that
a
little
bit
of
history
as
well
as
thought,
feel
free
to
chime
in
and
your
thoughts
there
I.
E
Ebola
was
talking
to
him
if
you
think
that
there
is
insufficient
like
focus
on
testing
sort
of
at
the
project
level
like
individual
states
focus
on
their
little
piece
to
fly.
But
especially,
is
you
know,
breaking
out
in
Federation
and
starting
to
think
about
how
sub
projects
are
going
to
be
testing?
That
kind
of
prompted
me
to
think
that
we
don't
really
have
a
great
deal
of
common
test
infrastructure
that
is
sort
of
consumable
outside
of
kaykai
and
so
I'm
hoping
you
know
whether
or
not
we
have
a
separate
venue
for
working
on.
C
E
G
Yeah
I
think
like
as
we
are
breaking
stuff
out
downstream
as
well.
We're
noticing
that
same
thing
and
it
I
think
it's
also
happening
in
a
lot
of
the
incubator
projects,
I'm
not
sure
exactly
how
much
bandwidth
people
in
this
current
conversation
have
today
but
like
I,
think
we
should
be
able
to
recruit
people
from
all
the
various
incubators
like
right
now.
G
I
know
a
couple
of
them
have
just
complete
forks
of
the
Yui
framework
but
they're
using
because
otherwise
the
defense
he's
not
going
to
work
out
and
like
maybe
that
was
necessary
for
the
velocity
of
the
thing
we're
targeting
at
the
beginning,
but
at
some
point
that
needs
to
come
back
together.
Otherwise,
it's
gonna
start
becoming
pretty
fragmented,
so
I
think
there's
definitely
gonna
be
a
huge
push
for
that.
I'm.
D
G
F
There
also
needs
to
be
a
clearinghouse,
so
either
we
a
lot
the
time
you
know
as,
like
you
know,
a
B
or
C,
because
we
only
have
half
an
hour
and
a
lot
of
the
time
that,
like
today,
is
a
good
example
where
20
minutes
was
consumed.
Talking
about
testing
which
isn't
bad
again.
It's
just
that.
There's
gonna
need
to
be
a
clearinghouse
for
this
stuff
in
the
next
cycle,
because
there
will
be
a
lot
of
people
spinning
into
it.
F
So,
if
you
think
about
that
as
a
whole
and
the
current
number
of
tests,
we
have
that's
gonna
be
a
lot
of
churn
and
we
would
just
be
focused
and
execute
on
some
of
those
pieces,
as
well
as
being
mindful
of
the
broader
scope
problems
that
exist
in
the
testing
apparatus.
I
myself
have
not
forked,
but
I've
done
the
same
thing
as
OpenShift
is
done
and
basically
have
an
intent,
extended
test,
suite
external
to
the
main
repository
that
I
use
as
pretty
of
stuff
I.
D
Would
say
that
would
hope
that
it
would
remain
at
least
fairly
closely
tied
to
sig
testing,
even
if
said
testing,
where
do
we
got
likes
again
for
or
something
not
not
like
dependent
on
them
or
anything.
But
you
know
in
close
discussion
with
and
I
would
hope
that
we
can
bring
some
of
the
mistakes
for
these
different
kubernetes
areas
in
on
like
owning
and
improving
these
tests
as
well.
Like
I,
don't
know
if
we
just
had
people
slowly
working
on
tests
that
that
totally
solves
everything
so.
F
There's
there's
a
couple
options
that
I
vetted
one
is
the
the
heavyweight
option?
Is
the
nuclear
one
right?
The
second
option
is
the
sub-project
one,
which
is
common
to
run
across
the
sequester
lifecycle.
The
third
one
is
the
working
group
on
which
is
very
same
thing
as
a
sub-project
just
named
differently.
F
A
Think
I'm
in
violent
agreement
so
like
I,
was
also
I
found
the
snake
in
the
first
place,
and
so
I
remember
like
helping
Jay
go
through
some
of
those
reviews
and
they
XD
helping
out
some
of
the
reviews
and
depends
point.
It
does
seem
like
we
don't.
Nobody
owns
the
testing
frameworks
top
anymore
and
so,
like
I
repeatedly
said
in
pucon,
like
I've,
said
over
time.
Let's
take
testing
we're
here.
People
defend
to
the
death
your
right
to
lab
tests,
but
we
will
not
write
them
for
you
and
I.
A
A
Testing
for
an
improvements
is
another
like
making
the
testing
for
stack,
reusable
and
across
projects
as
well
as
how
are
we
actually
improving
the
experience
of
this
project
I
personally,
my
dog
in
this
bike
is
I.
Think
that
contributor
experience
and
say
testing
both
have
overlap
in
the
same
area
of
how
do
we
improve
the
process
of
contributing
to
this
project
and
how
to
be
more
easily
automate
that
they
literally
touch
the
same
code
and
in
this
grantee
world?
A
Where
we're
supposed
to
be
signing
a
charter
I
somehow
feel
like
that's
all
pooped
in
there,
but
further
I
think
like
how
do
we
repeatedly
build
kubernetes
right?
There's
this
discussion
of
Basel
happening
in
the
channel.
It's
like
say,
fasting
and
like
say,
testing
seems
to
who
is
the
basil
chopped,
but
really
basil
is
also
about
repeatable
bill.
So
I
see
a
number
of
different
sub
areas
that
fall
under
the
umbrella
of
what
we
collectively
care
about.
A
You
have
been
doing,
I,
don't
know
if
testing
is
the
right
word
for
it,
but
in
the
short
term,
I
kind
of
want
to
say
sig
testings,
like
the
umbrella
thing
we
figure
out
if
we
need
a
different
cadence
or
different
meeting
lengths
to
be
able
to
sync
up
on
these
things.
We
talked
about
whether
you
wanted
to
tick
tock
models
to
focus
on
areas
as
needed
to
really
try
of
stuff
forward.
A
But,
like
I
sat
in
a
the
synapse
deep
dive
session,
where
synapses
also
got
this
kind
of
like
medicine
and
they
they
were
wondering
whether
or
not
they're
too
many
too
many
things
going
on
there
under
the
umbrella
of
that
state
right.
You
here,
after
half
working
group,
there's
composed
there's
home,
there's
charts,
there's
for
gaining
there's
draft,
there's
all
sorts
of
stuff,
and
the
overwhelming
response
for
people
is
to
note
and
you'd.
E
Like
to
point
out
that
it
might
be
nice
for
somebody
who's
not
actually
working
on
stuff
who's,
just
kind
of
wants,
an
information
dump
on
them
that
yeah
put
it
all
in
one
big,
pile
and
all
filter
through,
but
if
you're
actually
working
on
it
or
you're,
trying
to
just
collaborate
with
like
certain
group
of
people,
it's
a
subset
and
having
everything.
Just
conjoin
isn't
always
the
best
idea.
So
I
don't
know
that
sig
out
is
the
best
example
here.
I
agree.
A
But
I
think
cluster
lifecycle
so
say:
Apps
is
kind
of
like
things
are
focused
on
individual
code
bases
for
the
most
part,
but
we
kind
of
have
two
conjoined
code
bases,
and
maybe
we
talked
about
breaking
that
up
a
little
bit
like
I.
Think
a
reusable
framework
doesn't
necessarily
have
to
leave
in
a
reboot
called
testing
for
us
I.
A
The
fact
that
there's
been
a
lot
of
legwork
put
in
to
push
the
project
forward
and
like
the
name
doesn't
mean
much
to
me
but
I,
think
if
other
people
care
about
the
term
Stickley
I'm,
certainly
not
plus
one
for
it,
and
we
don't
really
like.
We
don't
have
a
whole
charter.
We
don't
have
a
mandate
and
you'll
tell.
A
To
kick
me
out
of
a
leadership
position,
because
we
don't
have
any
sort
of
Charter
and
a
government's
thing
in
place
and
I.
Don't
feel
a
strong
need
to
formalize
that
what
you
have
to
do,
but
it
seems
like
if
I
want
to
like
being
will
put
stuff
on
Steve's
plate
to
help
organize
the
flow
of
information
and
do
a
better
job
of
giving
the
community
a
heads
up
for
the
sorts
of
stuff
we're
doing
the
money.
In
fact
them.
It
seems
like
a
mutually
beneficial
I.
A
F
The
question
is,
then
apparatus
for
how
we
execute
right,
like
should,
if,
if
folks
want
to
talk
about
testing
for
I,
don't
care
I'm,
you
know
like
that's
their
thing,
that's
good
for
them.
You
know,
but
I
don't
want
to
be
a
part
of
it.
Really,
that's
not
what
I'm,
when
I
care
about
it
I
understand
that
some
of
the
people
in
testing
fro
have
an
overlap
right
so.
C
F
C
A
There
salute
the
other
week,
I'm
totally
fine
I'm,
changing
this
thing
up,
so
we
have
one
week.
That's
super
infra
heavy
one
week.
That's
super
test,
heavy
kind
of
whatever
makes
sense.
It's
not
necessarily
my
intent
to
hash
that
out
in
this
type
of
environment,
I
think,
like
I,
see
a
lot
of
head
nodding
in
agreement
to
the
general
idea.
I
think
what
comes
next
is
do
the
proposal.
Let's
do
it
in
a
written
document.
It
form
through
the
mailing
list,
plus
one
or
whatever.
We
feel
like.
F
A
Think
we've
done
not
the
best
job
at
actually
recording
those
breakout
sessions
and
sharing
or
take
home.
Some
meeting
notes
have
been
taken
like
that's
yeah
I
want
to
get
I
want
to
get
better
at
us
using
the
same
same
infrastructure.
To
do
the
like
meet.
You
come
to
stay
fascinating,
to
hear
all
the
some
projects
that
are
happening
under
s
the
same
playlist.
You
can
see
all
the
information
you
want
for
each
of
the
sub
projects
that
are
talking
about
testing
your
performance
would.
A
D
A
Like
either
day,
I'd
say
like
let's
ask
more
people
what
their
preference
is
for,
whether
it's
this
time
or
whether
it's
yet
another
meeting,
because
I'm
happy
never
to
do
any
option,
because
there
are
times
when
it
seems
like
we're.
Just
talking
just
to
talk
to
fill
this
space,
and
maybe
talking
about
I,
think
I'd.
F
Be
I'll
float
a
proposal,
I'll
write
it
down.
I'll
use,
sequester
lifecycle
as
an
example,
but
usually
I'm,
a
very
detail-oriented
execution
style
person,
so
I
I
literally
have
backlogs
and
price
or
today
everything.
So
it's
just
how
I
roll
so
the
the
that
will
be
how
the
modus
operandi
am
I
would
I
would
kind
of
fall
under
okay,
so
I
will
I
will
write,
strap
something
up
and
get
it
out
probably
either
today
or
tomorrow.