►
From YouTube: Technical Oversight Committee 2020/11/13
Description
Istio's Technical Oversight Committee for November 13th, 2020.
Topics:
- Release Blockers for 1.8
- TOC Approval for Helm support moving to Alpha in 1.8
- Istio 1.9 Roadmap Presentations for Networking
A
B
A
A
A
I
hope
lisa,
I
hope,
he's
nice
here
but
yeah.
I
think
if
he
split
slips,
I
would
propose
two
days
after
this
vr
is
merged
and
then
like
that,
will
give
us
give
us
some
buffer
for
build
and
the
proof
test,
and
I
would
expect
that
pr
could
be
merged
like
definitely
today
or
earlier
next
week,
so
latest.
I
think
next
thursday.
Maybe
would
that
be
acceptable.
C
C
A
A
A
E
I'm
not
sure
whether
steven
is
here
yeah,
so
that
fix
actually
was
not
going
to
be
sufficient.
It
was
kind
of
like
a
thing
that
would
just
still
break
as
soon
as
the
jot
expired.
I
am
working
on
a
different
fix,
though,
that
I'm
not
100
sure
will
work
or
I'm
not
hunter
century
I'll.
Have
it
done
by
the
end
of
the
day.
I'm
not
really
sure
why
the
tests
aren't
working.
C
D
D
F
F
So
so,
in
our
case,
our
user
was
using
revision
for
the
customer
gateway
1.7
during
the
iop
sql
operator
yaml
file,
but
in
1.8
because
of
the
semantic
of
the
revision
change.
Because
of
the
work
we're
doing.
I
think
martin
made
some
change
to
support
revision-based
gateway
upgrades.
So
the
semantics
of
the
revision
change
the
the
resolution
is,
you
would
actually
go
into
that.
Is
your
operator
yamo
and
remove
the
revision
field,
and
then
everything
has
been
working
for,
for
that
particular
simple
scenario:
we
tried.
F
G
B
G
F
F
They
had
in
their
istio
operator.yaml
file,
because
the
semantic
of
the
revision
changed
from
one
seven
to
one
eight
for
gateways,
because
if
you
don't
remove
that
revision
in
the
install
operator,
it
would
point
to
like
stod
revision
as
the
discovery
address,
which
in
their
case
they
were
using
like
the
in-place
upgrade
for
ecod.
So
it
doesn't
make
any
sense
for
them.
So.
G
F
D
G
I
mean
we
can
definitely
fix
that.
There's
a
hammer.
I
mean
it's
because
the
correct
behavior
is
very
clear
and
I
mean
with
helm
at
least
it's
clear
that
we
do
not
install
at
the
same
time
as
a
gateway
and
the
control
plane,
because
there
are
two
different
help:
charts,
that's
what
we
want
to
do
with
operator
as
well,
and
I
think
steve's
documents
describe
this
process
as
well.
So
the
problem
is
remains:
how
do
you
configure
the
gateway
and
gateway?
G
Just
like
any
other
workload,
you
need
to
point
it
to
a
particular
revision
of
history,
which
can
be
anything
and
the
gateway
itself,
the
name
of
the
gateway.
It's
a
separate
term.
There
are
two
different
things
in
gateway.
It's
you
know.
If
you
have
custom
gateways,
you
have
the
name
of
the
custom
gateway
and
each
gateway
can
point
to
an
arbitrary
control
plane.
So
there
are
two
completely
different
concepts:
the
name
of
the
gateway
and
the
the
namespace,
and
also
the
revisions
that
you
are
using.
F
So
one
action,
certainly,
I
would
think
we
need
to
make
sure
the
upgrade
notice
is
pretty
clear
on
the
semantic
hinge.
We
definitely
need
to
look
at
that.
It's
your
cuddle.
There
may
be
worthwhile
to
look
at
the
tool
inside.
I
don't
know
where
we
are
on
istio
condo.
For
one
a
do,
we
have
like
a
dry
run
command
to
tell
people.
These
are
the
things
you
know
they
should
be
thinking
about
modifying
update
before
they
move
to
1.8.
F
G
H
I
G
D
B
C
F
C
H
F
J
Well,
and
even
if
we
had
like
a
pre-upgrade
command
in
istio
control,
which
sounds
like
a
good
idea,
I'm
not
certain
that
we
would
catch
this
scenario
or
what
we
would
advocate
that
the
user
do,
because
this
was
a
scenario
that
we
didn't
document
anywhere
so
like
all
of
our
docs
tests
and
everything
else.
Yeah
never
be
covered
with.
C
J
J
C
H
B
K
K
B
H
B
G
Just
one
tiny
comment
here:
the
documentation
is
also
kind
of
still
in
in
two
worlds.
I
mean
there
is
the
old
style.
Where
is
your
catalyst?
Installing
everything
and
some
documents
are
in
the
new
world,
where
you
install
a
control
plane
separately
from
the
gateways,
for
example
with
helm?
It
can
only
be
separated
because
there
are
two
different
run:
charts
the
documentation
for
safe
upgrade
for
gate,
which
are
moving
towards
that.
That,
I
think
wrote
are
also.
G
You
do
not
install
the
gate
when,
when
you,
when
you
operate
on
the
control
plane,
while
many
documentation
examples,
still
assume
the
old
old
way.
So
that
is
a
breaking
change
that
will
keep
going.
I
mean
one
nine,
it
will
be
even
more,
you
know,
separate
and
user
will
control
the
gateway.
There
is
a
proposal
from
john
also
on
the
same
area,
so
I
want
uc
to
be
aware
of
this,
and
you
know
everyone
here
to
pay
attention
to
this.
L
B
C
Okay,
we
should
move
on,
I
think,
but
I
would
like
I'm
asking
other
toc
members
right.
Clearly
this
is
a
a
common
occurrence
right
where
we
and
there's
an
installer
upgrade
edge
case
that
we
don't
anticipate
before
the
release,
and
you
know
sometimes
these
get
found
after
the
release,
but
we
don't
have
a
way
of
capturing
them
mechanically
and
we
want
to
get
to
a
point
where
we
capture
them
mechanically,
so
that
users
doing
the
same
thing
over
and
over
again
get
an
expected
result.
C
M
D
N
H
G
G
C
H
B
H
G
H
B
C
B
O
O
Stuff
like
this
is
one
of
those
things
it's
like:
okay,
yeah.
Well,
that's
going
to
take
me
more
time
to
upgrade,
because
now
I
got
to
rework
stuff
to
get
there
and
I
you
know,
do
we
consider
this
when
we
make
these
breaking
changes
and
if
we're
making
breaking
changes,
do
we
at
least
make
an
effort
to
try
to
preserve
the
existing
functionality
so
that,
at
least
if
users
are
using
those
they're
not
broken
until
say
1,
9
or
110,
but
it's
more,
I
guess
rhetorical
than
anything.
C
F
Yeah,
how
about
people
yeah
do
the
homework
and
louie
asked
and
then
come
back
to
the
toc?
If
you
still
have
concern
for
me,
you
know
I'm
working
on
this
back
for
two
days.
You
know
stuff,
we've
been
telling
user
to
do,
but
I'm
happy.
You
know
it's
heading
to
a
good
direction
and
I
I
really
like
louie
what
you
have
with
the
framework
with
update
a
pre-updated
analyzer,
because
I
mean
if
that
tool
exists.
C
H
B
C
J
J
C
So
what
these
customers
right,
the
big
problem
we
have
with
customers.
If
you
tell
them
they
have
to
make
a
change
as
long
as
they
know
they
have
to
make
it
right.
You
have
a
much
better
user
experience
right.
What
you
don't
want
to
have
happen
is
they
don't
know,
and
then
they
end
up
broken
right.
Those
are
two
radically
different
outcomes.
Customers
doing
some
work
on
upgrade
as
long
as
it's
prescriptive
and
I'll.
P
H
G
F
G
I
300
values
yeah:
the
configuration
was
clearly
wrong.
In
my
opinion,
we
that
was
never
intended
to
work.
It
happens
to
work
by
a
miraculous
being
of
multiple
different
bugs.
So
this
is
not
the
same
as
other
cases
where
we
broke
backwards.
Compatibility.
In
my
opinion,
this
is
someone
yeah
using
a
bizarre
configuration
that
we
happen
to
change,
so
we
can
still
detect
it
and
stuff,
but
it's
it's
not
really
the
same
class
as
the
other
ones.
In
my
opinion,.
P
So
so
this
is
so
then
this
is
in
the
same
category
as
we
had
another
issue
where
someone
used
proto
text
format
to
define
configuration
which
is
not
in
any
of
our
documentations.
It's
not
it's
not
advertised,
but
it
happened
to
work
and
when
we
changed
that
to
json,
which
is
what
we
really
document
it,
it
broke
the
user.
So
this
this,
then
seems
like
that
that
it
was
an
undocumented
feature
which
happened
to
work,
and
so
so
then
I
don't
think
we
can
apply
the
same
rules.
There.
H
N
B
B
C
F
Okay,
I
mean
I
like
to
see
the
framework
in
place,
so
we
can
contribute
easily
when
things
are
detected
before
round
eight.
But
I
understand
you
know
the
release,
schedule
and
everything,
because
if
we
have
the
framework
you
know
everybody
can
chime
in
when
this
issue
happens.
So
it
would
just
be
so
much
helpful.
Like
you
know,
one
user's
issue
translate
to
a
tooling
for
100
other
users,
yeah.
B
C
C
C
The
decision
about
whether
this
is
a
blocker
or
not
is
not
predicated
on
anything
that
we
just
asked
mitch
to
do
or
ed
to
do
right,
but
it
might
be
predicated
on
what
we
asked
steve
to
do,
which
is
or
well
sorry.
No,
I
don't
mean
that
none
of
the
analyzer
work
right
is
going
to
happen
before
one
day.
C
F
C
B
B
This
is
proposing
making
it
alpha
environments
working
group
yesterday
or
day
before
yesterday,
approved
it
approved
the
rfc
and
from
their
site
was
directionally
approved.
There
are
docs,
there
are
pests
for
it.
If
you
scroll
down,
there
were
some
suggestions.
It
says
that
environments
working
group
made
how
to
improve
the
documentation.
B
B
N
This
is
do
we
do
we
approve
marking
this
one
alpha
in
there
yeah
any
objections,
and
I
think
I
I
have
lots
of
comments
in
there.
Obviously,
right,
like
my
main
one,
was
there's
no
there's
nothing
in
the
dock
today
that
says
how
to
configure
it
or
what
configuration
options
are
supported,
so
we
should
fix
that.
Otherwise,
I'm
good
yeah.
B
B
That's
a
good
question
so
for
this
one
I
don't
know
what
kind
of
apis
you
were
talking
about.
The
interface
is
through
the
helm,
install
upgrade
that's
one
api,
which
everyone
understands
and
that
is
approved.
The
other
api
is
configuration
values
which,
in
the
environments
working
group,
we
discussed
that
in
the
docs
we
will
say
the
values
supported
are
experimental
right
now
and
in
one
nine
we'll
try
to
mature
them.
B
D
G
C
F
N
B
N
B
C
I
I
The
main
things
that
aren't
are
all
at
the
bottom
in,
like
p3
and
nebula's,
future
that
we've
discussed,
but
we're
probably
not
going
to
focus
on
the
main
risk
I
would
say,
is
that
the
single
outbound
listener
work,
which
may
be
something
that's
required.
If
envoy
removes
support
for
the
apis,
we
depend
on
we
we
don't
have
an
owner
for
that.
So
that's
something
we
we
need
to
address.
C
C
I
I
B
Been
you
know
talking
about
it
for
pretty
much
most
of
this
year
now
and
it
has
been
a
p0
and
the
p0s
that
we
have
been
talking
about
were
actually
getting
a
demo
already.
That
we
can
show
before
is
the
demo.
Is
it
in
a
demobile
state?
Now-
and
this
is
the
next
p0
or
are
we
still
talking
about
getting
to
a
demo
able
state.
B
C
H
B
H
G
C
C
C
C
C
C
B
C
So
I
think,
there's
a
there's
a
general
question
here
right
we
allow
as
a
project
people
because
it's
community-based
we
allow
people
to
come
in,
propose
a
feature
and
implement
it.
Even
if
it's
not
a
p0
right,
we
are
open
to
ideas,
even
though
they're
not
necessarily
aligned
with
kind
of
the
top-line
roadmap
for
the
project.
F
C
B
C
P
C
B
C
N
And
another,
the
general
way
you
would
do
this
like
if
we
treated
this
as
if
it
was
a
continually
delivered
service
right
like
one
is
a
branch
and
another
is
just
getting
really
really
good
at
making
sure
that
things
are
well
tested,
even
when
they
first
go
in
and
have
a
clear
flag
control
that
they
can't
come
on
right
in
default
like
we
should
just
be
really
careful,
reviewing
new
stuff
and
making
sure
it
doesn't
break
things.
But.
N
C
I
We
talked
about
these
in
our
working
group.
We
are
interested
in
these.
We
have
absolutely
no
intent
of
doing
these
in
the
near
future
because
they
don't
have
owners.
If
someone
said
I
really
want
to
implement
hdb3
at
the
gateway,
though
then
we
would
be
perfectly
happy
with
that,
but
we're
here
to
have
the
the
bandwidth
to
solve
it
right
now,.
B
N
B
Q
N
B
C
Because
there's
a
decent
chance,
it
could
slip
again,
so
you
know,
but
but
still
a
feature
that
requires
more
than
one
person
to
work
on
it.
That
could
have
a
decent
amount
of
lateral
impact
so
that
we
could
evaluate,
because
the
the
pain
of
doing
keeper
branches
right
and
we
can
still
adhere
to
feature
flags
and
all
the
other
requirements
of
alpha
right,
because
it
doesn't
matter.
If
you
just
need
to
ship
the
feature
you
still
have
to
give
users
control
whether
that
would
work
efficiently
right.
B
Q
N
Right
we're
a
bit
over
time.
I
had
one
concern
that
I'd
like
to
maybe
talk
about
next
toc,
which
is,
I
see
a
lot
of
things
labeled.
You
know
they're
going
to
alpha
or
or
a
couple
in
the
beta
and
nothing
is
ga,
and
I
think
we
we
as
a
project,
need
to
maybe
start
focusing
a
little
bit
more
on
getting
some
stuff
to
actually
ga
we
have
a
like.
Do
we
have
any
stable
apis
yet,
do
we
have
anything,
that's
in
b1
api
or
is
everything
still
beta?
B
N
B
H
N
B
So
a
way
to
say
this
also
will
be.
If
networking
working
group
can
come
back
with
two
features,
they
think
they
can
promote
and
that's
the
standard
we
can
set
for
one
nine.
That
might
not
be
a
bad
idea
for
other
working
groups
before
you
think
about
adding
more
things
in
alpha,
make
sure
you
have
enough
b
and
s
there.
C
You
know,
obviously
that
would
be
very
useful
guidance
for
everybody
working
on
the
project,
and
we
should
then
focus
a
bit
less
on
features
and
items
on
these
various
roadmaps
that
are
stability
related
right.
There
are
obviously
things
that
working
groups
need
to
deliver
that
may
that
are
kind
of
effectively
blockers
for
certain
things.
I
don't
think
we
would
get
that,
but
it
would
be
guidance
we
might
want
to
give
all
right.
F
F
Yeah,
the
other
thing
really
quickly,
zhongfu
mentioned
about
rayleigh
meeting.
We
also
have
our
user
asking
it's
like:
okay,
mixer
is
being
removed.
What
do
we
do
on
really
mean
because
I
think
that's
the
most
single
feature
of
mixer
that
people
likes
to
use?
So
what's
our
recommendation,
so
I
back
to
you
know
what
you
guys
were
discussing
stabilized
feature
and
also
you
know,
having
story
in
place
for
features.
We
are
deprecating
and
removal.
I
think
it's
very,
very
important.