►
From YouTube: Kubernetes SIG Testing - 2020-06-16
Description
A
Hi
everybody
today
it's
Tuesday
June
16th
and
you
are
at
the
kubernetes
suggesting
finding
the
living
we
have
here
here
to
the
kubernetes
code.
Conduct
at
this
meaning
basically
means
beyond
berryfest
itself
and
we're
recording
this
meeting
so
that
it
can
be
person
to
you
to
talk
with
me
later.
I
am
your
host.
I
can
go
there
and
you
have
a
couple
things
on
the
agenda
today.
A
C
Thank
you
very
much
so,
just
to
pick
it
up
and
I'm
gonna
be
a
little
bit
more
I'm
gonna
be
a
little
bit
verbose,
just
to
make
sure
that
I
don't
lose
track
of
any
important
details
for
this
work
for
for
the
testing
Commons
plan.
So,
overall,
a
one
huge
thing
that
we
want
to
do
in
testing
testing
comments
is
to
clean
up
they
end-to-end
test
framework,
which
is
located
under
KK
test
into
E
framework.
It
def
whole
piece
of
code.
C
We
want
to
make
sure
that
it
is
well
maintained
its
readable
that
people
can
actually
take
a
look
at
it
know
in
at
least
in
at
least
under
standard
and
to
work
on
it
as
much
as
possible
to
prevent
any
obscure,
obscure
box.
To
that
end,
we
won.
We
were
thinking
about
proposed
in
the
mood
to
staging
so
move
the
test,
the
test
framework
from
KK
test
into
E
framework
into
someplace
into
the
staging
directory.
C
They
be
the
biggest
motivation
for
really
happening
into
staging
these,
so
that
people
who
are
already
important
the
framework
they
can
do
so
without
actually
importing
the
rest
of
kubernetes
its
own.
So
they
just
have
told
a
handful
of
utility
test
functions
which
are
used
for
end-to-end
tests
and
for
the
most
part,
a
lot
of
people
actually
import
that
framework,
because
they
are
using
the
what
is
called
the
test
context,
which
is
essentially
a
configuration,
a
configuration
that
lives
within
the
test
framework
it
needs.
C
It
is
used
in
conjunction
with
a
lot
of
other
utilities
we
use
for
into
a
for
end-to-end
test,
so
people.
Some
people
may
already
have
a
lot
of
interest,
a
lot
of
tools
built
to
to
essentially
replicate
and
twenty
end-to-end
testing
jobs
in
the
way
that
they
run
in
in
KK.
They
might
replicate
the
same
world
for
a
workflow
in
so
on,
CSI,
plug-in
and
the
like,
and
that's
why
that's
why
they
imported.
So
that
was
a
proposal
and
we
wrote
like
a
real
broad,
a
cap.
We
testing
comments,
I'm
gonna,
say
we.
C
C
Please
any
comments,
questions
suggestions,
criticisms
are
more
than
welcome
and
the
plan
is
to
have
it
for
120
all
all
set
up
and
ready
for
testing
comments
to
do
something
that's
going
to
make
the
framework
better,
but
for
right
now
for
one
anything,
I
also
wanted
to
ask
and
try
and
throw
ideas
off.
You
know
under
the
premise
I'm
moving
the
the
moving
the
framework
to
staging
it's
going
to
be
useful,
and
it
is
something
that
we
should
do
a
and
that
really
based
on
the
fact
that
it
is
really
pragmatic.
C
A
lot
of
a
ginkgo
is,
you
know
some
people,
some
people
like
it,
some
people,
don't
like
it
as
much
in
the
test
count.
The
test
context
then
lives
with.
That
is
a
core
of
the
framework
same
thing:
some
people,
some
people
live
with
it.
Some
people
have
a
some
some,
a
some
other
opinions,
and
this
whole
move
is
again
purely
a
purely
pragmatic
yeah.
C
It
is
I
think
it
is
a
hope
for
a
lot
of
people
that
we
can
build
on
it
and
improve
on
it
once
we
actually
clean
it
up
and
the
cup
away
from
the
rest
of
cover
nails
for
good
for
right
now,
we
just
want
to
decouple
it
to
allow
for
that
work
to
be
easier
in
the
future.
So
I
guess
I
guess
like
to
pay
like
that.
First,
like
that,
a
that
first
idea
of
just
making
this
more
purely
purely
pragmatic
and
trying
to
solve
these
issues
it
does
anyone
have
any
comments,
questions,
thoughts,.
A
D
A
Number
of
the
pieces
that
are
currently
important
and
to
be
framework
come
from
other
directories
being
the
test
directory,
so
I
feel
like
there's.
Gonna
have
to
be
me,
I
wasn't
sure
if
the
pep
talks
specifically
about
that
stuff,
so
some
of
their
utilities
are
not
like
in
the
manifests
and
things
like
that,
which
are
shared
across
a
number
of
other
pieces
of
testing
affected.
I.
A
C
The
other
kind
is
like
you
mention
where
we
have
some
other
end-to-end
tests
or
some
like
some
some
code
package
that
has
a
bunch
of
utility
functions
but
I
believe
somewhere
in
test
it.
We
apps,
you
know
just
just
to
me,
just
to
say
NX,
a
just
to
make
an
example
and
the
framework
might
actually
import
the
cake.
C
A
test,
III
apps,
a
slash
common,
it
might
imported,
and
we
also
consider
that
as
an
external
dependency
and
partly
a
part
of
the
plan
was
to
make
them
move
on
to
staging,
at
the
very
last
part
of
the
very
last
part
of
the
work,
yeah,
so
kind
of
a
kind
of
borrowing.
The
idea
of
the
future
gates.
Even
though
this
wouldn't
be
under
a
feature
away.
C
Like
the
first
phase
for
one
release,
we
make
sure
to
organize
everything
in
the
test
directory
to
to
make
sure
that
we
keep
the
things
that
should
be
in
the
framework
within
the
framework.
And
then
we
reorganize
utility
functions
in
some
other
way.
If
they
are
used
a
lot
and
we
might
remove
them
into
the
framework
so
that
other
people
can
confuse
them
from
the
framework
if
they
are
only
using
one
place
or
one
particular
set
of
tests.
C
And
we
we
factor
in
the
framework
to
move
that
in
a
piece
of
code
into
the
test
package
where
it
is
where
it
is
actually
used
and
for
external,
depending
for
external
dependencies.
You
know,
for
example,
something
that
might
be
in
package
cubelet,
CPU
manager.
If
we
make
sure
a
we
make
sure
to
try
and
use
a
decline,
go
or
some
more
official
way
of
actually
to
an
end
operation
in
a
in
terms
of
code
that
a
that
is
like
that
is
like.
E
E
E
E
C
And
that
definitely
that
I
think
that
I
think
it
makes
sense,
and
the
only
thing
that
I
can
add
on
on
that
is
that
that
was
that
was
also
that
was
also
kind
of.
It
was
also
kind
of
the
motivation
in
front
end
for
the
most
part,
a
with
within
the
framework
we
have
the
best
context
and
everything
around
the
test
context
which
might
be
which
we
hope
we
can
improve
it.
Some
later
point:
whenever
the
framework
is
a
little
bit
cleaner,
it
would
then
the
rest
of
it.
E
But
I
mean
once
you
stage
it:
it's
an
API
now
and
you
removing
things
from
the
test.
Context
will
be
breaking
for
users,
including
the
coronaries
test,
and
because
those
things
are
not
rocket.
Science
I
still
want
to
suggest
that
it
might
make
sense
to
kind
of
lift
the
things
that
are
useful,
but
not
rocket
science
into
a
new
repo
with
some
actual
design
behind
the
framework
and
say
like
this
is
best
practices.
E
That's
it
also.
If
had
they
asked
us
in
the
past.
That
would
have
said
that
you
know.
Sing
architecture
also
says
that,
depending
on
kubernetes
is
not
supportive.
If
you
need
to
stage
it
to
begin
with,
so
it
kind
of
seems
like
sending
the
wrong
well
here
that
we're
just
gonna
stage
everything
anyone
depends
on
and
that
like
that,
this
is
like
our
framework,
and
while
we
have
wound
up
with
this
in
kubernetes,
even
in
kubernetes,
I
would
I
would
like
to
replace
it.
E
A
Don't
feel
like
we've
had
this
discussion
before
about
concerns
that
staging
has
been
relegated
continue.
The
investment
of
it
would
be
better
spent
elsewhere.
I
just
feel
like,
like
I,
see
that
people
are
using
this,
so
I
don't
want
to
necessarily
block.
If
you
are
so
motivated
to
try
and
invest,
we
planted
this
I.
Don't
want
to
block
you
from
that.
I
guess
I!
Do
personally
wonder
if
your
time
could
be
better
spent
planning
a
framework
that
was
a
little
only
less
organically
grown.
A
You
actually
tried
to
do
that
under
testing
Commons
about
a
year
ago
next
month
and
that
ended
up
going
over
so
I
recognize.
This
is
kind
of
the
test
framework
that
we
have
yes,
so
and
I,
and
right
now,
I
think
like
working
to
continue
to
untangle
the
dependency
tree.
The
framework
would
be
helped,
as
I
expressed
earlier.
I
have
concerns
that
untangling
of
some
of
the
tasks
utilities
will
be
tricky.
A
The
issue
that
I
have
is
that
the
framework
is
intended
for
him
to
end
tests.
Only
and
I
wouldn't
want
to
see
utility
code
that
is
useful
for
tests
and
the
different
sort
or
access
to
different
functions,
get
bundled
up
in
the
e2e
framework.
Just
because
it
has
the
word
framework,
but
I
think
that's
something.
We
can
only
discover
if
I
think
this.
D
Am
so
so
so
so
before
this
discussion
started,
the
question
I
wanted
to
ask
George
was
what
are
the
learning
resources
for
the
framework
for
the
end
and
testing
framework
on?
Where
could
I
learn
about
this
to
basically
write
cement
and
test
using
ink?
Oh
so
that
question
still
stands
well
from
from
from
from
listening
to
this
subsequent
discussion.
E
E
I
have
actually
done
this
in
the
past.
Some
of
our
partner
projects
waterward
on
this
work
on
something
else,
and
we
hope
to
learn
from
like
a
native-
is
an
example.
They
have.
They
did
a
pretty
extensive
framework
evaluation
of
their
own
and
settled
on
as
much
as
I'd
like
to
reuse
things.
They
were
not
going
to
work
with
ginkgo
and
this
framework,
and
they
built
something
much
thinner
around
like
standard,
oh
testing,
stuff
I
believe
I
had
always
planned
to
come
back
and
build
something
from
that,
but
it
just
hasn't
been
prioritized
yet.
D
But
even
to
tell
those
stories
and
like
I
mean
yet
seal
joke
when
you
ask
an
old
Cruiser
in
Ireland
for
directions,
he'll
turn
around
and
say:
well
it
wouldn't
start
from
here.
Yet,
like
you
mean
so,
like
you
mean,
if
that
is
the
case,
then
we
should
say
that
and
point
to
examples
where
you
know
point
to
that
example
and
say
you
could
look
here,
you
could
look
there
and
ultimately,
I
think
there's
two
things:
people
are.
D
People
are
fairly
good
at
making
a
call
and
whether
or
not
to
take
on
a
tool
or
not
take
on
a
tool
whether
to
build
versus,
buy
or
improve
versus,
build
something
new
and
but
I.
Think
the
concern
about
would
the
real
concern
about
staging
being
be
that
okay?
This
is
an
endorsement.
This
is
a
this
is
an
agreement
to
support.
Is
that
a
real
consept,
the
real
concern.
E
Support
some
and
then
just
that,
like
I,
do
think
people
kind
of
cargo
cult.
What
upstream
is
doing
and
increasing
I
hate
for
the
first
impression
from
some
external
project
of
stick
testing
to
be
like
diving
through
the
RER,
the
like.
We
don't
currently
actually
owned
most
of
the
unit
tests
and
we
nominally
on
the
framework.
But
for
a
long
time
the
sig
was
not
the
guy
enjoined
years
ago.
E
This
ad
hoc,
like
extremely
type
thing,
that
we
don't
really
document
much
explaining
some
yesterday
and
like
the
output
of
the
failures,
tends
to
be
difficult
to
parse
and
unintuitive
English
and
just
like
in
general,
I.
Think
it's
a
it's
a
it's
overwhelming
and
I
frequently
seen
people
that
are
like
experienced
on
the
project.
E
Still
confused
by
failures,
so
I,
you
know
this
being
even
easier
for
some
third
party
to
come
along
and
adopt
and
have
that
be
there
and
I'm
suggesting
feels
kind
of
bad
on
the
other
end
like
I,
understand
the
motivations
of
like
the
products
of
already
using
it
and
like
the
need
to
have
something
and
that
you
know
I'm
not
saying
that
I'm
gonna
tomorrow
write
a
different
one
but
I
just
wanna.
We
can
find
some
way
to
suggest
to
that.
I
also,
don't
think
they
should
be
really
strongly
for
external
use.
A
So
I
personally
feel
like
we've
beaten
the
bed
or
so
even
as
the
staging
creates
an
API
that
you're
not
going
to
support,
and
we
have
all
sorts
of
things
that
we
don't
like
about
this
framework.
I
get
it
I
still
don't
think.
I
should
use
that
as
a
blocker
for
those
who
are
motivated
to
try
and
reduce
the
tangles
and
dependencies
that
this
creates
and
we
can
re-evaluate
whether
once
the
untangling
has
been
done
to
make
it
possible
to
move
this
to
staging.
A
If
anything
at
the
staging
is
a
good
idea,
I
kind
of
wanted
to
be
respectful
and
to
find
that
we
have
I,
could
sort
of
watch
the
about
30
minutes
for
this
discussion
and
maybe
15
for
each
of
the
following
proposals:
snow
order
to
make
sure
George
got
whatever
action
he
wanted
out
of
this
and
I
personally
had
a
question
around
one
of
the
proposed
issues
to
work
on
which
was
81
and
25.
So
it's
this
idea
that
the
core
eat
sleep
framework
shouldn't
import
any
of
the
like
packagings
underneath
of
it.
A
So
there's
been
a
lot
of
work
around
taking
some
of
these
grain
deck
utilities
if
they
used
to
always
been
like
inside
of
the
framework
package
and
the
Graduate
been
the
factored
into
like
et
me
framework
hot
eat,
we
framework
off
e
2
e
3,
more
storage.
So
if
you're
writing
a
test
that-
and
you
want
to
do
something
with
the
pod-
maybe
you
go
take
a
look
at
the
pod
package
and
you
have
like
a
clean
list
of
utility
functions.
You
can
use.
That's
great.
A
So
what
this
issue
proposes
is
one
way
to
avoid
cycles
is
to
say
that
the
framework
can't
be
import
any
package,
that's
underneath
of
it
within
packages
that
are
underneath
of
it
can
import
the
framework
so
that
they
get
access
to
some
of
the
frameworks
core
stuff.
This
is
most
often
used
for
access
to
the
frameworks,
logging
functions
and
for
access
to
some
about
the
like
expect.
90
points
expect
people
sorts
of
functions
that
we've
used
to
wrap.
Dinka
I,
don't
know
if
that's
enough
context
for
folks
than
understanding
what
I'm
talking
about.
A
But
my
concern
is
that
feels
like
the
opposite
direction
of
what
we
want
to
do.
Dr.
Golding
is
the
guy
from
safe
storage.
He
ended
up
refactoring
a
lot
of
very
work
to
move
it
just
to
try
and
get
it
set
up
stay
tuned
in
any
issue
that
talks
about
moving
a
staging
sort
of
lays
out
the
plan
that
what
would
be
ideal
is
if
each
the
framework
was
allowed
to
import
packages
underneath
of
it.
But
the
package
is
underneath
the
framework
weren't
allowed
to
report
anything
from
their
character
duties.
A
This
would
mean
that
the
directory
tree
kind
of
nears
the
dependency
tree,
and
we
make
things
nice
and
puffy
I
care
about
this
right
now,
because
I
want
to
be
able
to
provide
access
to
you
the
best
files
package
when
we've
been
permitted
like
him
for
the
important
test
files
crates
of
dependency,
his
test
files,
imports
mark
and
stuff
I
was
curious,
like
how
much
active
discussion
went
into
either
direction.
Fine,
how
were
the
only
dependency
cycles.
D
C
Did
the
same
for
if
ever
Daschle
idea,
where
the
core
framework
can
import
some
packages?
Bhutesu
packages
are
not
supposed
to
import
and
the
core
the
core
framework
in
some,
it
was
actually
designed
to
kind
of
play
along
with
it,
yet
that
we
eventually
want
to
make
the
framework
standalone
thing
that
you
can
import
without
actually
importing
the
rest
of
Coburn
eighties
and
the
mentality
was,
if
you
for
the
most
way
for
the
most
part.
C
And
if
you
and
if
that's
all
you
want
it
and
then
that's
it
and
that's
all
you
get,
then,
if
you're
worth
testing
staple
sets,
you
can
you
can
import
the
utility
functions
from
stay
away
from
it.
We
STS.
If
you
want
to
do
something
with
pots,
you
import
it.
We
age
import,
it
imported,
we
pods
and
they
I
guess
to
completely
answer
that
question
will
be
done
if
we
made
it.
The
other
way
around
were,
for
example,
Italy
pots,
which
is
as
a
package
of
the
framework
actually
imported
the
the
core
framework,
a.
A
C
Anything
else
we
need
to
move
so
just
to
just
to
pay
just
to
move
forward,
because
a
so
in
terms
of
the
the
I
guess,
implementation
details
and
everything
that
you
just
everything
that
you
just
mentioned
about
documenting
documenting.
It
definitely
think
it's
something
that
we
should
do
implementation
details,
something
that
I
also
think
should
be
documented
and
more
a
more.
C
This
gospel
over
a
put
overall,
a
really
just
taking
what
we
have
making
it
a
little
bit
more
consumable
for
the
people
that
are
already
using
it
and
with
that
premise,
a
moving
forward
with
the
with
the
cap
on
stage
in
the
framework
a
would
that
be
the
reason
aw.
That
was
a
reasonable
thing,
or
should
we
or
should
we
really
spend
a
spend
more
cycles
on
just
starting
from
scratch?.
A
Well,
I,
personally,
not
sold
on
the
captain
in
the
staging
I
would
like
to
understand
what
the
framework
looks
like.
We
know
what
dependencies
we
have
to
untangle
in
order
to
move
it
to
staging
and
I
feel
like
I
would
like
to
see
us
plan
that
out
a
little
more
and
so
some
of
that
we're
going
to
do
by
doing
some
of
the
work
you
have
proposed
to
try
shuffling
things
around,
but
we're
also
going
to
sort
of
document.
A
Why
we're
doing
the
things
we're
doing
in
what
and
staking
expect
to
get
that
and
then
I
think
we
can
have
a
better
idea
of
whether
it's
what
moving
is
to
staging
is
something
that
cavers
are
willing
to
support,
or
you
know,
be
put
a
huge
disclaimer
saying
morning.
This
is
actually
completely
unsupported.
It's
just
been
gradually
shown
to
staging
by
these
few
contributors
here
using
their
apparel,
like
whatever
I,
always
think.
There's
there's
work
finding
a
simple
way
but
I
like
them,
I'm
not
going
to
be
the
person
to
invest
if
I'm
doing.
D
A
I,
don't
think
I
should
be
forcing
you
to
do
that
either.
Listen,
so
you
can
just
sort
of
our
opinion
born
out
of
you
feel
like
there's,
probably
a
better
way,
then
in
the
hot
fudge,
but
take
a
look
myself
out,
but
that's
what
we're
gonna
go
with.
If
you
want
the
back
that
allows
you
to
do
incremental
iterative
progress.
C
Okay,
so
that's
not
reasonable
and
really
looking
for
the
way
forward
for
a
for
tasting
comments.
So,
in
my
from
my
perspective,
I
feel
like
a
lot
of
what
you
just
mentioned.
A
should
be
part
of
the
I
feel
I
feel
like
a
lot
of
the
a
lot
of
the
refactoring
and
everything
that
you
should
mention.
It's
work
that
we
should
do
a
regardless
of
the
cap
in
terms
in
terms
of
just
make
a
just
making
the
framework
more
a
consumer
consumer.
D
A
F
A
A
F
Yes,
okay,
so
for
folks
who
don't
know
cube,
test2
was
one
of
the
projects
that
me
started
around
a
year
back
and
it
was
basically
meant
as
sort
of
a
replacement
for
cube
test,
and
that's
because
you
test
suffered
a
variety
of
problems
because
it
became
a
tangled
mess.
That
was
the
sort
of
organically
grew,
because
all
of
the
diploid
logic
is
consolidated
in
this
monolithic
binary
and
that
sort
of
led
to
why
we
created
cube
test
two
in
the
first
place.
F
To
add
to
that,
this
is
sort
of
just
an
updated
list
of
proposals
that
we
should
like.
We
should
look
at
as
they
testing
or
to
make
sure
that
we
follow
through
on
what
we
decided
regarding
cube
this
just
so
that
we
can
sort
of
saw
the
whole
cube
this
and
make
it
more
easier
to
use.
So
there
are
sort
of
three
objectives
that
I
was
looking
at
in
terms
of
the
new
updated
to
phase
2
proposal,
one
of
them
being
to
also
decoupled
the
tester
lifecycle
from
the
deployed
life
cycle.
F
So
in
the
initial
design,
doc.
The
main
motivation
of
moving
to
confess
to
was
separating
out
the
diploid
logic
from
the
core
cube
test
binary,
and
that
just
means
that
each
individual
deployer
has
it's
sort
of
own
binary.
That
has
the
logic
for
whatever
it
does
to
create
a
cluster,
and
that
is
not.
F
That
does
not
touch
the
code
for
any
other
deployers
so
previously
in
cube
test
all
the
deplore
logic
in
sort
of
this
one
binary,
which
had
which
had
thousands
of
flags
to
make
to
select
which
deployer
and
then
the
specific
deployer
customization
was
done
by
had
thousands
of
flags,
and
they
were
all
in
this
one
binary,
which
is
why
we
sort
of
removed
the
deployers
from
from
the
main
clipped
is.
Finally,
what
this
proposal
is
asking
us
to
do
is
we
should
also
decoupled
the
testers.
F
So
in
the
initial
proposal
the
testers
were
still
four
as
implemented
as
packages
inside
which
the
deployer
then
called.
Instead,
we
should
also
decoupled
the
testers
in
two
separate
wineries
and
the
wave
tube
tests
to
call
these
binaries
it
is.
It
uses
a
plug-in
model
similar
to
what
Cube
shuttle
does.
So
if
the
deployer
is
named,
you
place
deploy
name
then
it
uses
then
cupid's
to
basically
calls
the
deploy
in
its
lifecycle.
F
If
anyone
has
tried
using
cube
test
locally,
it's
a
real
pain
and
then
most
likely
people
refer
a
job
in
a
CI
job
in
the
broken
head
and
try
to
replicate
that
locally,
and
it
doesn't
work
because
stuff
words
differently
in
CI
than
in
local.
So
this
is
sort
of
one
of
the
things
that
we
should
fix
is
that
we
should
firstly
identify
that
the
local
use
cases
is
bound
to
be
different
than
the
CI
use
case,
and
then
we
should
try
to
make
sure
that
it
works
for
both
the
use
cases.
F
Firstly,
the
first
puzzle
is
mainly
to
make
sure
that
we
marked
cutest
explicitly
in
maintenance
mode,
so
it
has
been
in
maintenance
mode,
a
sort
of
for
a
couple
of
months
now,
which
means
basically
no
one
has
been
adding
any
features
to
it,
and
then
only
bug
fixes
are
being
allowed
to
go
in
I.
Think
if
we
are
planning
to
move
to
the
tube
test
world,
we
should
actually
start
acknowledging
that
cutest
is
no
longer
supported
or
cutest
cutest.
F
One
is
no
longer
supported
and
sort
of
mark
sort
of
documented
somewhere,
and
we've
done
this
something
similar
to
the
scenario
script
that
we
have
in
our
bootstrap
lifecycle.
So
this
is
just
making
sure
that
we
document
that
the
next
two
proposals
deal
with
the
naming
scheme
for
the
deplores
and
testers.
So,
as
I
said
mentioned
earlier,
cube
test
two
uses
the
plug-in
model,
but
previously
only
deploy
ads
were
separate.
F
Binaries
and
testers
were
in
entry
packages,
but
now
that
we
are
planning
to
move
out
the
deplores,
we
should
also
think
about
naming
the
deploys
and
testers
separately
and
the
way
we
should
we
we
can
do.
That
is
basically
just
add
a
cube
test
to
deployer
in
front
of
the
provider
name
and
then
cube
test
to
tester
in
front
of
the
testimony.
F
F
The
next
proposal
is
about
making
this
an
official
sub-project.
So
one
of
the
reasons
why
cubist
became
such
a
tangled
mess
was
a
certain
lack
of
ownership
or
sort
of
maintenance
from
sick
testing
perspective.
So,
for
all
intents
and
purposes,
it
was
a
simple
project
that
people
added
ad
hoc
deployed
implementations
just
to
make
their
e
to
e
test
word,
and
it
was
just
something
interesting
from
that
people
added
logic
to
their
specific
logic
when
thing
broke,
but
in
sort
of
in
terms
of
having
a
good
maintenance
lifecycle.
F
We
should
probably
think
about
moving
this
to
out
of
testing
from
so
that
we
can
provide
a
correct
support
model
and
one
of
the
big
big
drivers
to
that
is
just
installing
gifts.
We
rely
on
go-getting
just
go,
get
touched
in
fact.
If
this
and
rightly
now
go
get,
it
doesn't
really
work
with
testing
from
for
some
gear
reasons.
So
that's
also
one
of
the
drivers,
my
ek,
we
should
consider
moving
it
out
and
then
also
try
to
make
this
a
sub
project.
F
The
next
two
proposals
deal
with
how
we
would
sort
of
model
the
releases
and
how
we
would
share
or
like
how
we
would
distribute
the
cube
test
binaries
or
the
cutest
core
binary
itself,
and
the
deplore
and
tester
binaries
for
using
in
CI
or
like
using
locally
the
first
one
talks
about
to
be
how
we
should
mimic
the
kubernetes
release
cycle.
The
reason
for
that
is
currently
we
already
have
separate
jobs
for
separate
release
branches,
and
they
are
mainly
this
is
being
achieved
by
having
different
cubicles
it.
F
So
this
is
sort
of
also
breaking
down
the
cube
test
to
deplores
and
testers
and
the
core
binary
to
also
follow
the
versioning
scheme
of
kubernetes,
so
that
we
can
use
the
specific
release
binaries,
which
just
special
release
branch
testing
and
then
the
CI
image
that
we
use,
as
I
said,
is
Cubans
e
to
e,
and
it
sort
of
suffers
from
some
of
the
same
problem.
That
cube
does
does
because
it
completely
relies
on
the
bootstrap,
who
is
right
now
and
cube.
F
It's
only
used
by
the
kind
jobs,
but
we
can
sort
of
like
piggyback
on
this
image
as
the
big
to
form
the
base
for
all
the
cutest
two
images,
just
so
that
maybe
not
no
longer
land
on
the
queue
conceit
we
scripts
and
bootstrap,
and
that
sort
of
stuff
and
the
last
I
think
proposal
is
mainly
to
sort
of
document
a
standard
for
how
the
deploys
should
interact
with
the
testers.
And
so
this
is.
F
This
was
meant
to
be
the
most
simplistic
and
the
most
robust
way
of
having
common
deployer
tester
interface,
so
that
we
can
actually
say
that
you
can
use
any
tester
with
any
deployer.
As
long
as
they
sort
of
satisfy
this
constraint-
and
the
only
constraint
that
really
makes
sense
is
that
the
deployer
sets
up
the
cube
config
for
tester
and
in
terms
of
like
without
the
deployer,
if
you
just
wanted
to
run
the
tester,
that
means
that
you
have
an
existing
cluster
with
cube
config
and
your
test
original
in
running
against
that
existing
test.
F
So
these
should
be
discouraged
in
general,
but
just
to
make
sure
that
they're
backwards
compatible.
The
independent
deployers
and
testers
can
like
pass
information
through
the
the
artifacts
directly
that
cube
test
to
provides,
but
like
cube,
test
core
itself
will
not
expose
any
environment
variables
through
this
way
and
that
will
basically
make
sure
that
we
are
no
longer
relying
on
these
thousands
of
environment
variables
that
we
line
the
CI
country.
F
The
next
section
just
talks
about
the
development
guide.
I
will
not
go
much
into
detail.
This
is
basically
just
best
practices
for
how
deploys
and
testers
can
be
implemented
to
follow
sort
of
what
the
about
proposals
meant
to
achieve,
and
then
the
last
part
basically
deals
with
something
what
we
should
look
at
in
terms
of
something
in
future.
F
F
We
should
sort
of
try
to
identify
a
common
use
case.
For
example,
we
rely
on
the
heartbeat
lifecycle
of
like
Reaper
janitor,
the
entire
Bosco's
lifecycle
that
we
use
in
seei
also
effect.
If
we
can
identify
some
specific
set
of
resources
that
we
support,
then
we
can
probably
move
the
individual
Bosco's
client
outside
into
the
Crypt
is
too
poor.
F
F
G
G
Yeah,
fantastic,
okay,
I
won't
take
too
much
of
your
time,
because
a
lot
of
this
doc
is
technical
details
that
are
not
that
important
for
this
discussion,
but
I'll
just
highlight
a
couple
of
things.
So,
as
Ahmed
said
cutest,
who
has
deployers
that
are
sort
of
separate
components.
This
is
one
for
GCE,
a
very,
very,
very
large
number
of
our
end-to-end
tests
run
on
GCE
clusters.
G
So
this
is
an
attempt
to
look
at
the
qubits
I
think
so
one
I
said
sorry
we'll
look
at
it.
I
wasn't
sure
if
you
had
a
window
with
you,
our
design
design
proposal.
Looking
at
the
meeting,
oh,
oh
I
do
I
think
I
scared
the
wrong
screen.
Yeah.
Sorry
about
that.
No
that's
all
right!
There
we
go!
This
is
the
one
okay
perfect.
So
this
is
a
deployer
for
GCE,
which
is
a
lot
of
what
our
end
and
test
run
on.
You
can
see
this
raw
flow
chart.
The
red
parts
here
are
bash
scripts.
G
Gc,
either
cube
test
to
look
like
only
we're,
eliminating
like
two
ish
bash
scripts
in
between
which
should
reduce
complexity,
a
lot
and
bring
us
sort
of
in
line
with
this
new
new
framework
for
engine
testing
Oh.
A
lot
of
persons
are
very
disfiguring
like
what
what
cute
test
provides
its
functionality,
what
we're
gonna
mirror
and
then
you're
through.
G
Most
pressing
frustration:
how
we're
gonna
migrate,
existing
end-to-end
tests
to
using
cube
tests
to
and
using
the
deployer
and
I
know.
Some
of
this
is
covered
in
documents.
The
comment
has
but
because
GCE
based
end-to-end
testing
is
so
critical
for
a
lot
of
our
stuff.
It's
really
worth
thinking
about
how
we're
going
to
move
tests
over
to
this.
G
G
E
A
Generating
data
that
proves
that
things
are
about
with
the
equivalent
is
helpful.
I'm
also
going
to
be
respectful
of
the
119
where
these
team,
if
they
decide
they,
don't
want
us
changing
some
part
of
how
the
jobs
run
as
we
get
closer
to
deadlines
like
Humphries
and
Trust
crew
using
stuff
like
that,
we
try
to
be
a
little
mindful
or
not
making
like
high-risk
changes
when
they're
looking
for
periods
of
stability,
but
I
think
that
this
is
the
sliding
window.
Approaches
provides
sort
of
maximum
transparency
to
help
them
make
the
ball.
E
G
A
G
A
G
This
is
something
like
investigate
like
the
SSH
bash
environment
is
something
that
needs
sort
of
some
introspection
and
I
think
for
to
find
specific
tests
that
you
did,
but
because
cube
up
and
cube
down
have
to
be
configured
with
environment
variables,
we're
just
making
it
so
that
we're
not
making
the
user
set
environment
variables
with
like
Q
test
has
like
a
dash
dash
ends,
slag,
which
is
not
great,
so
we're
going
to
try
to
like
provider
interface.
That's
just
like
flags
that
specify
specific
options
we
have.
This
was
in
computing.
E
What
we
could
also
allow
them
to
be
passed
down
just
as
real
environment
variables,
I
think.
The
problem
with
that
is.
It
makes
it
difficult
to
replicate
a
pro
job
locally,
because
now
you
need
to
go
like
park.
You
need
to
as
a
human
go,
find
all
the
environment
variables
that
were
set
and
the
job
and
set
them,
whereas
if
they're
flags
you
can
like
cut
and
paste
it
from
the
build
log.