►
From YouTube: Technical Oversight Committee 2020/10/09
Description
Istio's Technical Oversight Committee for October 9th, 2020.
Topics:
- 1.7 Release Retrospective
- Incentives to help test Istio Releases
- Development process for features (testing and design doc requirements for alpha and beta graduation)
- API Group for WorkloadEntry and WorkloadGroup
D
H
G
F
I
C
K
So
back
in
0.8
we
had
a
contest
on
the
testing
days
to
see
who
could
complete
the
most
tests,
and
there
was
a
small
prize
given
out
for
that.
We've,
since
gotten
rid
of
that
and
in
the
last
couple
of
releases,
we've
had
very
low
turnout
for
the
testing
days.
I'm
wondering
a
how
well
that
worked
for
0.8
and
b,
whether
it
would
make
sense
to
return
to
something
like
that
to
encourage
more
turnout
for
the
testing
days.
C
B
K
K
B
K
My
question
is
just:
how
do
we
increase
turnout
on
testing
days?
My
guess
is
one
of
the
problems
we
have
is
just
testing
isn't
super
exciting,
it's
more
exciting
to
write
new
features
and
that
sort
of
thing.
So
how
do
we
make
it
more
interesting
for
people
do
these
same
tests
every
release
until
we
have
everything
automated.
M
E
E
G
H
G
C
L
L
B
F
K
J
C
C
E
E
E
M
This
is
both
kind
of
a
just
raising
visibility,
as
well
as
a
shout
out
to
brian
avery.
Brian's
done
an
amazing
job
on
the
feature:
promotion
templates
in
the
enhancements
repo.
He
sought
to
really
document
very
clearly
what
our
development
process
is,
and
I
think
he's
done
an
amazing
job
of
it
can't
wait
to
use
them
across
the
board
for
the
one
nine
release.
Hopefully,
but
as
I
was
reading
through
the
various
templates,
I
was
a
little
bit
surprised
at
what
our
actual
development
process
is.
M
Then
you
write
an
rfc
and
a
couple
of
tests
and
you
can
launch
it
as
alpha.
Then
you
write
a
design
doc
and
a
test
plan
for
the
tests.
You
already
wrote
for
the
alpha
release
and
then
you
can
write
it
or
launch
it
as
beta
and
I'm
worried
about
like
writing
plans.
After
writing
tests
and
having
design
be
the
last
step
in
the
process.
C
Well,
it's
it's
one
way
of
looking
at
it
is
that
people
are
writing
a
prototype
to
even
you
know,
there's
so
many
possibilities,
the
prototype
kind
of
constrains
the
design
and
validates
the
design,
but
then
the
design
is
required
before
it
becomes
more
real
like
beta.
I
I'm
not
sure
if
I
like
this,
I'm
just
trying
to
figure
out
how
it
might
make
some
sense.
F
Yeah,
so
one
of
the
way
we
designed
this
is
when
we
look
at
the
criteria
for
experimental,
because
it's
the
fact
it's
dark
launched.
We
didn't
want
to
set
a
really
high
bar
for
experimental,
because
I
think,
if
I
recall
correctly,
the
major
criteria
for
mating
experimental
is
to
explain
the
user
scenario
and
be
able
to
make
sure
you're
not
impacting
the
existing
system
so
that
you
could
potentially
get
some
feedback
with
stock
launched.
F
E
Well,
I'm,
like
I'm
more
looking
at
development
process,
friction
right.
If
they've
gotten
what
it's
adopted,
then
it
puts
a
ton
of
pressure
on
people
to
go
and
right
fill
out
the
gaps
that
mitch
mentioned
right.
Yeah,
the
harder
part
right
is,
if
you're
developing
experimental
to
kind
of
do
a
proof
of
concept,
and
then
you
go
into
a
review
later
and
the
reviewers
go.
No.
This
doesn't
make
any
sense,
then
right
that
that
that
takes
an
emotional
toil
on
people.
Sometimes.
M
It's
also
a
little
bit
difficult
to
act
as
a
pull
request.
Reviewer
often
we'll
get
large
pull
requests
that
because
they're
experimental
don't
have
any
design
discussions
behind
them
or
architectural
documents
supporting
them
and
I'm
yeah.
It
doesn't
seem
like
a
great
way
to
evaluate
the
code
to
me
personally.
If
the
toc
disagrees,
then
then
I
think
we
should.
C
G
It
will
help
to
have
some
process
to
to
put
all
the
experimental
code
in
some
separate
packages,
because
the
primary
goal
was
to
keep
the
experiments
isolated
and
not
impact
the
main
code.
So
it
would
be
easier
to
review
if
you
know,
and
at
the
same
time
have
you
know,
strict
review
for
changes
to
the
critical
codes.
That
is
not
experimental,
but
I'm
happy
with
the
process
in
general,.
F
G
E
L
E
O
L
P
G
E
M
E
Well,
if
the,
if
the
the
borrower
for
the
test
for
experimental,
is
low
right
smoke
testing
effectively,
you
could
see
there
being
some
value,
because
the
amount
of
tests
you'd
have
to
write
to
bring
the
feature
right
effectively
to
a
releasable
state
would
be
much
more
significant
right.
So
if
and
I'd
really
like
to
hear
the
work
group
leads
kind
of
subjective
assessment
of
the
testing
bars
that
they
put
features
through
right.
If
you're
going
to
take
a
feature
and
experimental-
and
you
say:
okay-
well,
you
you
have
to
write
one
test
right.
E
E
M
G
M
So
caution
is
right
in
that
there
are
two
artifacts
to
a
test
plan.
One
is
a
pull
request
that
that
includes
only
the
feature
names
that
you
intend
to
test,
and
potentially
scenarios,
if
you
choose
to
include
those
the
other
is
a
section
in
the
design
dock,
where
you
lay
out
in
plain
text
what
your
intentions
are,
so
those
are
sort
of
the
two
halves
to
the
coin.
K
O
Yeah,
mostly,
some
features
are
really
tiny,
like
a
new
cli
flag
or
something
that
are
just
done
independently
by
the
other
pieces,
and
some
pieces
are
done
that
require
a
lot
of
parts
from
a
lot
of
working
groups,
and
I
I
think,
where
there's
a
lot
of
cross
work
group
things,
we
really
need
a
design
first
to
get
agreement,
but
where
it's
just
something
one
group
does
on
their
own,
it's
almost
better
to
implement
it.
First,
let
people
try
it
out
and
if
we
don't
like.
J
O
Well,
I
consider
it
experimental,
but
then
a
lot
of
the
stuff
I
do
is
on
the
cli
and
it's
just
experimental
and
it
stays
there
until
people
tell
me
they
like
it
enough
that
they
want
it
to
be
made.
Graduated,
that's
very
different
from
something
inside
pilot
that
is
going
to
depend
on
a
bunch
of
features
and
people
will
use
in
their
routing.
L
F
D
L
G
Building
on,
what's
them
said
earlier
about
people
doing
the
stuff
in
their
own
branch.
I
think
one
of
the
pressure
points
is
that
we
kind
of
removed
the
branches
in
the
past.
We
have
branches,
and
so,
if
we
provide
some
mechanism,
automation
against
to
build
to
automate
the
build
test,
everything
else
from
the
branches
we'll
have
a
way
to
have
kind
of
alternate
bills
that
people
can
use
with
experimental
features
on
and
do
all
the
trial
and
kind
of
reduce
the
pressure
on
getting
everything
into
master.
G
F
G
L
We
should
we
should
talk
about
branching
as
an
option.
I
don't
want
to
get
it
too
conflated
with
the
rest
of
this
discussion.
I
think
it's
a
good
discussion.
We
should
discuss
whether
we
can
make
it
easier
for
people
to
have
feature
and
collaborate
on
branches,
but
so
is
that
what
is
the
order
of
testing
and
requirements
and
code
writing.
G
One
more
point
on
the
same
topic:
sorry,
since
we
are
on
this
subject,
there
is
also
kind
of
the
subject
of
vendor
branch
or
vendor
extensions,
or
you
know
having
some
ability
or
some
hooks
to
have
kind
of
builds
that
are
optimized
for
a
particular
vendor,
which
is
also
kind
of
something
useful
for
some
people.
I
think.
E
Right,
I
think
the
issue
there
carlson
is
given
our
our
need
to
catch
up
on
testing
coverage.
It's
hard
to
get
quickly
when
it's
manual
right.
The
inability
to
kind
of
leverage
that
across
multiple
branches,
is
going
to
really
mitigate
the
value
of
that
in
the
short
term.
That's
good
much
better
with
automation,
then
I
think
that
becomes
much
cheaper
right
now
I
yeah
we
have
to
prove
to
ourselves
that
we
can
afford
to
do
that.
F
F
F
J
F
C
Yeah,
I
think
the
lynn.
The
thing
I'd
like
to
add
is
I'm
I'm
wary.
I'm
I'm
getting
increasingly
worried
people
bringing
stuff
like
this
to
the
toc,
because
I
think
it'd
be
better.
If
they
could
just
convince
you
know,
other
developers
on
the
project
should
do
this.
That
would
be
a
far
more
natural
way
of
doing
it
and
I'm
afraid
that
if
it
goes
to
the
toc,
we
end
up
mandating
things
in
a
top-down
sense,
that
maybe
people
don't
want
and
maybe
don't
make
sense.
It
would
be
nicer
to
have
this
be
grassroots.
B
B
F
B
Group
leads
meetings,
facilitate
some
conversations
there.
It
might
be
a
good
venue
to
do
that
and
then
they,
the
people
in
the
that
meeting,
can
take
it
further
to
the
individual
working
groups,
because
I
don't
think
the
conversation
we
are
we
are
having
right
now
is
actually
representative
of
the
facts,
because
it's
just
six
seven
people
talking
who
actually
don't
code
much.
C
K
E
E
O
L
So
one
of
the,
by
the
way,
with
the
template
that
we
wanted
to
do,
was
have
a
couple:
people
try
them
out
and,
like
you
know,
they're
living
documents
right
like
if,
if
something
seems
dumb,
then
we
should
remove
it
right,
like
we
shouldn't
be,
we
should
have
people
trying
them
out
and
saying
no.
This
is
bad.
We
should
include
this
like
we
should.
We
should
be
more
iterative
with
these.
I
think.
F
Yeah,
we,
I
think
people
are
already
trying
this
out.
For
example,
nathan
has
been
gone
through
this
for
multi-cluster
promotion
to
beta
right,
so
the
steve
is
working
on
like
a
gateway
upgrade
to
see
if
we
can
promote
that.
So
people
are
following
this:
it's
pretty
dangerous
if
we
actually
change
it
in
the
middle
of
a
release.
F
F
E
E
K
What
I'd
like
to
hear
is
I
mean
any
challenges
that
people
find
can
any
confusion,
that
kind
of
thing
just
general
feedback.
I
don't
know
if
I
have
specific,
like
survey
style
questions
right
now,
just
what's
there
right
now.
How
is
it
working
for
people?
How
does
it
need
to
evolve
to
address
a
project
best.
E
L
L
C
F
P
Okay,
I
would
also
state
that
maybe
we
can
find
a
better
way
of
organizing
the
documents
by
feature
like
if
there's
an
rfc
and
then
like
two
months
later,
there's
an
actual
design
dock,
but
you
know
here
is
another
proposal
for
moving
this
to
alpha
and
so
on.
These
things
just
tend
to
be
spread
out
all
over
the
place.
People
just
don't
know
the
progression
of
you
know
things
that
has
happened
as
part
of
the
history
of
that
feature
in
terms
of
okay.
We
tried
this.
This
didn't
work.
P
P
Talking
about
very
you
know,
similar
things
and
they
get
confused,
but
having
that
training
paper
trail
of
some
sort
would
actually
help
and
either
we
just
make
a
folder
in
google
drive
for
that
feature,
and
then
say:
okay,
you
put
all
the
stuff
for
that
feature
from
design
docs
to
rfcs
to
reward
docs.
Everything
in
that
folder,
which
then
means
somebody
who
goes
on,
can
then
actually
chronologically.
Look
at
the
progression
of
this
thing
and
understand
what
happened
and
get
an
idea
of
like
this
is
the
final
state
of
the
future.
K
P
P
M
Yeah
brian
has
great
plans
for
connecting
all
the
various
issues
together,
along
with
their
documentation,
so
that
there
is
a
shruram.
As
you
said,
like
a
paper
trail,
it's
not
a
reorganization
of
github
folders.
It
would
all
be
sort
of
tied
together
by
a
file
in
the
enhancements,
repo
and
brian.
I,
if
I'm
misrepresenting
your
intentions,
please
let
everyone
know.
E
M
Yeah,
that
would
be
a
single
issue
as
I
understand
it,
but
that
there
would
be
an
automated
system
that,
once
a
feature
has
progressed
into
a
given
state
updates
a
central
file
representing
that
feature
that
file
ties
together
all
of
the
issues
all
of
the
pr's
all
of
the
documents.
That
would
be
our
top
level
record
for
that
feature,.
E
So
I
think
the
question
mark
that's
obviously
very
useful
from
a
kind
of
tooling
and
tracking
point
of
view,
I'm
wondering
about
the
behavioral
side
of
it
right
about
what
we're
going
to
get
people
to
be
able
to
keep
track
of
in
our
kids,
like
our
developers
looking
at
features
in
the
enhancement
repo.
Are
they
looking
at
issues.
K
So
they'd
be
looking
at
the
this
all
needs
to
evolve
into
everything
right
now.
We
just
have
the
checklist,
but
they'd
be
looking
at
the
feature
and
then
tracking
from
that
feature,
the
hey
here's,
the
things
that
it
meant
for
beta,
here's,
the
things
that
met
for
alpha,
here's
the
things
you
can
track
from
that
feature
to
what
the
checklists
were
for
each
of
those
levels.
M
K
M
Would
be
where
they
spend
most
of
their
time
where
they
put
most
of
their
changes.
The
feature
files
would
be
more
relevant
to
say
the
operational
excellence
initiative,
where
we
want
to
look
at
all
of
the
features
and
their
maturity
levels
and
what
test
coverage
we
have
over
them,
but
as
a
developer,
working
on
an
individual
feature,
I
think
your
perspective
would
primarily
be
targeted
towards
the
issue
with
the
template.
K
E
K
Yeah,
the
other
thing
is
going
back
retroactively
like
we
want
to
promote
the
canary
stuff
to
beta.
So
in
order
to
meet
the
requirements
for
beta,
you
have
to
have
met
the
requirements
for
alpha
which,
looking
at
retroactive
going
retroactive.
You
need
to
then
complete
both
of
those
checklists.
So
if
everything
it
was
in
one
checklist
and
you'd
have
one
issue
to
keep
track
of.
E
K
So
it's
all
marked
down,
so
you
can
add
whatever
checklist
and
headings
and
everything
you
want.
There's
no
reason
we
couldn't
combine
it
all
into
one
file
and
then
I'd
have
to
figure
out
as
far
as
tooling,
how
to
do
regex
or
whatever
to
match
those
fields
that
have
been
completed.
The
challenge
I'm
seeing
here
that
I
know
is
coming
up.
I
haven't
figured
it
out
yet
is
the
gating
as
far
as
hey
you
know
what
toc
has
approved
this
promotion
right
here.
K
E
N
N
E
E
C
E
K
C
I
I
think
I
I
said
this
earlier,
I'm
sorry.
I
would
like
to
see
this
be
more
grassroots
and
less
about
top-down
mandates
from
the
toc
they're,
the
they're
there
there's,
I
mean
louis
to
your
point
like
at
some
at
some
point.
Yes,
like
there
there's
a
minimum
bar
for
for
ga
and
a
minimum
bar
for
beta
features,
and
we
need
to
set
that,
but
I
I
still
think
we
should.
It
would
be
nice
if
this
came
from
the
test
and
release
working
group.
C
M
C
L
G
One
crazy
idea
when
it
was
discussed
in
the
environment,
I
think,
or
some
of
the
chats
in
on
slack
in
some
cases,
it's
useful
to
have
a
different
person
whose
evaluation,
if
a
feature
is
tested,
completed
and
boxes,
are
checked
from
the
person
who
writes
a
code,
because
you
know
people
are
usually
honest,
but
there
are
some.
You
know
other
factors
so
and
also
kind
of
to
have
someone
independent.
You
know
kind
of
with
experimented
with
tests
with
familiar
and
understand.
G
The
testing
needs
makes
the
decision
of
what
kind
of
test
the
future
needs
compared
to
the
person
who
writes
the
code,
because
also
there
is
different
motivation.
So
maybe
the
test
and
release
working
group
should
kind
of
take
more
lead
on
you
know
doing
this
work
and
and
taking
ownership
of
the
checkboxes
and
not
the
developer.
Who
saw
him
on
that
feature?
E
G
K
O
C
F
E
L
E
O
E
I
Sure
it's
not
it's
not
shared,
but
I
know
what
I
mean.
The
feature
state
which
is
listed
in
the
link
and
click
they're.
All
most
of
them
are
stale,
so,
for
example,
mixer
is
listed
and
it's
already
deprecated
walking.
Category
upgrades
are
not
even
listed
here,
so
the
question
is:
who
is
the
responsible
to
make
sure
this
is
updated
every
time
and
how
do
we
make
sure
that
it
is
on
the
market.
F
L
I
Q
Q
We
introduced
the
work
worker
group
and
the
work
of
the
entry
which
is
actually
analogous
to
kubernetes
deployment
and
ports,
and
so
in
the
in
the
context
of
vm,
we
are
currently
using
workload
group
to
decide
a
vm's
identity,
so
it's
basically
serving
as
a
source
of
truth.
When
you
set
the
service
count
field
in
worker
group,
we
basically
decide
what
the
vm's
identity
will
be
so
yeah.
Q
So
I'm
currently
wondering
because
currently
the
worker
group
is
actually
in
networking.estio.io
api
group,
so
this
makes
sense
to
actually
move
this
to
a
corner
work
group.
I
don't
know
I
just
made
that
made
it
up.
Maybe
we
can
have
something
called
a
call.etheo.io
so
that
we
know
this
is
some
like
security
and
the
networking
critical
resource,
similar
to
how
kubernetes
handles
it.
G
I
think
at
this
point,
moving
things
around
is
very
disruptive
for
users.
Any
kind
of
change
has
always
been
a
huge
pain
and
there
are
a
lot
of
other
naming
related.
I
mean
the
secure
sub-social
names
and
and
other
things
that
are
in
the
coordinates
of
the
api,
like
gateway
and
destination,
so
I
would
be
very
reluctant
to.
Q
G
Q
Q
F
Q
Q
Q
G
Q
E
E
Q
J
J
So
one
of
the
challenges
is
that,
as
part
of
integration
testing,
we
want
to
make
sure
that
the
functionality
works
and
so
which
means
that
we
actually
in
the
integration
test.
We
actually
need
to
spin
up
the
external
ca
now
some
of
the
external
cas
that
we're
trying
to
test
with
they
don't
have
a
docker
image
as
and
they
don't
have.
They
don't
have
a
ready-made
image
that
we
can
actually
load
onto
integration
testing.
J
In
fact,
they
just
put
some
code
out
there
so
and
now,
if
we
wait
for
them
to
build
the
image
so
that
we
can,
you
know,
add
it
to
our
integration
testing.
It's
gonna
take
time.
So
the
question
I
guess
that
I
had
is
that
when
we're
integrating
with
external
components
under,
can
we
afford
to
build
so
they
have
source
code?
That's
out
there.