►
From YouTube: Technical Oversight Committee 2021/05/10
Description
Istio's Technical Oversight Committee for May 10th, 2021.
Topics:
- Extensions & Telemetry WG Roadmap
- Security WG Roadmap
- Istio 1.9 Upgrade Experience Report
- WG Leads Nominations
B
D
A
C
E
E
E
E
F
C
F
C
C
F
C
That
makes
sense,
I
was
just
wondering
if
the
user
would
took
it
implies
the
compatibility
of
the
istio
version
beyond
the
web
book,
because
I
would
you
know
what
I
mean
like
the
moment.
You
allow
people
to
do
tech
revision
on
older
version
and
without
a
warning
they
could
be
thinking
it
would
just
work.
That
means
we
allow
user
to
go
back
to
this
older
version
and
do
a
revision
like
skip
version
upgrade
to
110.
F
C
F
C
G
I
I'm
happy
to
talk
to
it.
I
don't
know
if
mundara
is
here
so
yeah
I
mean
this
is
this
looks
a
lot
like
our
110
road
map
to
start
except
this
time
for
real,
so
the
p0,
the
top
p0
is
finishing.
The
wasm
api
and
getting
the
implementation
in
there's
been
a
special
interest
group
has
been
working
on
that
for
a
while.
Now
I
think,
we've
made
great
progress
and
I
think
we
should
be
able
to
get
this
in
in
111.
G
the
next.
The
next
top
priority
for
us
is
adding
more
to
the
telemetry
api,
trying
to
be
conservative
here
and
saying
we're
just
going
to
add
the
metrics
bit
the
monitoring
bit
with
a
p1
of
getting
to
logging
as
well,
and
I
have
a
write
up
in
the
enhancements
repo
for
moving
it
from
experimental
to
alpha.
G
There
was
something
that
bubbled
up
around
publishing
agent
agent
metrics,
so
we
exposed
them
via
prometheus,
but
there
was
a
desire
to
have
them
actually
pushed
to
an
endpoint.
So
there's
a
design
in
progress,
and
we
want
to
finalize
that
and
build
the
implementation
in
111
and
then
the
rest
of
the
work
here
is
sort
of
we
don't
we
don't
have
necessarily
identified
people
for
so
the
the
bts
work
we
want
to
coordinate
with
the
networking
working
group.
G
G
We
probably
should
carry
that
work
on,
but
no
one
has
volunteered
the
time
or
thinks
that
they
can
own
it
necessarily
and
then
distinct
from
that.
Ed
has
pointed
out
a
few
missing
test
cases
that
we
want
to
have,
and
I
think
we
should
always
be
working
on
improving
our
test
coverage
and
converting
them
over
to
the
newer
way
of
doing
things.
So
I
put
that
that's
sort
of
like
a
background
p0
on
our
roadmap,
so
that
that's
sort
of
the
roadmap.
In
brief.
G
G
I
C
J
I
I
J
Yeah
yeah,
since
oliver
is
not
here
I'll
cover
the
yeah.
The
part
oliver
has
yeah,
so
the
the
last
two
are
actually
kind
of
related
is
for
providing
the
certificate
provisioning
api.
The
first
one
is
about
the
sds
configuration
api,
so
currently
the
when
we,
when
user
needs
to
configure
certificate
provisioning,
they
are,
they
are
using
the
environment
variable
mostly,
and
the
sum
of
the
config
is
in
mesh
config.
J
So
we
would
like
to
provide
a
better
api,
because
this
feature
is
already
stable
and
in
the
meanwhile,
we
also
want
to
allow
the
vendors
if
they
have
their
own
specific
api.
They
should
also
be
able
to
plug
in
their
certificates
for
virginia
api
and
yeah,
so
so
that
we
user
can
configure
it
saying
I
either
use
the
instio
negatively,
provided
a
certificate,
configuration
api
or
use
the
vendor,
provided.
J
Okay,
yeah:
if
there
is
no
question
we
can
move
to
the
next
section.
The
next
one
is
the
improvements
on
security
policy.
We
have
identified
a
few
improvements.
We
need
to
do
the
first
one
yeah
yummy
is
actually
only
most
of
the
stuff,
and
so
the
first
one
is
to
add
a
proactive
test
to
prevent
policy
bypass.
J
J
A
J
J
K
N
J
O
O
J
J
J
I
C
J
M
C
A
N
A
C
A
J
A
P
Oh
no
well,
if,
if
we
can
pull
it
off,
that's
great
because
we
are
hearing
from
customers
that
it's
important
but
because
it's
experimental,
it's
not
really
immediately
useful,
but
maybe
experimental
to
stable
would
be
kind
of
a
step
too
far
so
but
yeah
that
that
kind
of
that's
the
question.
Okay,
can
we
work
faster
but
still
not
like
directly?
Take
it
too
stable.
A
K
K
L
L
A
D
L
L
I
Q
Q
A
A
A
question
here
right
about
working
through
the
details
of
what
it
actually
takes
to
promote
it
right,
john,
like
I
know,
you
know
that
doc
amen.
I
I
don't
know
if
you'd
anticipated,
you
know,
participating
in
helping
make
sure
that
that
machinery
works,
but
I
think
every
team
should
be
pitching
in
to
help
make
that
work.
Q
K
K
L
Yeah
and
I
think
so
in
the
networking
when
we
went
from
v
one
alpha
three
to
v-
one
beta
one,
I
think
still
right
now
we
support
both.
We
haven't
removed
v,
one
alpha
three.
As
far
as
I
remember,
and
every
time
I
look
at
networking,
api's
reviews.
I
have
to
basically
look
at
two
sets
because
people
are
manually
copying
changes
in
both.
L
J
Q
Q
L
R
M
C
K
N
A
R
A
K
All
the
details
in
one
comment
regarding
what
the
mirror
said:
we
did
have
a
practice
with
networking
promotion
to
beta
and
duplicating
them.
We
know
that
it
works,
so
if
we
really
want
to
promote
them
to
to
be
v1,
we
could
repeat
what
we
did.
It's,
it's
not
perfect,
but
you
know
users,
experience
and
user
we
have
v1
will
it
can
start
using
v1
and
start
migrating,
and
if
later
a
better
solution
emerges
we
can
we
can
move
to
that.
K
Q
A
P
L
It
depends
right
so
for
a
little
bit
more
with
your
project
like
kubernetes,
I
know
there
are
users
who
want
to
consume
stable,
kubernetes
apis,
and
that
is
indicated
also
by
the
api
groups
for
istio,
where
we
are
our
most
stable
feature
also
has
a
beta
in
api
group.
So
maybe
for
us,
the
api
group
is
not
that
significant,
because
I.
L
H
L
Q
C
L
A
L
A
A
A
Q
H
N
C
N
So
a
little
bit
of
review
before
we
talk
about
istio,
one,
nine.
Remember
that
in
the
fall
we
conducted
a
comprehensive
upgrade
survey
of
users
getting
60
or
so
users
feedback
on
upgrades.
We
had
a
hypothesis.
We
started
off
that
process
because
we
observed
a
lot
of
people
running
old
and
vulnerable
versions
of
istio
across
multiple.
N
What
we
found
in
our
survey
is,
there
is
some
confusion
around
support
and
vulnerability
exposure,
but
even
though
many
users
knew
that
they
were
running
an
unsupported
version
or
a
vulnerable
version
of
istio,
they
felt
that
they
were
unwilling
or
unable
to
upgrade
istio.
They
felt
like
the
risks
in
upgrading
istio
were
greater
than
the
risks
in
running
a
vulnerable
version
indefinitely,
and
so,
as
you
guys
remember,
we
sort
of
pivoted.
The
last
two
releases
have
focused
very
strongly
and
heavily
on
day
two
operations,
particularly
on
the
experience
of
upgrading.
N
We
received
13
responses
from
users
who
had
upgraded
to
one
nine.
We
did
receive
four
responses
from
users
who
had
not
yet
upgraded
anything
to
one
nine
I've
discarded,
those
from
all
of
the
results
that
you're
seeing
the
focus
here
is
specifically
on
the
one
nine
release
to
understand
how
we're
doing
the
survey
is
pretty
brief,
and
so
the
results
will
be
brief
as
well
and
let's
get
started.
N
First
of
all,
this
gives
us
an
idea
of
how
much
upgrading
these
users
have
done.
Some
of
them
have
just
begun
in
their
non-production
messages.
That
was
one
respondent
all
the
way
up
through.
Actually,
the
majority
of
our
respondents
have
upgraded
all
of
the
meshes
that
they
own
to
istio
one
night
of
those
users.
We
asked
them
to
score
their
satisfaction
relative
to
previous
experiences.
N
N
It's
not
a
super
strong
signal,
but
it
does
look
like
users
who
had
a
poorer
experience
or
perhaps
the
same
experience
they've
had
before
are
a
little
bit
more
hesitant
to
finish
upgrading
they're
not
progressing
as
quickly
through
the
upgrade
process
as
users
who
have
a
high
degree
of
satisfaction.
With
the
experience
questions
there
all
right,
we'll
look
at
the
next
slide.
N
We
asked
users
what
they
thought
had
improved
the
most
relative
to
previous
experience,
as
well
as
what
they
felt
like
needed,
the
most
improvement
in
the
future-
and
these
are
not
surprising.
We
saw
that
a
handful
of
users
thought
the
revision
based
upgrades
improved
a
lot
in
one
nine,
but
upgrade
stability,
which
is
a
little
bit
of
a
vague
category.
It
was
included
there
intentionally
vague,
because
there
are
a
lot
of
things
that
we
do,
that
are
not
exactly
upgrade
features
that
we
might
label.
N
Instead,
it's
simply
not
breaking
stuff
quite
as
frequently,
and
that
contributes
significantly
to
upgrade
experience.
We
saw
a
strong
response
that
users
noticed
one
nine
was
much
more
stable
than
in
the
past.
However,
we've
still
got
a
long
ways
to
go
users
requesting
indeed
more
stability,
as
well
as
gateway
upgrades
skip
version
upgrades
is
the
most
requested
improvement
to
upgrade
experience
that
we
could
have
moving
forward.
N
F
N
So,
as
far
as
I'm
aware,
all
of
our
documentation
states
that
we
do
not
support
skip
version
upgrades.
We
instruct
users
to
not
do
that.
So
I've
not
we
did
not
ask
if
they
had
attempted
to
perform
their
own
skip
version
upgrade
and
experience
trouble
anecdotally.
In
my
experience
with
some
of
these
users
and
with
broadly
with
other
users,
they
will
wait
for
us
to
tell
them
it's
supported
before
they
are
likely
to
invest
heavily
in
skippers
and
upgrades
and.
C
Yeah
I
actually
test
this.
I
was
mentioned
to
sam
the
other
day
I
tested
from
183
to
110
release
candidate
zero.
It
went
pretty
well
for
a
couple
of
samples
I
was
using.
I
was
wondering
if
we
can
introduce
skip
version
upgrade,
maybe
as
whatever
stage
we
prefer
in
this
release,
so
that
we
can
get
some
feedback
on
this,
because
I
don't
see
any
reason
why
we
couldn't
support
it
from
at
least
from
one
eight.
F
L
Yeah,
I
think
that
that's
good
sam
I
mean
we
have
done,
skip
level
upgrades
and
quite
a
few
versions.
To
be
honest,
it's
painful
it's
like
for
every
version.
You
have
unique
failures,
but
it
works
so
yeah.
If
we
can
reliably
say
to
our
users
that
one
eight
to
110
works.
That
would
be
really
helpful.
That's
good.
K
N
All
right
in
the
interest
of
time
I'm
going
to
move
on
this
was
an
interesting
response.
We
asked
our
users
what
their
preference
was
for
upgrade
in
place
or
revision
based.
We
did
get
one
user
who
did
like
revision
based
upgrades.
The
remainder
of
our
users
either
were
unaware
of
the
difference
between
the
two,
in
which
case
I
suspect,
they're
using
in
place,
because
you
do
have
to
use
a
revision
flag
to
make
use
of
a
revision
based
upgrade
or
had
an
explicit
preference
for
in-place
upgrades.
N
This
is
consistent
with
the
signal
that
we
saw
in
the
fall
around
users
upgrade
preferences
at
the
time,
and
we
did
have
a
plain
text
field
where
we
allowed
users
to
express
why
they
preferred
one
method
of
upgrading
over
the
other
of
the
12
respondents.
On
this
particular
question,
only
three
hold
on:
let's
go
here.
Only
three
chose
to
give
us
plain
text
answers
with
in-place
upgrades.
The
preference
was
sim
for
simplicity
as
well
as
for
consistency
with
previous
upgrades.
N
N
Yes,
that's
correct
the
comments
about
name
space
labels
should
be
fixed
in
110,
so
that's
a
signal
that
we're
headed
in
the
right
direction
with
this
d0110
and
I
believe
the
web
hook
thing
is
fixed
as
well:
sean
yeah,
okay,
great
now,
I'm
going
to
go
back.
I
kind
of
got
these
slides
out
of
order
here,
track
to
upgrade
satisfaction
versus
the
way
that
they
intend
to
upgrade,
and
actually
the
title
to
this
slide
is
incorrect
should
be
upgrade
satisfaction
versus
method.
N
The
person
who
preferred
revision-based
upgrades
scored
it
the
same
as
previous
versions.
People
who
did
not
use
revision
based
upgrades
heavily
skewed
towards
about
an
average
of
a
four
which
would
be
moderately
better
experience
than
previous
installation
or
upgrade
experiences,
which
is
a
little
bit
interesting.
I
talked
to
sam
about
this
a
little
bit
we're
investing
heavily
in
revision-based
upgrades
the
one
user
who
used
it
didn't
see
a
substantial
improvement,
we're
not
investing
in
in-place
upgrades,
and
yet
our
users
are
showing
signs
that
they're
that
those
upgrades
are
getting
easier.
N
This
could
be
simply
due
to
lack
of
data.
13
users
is
nowhere
near
statistically
significant.
It
also
could
be
that
the
investments
that
we're
making
in
revision
based
upgrades
are
also
impacting
in
place.
For
instance,
just
not
breaking
backwards.
Compatibility
and
having
higher
stability
is
going
to
help
upgrades
all
around,
but
it
was
sort
of
an
interesting
data
point.
N
L
I
I
do
think
many
organizations,
at
least
I
talk
to
they
have
this
process
of
separate
environments
for
qualification,
and
they
have
you
know
more
quality
assurance
through
that
process.
So
if
I
have
a
staging
or
a
qa
environment
in
which
I
have
upgraded
in
place,
my
sto
I'll
do
the
same
in
production
and
if
they
have
made
those
investments
already,
I
think
for
them.
On
top
of
that,
doing
canary
seems
like
a
lot
of
work
as
of
now
with
improvements.
Maybe
not,
but
it
just
makes
sense.
K
Maybe
we
should
we
should
also
kind
of
change
the
terms
and
the
questions.
I
mean
it's
not
really
revision
or
in
place.
It's
downtime
or
no
downtime,
as
we
change
sharback
permissions
and
other
things
again,
you
will
know
the
upgrade
from
in
place
will
kind
of
guarantee
downtime
for
a
while
for
short
interval
of
time
until
everything
is
upgraded.
I
S
In-Place
upgrade
I
don't
have
to
go
and
uninstall
anything
it's
one
operation
and
I'm
done
if
it
doesn't
work.
I
roll
it
back
versus
splitting
out
two
things:
side
by
side.
Verifying
things
are
working
and
then
uninstalling
something
else
right,
there's
a
distinct
difference
there
from
a
usability
perspective.
K
N
N
Broadly,
it
looked
like
you
know:
users
are
very
concerned
about
upgrading
their
gateways,
which
makes
sense
sort
of
a
single
point
of
failure
for
your
cluster.
If
one
back-end
service
goes
down,
that's
bad,
if
your
cluster
ingress
goes
down,
then
your
entire
application
is
gone.
All
of
your
services
may
as
well
be
down
and
then,
of
course,
operating
the
data
plane
also
was
perceived
as
somewhat
risky.
N
So
those
are
opportunities
for
us
to
continue
investing
and
helping
our
users
to
manage
these
rollouts
in
a
way
that
feels
safe
for
them,
and
actually
the
gateways
are
an
area
that
have
been
heavily
invested
in
in
both
one
nine
and
110.
I
I
hope
to
see
that
the
upgrade
experience
there
continues
to
improve
all
right.
Two
key
takeover
two
takeaways
here
users
are
expressing
that
they
don't
want
revision
based
upgrades.
N
Rob
to
your
point,
I
think
more
research
needs
to
be
done
there
to
get
better
signal
on
on
where
the
gap
is
exactly
the
upgrade.
Experience
is
improved
over
istio
one,
eight
and
one
seven,
but
it
does
need
to
there's
still
a
lot
of
room
for
growth
and
we
need
to
expand
our
focus
beyond
the
control
plane.
N
Yeah,
so
a
little
bit
of
feedback
on
the
feedback.
Relative
improvement
is
good,
but
absolute
improvement
is
better.
We
didn't
really
measure
how
happy
users
were
absolutely
with
the
install
process.
We
measured
how
it
had
changed
from
previous
versions,
and
so
I
think
in
the
future.
We
also
want
some
questions
that
just
ask:
how
happy
are
you
with
the
process,
not
relative
to
previous
experiences?
N
We
also
didn't
carry
forward
our
signals
on
vulnerability,
exposure
and
user
awareness
of
that.
Even
though
a
lot
of
investment
has
been
made
there,
we
need
apple's
apple's
feedback
on
each
release.
We
need
surveys
that
are
consistent
from
one
release
to
the
next,
so
that
we
can
really
measure
how
we're
changing
over
time
and
so
to
that
end
in
istio
110,
we
already
have
a
survey
ready
to
go
for
install
experience
and
upgrade
experience
it's
tied
into
istio
cuddle.
N
So
if
you
use
the
istio
cuddle
install
command,
we
will
have
a
hyperlink
that
we
drop
onto
your
cli
at
the
end,
asking
you
to
fill
out
a
brief
survey
and
the
plan
is
to
keep
the
survey
mostly
the
same
as
this
one.
So
if
there
are
questions
that
you
wish
had
been
asked
and
were
not
or
questions
that
needed
to
be
phrased
differently,
please
let
me
know
as
soon
as
possible
and
I
will
update
the
110
survey
so
that
we
get
feedback
continually
through
the
110
process.
N
Amanda,
you
mentioned
delaying
the
survey
a
little
bit
more,
and
that
was
a
difficult
question
for
one
nine.
When
was
the
right
time
to
pull
the
trigger
on
this
with
110
we're
going
to
have
the
survey
open
from
day
one
as
soon
as
you
upgrade
to
110,
you
can
fill
out
a
survey
and
we
will
leave
it
open
for
quite
a
long
time,
perhaps
through
the
whole
111
development
cycle,
so
that
we
get
feedback
from
a
broad
number
of
users.