►
From YouTube: Technical Oversight Committee 2021/02/12
Description
Istio's Technical Oversight Committee for February 12th, 2021.
Topics:
- Alpha promotion of Gateway Topology
- Roadmap planning concerns
- Networking 2021 and 1.10 roadmap presentation
- Review of potential breaking changes
C
C
C
B
C
G
C
C
E
G
E
G
B
A
B
E
I
J
B
E
This
did
get
approved
in
the
networking
working
group.
Well,
that
was
the
last
status
unless
people
in
the
toc
and
this
meeting
have
any
objections.
I
think
it's
pretty
much
approved.
It
has
gone
all
through
the.
It
has
gone
through
all
the
stages
and
there
is
an
enhancement
issue
which
we
can
look
at.
K
D
Yeah,
I'd
like
to
point
out
that
I
put
an
item
at
the
top
of
the
of
the
queue
basically
to
to
say
that
I
I've
noticed
recently
that
people
are
kind
of
inserting
at
the
top.
When
you
know
sorry,
I'm
still
waking
up.
Other
people
already
had
items
and
it's
it's
fair.
It's
more
equitable
to
put
your
items
at
the
bottom
of
the
queue
and
in
order
to
send
this
message,
I
I
put
this
little
blurb
at
the
top.
Sorry.
B
And
then
people
put
things
up
yes,
but
it's
mostly
known,
I
was
mostly
just
teasing
right.
I
think
that
I
think
that's
fair,
yes,
make
sure
when
you
add
an
agenda
item
put
it
at
the
bottom.
I
think
something
that
we
all
should
do
is.
I
would
recommend
people
put
a
time
bound
on
their
items
like
how
long
they
think
it
should
take,
and
we
should
try
to
stay
within
that
time
bound.
J
B
A
Yeah,
so
we
there
there
was
a
there
was
a
request
or
asked
from
the
toc
to
have
a
yearly
roadmap,
and
then
there
is
a
general
format
of
reviewing
the
quarterly
roadmap
of
a
release
and
then,
after
the
release,
there
is
a
retrospective.
So
we
were
discussing
that
in
the
working
group
leads
and
seems,
like
I
mean
it's
a
lot
of
process
work,
obviously
for
everyone
to
work
on,
we
have
been
doing
that
at
least
the
yearly
came
up.
A
You
know
starting
last
week
of
november
and
we
are
still
working
on
it
now.
It
is
at
a
point
where
you
know
we
are
working
on
that
perspective
and
quarterly
and
yearly
roadmap
and
there's
a
general
concerns.
There's
a
lot
of
work,
so
I
just
wanted
to
hear
from
the
toc.
What's
the
best
way
forward,
do
we
need
all
of
them
is
that
is
there
value?
A
D
J
J
I
So
the
challenge
that
I
saw
with
it
is
just
a
year
is
a
hard
time
to
come
up
with
a
plan
for
ahead
of
time.
I
don't
mind
doing
it,
but
things
change
very
rapidly
in
the
project
and
trying
to
plan
out
a
year
means
that
information
that
might
not
be
accurate
and
it's
hard
to
hard
to
go
out
and
plan
that
far
in
advance
and
know
that.
J
D
I
E
I
H
E
D
B
B
A
J
A
No,
it
does
not
all
so.
My
general,
you
know
concern
was
to
have
a
consensus.
Do
we
want
a
yearly,
as
was
a
quarterly
roadmap,
because
I
think
that's
where
the
more
contentions
are,
that
quarterly
is
more
detailed
and
when
we
review
the
yearly
it
does
capture
the
quarterly
roadmap,
like
let's
say
for
the
current
one,
but
it
does
not
go
into
the
details
so
are
we?
J
A
L
Then,
in
the
toc
meeting
we
spend
probably
three
weeks
a
quarter
reviewing
road
maps
reviewing
retrospectives,
then
we
have.
The
weekly
working
group
leads
meeting
where
we're
looking
at
our
roadmap
and
checking
how
we're
doing
on
it.
I
don't
think
that
that
is
bad,
but
it
simply
means
that
the
payoff
for
all
of
that
investment
needs
to
be
very
visible,
certainly
in
2020
on
the
annual
roadmap.
We
know
that
we
didn't
have
the
kind
of
payoff
that
we
needed
to
justify
the
investment
there.
L
J
A
That
working
group
leads
meeting
louis.
We
discussed
that
not
a
mandatory
to
do
the
retrospective.
If
a
working
group
lead
leads,
think
that
they
need
it
and
it's
helpful,
they
can
actually
fill
up.
These
slides
and
toc
can
review
it
offline,
but
if
they
feel
like
we
don't
need
to
do
that
or
maybe
there
is
no
time
that
it's,
then
it's
not
mandatory
and
they
can
skip
it
all.
B
I
have
a
a
couple
of
quick
comments.
I
think,
on
the
on
the
rubik
presentations.
I
agree
with
louie.
These
are
actually
important,
especially
for
other
working
group
leads
to
understand,
like
what
other
groups
are
doing.
I
think
we,
actually
we
want
that,
especially
actually
mitch.
Ux
really
should
understand
what
every
other
working
group
is
doing.
I
know
it's
a
lot
of
time,
but
I
think
it's
important.
B
B
E
Yeah,
I
think
so
I
was
going
to
say
the
two
points
that
he
just
said.
So
I'm
not
going
to
repeat
that,
but
basically
looking
at
the
quarterly
roadmaps
and
toc
meetings
is
one
of
my
favorite
parts
here,
not
just
because
I
get
to
understand,
what's
going
to
happen
all
the
crosstalk
and
trying
to
understand
collectively
how
it
is
moving.
E
But
it
looks
like
mitch,
you
were
saying
it's
less
useful
and
the
usefulness
is
being
measured
by
how
much
you
we
have
actually
achieved
in
the
roadmap
that
we
set
out
early
in
the
quarter
early
in
the
year.
So
there
can
be
a
lot
of
things
that
might
have
gone
wrong
because
of
which
we
didn't
achieve
it
right.
E
If
that's
the
only
measure
of
usefulness
that
you're
talking
about,
we
can
work
on
lots
of
different
things
to
improve
the
efficiency
there.
Is
there
some
other
usefulness
that
you're
trying
to
get
out
of
these
activities,
but
you're
not
getting
like?
Is
there
some
value,
which
is
inherently
missing.
L
That's
a
good
question
and
I'm
not
sure
that
I
have
a
clear
answer
to
it:
I'm
simply
observing
that
there's
a
great
deal
of
investment
on
the
working
group
leads
side
and
it
doesn't
always
feel
like
there's
value
for
that
investment.
If
that
makes
sense,
unfortunately,
I
know
that's
pointing
out
a
problem
and
not
a
solution.
B
B
E
So
another
thing
can
be
better
course,
correction
and
sort
of
actually
maybe
at
least
twice
in
a
quarter
understanding
where
we
are
with
our
proposed
promises
for
the
quarter
like
it
looks
like
that
part
is
also
missing.
We
actually
don't
measure
until
the
end.
They
say.
Okay,
we
didn't
finish
these
things,
so
they
move
on.
C
Yeah,
that's
good,
so
guys
I
feel
like
there's
huge
value
on
the
overall
roadmap,
because
that's
also
made
out
your
user,
the
workgroup
roadmap.
You
know
it
should
be
minimum
time
spent
because
it's
really
used
internally
by
our
contributors
and
the
community
right.
So
I
hate
to
say
you
know
we
would.
We
would
not
require
you
guys
to
spend
a
lot
of
time.
It
should
be
minimum
time
and
adjust
as
needed.
J
You
know
that
one
we
have
made
a
statement
that
we
do
want
to
track
that
in
detail,
but
we
could
possibly
just
break
that
out
from
the
other
aspects
of
the
roadmap,
which
are
more
feature,
function,
oriented
and
say:
look
those
things,
they're
attracted
a
very
kind
of
coarse-grained
aspirational
description
of
what
we
want
to
do
for
the
annual
and
then
we
just
right.
We
just
have
a
more
detailed
tracking
for
api
progress
or
or
feature
progression.
J
A
J
C
So
giving
our
dates
around
it's
your
account
I
assume
most
likely
going
to
have
instagram,
probably
early
next
year.
Also
it
does
seems,
make
sense
to
have
like
the
most
recent
roadmap
produced
before
the
conference.
So
I
kind
of
like
what
lui
mentioned
like
early
in
the
year,
so
maybe
the
first
quarter
would
be
more
dedicated,
not
much
feature
from
world
group,
but
you
know
having
the
roadmap
produced
by
the
toc
and
then
the
war
group.
A
A
B
M
M
B
J
H
It's
not
a
big
deal.
If
not,
I
can
just
describe
it.
Okay,
yeah.
I
think
this
is
most
of
the
stuff
we've
already
talked
about
in
previous
road
maps,
as
kind
of
longer
term
plans.
I
actually
don't
think
there's
anything
here,
that's
going
to
be
surprising.
Potentially
so,
first
up,
we
have
better
transport
security.
We've
been
working
on
this
for
a
quite
a
while
now
and
that's
going
to
continue
to
be
a
focus
in
2021.
E
K
M
H
Yeah,
I
think
we
haven't
really
done
anything
on
the
easter
side
because
it
relies
on
the
envoy
stuff,
but
the
envoy
side
side's
been
progressing
quite
a
bit
so
got
it,
that's
good.
I
think
it
will
very
suddenly
happen
on
the
east
joe
side,
and
it
will
quickly
happen
because
the
control
plane
changes
are,
you
know
pretty.
H
So
we've
done
some
work
on
that
already,
but
we're
going
to
continue
exploring
that
a
bit
more
in
2021.
Hopefully
this
next
one
has
been
on
a
roadmap
for
quite
a
while.
So
it's
kind
of
been
already
in
the
yellow
or
red
that
we
want
to
promote
cni
out
of
alpha
stabilize
it,
improve
it
a
bit,
make
it
more
usable.
H
We
don't
have
an
owner
for
that
right
now,
so
it's
kind
of
tricky,
but
I
think
it's
pretty
important
because
it's
a
big
blocker
for
a
lot
of
users
and
it's
not
great
to
tell
someone
either
use
an
alpha
feature
or
go
use
another
solution
because
they
can't
use
estio
without
cni.
So
it's
important,
but
we
do
need
an
owner
next,
one
removing
custom
extensions.
This
is
really
low
priority,
but
it
would
be
nice
to
have.
We've
talked
about
moving
all
the
extensions
out
into
wasms
that
we
could
use
upstream
envoy
so
yeah.
H
This
is
more
of
a
nice
to
have.
We
don't
have
any
owners
dedicated
to
this
right
now
either
it's
probably
at
the
bottom
multi-tendency.
We
are
starting
to
explore
it
a
bit.
I
don't
think
we
have
any
concrete
designs,
which
is
why
we
it's
kind
of
vague
right
now,
so
the
action
here
is
not
really
to
go,
implement
multi-tenancy,
but
more
to
figure
out
what
exactly
we
want
to
do
for
multi-tenancy
and
then
maybe
we'll
implement
it
as
well
in
2021,
depending
on
what
happens,
but
for
now
it
is
intentionally
vague.
K
H
H
Your
current
plans
are
to
potentially
be
ga
by
the
end
of
the
year,
so
we
definitely
need
to
keep
up
adoption
with
them
and
make
sure
that
we
drive
the
direction
of
the
project
in
a
way
that
aligns
with
east
geo
and
allows
us
to
adopt
them
for
gateway
and
sidecar
traffic,
so
we're
working
closely
with
them
and
continuing
on
that
this
next
one's
basically
linked
to
it,
but
the
stability
of
the
networking
apis.
This
is
effectively
a
thing
that
we
do
not
plan
to
promote.
H
H
E
H
E
H
C
H
Yeah,
so
all
of
the
apis
for
quite
a
while
will
probably
remain-
I
mean,
there's
probably
thousands
and
thousands
of
virtual
services
out
there
in
the
wild,
and
we
have
no
intention
of
just
stripping
those
out
and
making
users
migrate
forcibly,
so
we'll
probably
have
to
keep
those
apis
around
for
a
very
long
time.
I
don't
want
to
say
forever,
but
you
know,
probably
quite
a
while
to
allow
people
to
migrate.
H
So
in
that
sense
they
will
definitely
be
there
now,
whether
the
optimal
or
like
recommend
recommended
is
to
use
sidecar
or
a
you
know.
One
of
these
new
apis
is
still
kind
of
up
in
the
air.
The
nice
thing
about
all
of
our
apis
is
they
they
layer?
Well,
so
you
could
definitely
use
like
their
hdp
route
and
gateway
and
replace
our
gateway
and
virtual
service,
but
then
still
layer
on
the
destination
rule
and
the
sidecar
apis
that
we
have
today.
So
whether
those
will
be
fully
replaced.
H
K
Also,
one
thing
to
keep
in
mind
is
that
kubernetes
apis
are
intended
to
be
multi-vendor,
so
there'll
be
multiple
implementations
of
multiple
vendors,
but
it's
also
a
baseline.
So
we
have
the
core
features
that
all
vendors
support
and
that's
the
main
power
of
them,
but
users
want
advanced
features
that
are
only
specific
to
each
use.
They
will
probably
continue
to
use
these
two
aps
for
those
specific
features
and
they
will
not
list
you
for
if
they
use
those
features.
K
B
J
J
J
But
it
is
getting
close,
so
I
I
do
suggest
that
people
who
specifically
spend
a
lot
of
time
on
the
networking
apis
start
familiarizing
themselves
with
the
current
state
of
the
gateway
apis.
Just
remembering
that
gateway
the
term.
These
their
gateway
is
a
collective
noun
to
refer
to
a
set
of
api
changes
and
not
just
the
gateway
resource
itself.
G
H
H
G
H
H
H
We
probably
this
would
be
just
I
mean
potentially
just
design
at
this
point,
we'll
see
we
don't
have
an
owner
for
this
either.
So
it's
kind
of
in
a
vague
territory
right
now,
but
it's
something
that
we're
looking
into
the
next
one
is
also
fairly
low
priority.
It's
supporting
http
3
at
the
gateway,
so
we're
not
trying
to
tackle
general
udp
support,
either
at
the
gateway
or
sidecars
due
to
some
complications,
but
hdb3
is
actually
relatively
easy
compared
to
generic
udp
supports.
H
B
H
So
I
think
the
most
important
one
is
cni,
that's
owner
list,
but
actually
also
important.
I
I
honestly,
I
don't
know
it
sounds
like
there
might
be
some
people
from
google
interested
in
pushing
this
forward,
but
I
haven't
heard
any
anything
inclusive,
the
other
things
like
alternative
capture
mechanisms.
H
B
G
E
E
J
Right,
yes,
we
are
friends
with
the
system.
Folks,
if
that's
what
you
mean
yeah,
we'll
we'll
certainly
talk
to
that
the
gke
networking
team
about
this
subject,
but
yeah
we
still
have
to
do
an
independent
evaluation
of
the
pros
and
cons
of
you
know
well
mostly
about
what
kind
of
dependencies
would
be
acceptable
to
take
right
to
do
this.
I
J
B
H
H
H
If
I
mean
we
need
to
find
owner
and
we're
definitely
going
to
have
a
lot
of
active
work
in
better
transport
security,
but
then
we
don't
have
any
any
solid
plans
beyond
just
continuing
with
these
other
longer
term
efforts,
so
we're
not
trying
to
introduce
anything.
Anything
too
new
in
1.10
just
continue
existing
efforts
and
stable
stability.
A
H
H
H
The
next
one
is
about
removing
the
server
header
by
default,
or
I
think
it
just
entirely,
I'm
not
sure
if
we
even
plan
to
make
configurable,
which
is
probably
fine
for
the
vast
majority
of
users.
The
concern
is
that
some
obscure
users
depend
on
random
headers
being
there
and
maybe
they're
doing
some
logic.
Based
on
that,
I
really
don't
know
why
someone
would
do
it,
but
you
know
people
will
do
anything
that
we
give
them
so.
E
H
J
J
J
K
J
K
J
A
B
J
K
K
J
N
C
B
B
H
H
So
if
that
table
probably
kind
of
describes
this,
but
when
you
add
istio,
we
configure
the
inbound
clusters
to
forward
to
localhost,
and
so
this
actually
changes
behavior.
So
if
you
bind
to
localhost
now,
your
service
is
actually
exposed
to
the
world,
and
the
other
concern
is
that
if
you
bind
to
the
pod
ip
now,
it's
not
exposed
to
the
world.
So
this
ends
up
with
a
lot
of
people
having
issues
with
applications
that
bind
to
the
pod
ip.
Some
common
ones
are
zookeeper
and
elastic
search,
and
so
what
will
happen?
H
Is
they
install
estio?
Suddenly,
all
the
traffic
stops
working.
They
have
no
idea
why
access
logs,
don't
really
help
envoy
logs,
don't
really
help
you
just
get
like
connection
refused,
and
it's
it's
pretty
tricky
to
debug.
You
know
we
have
a
goal
of
making
eastfield
just
drop
in
place,
and
so
ideally
we
preserve
the
behavior.
So
I
think
everyone
they
said
I've
talked
to
is
in
agreement
that
preserving
the
same
behavior
as
kubernetes
is
clearly
better,
but
the
one
concern
is
that
this
will
change
the
behavior
of
existing
users
of
istio.
H
So
unfortunately,
it's
it's
tricky
to
do
some
auto
migration
or
detection,
because
we
don't
know
what
the
application
is
going
to
bind
to
and
they
may
actually
do
it
at
any
point
in
the
pod's
life
cycle
right,
they
could
bind
an
hour
into
the
pod.
So
it's
not
like
we
can
even
do
startup
detection,
so
it's
tricky
to
provide
migration
here.
What
we
do
have
is
a
script
that
will
run
through
the
entire
cluster.
H
So
we
had
a
few
users
run.
This
there's
like
five
users
that
I
convinced
that
have
pretty
large
clusters
and
there
was
a
few
that
were
using
localhost
and
there
was
basically
two
cases.
One
was
they
were
actually
intentionally
doing:
localhost,
but
they're
already
using
sidecar
and
already
explicitly
configuring
it
to
connect
to
localhost.
H
H
We
did
not
consider
a
cve
part
of
the
reason
is
that
it's
only
so.
The
behavior
that
I
mentioned
with
easter
with
the
service
is
it's
only
if
that
port
is
exposed
in
the
service.
So
if
you
have
your
random,
like
like
the
admin
port
of
onboard,
for
example-
that's
not
exposed,
so
you
would
have
to
listen
on
localhost
and
expose
it
in
the
service,
which
is
kind
of
an
obscure
thing.
M
J
H
H
H
J
J
H
K
H
J
H
Right
but
users
can
adopt
the
correct
behavior
now,
even
without
the
patch
like
they
can
go
change
their
local
host
binds
to
wildcard
binds.
I
mean
they
can't
change
them
to
pod
ip
binds.
I
suppose,
but
I
think
most
people
are-
will
go
to
wild
card.
That
seems
the
vast
majority
of
applications
are
doing.
J
J
J
E
B
H
B
H
H
J
K
J
J
If
that's
occurring,
it's
a
red
flag,
yeah,
but
the
fact
that
we
have
to
you
know
exact
into
every
pod
to
figure
this
out
right
is
not
tenable
to
be
put
into
istio
couple
analyzer.
If
there's
some
other
way
of
knowing
that,
then
that
might
be
and
it
would
become
part
of
the
the
upgrade,
the
pre-upgrade
verification
and
we
worked
into
the
normal
process.
E
H
J
B
L
J
J
C
E
E
H
Yeah,
it
looks
like
we
need
to
investigate
better
detection
than
the
script.
I
don't
think
we
can
have
perfect
detection
like
easter
cut
analyze,
but
we
can
do
like
metrics
as
well.
Have
multiple,
we'll,
probably
have
the
script
and
metrics,
maybe,
and
maybe
an
optional
audit
log
investigation
like
I
think,
there's
no
server
bullet,
though
we
can
just
do
a
lot
of
different
things,
and
hopefully
some
of
them
stick.