►
From YouTube: Technical Oversight Committee 2021/01/29
Description
Istio's Technical Oversight Committee for January 29th, 2021.
Topics:
- Request to all Working Groups to pick up some doc testing automation
- Status of 1.9 Release
- Status API Graduation follow-up
- Release Process update for API/feature stability
- Rename of east-west gateway to expansion gateway
- Request for nominations for 1.10 Release Manager
- Doc Working Group charter
B
C
A
C
C
D
This
is
up
to
date,
the
stats
is
in
the
weekly
routine.
We
still
have
couple
of,
I
think
four,
which
needs
to
be
claimed.
This
is
much
better
than
what
we
were
last
week.
We
also
reviewed
one
more
time
with
the
working
group
leads
and
demoted
some
of
the
p0's,
so
four
which
needs
claim-
and
there
is,
I
think,
13
which
are
in
progress
and
today
is
the
last
day
of
the
community
testing
date.
D
D
C
D
C
C
C
E
E
G
C
C
B
H
C
G
C
C
C
D
We
are
starting
next
week,
josh
the
when
we
do
the
presentation.
The
team
is
planning
to
do
a
yearly
roadmap
which
they
are
working
on
and
1.10
release
review
so
and
because
it's
a
yearly
roadmap
and
the
release
roadmaps
by
two
teams.
I
I
am
worried.
If
everything
can
be
done
in
each
week,
do
you
think
or
three
weeks
can
we
expand
the
toc
meeting
by
30
minutes
or
we
can
use
the
tuesday
meetings
of
working
depletes
for
the
reviews
because
we
always
like
fall
behind
while
they're
doing
it.
C
C
D
C
A
A
C
D
A
C
These
meetings,
okay,
so
then
that
would
mean
strata
like
straw,
man,
thinking
through
this
and
still
waking
up
during
the
roadmap
reviews,
cancel
the
working
group
lead
meetings,
replace
it
with
an
invite
on
the
community
on
the
working
group
calendar
or
the
on
the
working
group
calendar.
So
anyone
can
attend
the
reviews
and
direct
add
the
working
group
leads
just
so
they
know
they
gotta
attend:
okay,
yeah,
okay,
wonderful!
Thank
you.
C
D
C
I
C
C
C
D
I
Oh
sorry,
yeah,
my
mic
wasn't
working
so
after
looking
through
these
most
of
these
are
related
to
testing
or
like
actual
tests.
The
one
that
I
do
want
to
raise-
and
I
know
sam
is
on
the
call
so
he'll
have
more
information
about
this,
but
the
one
for
revision
upgrade.
There
are
two
outstanding
prs
for
this,
one
of
which
affects
the
api
repo
and
at
least
according
to
sam
and
sam.
I
Please
clarify
this,
but
there's
still
some
discussion
on
what
the
proper
approach
should
be
in
tackling
this,
so
this
at
least
from
an
outside
perspective,
it
seems
like
this
is
something
that
that
could
hold
up
the
release
potentially
or
we
can.
You
know,
move
this
down.
You
know
further
the
list
given
the
severity
of
this.
I
think
that
we
have
to.
I
C
A
C
G
G
K
C
C
K
G
Josh
also
in
place
upgrade,
is
in
the
same
state,
so
we
know
between
both
of
them.
You
know
have
problems,
but
revision-based
upgrade
is
the
one
least
likely
to
to
to
break
stuff
when
you
upgrade
it's
not
like,
we
ever
promoted,
in-place
upgrade
to
beta,
which
obviously
said
that
we
are
not
going
to
support
it
at
all,
because
it's
not
so.
C
G
L
G
G
C
C
C
C
H
We
have
recommended,
but
most
of
the
users
are
not
ready
to
move
and
most
of
the
user
probably
won't
move,
and
here
they
see
the
revision
beta.
So
if
you
look
at
our
future
status
today,
we
said
control,
plane
upgrade
is
beta,
which
is
our
in-place
upgrade
that
we
did
long
time
ago.
So
I
don't
see
people
switch
to
use
revision
until
it's
beta.
L
Most
features:
don't
have
a
label
on
them
right,
like
the
soul,
labeling
everything
alpha
and
beta
is
relatively
new.
It's
not
experimental
or
alpha
beta,
we
just
shipped
it,
and
then
we
decided
it
was
good
and
we
had
people
start
using
it.
We
never
went
through
any
process
of
assigning
a
label
to
it.
So
I
I
guess.
C
Okay,
so
I
I've
I've
been
feeling
we're
going
to
have
a
spin-off
meeting.
I
don't,
I
think
we
could
spend
the
rest
of
the
toc
trying
to
untangle
this,
but
we
have
two
different
upgrade
mechanisms
right
now
and
I
don't
know
what
the
adoption
is
relative
to
each
other
and
they
may
both
have
this
bug.
So
we
need
to
understand
whether
this
is
a
blocker
or
not,
and
we
might
have
two
blockers.
We
might
have
one
we
might
have
zero.
C
G
I
personally
don't
think
it's
a
big
deal.
I
mean
people
can.
Can
I
mean
if
we
document
that
hey
you
need
to
have
a
default
revision
at
all
times
I
mean
you
start
installing
by
default
revision,
which
is
also
you
know
what
you
used
to
have
and
then
you
switch
generative
vision
and
then
you
can
install
it
backwards
or
upgrade
it,
but.
C
M
G
G
C
H
A
A
Do
people
who
have
done
the
work
on
this
feature
want
to
promote
revision-based
upgrade
to
beta
in
1.9?
I
think
it's
fair
to
say
that
control
plane
upgrades
being
at
beta
for
in
place.
You
know,
despite
the
reservations,
is
what
we've
communicated,
and
so
we
need
to
be
consistent
about
it,
and
if
we
are
going
to
hold
to
our
recommendation,
then
we
should
probably
try
and
bring
revision-based
upgrades
to
beta,
but
that
implies
work.
A
G
My
my
my
question
is
regardless
of
what
labels
we
put
and
regardless
of
what
we
see
in
the
docs,
there
is
a
reality
that,
if
you
do
an
in-place
upgrade,
you
may
have
an
omg.
If
you
don't
you
may
not,
I
don't
know
how
we
communicate
it,
how
we
label
how
we
say
that,
but
even
for
one
eight
and
one
seven,
you
know
since
one
six
when
we
actually
introduced
it
is
released.
That
was
the
reality.
G
G
Yeah,
the
problem
that
it
is
better
thank
you
because
avoids
some
problems,
but
it
is
more
difficult
and
I
think
that's
why
there
is
some
reluctance
and
some
people
you
know
prefer
to
keep
using
in
place
upgrade,
even
if
there
is
some
risk.
I
don't
know
how
to
express
this
duality
between
safety
versus
usability
and
that's.
H
A
G
So
maybe
maybe
to
follow
up
on
this.
Maybe
if
we
are
okay
to
say
that
that
hey,
there
is
some
extra
pain
and
some
additional
steps
you
need
to
do
for
revision
in
exchange
for
the
safety.
We
can
also
document
this.
You
know
the
worker,
I
mean
whatever
step
part
needed
to
keep
the
version,
the
validation
work
and
the
other
stuff
working.
So
there
are
some
additional
steps,
but
it's
already
a
bit
more
complicated,
and
if
you
don't
want
down
times,
then
you
need
to
you
know
I
mean
I
I
I
I
I.
C
Not
going
to
get
through
it
in
the
tfc
today,
unless
we
devote
the
entire
toc
to
it,
so
I'll
take
an
action
item
to
set
up
a
meeting
to
discuss
I'll
pull
in
the
environments
and
the
upgrade
working
group
leads.
I
will
pull
in
the
members
of
the
toc.
You
do
not
all
have
to
attend.
Who
else
should
I
pull
in.
C
I'm
sorry,
I'm
skipping
a
step.
We
still
have
other
release
blockers
anything
else.
We
should
look
at
in
the
release
blocker
list.
One
thing
that
caught
my
eye
was
that
we
have
blockers
that
have
multiple
assignees
who's,
actually
fixing
it
or
do
we
have
a
diffusion
of
responsibility
from
or
you
know
say
you
know,
zongu
thinks
that
that
rama
is
fixing
it
and
vice
versa.
J
J
C
H
C
C
O
O
P
O
P
C
C
C
It
so
I
think
that
we
discussed
this.
The
both
of
these
are
in
the
control,
multi-cluster
stevens
working
on
it
and
then
the
load
balancer
ram
is
going
to
revert
to
pr
and
hopefully
that's
going
to
take
care
of
it,
and
I
already
looked
at
that
and
I'm
gonna
do
that:
okay,
mitch
you're
still
with
us.
C
At
it's,
basically
the
promotion,
the
status,
api
promotion,
you
know
the
whole,
you
discuss
the
split,
and
then
we
have
to
have
a
little
discussion
about
you
know
on
or
off
by
default,
for
the
thing
that
we're
going
to
promote
to
beta
and
then
for
the
stuff
that
is
going
to
be
revisited.
We
need
to
talk
about
the
working
groups
that
own
it.
E
Yeah,
I
think
the
only
thing
to
report
out
today
to
toc
is
just
that.
We
we
are
sort
of
splitting
the
the
decision
we
had
asked
about
status
overall
and
instead
the
question
will
now
become
the
analyzer
status
should
go
to
beta,
yes
or
no,
and
then
the
distribution
status
information
should
go
to
beta,
yes
or
no,
which
just
sort
of
decouples
those
two
features,
so
that
one
is
not
held
back
by
the
other.
I
don't
think
either
is
ready
for
evaluation
today,
we're
not
talking
about
one
nine
for
either
of
them.
E
C
C
C
E
We're
still
sort
of
discussing
regarding
first
off,
I
don't
think
we
have
consensus
around
there.
Yet
I
met
with
john
today
to
discuss
some
quality
issues
in
the
validation
api
and
right
now,
I'm
working
on
scoping
to
understand
if
those
can
be
resolved
in
the
110
time
frame.
There's
a
substantial
amount
of
tech
debt
left
over
from
the
istio
d
refactor
that
it's
looking
like
will
have
to
be
addressed
before
we
can
go
to
beta
so
I'll,
bring
it
back
to
the
toc.
E
C
That
the
validation,
api
and
not
impul
could
be
considered
beta
in
110,
but
we,
but
we
don't
do
things
we.
We
don't
have
like
a
beta
api
with
an
alpha
input,
so
there
there
would
be
some
changes
on
the
implementation
side
to
bring
that
up
to
data
quality,
yeah
and
and
then
there's
a
related
decision
about
whether
the
beta
feature
would
be
on
or
off
by
default,
and
if
it's
on
by
the
default
that
quality
bar
will
be
higher
and
and
it's
a
you
know,
I
think
that
the
main
issue
there
is.
C
A
Sometimes
what
these
decisions
mean,
I
don't
think
we
have
any
guide
rails.
Nor
do
we
have
anything
in
place
as
part
of
the
build
test
pipeline
that
would
kind
of
capture
if
we
went
off
the
rails,
which
is
maybe
something
we
want
to
consider
somewhat
orthogonal
now
I
don't
want
to
derail
this
meeting
on
that,
but
it's
worth
considering.
E
Right
now
it's
something
that
requires
meeting
and
debating,
and
there
have
been
a
lot
of
disagreements
about
it.
It
also
didn't
really
come
up
until
this
feature
was
like
days
away
from
trying
to
go
to
beta.
So
if
we
had
had
an
objective
standard
and
an
automated
test,
all
along
that
would
have
been
an
improvement.
That
being
said
that
again
water
under
the
bridge,
we
can't
fix
it
now
we're.
C
C
Okay,
so
for
so
par
there's
a
there's
going
to
be
a
subjective
element
in
this.
Always,
I
think,
which
is
you
know
if
there
is,
you
know,
an
efficiency
regression
we
have
to
say
is
the
feature
that
that
we're
introducing
worth
that
efficiency
regression
and
that's
going
to
be
subjective.
I
don't
know
how
else
to
handle
that.
E
C
C
Okay
on
the
gr
on
the
distribution
status
that
one
I
so
sorry,
let
me
back
up
and
say
that
for
validation
status,
I
think
it's
blindingly
obvious.
The
the
ux
working
group
owns
that
for
distribution
status.
I
don't
know
which
working
group
should
own
that,
I'm
not
sure
it's
ux
or
maybe
it's
some
combination
of
working
groups.
C
Yeah,
so
I
guess
what
I'm
trying
to
understand
is:
it
would
be
nice
for
distribution
status
to
be
approved
by
ux
and
networking
working
group
before
it
co-leads
before
it
comes
back
to
the
doc
or
you
know,
or
at
least,
if
you
guys
can't
agree,
you
know,
make
an
effort
and
then
bring
it
to
the
t.
You'll
see
if
you
can.
E
C
M
A
A
H
J
Yes,
so
this
this
kind
of
came
out
of
discussions
regarding
assigning
stability
levels
to
various
apis,
like
annotations
labels,
proto
fields,
all
those
things.
So
in
this
discussion
it
you
know
we're
taking
this
we've
been
taking
this
kind
of
past,
like
I
did
it
in
a
in
in
the
annotations
pr.
If,
for
those
who
reviewed
that,
where
I'm
just
kind
of
like
asking
everybody
okay,
what
should
an
initial
stability
level
be
for
all
these
apis
for
all
these
annotations?
J
So
the
thing
is:
is
that's
quickly,
gonna
become
out
of
date,
so
we
need
a
couple
things.
One
is
a
process
for
promotion,
things
which
brian,
I
believe,
certainly
our
team.
I
think
brian's
gonna
take
that
on
specifically
we'll
we'll
come
up
with
that
process.
I
think
it's
gonna
be
lighter
weight
and
feature
promotion
status.
Obviously,
but
we
still
need
to
kind
of
like
work
this
into
our
release
process
yeah.
So
at
every
release.
We're
kind
of
reevaluating
both
probably
feature
at
the
feature
level
as
well.
J
As
you
know,
just
individual
apis,
and
you
know
I
obviously
it
I
think
it.
Basically,
the
release,
manager
or
somebody
will
just
be
kind
of,
like
you
know,
nagging
the
enviro,
the
working
groups
to
to
kind
of,
like
you
know,
re
reevaluate,
their
respective
annotations
or
features
whatever,
but
but
it
still
does
kind
of
need
to
be
in
the
process
somewhere
that
somebody's
kind
of
like
nagging.
C
A
I
don't
remember
if
we
had
captured
that
state
other
than
say
deprecated,
which
is
more
for
an
external
facing
thing
anyway,
and
I
don't
think
we
necessarily
well.
Some
features
are
alpha
or
beta
right
or
some
of
these
apis,
sorry
or
alpha
or
beta.
We
didn't
necessarily
want
to
progress
them
right
like
since
some
of
them
we
wanted
to
stop
and
so
recording
in
these
in
these
places.
A
What
that
that
durable
decision
about
progression
is
what's
really
helped
the
person
who's
going
through
the
cat
hurting
because
they'd
see?
Oh,
this
hasn't
been
progressed
right,
so
I
need
to
go
nag
and
the
work
leads
would
felt
like
they're
they're.
Their
states
were
being
recorded,
so
they
weren't
going
to
be
magged
unnecessarily
right
on
things
that
were
not
considered
valuable
right.
J
So
so
in
so
so,
I
think
that
will
have
to
be
an
update
to
the
feature.
Promotion
process
and
it'll
have
to
be
a
part
of
the
api
promotion
stat
status
as
well
our
process
as
well
so
yeah.
I
think
that
makes
sense,
and
I
think
brian
is
already
working
on
changes
to
the
feature,
promotion
that
will
kind
of
enable
that
ability
to
kind
of
tag,
something
as
yeah.
I
want
this
to
be
promoted
by
one
pen
or
something
like
that
yeah,
so
yeah,
that's
yeah,.
D
J
So
there's
two
levels
to
all
this
right
there's
feature
status,
which
is
that
and
then
there's
individual
api
status,
which
is
a
new
thing
that
we're
determining
that
also
needs
kind
of
like
a
level.
It's
probably
it's
level
is
probably
going
to
be
at
or
less
than
the
feature
that
it
controls.
But
that's
you
know
that's
something
for
us
to
define
still
but
yeah,
but
that
those
can
theoretically
have
their
own
kind
of
like
promotion
lifecycle.
J
D
I
just
pasted
the
sheet
I
am
working
with
all
the
working
group
leads
from
last
three
weeks,
the
ones
which
are
not
stable,
which
are
quarter
or
release.
They
are
planning
to
move
it
as
a
progression
part
I
just
listed
there
and
on
how
to
make
it.
A
promotion
is
that
what
me
and
brian
are
working,
but
it's
definitely
makes
sense
to
have
you
included
in
those
discussions
as
well.
J
J
We
still
need
to
kind
of
like
follow
up
at
the
end
and
say
hey
dude.
We
have
to
do
it.
Do
we
promote?
Do
we
not
promote
and
the
same
things?
It's
it's
gonna,
be
you
know
at
the
api
level
as
well,
so
so
yeah
we
we
need
a
front
loading
and
a
you
know
of
of
establishing
what
we
want
to
do
and
then
and
then
another
re-evaluation
at
the
end.
A
C
Right
right,
so
this
would
or
would
not
be.
Would
would
I'm
not
that's
the
I'm
not
sure
about
that,
because
the
people
that
tend
to
do
the
release
management,
you
know
they're
they're,
making
sure
that
branches
are
created.
Tests
are
run
against
them,
they're,
looking
at
all
the
prs
coming,
so
it
is
more
kind
of
reactive
and
mechanical,
and
I
don't
know
if
they're
getting
the
bandwidth
to
do
this.
A
J
J
A
Yeah
well,
so
I
think
well
that
dumps
the
report
right
of
what
whether
things
are
meeting
their
their
promotion
goals
are
not
right,
like
if
you
said
that
this
feature
was
or
this
api
was
supposed
to
be
at
theta
for
1
11
and
it's
not
marked
as
beta.
Yet
then
right
as
you
get
close
to
the
release,
it
that
becomes
a
flag.
J
A
H
R
J
H
J
H
J
A
J
A
J
So
I
guess
today
does
the
release
manager
kind
of
like
do
nagging
at
the
back
end
to
say:
hey,
I
saw
you
had
this
featured
proposal
or
feature
promotion
proposal.
Did
it
happen?
If
that
happens
today,
then
I
think
I
think
that's
just
what
we
need
to
do
the
same.
We
need
to
do
the
same
thing
for
api
status
once
that's.
There.
R
A
D
A
A
C
Twitter
offline,
yeah
yeah,
it
would
be
great
if
we
can
move
on
to
the
next
one,
because
I'm
actually
quite
worried
about
it.
Okay,
jason!
Are
you
here,
yeah,
I'm
here
yeah.
I
guess
the
main
question
I
have
about
this.
Is
you
know
what
is
a
user-facing
impact
like?
Is
this
going
to
be
a
step
that
they
need
to
take
when
they
upgrade.
S
S
C
Think,
that's,
I
don't
think
we
can
do
it.
I
don't.
I
think
that
we
need
to
get
out
of
the
mode
of
so.
The
part
of
the
problem
is
that
a
lot
of
people
are
building
systems
on
top
of
the
istio,
where
we
will
automatically
upgrade
them,
and
we
can't.
We
can't
have
these
small
backwards
compatibility
breaks
because
it
means
we
can't
automatically
upgrade.
S
C
S
S
A
A
A
D
S
C
S
Yeah,
so
so
we
we
kind
of
made
an
internal
kind
of
this.
We
had
an
internal
discussion,
I'm
sorry
internal,
to
which
group,
oh
with
nate
and
a
few
other
folks,
okay,
yeah
so,
and
just
wanna
kind
of
this
is
a
very
last
minute
decision
because
we
figured
out.
This
is
a
some
long
buried
pr
that
we
we
we
wanted
to
make
changing
one
night,
but
we
didn't
take
care
of
it.
So
that
was
like
decision
made
yesterday.
C
S
J
Well,
no,
I
think
I
think
the
action
is
go
ahead
and
change
the
docs
right.
Okay,
I
think
that's
you
know
as
far
as
a
user-facing
thing
that
we
can
actually
change.
I
think
that's,
I
think,
that's
a
change
in
the
right
direction.
Yeah
the
fact
that
the
scripts
or
whatever
are
east
west.
You
know
we
can.
We
can
do
anything
in
that
realm
that
doesn't
break
upgrade
like
if
we
want
to
change
the
script
name,
we
can
probably
do.
N
A
Yeah,
there's
probably
even
some
flexibility
on
instructions
right
if
a
script
that
a
user
might
have
used.
If
you
rename
the
script,
it's
not
terrible
right
like
that's,
not
really
yet
terrible,
breaking
change.
It
still
has
the
potential
to
be
breaking
so,
but
it's
it's
not
like.
We
haven't
made
changes
to
command
line
arguments
or
other
things
of
a
similar
ilk
right,
yeah,.