►
From YouTube: Kubernetes SIG Testing 2018-10-16
Description
A
All
right,
hi
everybody
today
is
Tuesday
October
16th,
and
this
is
the
weekly
sick
testing
meeting
I
am
your
host
Aaron
of
cig
beard.
We
are
being
recorded
and
will
be
posted
to
YouTube
shortly.
So
please
keep
in
mind
that
we
follow
a
code
of
conduct
which
basically
means
don't
be
a
jerk
on
today's
agenda.
A
We're
going
to
talk
a
little
bit
about
cube
test
v2
with
some
initial
ideas
proposed
by
Sun
and
we're
going
to
talk
a
little
bit
about
Patrick
Bowie's
efforts
to
refactor
the
e2b
framework,
and
if
you
have
time
at
the
end,
I
wanted
to
remind
folks
that
we're
giving
an
update
at
the
community
meeting
so
I
have
some
slides
to
run
through
and
I
have
written
a
charter
and
it
popped
it
up
to
the
steering
committee
for
review
pending
any
other
objections.
So
with
that
I
will
hand
off
to
send
to
talk
about
cube
test.
A
B
B
I
wrote
out
a
few
bullet
point.
The
things
I
currently
have
in
mind
that
we
want
to
resolve
and
improve
on
and
the
few
goals
some
code.
The
main
pain
point
I
feel
these
days
is
we
lack
of
so
Q
test
is
actually
very
powerful.
It
can
do
a
lot
of
things,
but
we
really
lack
of
examples
and
dogs
on,
like
example,
how
to
run
tests
locally
or
how
to
run
tests
within
an
existing
cluster,
and
there
were
too
many
really
too
many
flags
to
manage.
It
was
in
queue
test.
B
If
you
look
at
package
main
there's
like
two
or
three
hundred
flags
across
maybe
ten
different
files,
and
even
people
like
me,
didn't
remember
like
what-
which
each
flag
means
and
also
we
have
a
giant
underlying
layer
of
Bosch.
We
we
want
to
get
rid
of
them
like
for
years,
but
we
never
been
able
to
for
Campo
the
famous
accent
Oy
veh.
B
B
Speaking
of
that,
there
are
some
cool
items
we
can
use,
we
can
utilize
or
we
should
use
eyes
in
the
future.
The
first
thing
is
kind
which
span
is
working
on,
so
if
I
want
to
run
some
engine
test
locally,
I
should
not
I
should
be
able
to,
without,
depending
on
a
specific
deployer
say,
I
need
to
have
a
g-cloud
account
or
a
diverse
cluster
I
should
be
able
to
run
a
locally
with
my
my
own
communities,
binary,
relatively
easy,
and
also
even
if
I
want
to
run
from
you.
B
You
test
I
should
be
able
to
utilizing
cluster
API
to
managing
cluster
lifecycle
rather
than
cubed
and
cube
down
script
in
the
future,
and
so
some
of
the
girls
at
least
here
is
don't
you
have
a
pure
go
Oh
cute
ask
rather
than
a
zillion
script,
burying
underneath
or
a
lot
of
light
mm
shell
command.
So.
D
B
No
I
mean
we
still
want
to
support
different
kind
of
deployers,
although
currently
I
believe
the
azure
deployer
is
actually
in
package
main.
We
want
to
put
it
into
its
own,
at
least
being
its
own
package.
Ideally,
we
should
put
a
code
into
you
like
a
prior,
a
zero,
a
step
for
repo,
so
you
can
just
manage
it.
We
can
provide
an
interface
function
like
register
deployer,
so
you
can
just
include
cubes
has
been
and
registry
or
deployer
from.
B
C
It
is
I'd
want
to
send
that
this
is
Andrew
from
VMware
I.
Don't,
although
no
doesn't
seem
like
go,
plugins
have
exploded
in
popularity.
The
way
they
thought
they
would
I've,
don't
know
a
lot
of
deep
dice
on
those,
and
there
is
a
way
to
make
those
work
to
your
advantage
here
and
the
best
way
I
can
describe
go
plugins
is
it's:
it's
like
building
patchy
with
the
functionality
that
you
want
at
Build
time,
but
not
necessarily
loading
it
at
runtime.
C
E
E
That's
in
the
doc,
okay,
sorry
I.
Think
one
of
the
big
things
is
that
like,
for
example,
with
the
cluster
API,
we
can
probably
just
say
like
here's,
the
cluster
API
config
and
move
instead
of
having
like
200
top-level
cube
test
flags
for
configuring
that
cluster,
you
just
specify
the
config
and
pass
it
to
the
cluster
API
and
move
all
of
that.
Mangalam
cube
test
flags
and
cream
flags
for
another
binary
on.
E
We
can
probably
actually
standardize
that
pattern
and
like
hey,
without
even
necessarily
using
plugins,
treating
them
like
plugins
at
least
gets
us
to
the
point
where
we
stop
having
everyone
just
like
register
global
things
and
we
scope
of
the
player
to
a
package
and
at
the
same,
the
command
line.
Something
else
I've
thought
about
that
is
in
here.
I
think
cube
test
should
probably
grow
some
tooling
for
I,
don't
think
we
can
totally
get
rid
of
shelling
out
other
commands.
E
For
example,
building
kubernetes
is
going
to
be
like
calling
another
command,
but
I
think
something
that
we
should
get
away
from
is
kind
of
like
how
ad
hoc
that's
implemented.
I
think
we
should
make
some
tooling
for
manage
like
present
alert
right
now.
We
we
get
get
cube
right
now.
We
just
kind
of
like
dump
that
somewhere
I
think
probably
we
should
add,
as
cube
test,
should
have
some
tooling
for
making
like
a
holder
and
managing
copies
of
the
scripts
and
things
there,
and
we
should
build.
E
Some
good
tooling
for
like
here,
is
how
you
shell
out,
like
example,
right
now,
we
construct
bash
strings.
We
should
probably
construct
argument
vectors
instead,
like
I
I,
think
we
do
also
want
the
deployers
and
go
but
I,
don't
think
what
we
actually
need
from
those
is
necessarily
like,
say:
compiling
them
cube
dust
I
think
actually
might
be
better
if
they
weren't.
E
So
the
binary
is
not
so
big
and
they
may
be,
like
you
know,
download
a
plug-in
or
something
but
having
them
written
in
something
like
go
gets
us
away
from
like
this
is
a
brittle
shell
script
and
we
basically
have
a
brittle
shell
command.
Calling
another
brittle
shell
command.
I
think
we
need
we
need.
C
Likes
but
I
think
what
you
said
earlier
was
was
my
biggest
thing
and,
and
you
and
I
talked
about
this
a
couple
weeks
ago,
I
think
even
you
weren't
necessarily
clear
on
it
either.
So
that
tells
me
how
complicated
it
is,
but
all
of
the
the
shell
scripts
and
that
you
get
when
you
download
the
kubernetes
that
it's
hard,
GZ
I
believe
in
the
cluster
area.
It's
like
okay,
so
these
match
up
with
some
of
the
deploy
or
some
of
them
don't
and
oh
there's
no
go
equivalent.
A
C
A
Cluster
API
talks
about
lack
of
running
tests
locally,
and
we
think
we
can
get
get
away
from
that
by
using
kind.
So
the
underneath
a
layer
of
fast
scripts,
there's
there's
ete
kinko.
I
don't
think
we're
talking
about
replacing
gingko
as
part
of
this
effort.
Is
that
correct,
great
okay,
so
that
that
script
would
continue
to
exist?
Or
would
we
just
construct
the
set
of
blocks
that
we
passed?
He
can
go
further
up
the
inside
of
code
test,
the.
E
Ladder
we
have
some
work
on
this
today,
but
it's
not
rolled
out
to
everyone.
I
think.
One
of
the
biggest
reasons
we
need
a
v2
is
that,
since
cube
test
runs
all
over
the
place,
it's
really
hard
for
us
to
like
make
a
breaking,
but
if
we
were
to
start
over
some
things,
like
you
know,
less
lush
Bosch
calls
more
like
calling
a
well-defined
command
minimizing
number
of
flags.
E
A
E
Mean
I
think
we
should
push
things
in
that
way,
but
I
don't
think
we
can
like
I,
think
that's
that
is
itself
kind
of
a
big
scope.
We
should
look
towards
pushing
deployers
holds
big
butter
and
like
possibly
we
could
decide
that
we're
just
not
going
to
integrate
once
that
are
that
poorly
behaved
in
the
new
world
okay
mean
so
right
now.
One
thing
like.
C
A
So
hippy
is
right.
We
we
I
did
say
I
wanted
to
time
box.
Our
discussion
here
so
I
think
there
is
a
lot
of
interest
in
this.
These
do
sound
like
good
ideas
to
me.
It
seems
like
the
next
step
is
to
figure
out
where
we're
hoping
to
land
some
parts
of
these
and
see
like
a
design
proposal,
but
I
think
these.
These
all
sound
great,
selfishly
I,
want
to
understand.
I
can
catch
up
with
you
offline.
How
much
of
this
we
want
to?
B
A
F
Thank
you,
so
I'm
I'm,
basically
here,
because
I
have
a
an
open,
pull
request
and
an
ongoing
discussion
with
Timothy
about
that
pull
request,
and
he
suggested
that
I
come
to
this
meeting
again.
I
did
a
presentation
before
I
started
with
a
general
outline
of
a
concept.
I,
don't
know
a
few
few
months
back
and
at
that
time
we
had
identified
I
think
three
main
problems
in
the
current
end-to-end
test
binary
and
in
it's
basically
of
a
complementary
part
to
cube
test.
F
It's
the
one,
but
you
actually
run
inside
a
class
or
against
the
cluster,
the
what
what's
in
humanities
and
a
test
and
ii
ii
ii
ii
ii,
but
has
that
produces
a
gingko
by
honoré,
giving
good
test
suite
and
that's
the
one
that
I'm
working
on
I
and
I'm
facing
similar
issues
with
of
cube
test
and
provider
dependencies
in
that
code.
So
for
background.
F
F
So
all
of
these
packages
get
imported
when
someone
tries
to
use
free,
end-to-end
framework
I've
tried
to
vendor
in
the
existing
end-to-end
framework
into
my
own
project
with
depth,
and
it
was
horrible
just
chasing
down
the
dependency
tree
and
finding
out
the
right
words.
The
referee
was
just
almost
impossible.
It
was
possible
in
the
end,
but
a
lot
of
work,
so
I
tried
to
figure
out
whether
that
is
really
how
things
need
to
be
or
whether
that
can
be
changed
the
path.
The
other
related
path
was
when
I'm
writing
a
test.
F
F
So
now
I
could
write
tests
you,
the
framework
I
just
can't
really
import
it
into
my
project
and
that's
what
I'm
trying
to
fix
with
this
bull
request,
as
I
said
for
current
status,
is
that
we
end-to-end
framework
itself
a
rather
large
package
contains
the
codes
of
a
skin
contains,
basically
all
the
utility
code
in
one
package,
including
the
provider
specific
calls
and,
as
a
result,
the
test
binaries
that
get
published
by
communities
also
depend
on
those.
This
is
not
a
problem
for
me.
F
I
would
write
my
own
end-to-end
test
definition
at
Inter
and
go
file
where
I
basically
define
what
I
wanted
to
find.
What
kind
of
providers
I
have
if,
if
Cuba
natus
decides
to
support
AWS
GCE
and
all
of
those
in
one
binary,
I
don't
have
a
problem
with
that,
but
I
need
to
get
V.
The
core
framework
changed
otherwise
I
I
can't
use
it.
So
what
I
started
doing
is
I.
Looked
at
all
the
direct
calls
to
God
providers.
F
Usually
you
can
find
them
in
the
source
code
with
an
if
check
if
provider
is
GCE
then
do
this
if
it's
AWS
do
that
and
what
I've
done
is
I've
taken
that
code,
those
locations
where
we
have
these.
If
checks
and
I've
created
an
abstract
interface,
I'm
calling
it
provider
again,
it's
perhaps
a
porno
name
choice
and
perhaps
bet
through
Timothy
off
its.
It's
really
the
same
call
that
already
is
in
the
framework.
It's
just
getting
moved
into
separate
packages
and
it
gets
hidden
or
it
gets
accessed
by
an
abstract
API.
F
And
then
there
is
a
registration
mechanism
where
a
certain
implementation
of
that
interface
can
say.
Well,
I'm
I'm
provided
GCE.
If
someone
chooses
GCE
on
the
command
line,
call
my
coat.
That's
that's!
What
for
pull
request
does
in
the
code
that
gets
called
it's
exactly
the
same
one
as
before?
It's
just
refactored
and
and
made
optional,
because
the
framework
itself
just
needs
via
the
interface
and
some
implementation
of
the
interface.
F
But
it
doesn't
actually
pull
in
the
implementations
that
gets
done
by
the
author
of
a
test
suite
by
importing
the
provider
specific
packages
and
then
an
init
function
involves
basically
adds
themselves
to
a
global
table.
That
says,
we
have
provided
a
support
for
GCE
for
AWS,
or
we
don't,
and
if
we
don't,
we
just
end
up
with
a
default,
which
is,
you
can
run
again
against
a
local
cluster
and
it
just
uses
the
the
official
kubernetes
api
s
and
nothing
else.
F
F
There
I
moved
the
ingress
code
into
a
new
package
and
it
still
calls
I
think
just
Google
Kukla
a
G
cloud
directly
for
most
of
the
work,
but
it
needs
to
do
but
because
it's
now
a
separate
package,
it
doesn't
necessarily
end
up
in
my
test
suite
unless
I
want
to
use
a
test
that
uses
it,
of
course,
but
for
that
this
particular
code
is
not
something
that
I
have
that
I
would
use
for
it.
Personally,
so
I
don't
care
and
then
I'm
also
interested
in
importing
some
tests.
F
That's
an
ongoing
activity
in
this
sick
storage,
where
we
are
looking
at
the
entry
tests
and
how
they
could
be
applied
to
external
components.
That's
pretty
much!
What
I'm
working
on
I'm
working
on
a
CSI
driver
and
I
want
to
use
the
same
tests
in
my
tests
within
my
end-to-end
testing,
which
isn't
running
in
Cuba
Nettie's.
It's
not
it's
not
the
upstream
and
to
end
test
binary,
but
I
want
to
use.
E
F
That
is
I
think
it
would
make
sense
yeah
that
would
be
further
out
right
now.
I
think
this
is
just
this
pull
request
is
a
first
step,
which
is
already
usable,
I,
have
a
test
repository
and
on
my
github
account
where
I'm
setting
up
a
CSI
end-to-end
repository,
which
vendors
in
the
core
framework
and
has
its
own
test
suite
just
as
proof
of
concept
so
yeah
it
is.
F
Would
make
sense,
but
the
future
direction?
That
is
where
I'm
currently
uncertain,
where,
where
Timofey
is
going
because
he
he
started.
Commenting
on
some
aspects
of
the
poll.
Question
saying
that
this
is
not
the
direction
we
want
to
go
without
saying
what
the
direction
is.
I
think
I'm,
getting
my
my
impression.
Is
that
he's
trying
to
not
have
any
vendor
specific
codes
in
kubernetes
I.
E
Believe
that
is
eventually
the
direction
of
the
project
yeah.
It's
not
super
clear
exactly
when
that
will
happen
or
there's
a
bunch
of
open
questions
like
we're
still
determining
how
do
we
test
this,
but
I
think
II.
So
it
looks
like
a
big
thing.
That's
coming
up
here
is
volume
tests
and
that's
your
motivation.
I
have
talked
to
some
people
working
on
storage
in
DCP,
and
they
seem
to
at
least
in
principle,
be
an
agreement
that
really
all
of
these
tests
that
are
just
testing
GCP
storage.
E
F
Think
Michelle
is
very
much
interested
in
that
and
that's
why
she
would
love
to
get
the
spool
wickets
merge
so
that
we
can
proceed
with
setting
up
an
end-to-end
test
suite
outside
of
Cuba
natives
while
still
using
the
same
infrastructure
and
that's
just
not
not
possible
at
the
moment.
I
would
think
that
maybe.
E
The
thing
to
say,
then,
is
that
so
maybe
we
can,
we
gonna
say
that
this
is
a
stopgap,
then
I
do
think.
Probably
hopefully,
everyone
I
think
agrees
that
the
eventual
ideal
place
is
that
the
actual
vendor
tests
are
in
vendor
repos
and
that,
like
maybe
the
core
framework,
is
shared
and
reusable.
But
it's
like
an
actual
exported
thing.
It
doesn't
include
the
vendor
specific
stuff.
E
Specific
honest,
so
you
threw
out
the
Michelle
was
interested
in
this.
Do
you
think
you
can
get
her
to
help
review
I?
Think
one
of
the
problems
here
is
just
that
like.
While
we
all
want
to
see
this,
we
shall
way
too
many
things
and
given
that
like
providers
aren't
quite
to
moving
out
yet
this
isn't
like
super
high
up
on.
F
C
F
She
can
she
can
get
more
involved
with
tests
with
revenue
is
to
do
it.
Do
I
need
to
have
another
discussion
with
Timothy,
or
how
do
we
move
forward
with
with
this?
What
is
apparent
section
of
his
proposal?
I'm,
not
sure
and
I'm,
not
sure
what
what
he,
what
he,
what
he
wants
to
do
differently.
That's
my
problem.
A
A
It
certainly
looks
based
on
what
you've
said
and
what
I'm
looking
at
on
the
code
here,
that
this
is
a
stopgap
measure,
and
this
does
move
us
in
the
direction
just
because
we
eventually
want
to
live
in
a
world
where
another,
the
vendor-specific
code
is
entry,
means
that
you
have
to
block
us
from
taking
step-by-step
progress
to
that
world.
So
this
looks
really
reasonable,
but
I
would
like
to
understand
what
his
concerns
are.
The
the
one
thing
that
maybe
jumps
out
to
me
is
yeah.
A
Maybe
naming
is
hard
and
provider
may
not
be
the
best
word
for
that
abstraction.
Maybe
it's
the
sort
of
thing
that
needs
some
input
from
the
cloud
provider.
Folks,
because
maybe
this
interface
looks
an
awful
lot
like
an
abstraction
around
the
different
operations,
the
different
cloud
providers
offer
and
maybe
they're
doing
something
there.
Maybe
it's
the
different
cluster
providers,
so
I
think
we
can
stay
I,
don't
think.
F
F
A
We
can
do
an
online
chat,
we've
also
historically.
First
things
like
this
that
need
to
be
discussed
face-to-face.
We
can
schedule
breakout
sessions,
so
we
could
give
that
a
shot,
but
I
think,
let's
just
see
if
we
can't
find
a
way
to
that
pinging
team
today
and
if
we
can
schedule
something
offline
from
there.