►
From YouTube: Technical Oversight Committee 2021/04/26
Description
Istio's Technical Oversight Committee for April 26th, 2021.
Topics:
- Validation webhook config and revision update
- Networking WG Roadmap
A
B
C
B
B
B
D
E
F
A
E
D
Right
yeah,
so
the
the
tag
stuff,
unfortunately,
doesn't
doesn't
fix
the
validating
web
hook
issue.
We
had
a
proposal
for
kind
of
introducing
an
api
to
fix
the
which
revision
handles
validation
and
that's
kind
of
stagnated,
and
I
don't
think
we
have
a
good
way
forward
on
that
proposal
sam.
Why
is
this.
D
I'm
curious
that
there's
something
we
can
do
to
help
yeah.
So
there's
a
dock
and
there's
there's
just
feedback
that
I'm
having
a
hard
time
resolving
pretty
much
there's
a
lot
of
valid
feedback
there
and
it's
the
default
revision
proposal
by
the
way
that
was
going
to
control,
which
revision
handled
both
istio
injection
enabled
inject
the
injection
the
default
injectors
and
also
which
one
handles
validation,
which
is
the
harder
problem.
Probably.
G
Problem
is
not
I'm
blocking.
Him
is
the
price.
You
don't
have
a
solution
that
doesn't
regress
in
in
some
area
I
mean
it's,
it's
some
ways
are
possible,
but
that
will
mean
that
each
study
instance
will
have
more
permissions,
require
more
permission
to
install,
which
is
something
that
we
certainly
do
not
want
to
do,
and
so
basically
we
lack
a
good
solution
that
satisfies
you
know
that
is
moving
us
forward.
G
G
G
The
the
base,
so
we
have
a
bit
more
flexibility
for
advanced
users
on
how
they
configure
this
kind
of
stuff.
Basically,
the
proposal
is
to
move
the
validation
out
of
the
charts
and
have
it
as
a
completely
separate
standalone
step
where
the
user
is
actually
explicitly
specifying
what
validations
they
want
and
not
because
as
a
promise,
we
have
the
spaghetti.
You
know
charts
and
installs
that
we
have
and
with
multi-revision
and
everything
else,
it's
getting
more
and
more
difficult
to
do
to
hack
it
to
do
duct
tape.
E
E
What's
confusing
is
in
the
revision
tag
documentation
we
kind
of
showcase
to
user
hey.
This
is
your
production
revision
of
where
you
are
today
and
then
this
is
how
you
move
to
a
newer
revision.
So
so
we
kind
of
also
tell
people,
you
should
revision
your
old
version
and
then
this
is
how
you
upgrade
to
a
new
revision.
E
I
just
feel
like
the
best
recommendation,
wasn't
super
clear
and
as
a
community,
it
would
be
great
if
we
can,
you
know,
have
clear
guidance
to
the
user,
whether
they
should
start
with
a
revision
in
the
first
place
or
whether
they
should
just
always
do
default,
but
then
later
on,
they
can
always
do
revision
once
they
met.
The
requirement
of
the
first
release
was
the
default.
D
So
installing,
with
with
an
initial
revision
that
should
work
with
the
fix
here-
and
one
thing
we
could
do
actually
is
in
the
installer-
just
create
an
istio
g
service
and
then
installing
with
a
revision,
will
just
work.
The
problem
there
is,
it
won't
work
for
helm,
install
because
it'll
be
a
fix,
that's
unique
to
our
installer,
and
also
we
won't
have
an
api
after
that
on
how
to
change
which
revision
is
istio.
It
handles
validation.
That's
that's
kind
of
the
problem.
G
But
in
reality
the
root
problem
is
that
we
are
relying
on
install
hacks,
I
mean
helm,
template
hacks
and
there
are
kind
of
restrictions
that
held
places.
This
your
cattle
has
a
different
set
of
restrictions,
so
we
are
in
a
situation
where
we're
you
know
doubling
down
on
everything
must
be
done
to
help
templates
and
working
around
instead
of
taking
a
more.
You
know,
drastic
saying
that
hey,
if
you
want
to
control
the
version-
and
you
know
some,
some
things
need
to
control
to
api.
G
Basically,
so
you
need
to
use
cube,
cut
or
apply,
or
you
need
to
use
a
separate
step
where
you
configure
with
you
know
easy
to
install
everything
all
in
once
doing
the
default,
which
you
know
works
perfectly
fine.
But
if
you,
if
you
want
to
do
advanced
things,
you
should
use
some
tools
to
control
what
revision
I
mean
not
not
to
bundle
the
validation
work
yet
with
with
the
templates.
Basically,
that's
kind
of
the
more
deeper
deeper
fix,
basically.
G
I
I
mostly
agree,
but
but
with
with
the
exception
that
eventually
we
want
this,
this
step
of
configuring,
the
validation
to
be
taken
out
of
the
base,
basically
to
be
a
stand-alone
step.
So
if
you
are
a
user
who's
using
revisions
to
have
a
safe
update,
you
need
to
have
used
your
cattle
set,
something
and
and
or
or
you
know,
apply
a
yaml
that
will
control
the
validation
and
possibly
the
imitating
webhook
for
the.
H
G
E
G
And
and
and
that's
perfect,
and
that's
that's
where,
where
we
are
completely
aligned-
and
I
think
we
we
are
on
the
same
page-
the
only
promise-
the
actual
implementation
of
that
right
now
is
still
based
on
some
hacks
in
the
template.
Basically,
some
problems
with
install
just
rip
the
band-aid.
Do
it
with
you
know.
G
G
And
both
of
them
will
be
single
command
effectively
to
do
a
beginner
install.
So
there
is
no
concern
here.
I
mean
it's
a
default
install,
but
once
you
start
to
do
upgrades
and
operate
and
do
more
advanced
stuff
and
do
revision
based
if
you
want
zero,
downtime
and
everything
else,
then
you'll
have
some
commands
to
run,
and
maybe
you
know
take
a
bit
longer
to
do
the
upgrade,
maybe
not
instantaneously,
but
maybe
it
will
take
a
day
or
two
a
week
to
kind
of
roll
out
each
component
at
a
safe
place.
C
G
E
E
Well,
we
would
either
ask
a
user
to
create
the
sdod
service
manually
through
maybe
cube
cuddle
commands
or
maybe
we'd
make
a
change
to
israel
cuddle
to
take
care
of
that
action
for
the
user,
so
user
doesn't
have
to
do
that
actual
step,
so
that
that's
a
question
you
know
just
to
ask
the
general
tlc
for
feedback,
because
today
you
know,
like
I
mentioned
to
sam.
If
you
look
at
that
warning
message,
I
start
at
that
message
for
like
a
couple
of
minutes,
I
couldn't
make
sense
of
it.
G
So
I
think
I
think
that
my
answer
is
is
both
I
mean
easter.
Cutters
should
definitely
do
this,
but
we
should
also
have
the
documentation
saying
you
can
also
create
this
visually
service
or
apply
this
validation
work
basically
to
to
expose
to
the
user.
What
actually
your
cutter
is
doing
in
case
they
want
to
do
it
through
to
cube
cutter.
Some
people
are
more
comfortable
with
ci
cd,
applying
cube
cutters,
and
they
are
comfortable
trying
to
use
your
pattern
in
a
cic
system.
D
I
think
that's
one
of
that's
recommended
in
the
warning
as
well.
Right
yeah
create
a
service
called
sdrd
using
this
service
as
a
template.
I
I
the
signaling,
is
really
bad,
though,
for
one
time,
especially
for
our
recommended
install.
I
agree
that
I
think
that
we
should
move
forward
with
a
change
to
the
installer
and
just
get
rid
of
this
message,
because
it's
not
relevant.
A
D
G
A
G
A
G
Well,
with
with
helm,
I
mean
the
whole
idea
is
that
we
document
what
you
need
to
put
in,
you
know
help
template
or
in
whatever
you
are
using
for
data,
for
example,
the
current
plan
for
gateway
is
that
you
will
have
a
yaml
file
where
you
have
some
some
basics
template
and
you
apply
to
helm
with
tube
cutter
with
whatever
you
want.
We
do
injection.
So
it's
it's!
It's
completely.
Automated
all
the
complicated
parts
are
automated
same
here
I
mean
we
document,
hey
put
this
validation
workbook
in
your
whatever
you
want
help
in
your
own.
G
A
A
I
mean
gateway
is
understandable
because
it's
like
you're
creating
a
new
instance
of
a
thing,
so
you
should
have
a
email
representing
it.
That's
fine
and
I
think
it's
okay
to
have
a
emo
representing
you're,
used
to
install
right
like
that's
how
the
installer's
model,
like
that's.
What
kind
of
why
I'm
asking
for
you
know
a
dock
that
describes
this
mostly
in
under
examples,
so
we
can
kind
of
take
a
look
and
see
if
there's
improvements
we
can
make
to
the
experience
while
keeping
the
same
flexibility
in
power.
G
G
I
is
the
operator
I
can
you
know,
change
your
configuration
and
do
stuff
without
having
a
cluster
admin
privilege
I
so
far,
my
understanding
was
that
it
is
a
goal
to
have
lower
permissions
and
and
and
be
able
to
do
that,
and
cluster
wide
resources
like
crds
validating
web
communicating
web
hook
are
kind
of
part
of
this
problem.
Where
we're
having
all
this
confusion,
if
the
qc
say
hey
no
problem,
cluster
admin
is
perfectly
fine.
It
opens
up
a
lot
of
options
in
this
area.
I
G
I
G
We
don't
have
a
lot
of
feedback
for
users.
That
securities
should
do.
I
mean
it's
kind
of
an
implicit
yeah.
I
don't
think
anyone
said
hey.
I
don't
want
to
to
run
class
dramas.
There
are
some
multi-tenant
requirements
where
you
know
tenants
definitely
do
not
want
to
have
to
be
all
of
them
cluster
admins,
because
if
it's
a
purpose.
C
G
G
A
G
G
G
We
know
helm,
for
example,
strong
recommends
that
you
don't
even
have
ability
to
set
labels
on
namespaces.
We
know
that
there
are
companies
that
are
doing
multi-tenant
where
users,
you
know
just
don't
have
and
they
lock
down.
Basically,
the
user
jk
autopilot
is
is,
is
you
know
restricting
what
what's
the
issue
or
what
any
any
application
can
do.
G
J
C
G
Look,
I
mean
if
the
usc
decision
is
that
this
is
not
a
requirement,
not
a
priorities
and
again
everything
becomes
super
simple.
We
don't
even
need
two
templates,
I
mean
we
can
just
have.
You
know,
put
everything
everything
is
running
as
cluster.
A
lot
of
things
are
super
simple.
So
that's
that's.
Don't
get
me
wrong.
I
mean
I'll,
be
very
happy
to
have
this
restriction
removed.
A
G
A
So
so
the
separation,
the
separation
for
like
external
control,
plane
operator
of
the
control
plane
versus
the
operator
like
within
the
cluster,
so
that
that
separation
makes
total
sense
to
me.
But
having
this
additional
split
within
a
cluster
doesn't
like,
I
don't
see
the
use
case
for
that,
because
I
think
anyone
who's
anyone
who's
installing
istio
in
a
cluster
kind
of
should
be
cluster
admin.
G
A
B
C
G
A
G
A
G
H
G
G
C
C
A
A
And
by
the
way,
I'm
also
fine,
with
the
the
operator
like
just
like
red
hat
right,
like
the
operator
model,
where
the
operator
has
elevated
permissions,
that's
fine
to
me,
but
I
think
there's
a
separation
between
operator
and
s2d.
Right
like
you,
can
you
separate
those
and
the
operator
is
optional
right?
If
you
don't
want
to
give
a
component
running
in
your
cluster
that
permission,
you
have
the
option.
G
A
Okay,
so
I
think
we
need
to
follow
up
some
more
on
this
again.
I
still
I
I
I
would
like
environments
to
take
this
on
and
try
to
try
to
lay
out
what
this
should
all
look
like
sort
of
holistically,
rather
than
piecemeal,
which
we've
been
doing
where
we're
like
we're,
fixing
a
piece
here,
fixing
a
piece
there,
but
we
don't
have
the
whole
picture.
A
J
A
C
H
C
A
A
C
J
J
C
J
Will
say
it's
like
95
complete,
so
we
didn't
fill
in
all
the
details
on
priorities
and
people
yet
because
I
didn't
plan
to
present
today,
but
we
have
the
high
level
stuff
there.
So
overall,
this
is
is
not
much
different
from
what
we
discussed
in
the
2021
roadmap
and
the
1.9
roadmap.
A
lot
of
this
is
long-term
stuff
that
we've
been
working
on
for
a
while,
and
it's
just
continuation.
J
So
we
have
our
I'll
go
a
bit
out
of
order.
We
have
had
cni
to
beta
for
ever
basically,
and
we
finally
have
owners
and
they've
already
started
the
work
as
well
so
like
this
is
actually
finally
going
to
happen.
I
think
so
I
think
we'll
actually
promote
cni
to
beta
this
release,
hopefully,
or
will
at
least
get
far
closer
than
we
have
been
before.
J
Then
the
gateway
api
once
again
we're
continuing
the
implementation
of
the
kubernetes
gateway.
We've
made
a
lot
of
progress.
Some
of
the
things
we're
going
to
work
on
now
are
especially
support
for
mesh
traffic.
So
right
now,
we've
always
been
focusing
on
ingress
and,
to
some
extent
eres
other
than
that
just
continuing
to
work
with
them
on
the
api
and
make
sure
it
fits
meets.
J
Our
needs
et
cetera
and
oh
yeah,
also
implementing
gateway
selection
right
now
we
only
support
one
easter
egg
gateway,
so
we
want
to
make
sure
that
we
support
arbitrary
gateways,
so
you
can
have
multiple
of
them
and
that
we
write
to
the
status
fields.
So
they
have
things
like.
Is
this
gateway
ready?
Is
there
conflicts?
Is
there
issues
et
cetera?
J
J
A
J
J
Some
of
the
other
work
mcs
to
alpha
so
nate's
been
working
on
this.
A
lot
on
this
is
multi-cluster
service
discovery,
the
new
kubernetes
api.
So
we
have
a
like
full
design
out
for
how
we're
going
to
implement
this
and
we're
making
some
progress
there.
So
I
think
we'll
probably
have
I
don't
know
if
I'll
actually
make
it
to
alpha
or
just
experimental,
but
I
expect
to
have
some
support
landed
by
this
release.
Wonder
1.11
now
yeah!
J
The
other
one
is
delta
xds,
so
this
is
mostly
about
performance.
Optimization
in
general,
we
added
experimental
support
in
1.10.
It
is
very
experimental
and
so
we're
hoping
to
slowly
productionize
that
a
bit
so
it
works,
but
it
does
not
work
well
at
all.
Well,
it
does
work,
but
it's
not
meant
to
be
efficient
right
now.
It's
meant
to
actually
pass
test.
So
we're
going
to
work
on
improving
that
we
have
a
pretty
detailed
road
map
on
how
we're
going
to
incrementally,
adopt
this
and
not
break
everything.
J
J
J
J
J
J
J
The
rest
is
just
more
minor
stuff
that
wasn't
didn't
really
warrant
a
whole
full
section.
Just
some
important
important
bug,
fixes
and
minor
features.
So
there's
like
an
issue
about
listener
imbalances
how
we
can
do
some
performance
optimizations
there
kubernetes
has
this
new
node
local
service
api.
We
need
to
figure
out
how
that
interacts
with
estro
and
if
we
need
to
make
any
changes
or
support
that
we
also.
K
J
Yeah
they
have
it's
like.
I
think
it's
called
service
topology
or
something
maybe
that's
the
old
one,
but
I
think
it
has
like
three
values
like
you
can
be
build
local
or
cluster
local,
or
I
thought
there
was
a
third,
but
I
can't
think
of
what
it
would
be
and
it
basically
means
keep
the
traffic
only
local
to
the
node.
Oh,
I
think
it's
no
local,
only
or
no
local
preferred
or
cluster-wide
yeah.
So
I
think
it's
an
alpha
api.
So
the
idea
here
is
we.
J
We
may
not
even
support
it,
but
we
need
to
figure
out
what
we're
going
to
do
here.
So
a
plan
for
a
plan
yeah.
This
is
brand
new,
so
it's
not
as
urgent
as
some
of
the
other
stuff
yeah
thanks
yeah,
no
problem,
some
other
things
we
discussed
in
the
past
about
the
single
outbound
listener
work,
consolidating
all
the
listeners
to
one
listener,
like
we
do
with
the
inbound
listener.
J
J
J
We
also
have
a
feature
that
we
had
in
experimental
for
quite
a
while
about
scoping
gateway
clusters.
So,
right
now
we
send
clusters
for
every
single
service
to
a
gateway
which
is
a
ton
in
a
big
cluster,
and
you
can't
scope
it
down,
like
you
can
with
side
cars.
So
we
have
this
feature
where
we'll
actually
send
only
ones
that
are
used
by
virtual
services,
but
this
is
introduced
various
bugs.
J
J
Yeah,
I
also
talked
about
ex
like
progression
of
the
import
and
export
and
how
it
may
relate
to
mcs,
which
kind
of
has
similar
concepts
and
gateway
api.
This
is
very
vague
because
the
idea
is
to
figure
out
what
we
want
to
do
here.
We
don't
have
anything
more
than
a
vague
statement
for
now,
but
I
think
there
is
definitely
some
improvements
we
can
make
here
and
finally,
we
have
some
egress
improvements
to
look
into
right
now,
eager
skate
way,
I
think,
is
kind
of
a
known,
clunky
area
of
east
geo.
J
So
we
have
various
ideas
on
how
that
could
be
improved,
whether
it's
kind
of
having
like
the
pass-through
traffic
go
through
the
eagers
gateway,
how
we
can
better
handle
mpls
to
the
eager's
gateway
when
we
do
sni
routing
and
wild
sni
routing.
I
think
it's
meant
to
be
wild
card,
sni,
routing
improvements
which
currently
doesn't
work
so
well.
J
So
this
is
kind
of
just
like
the
whole
section
is
just
the
crop
bag
of
stuff
that
we
may
be
interested
in
working
on.
But
we
don't
really
have
things
flushed
out
now,
so
they
didn't
make
it
to
the
top
level
and
at
the
bottom
is
kind
of
our
dreams
that
we
very
unlikely
will
do.
But
we
we
are
interested
in
them.
So
we
continue
to
discuss
them
a
bit.
G
J
J
J
J
C
I
J
I
mean,
I
think,
analyzer
improvements
are
always
welcome,
but
there's
nothing
that
really
stands
out
as
as
new
things.
We
need
one
interesting
interaction.
There
is
with
the
new
gateway
api.
To
some
extent,
they
already
have
their
own
analysis.
You
know
they
have
their
own
status
fields,
which
are
not
just
a
blob
of
conditions
that
we
can
write
these
two
conditions
they
have
specific
ones
like
is
this
listener
ready
and
they
have
specific
apis
that
we're
supposed
to
report
for
various
issues
like
no.
J
G
G
F
G
G
J
G
F
Right
so
there
there
might
be
some
sort
of
what
it
might
do
is
it
might
constrain
their
upgrade
path
where
at
some
point
you
know
there
are
a
series
of
releases,
it
might
be
like
you
know,
111
through
113,
or
something
where
you
can
actually
use
both
simultaneously,
and
you
would
have
to
hit
one
of
those
releases
on
your
way
to
upgrading
to
something
you
know
higher
than
113..
Okay,.
G
K
G
K
G
It's
mostly
implemented
on
the
voice
side,
as
far
as
I
know,
so
we
just
need
to
tweak
configurations
and
to
draw
it
in
production,
and
it's
not.
We
don't
miss
any
piece
as
far
as
I
know,
in
terms
of
you
know,
upgrading
the
tcp
connection
to
h2
and-
and
I
know
other
products
that
are
using
this
feature.
G
C
K
K
So
I
I
think
we
need
to
sync
with
you,
chen
and
or
taylor,
to
to
get
some
real
details
so
so
that
we
can
start
testing
using
it
and
there
is.
There
is
a
related
telemetry
item
of
what
we
do
and
I
think
now
we
are
much
closer
to
actually
moving
on
that
time.
Viewer
before
that.
That's
the
reason
for,
for
my
questions.
H
A
E
A
So
then,
I
think
the
question
is
going
to
be
how
long
we
need
to
keep
right.
The
current
way
around
all
right
kind
of
like
with
with
the
whatever
we're
talking
about
right
here
forget
which
part
the
new
apis
yeah
anytime.
We
have
a
new
api
right
like
anytime.
We
have
a
new
way
of
doing
something:
yeah
bts
right
so
like
we
got
to
keep
the
old
stuff
around
for
a
while,
and
I
think
there's
going
to
come
a
time
when
we
start
discussing.
When
can
we
deprecate
and
remove
old
stuff.
A
A
So
the
the
mcs
names
are
kind
of
like
kubernetes
service
names,
they're
actually
addresses
they're,
not
they're,
not
the
same
concept
as
canonical
service.
That's
why
I
was
sure
yeah,
it's
it's
different
enough
that
actually,
like
we
don't
use
in
canonical
service,
we
don't
actually
use
service
names
at
all
to
drive
to
drive
things
it's
based
on
labels.
It's
not
based
on
service
names,.