►
From YouTube: Kubernetes SIG Testing 2018-09-25
Description
A
All
right,
hi
everybody
today
is
Tuesday
September
25th
I
am
Aaron
tricking
burger
your
host
for
today's
kubernetes
sig
testing
weekly
meeting.
This
is
being
publicly
recorded
and
will
be
posted
to
YouTube
for
all
to
see
forever
and
ever
so.
Please
keep
in
mind
that
we
have
a
code
of
conduct
on
today's
agenda.
We're
going
to
have
Steve
talk
to
us
a
little
bit
about
using
basil
for
image,
builds
and
then
Timothy
st.
A
B
B
But
I
think
the
biggest
thing
we
just
yeah
do
we
have
like
a
one-stop
button
push
that
we
can
use
to
do
all
of
the
image
builds
downstream
using
basil
today,
since
they're
docker
files,
like
I,
don't
know
I,
guess
just
making
that
change
means
that
if
openshift
wants
to
continue
using
like
latest
proud,
we
need
to
re
architect
how
we're
doing
all
of
our
image
files.
That's
a
pretty
big
shift.
So
if
you
guys
can
spare
a
little
bit
of
time
to
help
us,
then
I'm,
okay,
with
those
changes
completely
I.
C
Can
help
with
that
I
mean
we
for
the
most
part
use
basil
for
all
of
our
images,
so
it
should
be.
You
know,
especially
if
you
are
able
to
get
basil
somewhere
in
your
tool
chain
that
should
work
pretty
well
but
yeah.
We
should
talk
about
that
or
if
somebody
else
wants
to
help,
I
am
happy
to
defer
I,
don't
Katherine.
Are
you
interested
in
sorry.
A
D
A
A
D
E
C
C
You
know
the
state
testing
team
on
a
weekly
or
whatever
basis,
sort
of
push
out
like
a
you
know,
official,
maybe
semver
typed
version
of
prowl
or
something
that's
like
tagged,
and
then
it's
available
for
people
to
use
if
they
want,
but
I
also
do
agree
with
proud
of
it
or
what
I
mean
sorry
I
do
agree
with
Cole
that
there
we
shouldn't
make
it
to.
You
know
onerous
for
someone
who,
for
whatever
reason
wants
to
have
you
know
provenance
over
their
own
builds.
C
D
Not
saying
we
should
make
it
harder
for
them
to
build
I'm
saying
we
should
make
it
easier
for
people
to
not
have
to
build
because
a
lot
of
the
consumers
don't
shouldn't.
We
should
be
getting
to
a
point
where,
like
the
binaries
worth
without
modifying
them,
and
we
like
Auto
push,
builds
on
yeah.
It's.
B
It's
not
as
much
that
we
have
any
changes
that
we
hold
on
top
of
I.
Don't
think!
Maybe
some
of
the
basic
you
used
to
have
to
for
the
style
sheet
in
for,
like
the
yeah.
F
B
For
those
small
things,
but
also
like
what
I'm
doing
experimental
pushes
and
if
I
notice,
like
I,
don't
know,
there
was
a
bunch
of
point,
points
were
like
we
merged
some
like
really
awesome,
tight
improvements.
That
also
happened
to
be
totally
broken,
and
it
was
nice
for
me
to
test
things
quote-unquote
in
production
and
build
my
own
images
and
hold
little
commits
here
and
there
yeah
so
as
like
a
downstream
consumer.
B
D
No
I
just
want
added
like
right
now,
the
we
do,
publish
images
and
people
are,
is
expected
to
use
those
if
they're
not
trying
to
customize
the
like
build,
but
we
don't
push
them
for
like
every
commit
it's
just
kind
of.
Whenever
we
decide
to
bright,
we
shouldn't.
We
should
automate
that
away
so
like
if
there's
a
pro
commit,
there's
an
image.
Yeah.
B
And
I
mean,
like
the
other
interesting
thing
here,
is
so
like
a
docker
file
as
the
currency
of
contain
image
building,
like
obviously,
there's
massive
drawbacks
to
like
that
approach,
but
like
it
is
an
accepted
standard,
there
are
a
million
ways
to
use
it.
It's
interoperable,
like
OpenShift
as
a
system
supports,
like
my
fork,
I've
tested
for
when
a
new
commit
gets
pushed
to
there
I
automatically
get
image
rebuilds.
You
know
they're
scheduled
into
my
cluster
the
same
way.
B
D
B
D
C
B
B
B
The
reason
I'm
gonna
be
in
Europe
is
because
the
rest
of
the
team
is
there
break,
but
cool
that
sounds
good
yeah.
So,
let's
just
like
see
how
it
works
as
long
as
it's
like
not
cuz,
I'm
gonna,
be
honest.
I,
don't
understand
basil
like
to
any
extent,
as
noticed
by
like
my
comments
today
in
the
state
testing
chat.
So
it
just
seems
it's
scary.
So
if
we
can
make
it
less
scary,
if
we
make
it
easy
like
I'm
totally
for
it
so
hope.
C
A
G
A
A
F
So
we
talked
about
this
a
while
ago
about
the
the
coop
khun's
container
contains
a
bunch
of
other
details
and
information.
That's
germane
only
pretty
much
tested
from
and
we
wanted
to
get
a
canonical
version
of
the
conformance
tests
in
upstream,
because
we
don't
have.
We
have
deal
maintained
it
for
a
period
of
time,
but
it
makes
no
sense
for
us
to
do
that,
and
people
want
to
have
it
on
a
per
PR
basis
for
them
to
be
able
to
evaluate.
So
we
just
want
to
get
that
pushed
up
as
part
of
the
release
degree.
F
F
F
The
node
intent
test
suite
is
useful
as
a
precursor
to
evaluate
if
their
installs
are
seen,
and
we
do
have
some
wrapper
scripts
for
how
we
execute
and
I
do
need
to
make
some
changes
to
the
intent
test
suite
in
order
for
it
to
play
nicer
on
some
deployment
environments,
but
that's
pretty
much
it
so
it's
basically
a
set
of
script
wrappers
for
execution.
So
that
way
we
can
clean
the
we
can
clean
up
nicer
on
environments
where
you
know
it's
not
just
running
into
a
desk
reading.
C
F
D
F
D
That
one
very
recent
change
that
is
an
auto
discoverable
and
I,
don't
think
it's
easy
to
auto
discover
there
I
mean
so
some
of
these
things
should
just
move
out
anyhow
like
we're
trying
to
get
cloud
provider
stuff
out,
but
in
the
meantime,
there's
at
least
one
GCP
storage
thing
where,
if
it
doesn't
have
this
like
supplied
service
account
key
it's
going
to
generate
one.
We
really
need
the
e
to
be
test
not
to
be
generating
a
service
account
key
file
for
every
time.
They
run.
D
F
To
be
honest,
like
there,
with
the
work
that
Lukas
has
been
doing
for
component
configuration,
there's
no
real
reason
in
the
long
haul,
it
could
be
totally
introspective
right,
we
should
be.
We
should
be
able
to
grab
the
config
Maps
for
the
component
configs
for
the
difficult
one.
It's
an
instantaneous
ly
detect
what
provider
is
is
there
and
what
features
have
been
labeled
in
the
very
long.
D
Term,
all
storage
providers
and
all
the
providers
are
moving
out
as
well.
Hopefully
we
will
be
testing
that
storage
provider
with
some
other
tooling
out
of
tree
anyhow.
I
mean
it'll,
probably
be
the
same
thing,
but
it
it
won't
literally
be
that
huy
image
yeah
in
the
shorter
term.
We
still
need
ways
to
like
plumbing
through
stuff,
like
that.
D
C
Tim
is
there
a
document
to
sort
of
you
know
shows
what
the
interface
of
the
image
is
that
is
currently
used,
so
that
we
can
make
sure
the
new
one
does
the
same
thing,
because
and
I
assume
what
you
want
is
a
published
image
right,
because
we
already
do
publish
the
Yui
binary.
Is
this
like
a
tarball
but
I
assume
you
want
something
that
someone
can
just
you
know,
cube
control
apply
or
whatever
and
it'll
run
conformance
tests?
Yes,.
F
C
F
The
other
next
topic
was
the
intent
test
refactoring
in
order
for
be
able
to
import
it
because
I
don't
know
if
anybody
else's
besides
me
has
I
know.
Steve
has
but
openshift
kind
of
eats
the
whole
test.
Suite
Clayton's
modifications
is
like
nom
nom,
your
tests
are
delicious,
but
the
problem
with
that
approach
is
that
you
can't
import
the
framework
cleanly.
You
have
to
do
a
bunch
of
hacks
because
of
staging
and
all
the
other
stuff
that
goes
along
with
it.
F
So
the
there's
no
way
anyone
can
import
a
framework
and
try
to
run
test
and
part
of
the
work
that
I
believe
Phillip
was
trying
to
do
was
to
to
disentangle
some
of
that
stuff
and
to
get
a
depth
graph,
which
was
a
little
more
sane
ish.
The
problem
with
his
PR
is
that
it
is
large
and
conflating
a
bit
I'd
like
to
separate
out
pieces
one
at
a
time
and
he's
in
a
different
time
zone.
A
Was
just
gonna
say,
I
was
under
the
impression
he
had
pushed
that
large
PR
forward
to
make
sure
he
was
heading
in
the
right
direction,
but
I
agree.
It
needs
to
be
broken
down
into
smaller
commits
for
reviewer
consumption,
with
your
mention
of
staging
and
a
same
def
graph.
I'm
wondering
is
the
goal
here
to
make
sure
that
the
framework
is
something
that
lives
out
of
tree
or
would
it
still
live
inside
of
KK
and.
F
That
would
it
I
I,
don't
think
I,
don't
think.
In
all
honesty,
anything
is
going
to
live
out
of
KK
in
the
near-term
future.
Even
in
the
medium
term,
future
I
know
people
have
they
push
it
into
staging
and
I.
Think
staging
is
an
appropriate
location
for
it
eventually,
but
I,
don't
I,
don't
see
it
actually
getting
out
of
tree
yeah.
A
B
F
It
just
it's
just
import
cycle
of
doom
right.
The
problem
is,
it
depends
upon
it's
like
picking
up
like
one
strand
of
a
yarn
ball
and
it
picks
up
the
whole
yarn
ball.
It's
so
that
that's
just
the
problem
with
some
of
the
internal
code
and
disentangling
it
is
a
non-trivial
work.
So
the
you
know,
I
I,
applaud
him
for
his
efforts.
F
I
just
think
that,
in
order
for
us
to
take
some
of
those
efforts,
we
need
to
break
down
the
problem
a
little
more
discreetly
to
talk
about
each
topic
at
a
time,
namely
like
what
Steve
was
talking
about
earlier.
The
cloud
provider,
integration
incident
and
test
Suites
is
kind
of
a
little
bit
of
weird,
thorny
enos,
and
some
of
the
changes
that
he
made
with
there
was
actually
he
integrated
the
cloud
providers
directly
into
the
test.
That's
actually
the
opposite
direction
that
we
kind
of
want
to
go
in
the
long
haul.
D
You
wind
up,
okay,
we'll
use
ginkgo
and
we'll
build
an
e
to
e
dot
test,
but
we'll
actually
have
to
like
right
around
framework
packagin
like
it
winds
up
being
kind
of
the
same
thing,
but
not
really
I
think
be
really
good
if
we
could
get
all
of
the
kind
of
like
kubernetes
ecosystem
projects
using
more
or
less
the
same
cooling
for
this
and
right
now,
that's
not
really
feasible.
Yeah.
F
There's
there's
other
refactorings
that
need
to
occur
the
test
suite.
There
is
one
PR
that
regionally
recently
came
in,
or
one
issue
that
recently
came
in
that
we
should
probably
add
to
the
conformance
test.
Requirements
is
like
you:
shouldn't
need
SSH
keys
into
the
actual
images
themselves.
Okay,
that's.
D
We
we
should
look
in
doctors,
there
I've
been
looking
at
too
late.
We,
you
know
we
probably
want
to
promote
more
stuff
to
conformance
and
I've,
been
looking
at
well,
what
do
the
into
in
tests
typically
require,
and
it's
kind
of
all
over
the
place
from
binaries
on
the
host
to
like
using
an
ax,
Center
and
running
sudo
on
the
hosts
like
we
might
want
to
even
revisit
kind
of
standards
for
what
we
expect
into
intestine
to
otherwise
we're
just
going
to
have
a
lot
of
tests
that
we
can
never
promote
because.
D
B
B
A
Because,
like
it
appears
to
me
or
better
or
for
worse,
the
reality
of
the
day
is
there
is
no
real
sync
owner
for
the
e2e
framework
code
base.
So,
like
I
can't
go
tap,
somebody
on
the
shoulder
and
say:
hey.
Could
you
please
come
back
over
here
and
take
over
ownership
of
this
codebase,
we're
all
big
fans
of
the
codebase
getting
made
better
but
I'm,
not
sure,
specifically
what
you're
asking
for
and
how
we
can
help.
A
Agree
completely
I
think
one
specific
facet
of
the
framework
I've
been
trying
to
untangle
lately
is
around
upgrade
tests
and
I
know.
There's
been
this.
This
ongoing
theme
that
sued
cluster
lifecycle
doesn't
own
any
of
the
contents
of
the
cluster
directory
and
the
bash
scripts
they're
in,
but
there
are
a
whole
bunch
of
tests
that
are
tagged
as
like
feature
master
upgrade
feature
cluster
upgrade
and
whatnot
that
are
part
of
the
e2b
framework
thing
and
I.
A
F
F
So
we
can
take
this,
you
know
I,
think
we
can
file
an
issue
and
like,
but
you
know
we
can
shop
it
around
sequester
lifecycle,
but
I
can't
I,
don't
think,
there's
anyone
at
least
that
I'm
aware
of
that
wants
to
own
that
stuff,
we're
having
troubles
owning
the
testing
infrastructure.
We
currently
have
sure.
A
A
So
yeah
we
are,
we
are
more
or
less
at
time.
I
did
just
want
to
give
anybody
who
has
any
strong
objections
on
us.
Dropping
our
state
testing
meetings
in
favor
of
increased
breakouts
a
chance
to
speak
up
here.
I
know
I've
heard
from
Steve
who's
probably
been
the
most
active
attendee
out
of
this
group,
which
I
totally
see
and
hear
and
comprehend
the
thumbs
down,
but
I
think
like
breakouts
would
be
ideal
Aaron
can
you
can
we
instead
have
a
daily
three-hour
meeting
just.