►
From YouTube: Technical Oversight Committee 2021/12/06
Description
Istio's Technical Oversight Committee for December 6th, 2021.
Topics:
- Networking WG Roadmap
- Environments WG Roadmap
C
A
C
C
D
A
A
G
F
Take
it
away
steve:
the
road
map
is
relatively
small.
I
didn't
really
get
a
chance
to
go
triage
and
just
like
list
critical
bugs
here,
I'm
not
really
sure
if
they
were
appropriate
to
put
in
here,
but
the
the
main
things
I
want
to
get
done,
we're
still
waiting
for
autzy
from
the
grpc
side
and
it's
a
pretty
critical
feature
to
be
able
to
actually
call
proxies
jrbc
alpha,
dns
proxying.
F
We
added
a
few
tests
in
the
last
release
and
last
release
also
gave
a
couple
features
that
we
had
for
allowing
cross-cluster,
headless
services
and
staple
sets
for
multi-cluster
to
marinade,
and
we
had
like
three
or
four
different
users
reach
out
asking
whether
or
not
that
was
possible
and
yeah
just
turn
on
the
feature
flag
and
they
seem
to
have
success
with
it.
So
I
think
it
should
be
ready
for
beta
the
workload
group
crd
doesn't
really
seem
to
have
any
new
things
that
we
really
want
to
put
into
it.
F
One
thing:
that's
kind
of
been
in
the
backlog
that
I
haven't
really
prioritized
is
aks
or
sorry,
eks
and
aws
tend
to
use
hostnames
for
their
external
load
balancers,
and
there
are
a
ton
of
users
of
multi-network
who
are
have
reached
out
and
are
using
some
pretty
weird
hacks
to
support
this.
So
I
want
to
add
first
class
support
to
istio,
there's
like
several
options
in
this
dock,
for
how
to
do
that,
and
I
just
want
to
get
any
basic
version
of
it
working
because
it
would
be
better
than
current
state.
F
One
of
the
biggest
things
for
the
release
will
be
actually
implementing.
H-Bone
dynastio,
you
chan
said
that
it
is
a
work
in
progress
with
an
envoy
and
should
be
ready
for
a
sexually
programmed
control
plane
relatively
soon
last
release
we
merged
code
to
raise.
That
is
the
charge
to
get
that
into
like
experimental.
Yes,
yes,.
F
We
have
code
that
handles
using
endpoint
slices
instead
of
endpoint
for
istio's
main
service
discovery,
our
endpoint
discovery.
So
this
will
just
switch
istio
to
automatically
read
those
instead
of
endpoints
if
using
kubernetes,
121
or
greater.
We
actually
already
have
the
code
to
do
this,
but
we
wanted
to
actually
give
it
time
to
be
tested
and
it
leads
emerged
pretty
late
in
the
cycle
for
112.
F
D
F
I
I
I
I
E
F
F
There's
a
slight
issue
where
some
of
the
changes
that
we
made
to
support
the
latest
grpc
version
break
older
grpc
clients,
their
xds
implementations
seem
to
have
kind
of
switched
over
slightly
in
one
area.
So
there's
a
chance.
We
need
to
conditionally
send
different
config
based
on
the
version,
but
I'm
trying
to
kind
of
work
with
the
grpc
team
to
figure
out.
If
that's
actually
the
case.
I
C
I
think
the
future
promotion
items
stephen
you
had
on
your
list
makes
a
lot
of
sense.
I
do
have
a
question
on
the
host
based
low
balancer
for
multi
network.
I
think
that's
also
a
very
important
gap
we
have.
I
was
just
wondering
your
bandwidth
as
far
as
like
you
on
the
many
of
things
on
the
list.
What's
your
take
on,
you
know
having
that
actually
landed
on
113
for
the
host
name
base
load,
balancer.
C
F
The
the
version
before
that
I
have
like
partially
implemented
is
like
resolving
in
the
control
plane,
which
isn't
great,
but
it's
you
know
essentially
what
users
are
doing
today
with
their
own
custom
tools.
But
I
would
like
to
experiment
with
trying
to
just
like
switch
clusters
over
to
strict
dns
and
then,
if
that
doesn't
work,
try
doing
something
with
aggregate
cluster.
C
F
There
was
some
debate
about
it
last
time,
but
I
don't
know
if
I
guess
there's
only
two
items
on
the
agenda
for
toc,
so
maybe
we
do
have
time
to
talk
about
it.
It
sounded
like
that
would
require
us
actually
deserializing
the
eds
responses
and
then
re-serializing
them
which
didn't
sound
super
optimal
but
yeah.
It
is
possible.
C
A
D
F
For
this
release
for
this
release,
get
cds
pretty
much
working
and
then
make
sure
that
way
the
way
that
they
have
other
xts
types
implemented.
It's
pretty
much
the
item
from
112
there
was
just
no
work
on
it.
Yeah
so
like
cds
should
actually
have
an
improvement
over
traditional
and
then
right
now.
Other
types,
I
think,
are
slightly
worse
than
like
state
of
the
world.
Xcs.
G
D
J
G
I
G
H
G
A
D
I
I
And
also
for
stability,
it's
a
very
good
thing
to
keep
the
current
code
as
stable
as
possible
and
focus.
You
know
any
kind
of
experimental
stuff
in
the
h1
path,
which
is
a
bit
more,
so
it
may
slow
down
h1
a
bit,
but
the
people
will
benefit
from
the
stability
of
the
core
existing
deprecated
legacy
code,
yeah,
okay,.
D
A
G
G
G
I
think
it's
kind
of
blocked
by
the
api
itself
so
if
and
when
they
go
to
beta,
which
might
happen
in
1.13
time
frame.
Actually
so
maybe
we
should
track
it
here.
I
think
it
would
be
good
for
us
to
go
beta
at
the
same
time.
If
it
doesn't
work
out,
then
you
know
one
release
afterwards,
but
you
know
we
can't
go
beta
until
they
do
so.
I
D
I
G
Yeah,
I
don't
know,
if
that's
the
I
mean
it
may
be
a
short
term,
but
I
don't
know
if
that's
the
right
path
for
long
term,
because
that
means
that
you
have
to
like
in
order
to
use
egress
in
a
sane
way.
You
need
to
not
have
a
service
defined,
which
means
you
lose
a
bunch
of
other
things
like
telemetry,
et
cetera,.
I
D
E
E
G
D
I
D
I
I
That
we
know
how
to
do.
I
mean
it's
not
a
problem.
The
problem
is
how
to
get
how
to
get
the
original
source.
When
you
capture
on
this
on
the
sidecar.
Is
that
really
the
thing
we
don't
have
a
solution
for,
or
we
don't
know
how
to
do
it
ebb
for
different
cni,
where
you
create
the
second
second
v8
pattern,
and
then
you
you
can
get
it
from
on
the
second
one
that
ways
but
yeah,
okay,.
D
D
L
D
C
C
I
I
No,
we
we
reach
the
conclusion.
Well,
at
least,
I
hope
we
reach
that
that
it's
completely
automatic
I
mean,
if
you
have
the
cni
plugin,
that
creates
the
cn
the
uds
socket
agent
will
detect
it
and
say
hey.
I
have
this
sds
so
get
created
by
cli.
Let's
use
it
don't
do
anything
else,
so
user
will
not
have
to
to
configure
anything
globally
or
anywhere
just
if
they
install
sds
support,
inspire
they
use
it.
Otherwise
they
don't.
C
I
K
B
All
right:
okay,
cool,
let's
just
start
on
future
promotions,
so
first
things
revision
tags.
We
actually
had
the
same
exact
item
on
our
112
roadmap
and
we're
going
to
kind
of
have
a
better
story
for
helm
support
and
the
proposal
kind
of
didn't
make
it
anywhere.
So
we're
gonna,
try
again
for
113
to
get
this
officially
promoted
to
alpha
helm,
we're
looking
at
beta
for
113.
We
just
moved
to
like
official
helm,
repos
and
stuff.
B
So
hopefully
things
will
stabilize
a
little
bit
more
and
we're
looking
at
beta
there
for
multi-cluster
steven
has
been
working
a
lot
on
making
it
stable.
There
are
a
few
outstanding
items
with
respect
to
like
off-boarding
clusters
from
a
mesh
that
kind
of
need
better
testing
and
maybe
more
attention
on
the
ux
there.
So
that's
kind
of
the
remaining
work.
F
Right
right,
one
thing
I
did
also
want
to
add
is
that
I
want
to
try
to
get
like
the
the
stable
promotion
does
kind
of
list
that
we
want
to
have
solid
performance
numbers
and
with
multi-cluster.
One
thing
we
don't
have
is
kind
of
control,
plane
performance
numbers,
as
you
scale
up
a
number
of
clusters,
because
you
know
it's
going
to
be.
A
B
B
and
then
potentially
making
it
so
that
more
fields
are
like
live
reloadable
and
proxy
config.
So,
instead
of
relying
on
the
field
being
set
at
injection
time,
you
can
change
it
in
the
cr
and
then
through
proxy
config
discovery
service,
it'll
automatically
change
in
the
proxy,
so
we
have
mesh
config
cleanup.
B
B
A
K
I
B
E
J
L
G
Backing
out
we're
just
saying
that
it's
not
recommended,
and
I
don't
think
our
docs
ever
said
it.
Although
I
spoke
to
a
number
of
people,
then
I
asked
them:
why
they're
using
it
and
they
said
the
docs
recommended
it,
and
I
asked
them
to
point
to
it
where
it
recommended
and
there's
like
confusion
on
what
the
recommendation
is.
I
But
strategy
right
now
is
to
not
deprecate
anything
that
we
launched.
Everything
that
we
launched
will
support
it
forever.
I
mean
we,
we
pay
for
our
mistakes
and
forever
we
pay,
but
helm
experience
is
so
much
better,
especially
with
with
the
remote
repository.
Basically,
you
don't
have
to
download
anything.
You
just
run
two
commands
and
heaviest
you're
running,
and
I
think
people
will
naturally
migrate
to
this
because
it's
you
know
simply
better
and
easier.
I
G
Yeah
once
we
have
the
new
gateway
stuff
as
well,
I
think
the
install
method
will
be
less
important,
hopefully
because,
if
you're,
just
installing
one
deployment,
easter
d,
how
you
install
it
really
doesn't
matter
like
people
are
perfectly
fine,
installing
the
ego
operator
and
it's
selling
used
to
id
is
just
as
hard
as
installing
the
hdo
operator.
So
I
mean
it
is
important,
but
it
hopefully
is
less
important,
especially
compared
to
where
we
were.
You
know
a
year
and
a
half
ago
where
we
had
like
14
deployments,
yeah.
I
E
I
K
G
It's
already
been
that
way,
though,
we've
had
so
many
critical
bugs
in
the
operator
that
haven't
been
fixed
ever
and
like.
I
don't
think
that
it's
we
should
invest
effort
into
fixing
these
when
it's
not
the
path
forward.
Obviously
we
shouldn't
break
it
intentionally,
but
at
the
same
time,
like
there's
a
lot
of
work
that
would
be
needed
to
get
it
to
a
stable
quality.
I
E
I
will
have
to
say
I
mean
it's
a
bizarre
place
where
we
are
right,
so
istio
ctl
is
the
preferred
way
and
that
has
been
stable.
I,
like
the
other
most
stable
thing
is
in
cluster
operator,
which
is
beta,
but
it
has
bugs.
We
don't
fix
and
we
don't
want
to
support
and
helm
has
been
lying
around
with
experimental
alpha
for
more
than
a
year
right.
I
I
E
D
D
K
G
I
I
I
think
one
thing
that
is
not
very
clear
in
this
discussion
is
that
the
new
helm
is
actually
has
a
different
apis
and
then
the
list,
your
cartel
and
operator
understands.
So
basically,
when
you
install
you
have
a
much
smaller
set
of
features
because
it
takes
into
account
that
a
lot
of
things
moving
to
proxy
config
is
moving
to
crds.
It's
it's,
it's
a
simplified
gateway,
a
route.
So
it's
it's
a
simpler
api.
J
If
we
hear
a
lot
from
the
customer
saying
that
like
don't
do
it,
then
that's
a
good
signal.
However,
if
we
hear
from
the
customer
okay
deprecate
it
here
is
the
reason
why
and
in
favor
of
this,
and
if
the
community
is
okay
with
it,
then
and-
and
I
think
if
we
don't
do
anything,
it
looks
like
that's
where
we
are,
because
we're
not
really
fully
supporting
it
anyway.
J
D
You,
like,
I
think,
the
point
here.
Amanda
is
no
matter
what
we
do.
We
have
to
hand
hold
the
user
right.
It
can't
be
go
and
redo
things
right
by
hand
right.
They
need
some
conversion
all
right.
They
may
be
willing
to
move
to
helm
but
they're
not
willing
to
move
to
helm
right
without
help
and
that
help
them
better,
be
clear
right,
like
yep.
Is
your
cuddle
migrate
to
right?
If
that's
what
we
would
never,
because
we
can't
deprecate
without
doing
that.
G
Yeah,
I
don't
think
that
we
should
deprecate
it
because,
first
of
all,
deprecation,
I
think,
is
this
like
dirty
word,
that
scares
people
and
if
we
say
like
oh,
it's
deprecated,
but
we're
not
going
to
remove
it
for
two
years.
That
nuance
will
not
be
understood.
It's
almost
certain.
I
feel,
like
we've
done
so
much
churn
in
this
area
that
we've
kind
of
used
up
our
churn
budget
for
the
next,
maybe
two
years,
such
that
any
change.
Even
a
good
change
is
almost
not
not
good
right.
G
G
I
would
rather
have
you
know
if
you're
using
the
operator
fine
keep
using
the
operator,
we
should
probably
shouldn't
be
a
new
user,
that's
deciding
for
the
first
time.
If
you
picked
operator,
then
we
did
something
wrong,
but
I
don't
think
there's
any
desire
to
you
know
push
people
away
from
the
operator
that
are
already
on
it
and
cause
more
churn.
I
And
at
the
same
time,
we
don't
necessarily
want
to
improve
it
too
much.
I
mean
to
change
the
experience
to
make
improvements,
because
that
will
actually
create
danger
for
people
who
are
actually
using
it
currently,
and
so
we
will
have
to
make
changes
so
keep
it
stable
fix,
p0s
seems
like
the
safest
thing.
K
I
I
think
what
I'd
like
to
see
is
some
investment
on
test
on
the
testing
side,
so
that,
like
some
of
the
recent
regressions
that
we've
seen,
are,
are
checked
for
and
we're
sure
that
they're
not
happening
again
in
future
releases.
That
shouldn't
involve
any
risk
to
the
operator's
stability
for
users.
D
I
D
D
J
J
K
H
I
G
The
documentation,
I
think,
is
pretty
good
in
1.12.
It
basically
says
this
feature
is
not
good,
don't
use
it
if
you're
not
already
using
it.
Let
me
see
it
says:
use
of
the
operator
for
new
installations
is
discouraged.
The
operator
will
continue
to
be
disported.
New
features
will
not
be
prioritized.
I
One
thing
I
mentioned
a
few
times:
I'm
not
sure
if
it's
so
just
like
with
releases,
we
need
some
people
to
you
know
do
this
work
if
we
believe
it's
important.
So
it's
not
happened
by
magic
and
we
need
you,
know
dlc
or
someone
to
assign
to
find
resources
to
assign
them,
and
it's
nothing.
It's
it's
free
and
if,
for
example,
niraj
believes
that
operator
is
important
and
customers
are
using
it,
then
it
is
a
priority
to
find
some
swiss
to
to
work
on
it.
D
D
They
can
already
use
this
to
a
couple
with
basically
the
same
configuration
so
that
the
question
would
be.
Do
we
provide
tooling
to
help
users
might
pay
to
hell,
or
is
it
even
worth
it
right?
Because
there
were
codification
of
the
other
api
options
anyway
in
proxy
config
and
mesh
config,
and
so
this
will
all
just
wash
out
in
the
end.