►
From YouTube: Test/Release Working Group Meeting 9/11/2018
Description
Meeting Notes: https://goo.gl/6G4dwx
B
C
E
B
So
for
103
we
don't
have
a
target
date
yet
but
similar
to
due
to
the
prior
patch
releases,
if
you
find
any
critical
bugs
that
needs
to
be
fixed
in
one
or
two
or
even
101
feel
free.
To
add
to
the
tracker
that
we
have
already
opened
on
github
and
we
will
plan
around
a
new
patch
released
whenever
is
necessary.
B
E
So
we
looked
around
to
to
use
the
in
cluster
registry,
which
would
basically
create
a
cluster
in
the
GK,
a
resistor
in
the
GK
cluster.
So
we
can
push
directly
to
that
cluster
and
consume
those
image
locally,
but
going
back
to
time
the
issue
was
that
I
didn't
support
the
run
after
success
correctly,
and
so
there
was
a
patch
made
by
Cole
from
the
current
his
team
to
fix
that.
E
Coupled
with
the
I
guess,
the
presubmit
update
we
kind
of
did
a
maintenance
on
the
cluster
reprise
running
and
make
sure
to
make
sure
that
we
had
all
the
right
resources
to
run
tests
and
occur
bills
and
basically,
and
also
abated
the
the
docker
image
to
run
the
most
updated
version
of
docker
and
bunch
of
optimization
that
we
did
looking
at
house.
You
know
that
they
today
is
looking
at
the
performance.
B
Here,
specifically,
this
is
the
job
we
are
talking
about,
the
EcoP
some
a
job.
It
usually
take
almost
well
over
30
minutes
and
now
it's
less
than
eight
minutes,
and
this
is
the
job
that
has
to
happen
before
all
the
other
tests
can
can
start
so
that
pretty
much
means
we
cut
the
overall
piece
of
a
time
by
and
by
at
least
22
minutes.
B
E
And
we've
been
looking
at
it,
I
mean,
I
think
now
there
is
nobody
actually
merge
since
last
week.
Nobody
actually
merged
manually
PRS,
which
is
a
good
thing,
choose
exactly
what
we
want
cuz
you
don't
need
to
if
you're,
GTM
and
approve,
and
you
get
to
hold
the
right
approval,
then
you
don't
have
to
think
about
it.
E
E
We'll
definitely
revisit
the
in
cluster
registry,
such
that
you
know
we
don't
even
need
to
to
send
to
DCR.
It's
definitely
something
that
we
can
attach
to
the
test
framework,
because
it's
much
easier
for
the
user.
You
actually
gonna
need
to
have
a
personal
registry,
so
I
mean
this
is
working
right
now,
okay,
you
can
already
use
it,
but
maybe
we
don't
use
it
in
intros.
Well,.
F
A
Okay,
you
can
see
that
yeah,
okay,
just
a
quick
update
on
where
we
are
with
the
test
framework,
Oz
and
I-
have
been
packing
away
in
between
fires,
for
one,
oh
and
and
after,
but
just
a
quick
update
where
we
are
so
just
kind
of
like
a
review
and
what
we
were.
What
we
were
doing
since
we
haven't
talked
about
this
in
a
while
so
testing
today.
Obviously
it's
the
test
code
is
pretty
complex.
Anybody
that
seen
the
pilot
and
ten
tests.
There's
there's
a
lot
going
on
there
and
it's
also
tied
to
kubernetes.
A
So
so
we
couldn't
easily
take
those
same
tests
and
make
them
work
on
some
other
platform.
That's
that's
gonna,
be
a
big
problem.
Going
forward
running
tests
is
hard.
You
know
we
have
scripts
to
help,
simplify
it,
but
even
then
it's
it's
a
lot
of
extra
steps.
If
you
ever
try
to
do
it
manually
from
like
goal
goal,
and
you
have
like
a
million
flags,
you're
gonna
put
on
the
command
line,
it's
it's
not
trivial.
A
A
So
so
what
do
we
want?
We
want
to
make
the
test
code
simpler,
platform-agnostic,
running,
test
locally
is
gonna,
be
a
big
win.
They'll
be
faster,
they'll,
be
less
flaky,
so
we
want
to
what
we
also
want
to
make
tests
just
kind
of
run
out
of
the
box
without
having
specified
flags.
So
that's
we're
running
locally.
It's
gonna
come
in.
A
We
want
to
have
a
more
reliable
config
propagation.
That's
been
a
big
source
of
flakiness
running
tests
before
the
config
is
actually
propagated
to
all
the
envoys
and
simplify
the
configuration
when
we
run
when
you
are
running
communities,
so
hopefully
those
that
list
of
flags
can
kind
of
world
on
for.
A
Simple,
so
here's
this
is
where
we
at
where
we're
at
now
here's
a
an
actual
living
breathing
test
that
will
work
either
locally
on
or
or
in
kubernetes.
So
this
is
kind
of
like
a
copy
of
some
of
the
stuff
we've
been
doing
on
pilot
end
tests
where
we
test
HTTP
connectivity.
So
you
look
at
the
first
line
there.
It's
saying
that
we
require
this
one
component
and
we'll
see
in
the
next
slide
that
the
environment
is
actually
broken
down
into
a
series
of
components.
A
We
have
we
acquire
an
environment
and
that
the
environment
would
given
is
totally
driven
by
flags.
So
we
don't.
This
test
doesn't
know
which
environments
using
it
just
uses
the
API.
Then
we
get
the
each
of
the
two
services
named
a
and
B,
and
we
get
all
the
HTTP
endpoints
for
for
B.
Take
the
first
one
and
we
make
a
call
to
it
from
A
to
B
get
the
result,
make
sure
it's
okay.
A
So
that's
this
is
actually
very
similar
to
what
the
the
code
is
doing
in
the
pilot
end
test
today,
but
you
can
see
the
the
big
advantage
here
is:
there's
no
kubernetes
stuff
here
at
all:
it's
totally
agnostic,
there's
no
ports,
there's
a
the
no
pushing
of
Gamal
any
of
that.
It's
just
just
kind
of
focus
on
business
logic,
so
real,
quick
under
the
hood
just
acquiring
environment.
We
there's
this
kind
of
global
environment
that
that's
used
when
you
anytime,
you
call
requires
or
any
of
the
any
of
the
framework
functions.
A
Ultimately,
it's
going
to
boil
down
it's
you
acquiring
an
environment
or
creating
an
environment
and
obviously
based
on
flags.
It's
either
gonna
be
for
now.
Kubernetes
or
local,
and
each
of
them
kind
of
defined
their
own
version
of
components,
so
pilot
has
a
kubernetes
version,
a
local
version
mixer
as
well,
etc.
A
We
want
app
a
and
FB
to
just
kind
of
talk,
but
it's
a
bit
trickier
because
pilot
is
assuming
a
lot
about
IP
tables,
redirects
and
all
those
things
which
obviously
aren't
going
to
work
locally.
So
you
actually
have
to
kind
of
take
the
configuration
pilots
giving
us
and
massage
it.
A
bit
specifically
were
actually
adding
outbound
ports
so
that
it
can
talk
to
be
were
kind
of
discarding
a
few
of
the
inbound
listeners
doing
a
few
other
things
as
well.
But
it's
it's
actually
quite
a
quite
a
bit
of
work.
A
So
it's
still
a
lot
to
do
for
local.
We
still
need
to
fill
out
MPLS.
We
we
need
to
have
the
apps
integrate
with
Zipkin
and
mixer
properly
they're.
Not
doing
that
yet
there's
also
an
issue:
I
ran
into
running
locally
with
multiple
service
versions,
so
we
have
to
get
that
working
and
we
still
have
basically
the
only
components
we
had
today.
Our
mixer
pilots
I'm,
not
sure
if
we
have
galley
complete
yet,
but
so.
G
There's
quite
a
bit
of
work
to
do
there,
so
one
that
is
sorry.
A
as
we
are
adding
more
functionality
to
galleon
is
starting
to
become
the
primary
way
to
distribute
a
configuration.
I
think
one
thing
we
are
gonna
try
to
focus
on
is
try
to
get
that
as
the
front
and
center
component
in
the
test
framework
for
config
distribution
as
well.
Today
we
are
doing
somewhat
of
an
ad
hoc
file
based
distribution,
and
it
has
a
bunch
of
problems
right.
So
that's
one.
A
We're
still
hashing
that
out
so
in
the
demo
about
to
give
you
I,
actually
we're
going
to
be
running
with
an
existing
cluster
all
set
up,
so
the
components
are
actually
going
to
deploy
themselves,
but
that
is
where
we're
going
to
head
into
the
future.
All
the
configuration
the
components
themselves,
all
that
stuff
will
be
part
of
a
deployment
strategy
for
kubernetes.
A
A
A
A
I
mean
this
there's
a
lot
that
I'm
leaving
out
here,
but
basically,
what
we're
doing
is
we're
getting
all
the
apps
we're
kind
of
iterating
over
all
of
their
ports
and
we're
making
calls
from
service
to
all
the
ports
and
all
the
other
services,
all
the
HTTP
ports,
and
this
this
test
actually
has
to
hard-code,
then,
which
is
you
know,
just
an
artifact
of
being
very
dependent
on
the
under
the
particular
setup.
We're
using,
but
you'll
also
notice
that
when
we
actually
go
to
make
the
request,
that's
a
lot
of
kubernetes
stuff.
A
So
this
test
there's
no
real
easy
way.
We
could
make
this
portable
to
other
platforms
like
local
or
anything
like
that,
so
just
to
see
what
that
looks
like
in
the
new
world.
So
this
is
the
effectively
the
same
test,
and
what
we're
doing
here
is
it's.
This
is
a
lot
of
the
same
code.
We
saw
on
that
in
the
slides
we
get
the
acquire,
the
environment,
we
get
a
few
apps,
we
get
their
HTTP
endpoints
and
then
we
for
each
source
app.
A
We
iterate
over
the
endpoints
for
all
the
other
apps
make
requests
and
make
sure
the
result
is
okay,
so
this
is
doing
the
same
thing,
but
it's
doing
it
in
a
platform
agnostic
kind
of
way.
So
this
is
a.
This
is
a
little
helper
method
here
and
what
I've
done
is
I've
made
three
actual
test
methods
to
demonstrate
how
they
can
all
require
different
things.
A
So
one
of
the
first
things
you
do
in
a
test
with
the
new
framework
is
you
you
indicate
what
you
need
in
order
for
this
test
to
run
with
the
requires
method,
so
they
all
need
the
apps
component,
but
I've
taken
a
couple.
Other
add
a
couple
other
methods
here,
where
we
also
also
require
a
particular
environment.
So
this
one
actually
requires
that
it
runs
in
kubernetes,
and
this
one
requires
that
it
runs
locally.
A
Okay,
you'll
see
that
test
HTTP,
the
one
that
was
environment,
agnostic
and
test
HTTP
local
were
the
two
that
run
and
kubernetes
was
skipped
because
it
requires
everyday
environment
and
then
likewise,
if
we
go
over
to
the
cube
version
of
this,
take
a
look
at
its
parameters.
So
may
that
mean
two
parameters
that
this
requires
are
specifying
that
the
environment
is
kubernetes
and
pointing
to
the
cube
config
these
these
other
namespaces
are
I,
won't
go
into
those
but
effectively.
What
I'm
saying
is
we're
using
an
existing
environment.
A
A
A
Since,
since
it
requires
the
local
environment-
and
so
that's
basically
it
moral,
the
story
is
local
and
way.
Faster.
Kubernetes
took
almost
30
seconds,
whereas
running
locally
to
basically
a
second
and
and-
and
this
didn't
even
actually
deploy
anything
to
communities,
it
was
just
using
the
existing
pods.
A
A
A
F
A
A
G
D
Please
so
in
the
help
fund,
hello,
so
in
the
help
file
is
that
in
the
list
of
things
you
won't
try
to
build.
That
is
not
available
yet
because
I
saw
that
is
a
major
X
or
histories,
but
they
didn't
sound
like
a
list
of
functions
are
trying
to
achieve
or
something
I
like
to
help
on
that
of
the
legend
it's
and
better.
What
is
needed.
A
Yeah,
it's
a
good
question.
Yes,
so
we
do
have
an
epic
I
think!
That's
we
referring
to
I've,
captured
I,
tried
to
capture
in
that
epic
all
of
our
current
tasks,
but
it
but
yeah
it's.
It
probably
could
use
some
love
and
feeling
out
more
long-term
vision
under
that
epic
as
well.
So
yeah
I
expect
that
epic
to
be
kind
of
an
ongoing
thing
that
will
will
continue
to
expand
as
we
go
forward,
but
but
yeah
feel
free.