►
From YouTube: 20190322 sig testing commons
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
So,
breaking
apart,
one
of
the
simplest
things
I
can
think
of
to
do
is
to
get
rid
of
use
of
the
internal
client
and,
as
we
start
to
piece
apart
some
of
the
tests
or
take
apart.
Some
of
the
framework
you'll
find
that,
like
you,
can
start
to
put
pieces
of
the
framework
into
composable
units,
but
it
just
just
by
getting
rid
of
use
of
the
internal
client
that
should
shrink
the
depth
graph
of
the
dependencies
that
currently
exists
inside
of
the
intent
test.
A
A
A
You
gotta
pull
it
what's,
gonna
be
funny
about
the
end.
This
whole
thing
is
that
it's
gonna
be
very
much
like
a
ball
of
yarn.
You're
gonna,
try
and
pick
it
apart.
It's
gonna
take
a
couple
times
to
like
you
know,
to
find
out,
which
is
the
thread
that
kind
of
can
undo
the
yarn
ball,
but
I
think
I
can
open
it.
A
large
issue
in
this,
like
a
tracking
issue.
D
A
They
make
the
actual
client
tooling,
so
the
like
client
go
right,
so
client
go
is
called
the
external
client.
That's
the
client!
That's
used
by
all
the
other
tools.
You
know
that
want
to
build
the
top
of
kubernetes.
So
if
I'm,
if
I'm
using
COO
builder,
for
example,
it
uses
the
external
client,
the
internal
client
is
basically
the
inner
side
of
the
client
tooling.
That
was
developed
in
the
beginning
that,
basically,
if
you
look
at
the
depth
graph
sprawl
of
some
of
that,
it
touches
everything
right.
So
you
can't
it
it's
not
factored
so.
A
A
I
think
it's
kind
of
like
you
need
to
break
apart,
how
they
can
vendor
it.
So
like
what's
the
forcing
function,
that's
the
next
thing
here.
The
forcing
function
are
people
that
need
to
use
or
vendor
the
intent.
S
right
and
I
think
we
should
start
to
define
what
are
those
requirements
like
minimizing
the
dependencies
and
I
know
Patrick's
done
some
good
work
there,
but
they're
still
I
think
the
long
way
to
go.
E
D
C
A
Mess
so
there's
there's
a
combination
of
flags,
there's
a
combination
of
Viper
and
this
this
again
this
is
all
evolutionary,
so
it
was
before
we
actually
had
component
config
I,
don't
know
if
we
use
component
config
in
the
similar
fashion
to
the
way
things
like
kind
uses
component
can
famed
for
its
versions
configuration
file.
This
might
be
a
way
for
us
to
do
that
so
factoring
out
the
variables
into
a
component
configuration
which
is
also
a
lot
of
work.
A
C
A
C
A
A
Can,
if
you
want
it
could
be
a
separate
binary
or
you
can.
We
can
add
the
QB
DM
and
to
then
test
into
this
binder
if
you
wanted
to,
but
then
we'd
have
to
quarantine
them
to
make
sure
that
they
have.
You
know
a
feature
tag
or
some
other
way
of
quarantine
e
you
could
we
could
do
it
so
that
way,
it's
just
one
binary.
We
don't
have
separate
binaries
that
we're
shipping
around
I,
don't
really
have
strong
opinions,
one
way
or
the
other.
A
C
A
I'm,
not
a
big
fan
of
that
idea.
I
mean.
Why
would
we
do
that
versus
what
we
have
today?
I,
don't
I
don't
see
compiling
it
as
it's
terrible
other
than
like
what
what
I
do
see
is
terrible
is
the
non-uniformity
inside
of
our
flag
handling,
but
I
don't
see
compiling
it
as
binary
as
being
terrible,
terrible
I.
C
F
A
A
A
C
C
A
Right
I
do
I,
do
think
it
will
help
cloud
providers
I.
Think
it's
more
of
a
forcing
function.
There's
a
there
are
a
bunch
of
cloud
provider
specific
integrations
all
over
the
place.
It's
like
super
weird
to
be
honest,
I
think
in
disentangling
cloud
providers
might
be
that
forcing
function
for
us
to
start
to.
C
C
For
instance,
this
end-to-end
mode
tests
they
are
pretty
bound
to
Google
infrastructure,
so
we
have
to
cooperate
with
Google
people
if
you
want
to
decouple
time
frame
mode
test
from
the
provider
room.
Basically,
I
was
thinking
like
moving
it
out
or
something,
but
it
is
quite
integral
into
the
CI
signal
at
the
moment.
C
A
Think
we
will
be
blocked
and
starting
to
get
traction
on
pushing
the
code
in
the
right
place
and
to
try
and
get
it
out.
I
think
we're
gonna
need
sort
of
levels
of
doing
this.
One
one
thing
we'll
need
to
do
is
a
level
of
shuffling
in
the
code.
A
lot
of
this
is
going
to
be
rearranging,
so
it
can
actually
be
cleanly
extracted
and
I.
Think
we're
gonna
need
to
actually
open
some
parent
issues
to
talk
about
this
stuff
and
then
just
start
doing
the
work.
A
A
You
have
a
problem
statement,
but
it
presupposes
a
final
design
when
the
intent
test
is
very
organic
and
there's
a
bunch
there's
pieces
of
design
all
over
the
place,
and
we
there
is
no
final
end
state
that
we're
trying
to
get
to
yet
other
than
decoupling,
so
I
think
just
doing
the
work
to
decouple
alone
and
then
eventually,
maybe
after
we
start
to
get
pieces
and
traction
moving
in
the
right
direction,
then
we
can
actually
start
to
have
a
well
factored
design
that
we
can
think
about.
But
right
now
it's
like
good.
C
A
What
we
should
start
to
do
is
it
step.
One
is
like
enumerate
what
we
currently
have
like,
what?
What
is
there
and
walk
through
it
to
understand
how
we
want
to
do
extraction
like
the
the
highest
priority
tasks?
I,
think
that
works
as
a
forcing
function
would
be
cloud
provider
extraction.
I,
don't
think
anything
else
would
be
as
good
of
a
forcing
function.
We
could
say
we're
doing
internally
factoring,
but
that
winds
like
a
be
a
driving
force
to
get
the
work
done
cloud
provider
extraction,
would
be
a
driving
force
to
get
the
work
done.
A
C
A
A
There
are
other
elements
we
can
do
along
the
way.
We
should
long
issues
for
that
and
then
then
sort
of
kind
of
actually
have
a
real
backlog,
but
that
seems
like
the
seed
that
helps
everything
else
go
the
the
well
factored
component.
Config
I
would
like
to
get
to
it
an
ideal
world
I,
don't
think
that's
not
a
we're
dependent
upon
some
other
tools
and
pieces
being
in
place.
It's.
B
Yeah,
that's
fine.
He
said
I
I
I
feel
like
I'm
in
the
boat
of
like
a
walkthrough
or
a
like.
I
know
enough
to
like
be
dangerous,
but
not
enough
to
like
have
strong
opinions
yet
about
you
know
how
to
change
things
so
I
just
know:
I
don't
come
from
a
background
of
using
this
a
whole
lot.
So
you
know
it's
when
you
don't
have
that.
Like
in-game
experience,
it's
hard
to
like
work
on
improvements,
cuz
I,
don't
I
haven't
felt
the
pain,
I.
Guess
it's
generally
a.
C
A
Yeah
I
would
never
create
a
cloud
provider
abstracted
into
your
face.
I
might
consider
some
high-level
tasks
that
provides
some
level
of
guarantee
that
my
provider
is
doing
the
right
thing,
such
as,
like
you
know,
storage
attachment
and
some
PV
stuff,
some
basic
cloud
provider
integration
things
to
ensure
that
my
cloud
provider
Gershon,
is
actually
working
right,
but
I
wouldn't
I,
wouldn't
do
any
deep
dependencies.
So.
A
The
conformance
or
folder
is
basically
not
the
actual
tests
themselves,
but
like
metadata
and
wrappers
to
be
used
by
on
the
tests
inside
of
the
intent
test
suite.
This
is
where
all
the
magic
happens
right
and,
to
be
honest
and
clear.
Most
of
these
binaries
here
are
just
bin
smashers
right.
So,
if
you
look
at
like
the
end-to-end
file
here,
this
go
file.
It
basically
just
smashes
all
of
the
other
binaries
together.
That's
the
way
the
test
structure
for
ginko
works
is
it
basically
takes.
A
All
the
separate
folders,
these
are
all
the
actual
enzyme
tests
and
then
smashes
them
into
them
into
a
single
compilation
unit.
The
way
the
intend
tests
artifacts
are
generated
is
a
little
different
than
standard
go
and
that's
always
kind
of
troubled
me
a
little
bit,
because
this
is
the
only
artifact
that
you
can
create.
That
actually
depends
upon
Lib
C,
an
external
Lipsy.
A
A
A
Dependency
from
from
the
way
go
laying
does
builds
because
they
are
considered
both
tests,
they
they
don't
get
build
into
artifacts.
So
there's
a
separate
process
that
happens
and
that's
why
you
see
things
like
that
are
really
weird:
there's
no
real
main.
Instead,
there's
like
a
smashing
through
an
it
so
in
it
is
where
everything
actually
happens.
I.
B
A
A
If
it's
like,
it's
technically
the
way
go
says
to
do
things:
it's
not
I,
don't
know
if
it's
a
hacker,
if
it's
just
like
a
deficiency
and
how
go
does
things
because
they
don't
actually
produced
test
binaries
right.
If
you
want
to
take
your
tests
and
bundle
them
into
an
artifact
instead
of
going.
This
is
what
they
recommend
doing.
They
don't
actually
have
the
semantics
for
building
artifacts
that
are
also
test.
A
We
can
make
it
an
implementation
detail
so
that
you
don't
really
know,
and
that's
actually
partially
done
already
so
like
the
way
things
are
factored
currently.
Is
that
because
these
folders
are
totally
separate
that
there's
no
notion
there's
no
dependency
currently
on
the
actual
details
they
just
get
smashed
in
the
binary
okay,
but
the
the
problem
was
bin.
Smashing
in
golang
is
like
there's
no
incremental
linkage.
A
C
A
A
So
that's
that's
part
of
the
magic,
but
you
can
always
decouple
it.
So
one
of
the
things
we
wanted
to
do
was
decouple
the
actual
tests
themselves.
There's
no
reason
that
most
of
the
testing
stuff
itself
couldn't
just
be
a
go
file,
it's
just
in
a
separate
location.
So
if
we
wanted
to
actually
make
so
if
you
look
underneath
anything
like,
let's
pick
one,
it's
gonna
be
a
machinery
and
they
all
are
cool
files
actually
hold
on
look
a
different
one
control.
I!
C
So,
technically,
if
we
distribute
everything
with
source
code
instead
of
a
binary,
this
means
that
the
users
cannot
like
run
it
immediately.
They
have
to
first
compile
it.
So
that's
part
of
the
problem:
I
guess
we
distributed
source
code,
yes
distribute
the
source
code
in
at
I
mean
that's
no
33
yeah.
A
A
That's
just
the
consumption
model
that
people
expect
right
like
we.
We
wanted
to
make
containers,
be
the
standard
distribution
model
for
curb
ATM
and
get
rid
of
rpms
and
Deb's,
but
it's
just
what
the
world
expects
and
I
I
think
presupposing
that
somebody's
could
have
compiled
the
tests
before
they
run
them
I
think
is
crazypants
for
most
users
like
they
wouldn't
do
that.
C
A
Problem
is
that,
like
all
these
tests
like,
if
you
just
saw
the
test
here
on
the
open
one
window
and
open
another
one,
so
if
I
do
control
the
problem,
is
that
like
when
we
were
started,
writing
the
tests?
Originally,
all
of
these
tests
basically
did
had
a
lot
of
commonality,
and
they
were
doing
this
same
thing
over
and
over
again.
So
when
a
what
you're
doing
the
same
thing
over
and
over
again,
you
have
a
standard
patterns
like
you
should
push
the
common
code
into
a
comment
section
and
that
was
basically
their
framework.
A
But
the
framework
is
basically
instead
of
being
well
factored
set
of
individual
pieces.
They
were
kind
of
thumps
together
and
we
grew
organically
versus
being.
You
know
like
we
should
put
this
here
instead,
it's
just
like
you
checked
it
all
into
the
closet,
now
you're
trying
to
close
the
closet
and
not
think
about
it
versus
like
stacking
things
nicely
and
Neely
is
he
can
take
out,
which
is
what
you
need
so
instead,
like
now
you're
opening
the
clause
and
it's
all
pouring
down
on
you
and
I
just
needed
one
thing.
A
So
that's
where
the
commonality?
The
framework
came
in
and
that's
where
the
problems
don't
exist
and
that's
where
we
need
to
fix
the
work,
because
people
want
to
use
us
in
to
write
tests
very
similar
to
the
way
upstream
writes
to
us
right,
because
you
know
we
can
we
can
nitpick
on
ginko,
but
the
tests
themselves
are
pretty
powerful
if
you
actually
think
about
the
details
of
how
they
actually
work,
you're,
basically
kicking
off
an
entire
set
of
ways
of
running
things
on
a
cluster
and
being
able
to
detect
and
verify
that
behavior
of.
A
A
The
framework
is
the
problem
frame.
Work
is
a
problem
because
it's
actually,
if
you
look
inside
a
framework
that
go
it's
itself,
I,
think
it's
like
a
ridiculously
long
file,
and
you
know
what
the
total
line
count
on
this
Center
is,
but
it's
similar
than
the
thousands
I
believe,
but
what's
clear
is
that
you
have
to
dot
whatever
against
the
framework
right
and
it
doesn't
really
make
a
lot
of
sense,
sometimes
because
maybe
the
framework
would
be
decomposed
into
pieces
like
framework
pairs
framework,
dot,
initialization
framework
dot
whatever
right.
A
So
that
way
it
was
composed
into
pieces,
you
know
or
not
even
say
dot.
It
would
be
like
you,
import
framework,
slash
errors
and
say
F
errors
got
a
foo
equals
whatever
or
you
know,
kubernetes
testing
errors.
Just
that
way,
you
can
actually
take
a
piece
of
the
puzzle
that
you
care
about
and
not
care
about
everything
else
and.
A
A
So
it's
not
well
factored
you're,
basically
passing
around
a
ton
of
data
everywhere
you
go
and
there
there's
not
a
separation
of
certain
behaviors
so
like
we
call
scripts
inside
of
the
framework
which
don't
even
make
sense
nowadays,
right,
like
we
already
hit
like
sonobuoy,
has
a
system
D
collect
log
collector,
but
we
have
a
separate
script
inside
the
detent
and
test
framework.
That's
like
this
weird
kicked
the
script
to
go
SSH
across
this
cluster
and
try
to
grab
them
the
logs.
That's
kind
of
that's
a
little
crazy
right.
A
A
So
I
think
the
problem
was
even
walking.
The
code
is,
as
you
walk
the
code.
You
just
keep
on
asking
more
and
more
questions.
You
literally
need
to
like
beautiful
mind
the
sucker
and
sit
down
and
go
through
it
several
several
times
to
understand
why
certain
pieces
exists.
The
way
they
do,
and
maybe
that
alone
is
a
good
action
item
would
be
like.
Maybe
one
of
us
in
this
group
can
sit
down
and
decompose
the
units
that
we
see
or
the
groupings
that
we
see
to
have
a
conversation
that
is
more
meaningful
than
like
me.
C
A
Well,
the
biggest
problem
detractor
with
me
or
currently
is
not
necessarily
that
I
couldn't
do
it.
It
says
I
have
these
really
ridiculously
long
documents?
I'm
writing
I
have
to
finish
first
once
that's
done
I.
Do
you
think
I
should
have
capacity
to
at
least
get
the
block
diagram
of
where
we
are,
which
is
where
we
want
to
go.
A
C
C
A
Think
we
should
create
an
umbrella
yet
because
I
think
we
need
to
like
we
need
to.
This
is
one
of
those
efforts.
That's
gonna
be
a
ChaCha,
we're
gonna
step
into
one
piece
of
the
puzzle,
but
then
we
might
have
to
step
back
and
then
fix
all
this
other
crap
before
we
can
actually
get
there.
So
I,
don't
expect
us
to
actually
be
able
to.
A
You
know
just
go
in
a
straight
beeline
from
a
single
effort,
so,
although
we
say
like
ven
during
cloud
providers,
cleanly
extract
cloud
providers
and
have
a
clean
ven
during
strategy,
even
though
that's
not
good,
it's
almost
an
umbrella
issue,
but
the
actual
doing
all
the
work
to
get
it
into
that
state
will
probably
be
you
know
we
take
one
step
in
this
direction.
Then,
like
we
step
back
and
then
we're
gonna
have
to
like
change
all
these
things,
then
we're
gonna
take
another
step
in
that
direction.
A
A
A
A
B
A
C
A
E
E
A
Think
this
should
be
sufficient
for
us
to
get
started.
I
don't
want
to
like
over
overburden
the
group
here,
but
I
think
this
will
at
least
get
an
initial
starting
point
and
then
help
us
to
actually
create
a
backlog
of
items.
I
fully
expect
this
to
be
a
cha-cha
exercise.
We're
gonna
take
one
step
forward
and
two
steps
back
initially.
A
I
think
so
long
as
we
don't
break
anything
like
we
need
to
make
some
rules
about
how
we
go
about
doing
this
first
quarantine.
Minimize
then
cut
right,
so
it's
kind
of
like
you're
building
a
freeway
right.
You
don't
just
like
smash
their
freeway
and
then
be
like
alright
I'm
ready,
see
you
later.
You
build
a
side
road
for
the
new
one.
You
know
or
you
build
a
way
to
get
around
the
existing
Road
and
then
you
build
the
new
superstructure
and
then
once
once
it's
ready,
then
you
smash
the
old
one.
A
Yeah
I
don't
see
a
lot
of
trouble
so
long
as
we
we
follow
standard
pattern
of
like
you
know,
we
can't
tear
down
the
road
that
we
currently
have.
We
can.
We
can
reshape
some
things,
we
can
change
the
lanes
and
we
can
get
it
ready
and
then
we
can
at
the
same
time
we
can
build
up
this
parallel
track
to
get
it
ready
and
then
only
at
the
last
thing.
The
last
thing
you
do
is
smash
the
old
road.
That's
everything
else
has
been
created.
E
C
A
I
think
the
big
ones
are
already
listed
here,
like
the
component
configuration
and
the
internal
versus
external
client
and
well
factoring
the
framework
so
wealth
it
breaking
it
apart
is
a
is
many
pieces
right.
It's
a
well
factored
way
of
importing
it,
so
this
is
gonna.
Take
a
while
there's
there's
many
parts
to
this
thing.
C
D
C
A
Years
but
I
think
the
problem
is
we're
in
this
weird
boat
now
with
kubernetes,
where
we
have
this
system
that
kind
of
sort
of
works,
but
it
doesn't
necessarily
mean
that
it's
efficient,
right
and
I
think
we
need
to
get
to
a
place
where
we
have
some
level
of
efficiency
and
some
set
of
layered
models
and
some
positions.
So
that
way,
kubernetes
can
just
be
locked
down
tight
over
time,
and
we
only
do
the
things
in
the
core
that
we
need
to
get
done
in
the
core.
B
A
I
think
the
it'd
be
forcing
function
like
create.
Look
at
the
existing
cloud
providers
say
something
like
you
know.
If
we
wanted
to,
we
could
because
most
of
the
folks
here
are
VMware,
we
could
start
with
vSphere
as
the
example
right
try
to
create
a
end-to-end
test
suite
for
vSphere
that
exists
outside
of
tree,
which
could
be
run
right
and
figure
out.
As
you
start
to
do
this.
Like
start
very
simple,
you
know,
as
you
start
to
vendor
in
the
current
code,
then
you're
gonna
have
to
go
up
to
the
code
be
like.
A
C
A
Iii,
don't
I
think
we
can
separate
concerns
there,
I'm,
not
gonna.
Eventually,
if
we
want
to
take
on
that
cleanliness
role
of
like
cleaning
house
on
the
generation
of
some
of
this
stuff,
I
think
that
we
should
go
there,
but
right
now,
I
think
there's
so
much
other
work
to
do
that.
I,
don't
care
so
long
as
I
get
an
e
to
e
dot
test
file
at
the
end
of
the
day
and
so
long
as
I
can
vendor
in
the
framework
and
not
not
all
kubernetes
yeah.
C
A
I
think,
leaving
that,
for
the
time
being,
is
totally
fine
I.
This
is
the
this
is
the
track.
I
took
even
way
back
at
Red
Hat,
as
Google
was
doing
their
own
thing
and
not
really
consulting
with
the
community
on
sort
of
test
automation,
so
so
long
as
we
had
the
ability
to
do
what
we
needed
to
do
it
didn't
matter
for
the
most
part
and
sort
of
I
tried
to
invoke
separation
of
concerns.
A
I
do
think,
though,
as
we
start
to
move
a
lot
of
this
test,
automation
out
of
Google's
umbrella,
that
we
should
probably
try
to
factor
it.
So
it's
like
cleanly
separate
and
understandable
because,
like
the
dependency
graph
of
like
how
the
coop
khun's
test
container
uses
the
intent
tests
and
how
it
all
gets
reported
through,
brow
is
way
too
much
magic.
A
Some
of
the
people
that
helped
write
this
thing,
mainly
jeff
xt,
was
one
of
them.
Myself
was
another
a
lot
of
them,
actually
don't
even
work
on
the
project
anymore,
so
I'm
trying
to
think
no
most
of
them.
Don't
work
on
the
project
anymore,
but
Jeff
and
I
are
the
old
timers
that
still
still
are
around
that
understand
what
was
created
and
when
and
and
what
was,
and
why.
Some
of
the
reasons
are
why
they're
it's
the
way?
It
is
the
way
it
is.
C
Well,
Google
seems
to
be
like
if
we
need
to
be
DM.
If
you
move
away
from
the
upgrades
package,
every
framework
Google
will
remain
the
only
owner
of
this
code.
Like
do
you
think
that
we
I
don't
know
what
to
do
with
this
particular
codes.
The
upgrade
has
the
other
bridges
that
Kris
Rousey
wrote
it's
part
of
the
framework
in
a
way
and
it's
Google
maintained
and
we
disinfect
drink
we
have
to
figure
out,
like
I,
did
I.
Think.
C
A
A
C
A
Well,
we
have
two
minutes
and
we're
kind
of
in
kvetch
mode,
so
I
think
the
action
items
are
pretty
clear,
tend
to
write
a
diagram
start.
Creating
an
umbrella
issue
have
some
type
of
forcing
function
with
external
cloud
provider.
We
can
start
with
vSphere
because
it
makes
a
lot
of
sense
and
then
triage
the
legacy
issues.