►
From YouTube: Technical Oversight Committee 2021/08/09
Description
Istio's Technical Oversight Committee for August 9th, 2021.
Topics:
- Release Announcement for Istio 1.11
- Release blockers for Istio 1.11
- Continued discussion of Istio Extended Support
- Test & Release Roadmap for 1.12
- UX Roadmap for 1.12
- ARM support
A
A
C
C
B
A
I
do
one
of
them
the
memory
issue
with
the
cache
that
was
caught
in
the
performance
test,
so
that
could
have
easily
been
caught.
If
we
had
done
any
performance
testing
beforehand
like
we
used
to
kind
of
do
that
from
time
to
time
on
master-
and
I
just
I
don't
think
anyone's
been
doing
that
the
other
one
was
actually
purely
coincidence.
I
just
happened
to
be
testing
it
out
for
a
completely
unrelated
reason
and
it
was
wasn't
working
and
I
was
confused
and
then
found
out.
E
F
B
F
You
can
see,
can
you
also
go
back
if
topic
is
done?
Little?
Do
you
want
to
review
this?
Yes,
questions.
Okay,
go
ahead,
so
this
is
what
I
do
like.
I
don't
know
if
this
is
what
you're
looking
at
this
is
what
I
do
at
the
end
of
the
videos.
So
all
the
features
which
we
planned
per
working
grip,
the
ones
which
are
marked
red,
are
the
ones
did
not
make
into
the
release.
F
G
C
G
H
F
So
normally
I
used
to
change
color
based
on
every
week
and
then
all
the
dark
greens
are
the
ones
which
are
done.
Environment
is
the
only
one.
I
don't
have
a
good
status.
They
were
on
progress,
so
the
light
would
be
nice.
They
were
on
progress
up
until
last
minute,
but
I
do
not
have
the
good
status
of
the
environment
exact
at
the
end
of
one
time.
What
was
the
update.
I
B
I
C
So
I
I
noticed,
there's
actually
a
whole
lot
of
features
that
craig
you
didn't
had
in
the
vlog
like
the
security
work
group
like
multiple
routes.
I
guess
this
is
like
super
important
feature,
all
the
I
guess,
all
the
mutual
tras.
It's
been
there
for
a
long
time
so
main
I
don't
know
what
else
was
highlighting,
but
the
customer
action.
I
feel
like
it's
been
there
too,
but
this
one
is
super
important.
So.
G
C
B
F
C
C
C
C
C
C
C
C
I
J
G
I
C
I
K
Yeah
guys,
you
want
to
go
over
the
state
of
the
release
themselves
from
the
update,
in
that
pr,
so
going
to
be
integrating
all
the
changed.
Both
commented
and
checking
on
the
cherry
picked
prs
that
have
gone
in
since
then
are
any
of
the
release.
Blockers
that
are
currently
getting
fixed
gonna
require
entries
in
the
change
log.
C
B
B
C
M
L
C
D
Yes,
I
am,
if
you
just
want
to
open
up
the
link
and
then
scroll
down
to
the
test
and
release
stuff,
so
just
sort
of
arrange
these
things
into
the
items
that
were
completed,
sort
of
what
we
were
doing
in
the
last
release
and
then
the
things
that
are
in
progress
or
what
we're
picking
up
for
on
not
11
or
continuing.
So
the
first
one
is
the
one
that
we
had
targeted
for
1.11,
that's
not
done
it's.
The
evaluation
of
features
work
miriam
has
created
all
of
the
prs.
D
The
only
reason
it's
not
done
is
because
workgroup
leads
and
or
maintainers
in
the
work
groups
have
not
gone
and
got
those
prs
merged.
So
basically,
I
just
need
to
review
the
check
boxes
in
the
documents
and
verify
that
they're
indeed
accurate,
that
miriam
has
the
right
things
in
there
and
then
merge
those
pr's.
D
So
the
to
do
here
is
work
groups
get
the
prs
in
and
then
we
can
mark
it
complete.
But
from
our
from
our
standpoint,
it's
done.
Continuation
from
from
prior
releases
are
the
promotion
of
feature
process
that
fine
and
schweda
have
been
working
on,
as
well
as
the
annotation
maturity
level
stuff
that
brian's
doing
so.
D
When
we
update
the
build
tools
image,
we
don't
have
any
automation
to
push
that
change
out
through
common
files,
so
we
use
we
have
the
image
name
and
the
common
files
and
then
that
pr
needs
to
be
done
manually
today,
which
then
kicks
off
the
rest
of
the
automation.
So
we
just
need
to
marry
those
two
things.
I
believe
I
have
code
to
already
do
that
in
one
of
the
repos,
so
it
should
just
be
sticking
it
into
the
pipeline.
D
D
D
Going
forward
one
of
the
things
that
was
highlighted
in
1.10
on
the
on
the
prior
to
what
I
had
that
we
didn't
do
for
1.11,
that
we're
gonna
pick
back
up
in
1.12
stuart's,
going
to
look
at
updating
the
docker
hub
and
gke
images
for
things
like
book
info
today.
You
know
somebody
has
to
be
able
to
to
do
that
manually
and
I
believe
the
number
of
people
that
can
do
that
based
on
the
the
admin
pr
and
community,
is
becoming
smaller.
D
D
B
It's
a
bit
of
flag
here
I
was
going
to
say
it's
a
long
list
eric
which
is
good,
but
I
just
wanted
to
see
if
we
can
rejiggle
the
priorities-
or
at
least
I
can
understand
like
so
destroy
this
images,
for
example
right,
that's
what
we
recommend
in
our
security
guide
it
being
alpha
or
I
don't
know
what
the
status
is,
that
kind
of
puts
you
know
dent
in
that
whole
plan.
So
can
it
be
what
what
remains
to
be
done,
and
why
is
it
equal.
D
That's
a
good
question,
so
we
don't
have
a
roadmap
document,
that's
something
that
I
know
wasn't
done
yet
when
I
joined
the
team-
and
we
just
haven't
done
that
in
the
work
group
yet
and
maybe
that's
something
we
need
to
do
so.
This
is
the
so.
The
reason
this
list
is
kind
of
long
is
because
this
is
basically
our
2021
roadmap.
D
These
are
the
things
we
wanted
to
do
for
2021
and
when
we
did
the
original
priorities
that
was
sort
of
the
priority
for
2021,
so
I
guess
we
don't
really
have
a
good
way
in
here
to
say
this
is
the
priorities
for
this
release,
but
I
do
agree
that
the
dystrolis,
probably
shouldn't
be
a
p2.
It
was
sort
of
a
p2
at
the
beginning
of
the
year
in
terms
of
prioritizing
things.
B
D
C
C
B
D
C
J
Sure
yeah
that's
linked
there.
I
don't
think
I've
seen
ed
this
morning.
I
think
he
may
be
out
so
the
ux
roadmap
for
112.
We
took
the
dock
for
111
and
put
a
two
where
the
second
or
the
third
one
was
more
or
less
both
ed
and
I
have
been
almost
100
allocated
internal
facing
projects
at
our
various
companies.
The
last
quarter,
somewhat
unexpectedly,
so
very
little
moved
forward
in
111,
and
so
we
have
carried
all
of
that
forward
to
112..
J
From
the
ux
perspective,
upgrade
pain
in
and
the
surveys
around
it
are
are
our
top
p0.
We
did
move
that
forward
in
terms
of
interviews
or
sorry
surveys
on
110
in
this
quarter.
We
also
have
surveys
set
up
for
111
that
are
giving
us
more
and
more
data
in
terms
of
an
apples
to
apples,
comparison
of
upgrades
between
versions
of
istio,
which
is
great.
J
L
J
J
B
L
I
was
thinking
of
having
a
list
of
recommendations
that
are
presented
to
toc
based
on
the
feedback
and
then
having
some
sort
of
cycle
where
we
actually
agree
to
take
those
on
for
the
113
or
something
I
don't
know
so
like
list
of
suggested
fixes
for
113.
I
don't
know
something
like
that:
yeah,
okay,.
J
J
B
J
We
we
had
user
feedback
last
fall.
That
said
that
it
was
a
problem.
The
high
level
problem
is
that
users
don't
understand
the
maturity
of
the
various
features
that
they're
using.
We
developed
an
analyzer
to
help
users
understand
that.
However,
the
analyzer
listed
essentially
told
users
that
everything
that
we
use
by
default
is
alpha,
because
we've
not
been
in
great
shape
in
terms
of
what
alpha
features
we
use
by
default.
J
A
J
Yeah,
that's
a
great
question.
The
ux
working
group
could
definitely
use
staffing.
If
you
have
people
who
are
looking
to
get
involved
in
the
project,
we've
got
ed
and
myself
who
are
spread
pretty
thin,
and
then
we
have
iris
and
steve
joining
us
from
intel
china
once
a
month
for
our
apac
friendly
meetings,
but
that
is
by
and
large
the
extent
of
it.
Justin's
got
the
api
promotion
thing
he's
working
kind
of
in
his
own
thread.
J
N
Yeah
and
I
guess,
towards
the
support
stable
api
promotion
work,
I'm
working
with
the
plan
to
work
with
the
security
team
on
that,
but
it's
that's
sort
of
like
there
will
be
work
done,
but
that's
not
like
crisply
defined
exactly
what
we're
what
we're
promising.
So
maybe
we
need
to
work
on
that,
but
yeah.
I
do
plan
on
working
on
this,
but
it's
a
little
unclear
exactly
what
we're
promising.
J
N
No
there's
not
I'm
not
sure
exactly
what
yeah
I
mean.
I
guess
it
will.
I'm
not
sure
if
it
will
be
a
design
dock,
though,
because
we
actually
have
a
live
documentation
about,
what's
supposed
to
happen
for
stable
apis,
it
probably
even
more
of
a
road
map
for
how
we
work
with
various
teams
to
get
the
api
stabilized.
D
N
J
J
The
question
in
the
chat
justin:
did
you
see
that
no
I
missed
it,
he
asked
basically
didn't
we
decide.
We
need
to
figure
out
how
to
evolve
apis
before
actually
evolving
them
or
before
promoting
them
to
stable,
and
I
know
you
and
I
have
had
a
number
of
conversations
on
that.
I
don't
know-
we've
documented
it
anywhere.
J
J
O
Yeah,
I
guess
the
concern
there
right
is
that
if
somebody
does
want
to
evolve
it
and
you
need
a
converter,
I
don't
know
what
that
looks
like
today,
because
currently
the
apis
are
essentially
the
same
right.
We
have
a
single
open
api
schema
for
all
of
the
types,
regardless
of
what
version
they
are,
so
we
don't
really
have
versioning
today.
O
I
Want
to
to
make
an
effort
for
everyone
to
make
an
effort
to
never
actually
remove
and
duplicate,
because
we
are
at
the
stage.
We
have
a
lot
of
users
using
a
lot
of
the
existing
apis
and
if
we
remove
or
duplicate
anything
regardless
of
the
infrastructure
we
have
or
not,
users
should
be
impacted
so
for
any
apis
that
we
promoted.
We
should,
you
know,
consider
that
we
need
to
keep
them
for
years
and
forever.
Basically,.
O
Yeah,
well,
that's
why
you
have
converters
and
things
in
istio
right,
so
we've
already
gone
through
that
right
upstream,
with
kubernetes,
with
respect
to
crd
versioning
right.
So
it's
not
something
that
is
completely
off
limits.
It's
just
something
that
requires
planning
and
some
implementation
around.
O
C
N
Okay,
mitchell,
you
and
I
can
talk
about
how
we
might
be
able
to
write
such
a
talk,
because
we
did
have
some
conversations
around
that,
but
yeah
yeah
and
we
can
have
a
proposal,
because
I
do
think
that
I'm
not
sure.
I
agree
that
we
can
never
retire
apis
or
we
at
least
need
to
be
able
to
sort
support
multiple
simultaneously.
But
if
it's
gonna
be
hard
to
make
forward
progress,
if
we're
just
sort
of
stuck
yep.
C
Okay,
awesome,
thank
you
so
much
mitch
and
justin.
So
when
you
have
the
survey
and
the
interview
ready,
definitely
bring
back
to
tlc
and
then
you're
going
to
check
back
resources
to
see
if
p0
makes
sense
and
justin's
going
to
help
us
put
a
dog
together
for
stable
api
promotion
thanks
guys.
Thank
you
all
right.
So
we
have
last
eight
minutes
for
israel
extended
support
mitch.
I
think
you
are
the
leader
for
the
stock.
Also.
J
Yes,
so
we
talked
a
few
weeks
ago
about
extended
support.
There
was
some
talk
about
needing
to
get
steering
approval,
because
this
does
involve
staffing
up
our
efforts
on
older
versions.
I
understand
that
there
was
some
progress
in
steering
a
week
ago
and
I
don't
know
sven.
Did
you
want
to
kind
of
give
a
readout
of
what
that
looked
like.
L
Yeah
I
mean
effectively,
I
think,
steering
says
we
want
to
do
it.
There
was
some
discussion
stirring
about
like
the
skip
the
lts
model,
where
every
other
one
is
versus
just
doing
it
for
everything,
and
I
think
there
was
a
majority
of
steering
in
favor
of
just
doing
it
for
everything
I
would
say
I
wanted
to
know
more
about
kind
of
the
cost
between
those
two
but
yeah.
I
I
that
was
my
take
mirage,
louis
feel
free
to
jump
in
with
your
views.
J
So
what
I
would
love
to
leave
with
today
is
a
first
step
towards
extending
support.
We've
heard
proposals
that
we
do
every
other
we've
heard
proposals
that
we
do
every.
I
think
the
product
security
working
group
had
an
idea
where
maybe
we
dark
launch
it
effectively
by
doing
all
of
the
patchwork
for
one
nine
over
the
next
quarter,
but
not
shipping
it
so
that
we
get
a
better
understanding
of
the
workload
that
we're
committing
to
before
we
make
that
commitment.
M
C
B
L
A
fan
yeah,
so
I
I
feel
like
this:
whether
we
do
every
release
or
every
other
release
is
something
we
can
change
our
minds
on.
Either
direction
is
fine.
We
can
start
with
the
other
one,
so
I
I
think
we
should
just
start
doing
it
right
because,
like
going
to
every
other
release,
just
means
that
you
know
we
get
a
break
right.
Please
stop
doing
it,
so
we
should
start
doing
it
see
how
much
load
it
is
like
start
doing
it
with
where
we
assume.
L
C
A
A
We
should
just
be
careful
about
how
we
announce
this
to
users
like
it
would
not
be
great
to
say,
hey
we're
gonna
support,
I
don't
know
whatever
releases
and
then
be
like.
Oh
just
kidding,
we're
gonna
do
every
other
release,
but
if
we
just
say
like
we're
going
to
extend
the
support
of
this
version
and
then
a
month
later,
we
say
we're
going
to
keep
doing
that
for
all
versions
or
we'll
keep
doing
that
for
every
other
one.
That's
that's
fine,
but
yeah.
That's
right!
We.
J
I
J
A
So,
there's
a
couple
reasons
why
one
tents
are
objectively
better.
I
think
one
we've
historically
had
a
kind
of
even
a
stable
pattern.
That's
just
naturally
risen.
A
lot
of
people
are
on
1.10
and
a
lot
of
people
are
moving
to
110
versus
1.9.
I've
heard
from
many
many
many
customers
that
they've
skipped
1.9
entirely.
A
So
it
doesn't
really
matter
if
we
support
it
nine
months
from
now,
because
if
they
update
their
kubernetes
will
break
so
we're
only
helping
users
that
aren't
old
kubernetes
that
are
out
of
support
anyways,
so
I
personally
prefer
1.10.
Also
it
is
slightly
newer.
So
we
don't
go
to
these
release
managers
who
thought
they
were
off
the
hook
in
a
couple
days
and
tell
them
they
have
to
keep
working
for
three
more
months.
So
I
mean
1.9
is
not
horrible,
but
I
just
think
1.10
is
a
better
place
to
start.
J
I
M
C
M
Right
yeah,
so
I
I
don't
think
that's
viable
right,
yeah
and
yeah
on
the
resourcing
side
right
this.
The
simplest
message
to
deliver
is
we're
going
to
n
minus
two
right,
like
that's
the
simplest
thing
that
we
can
say
that
everybody
can
understand.
N
minus
two
with
skip
level
upgrade
support
right,
so
you
could
go
from
110
to
112
to
114
right
and
you
would
be
fine
if
that's
the
behavior
that
you
wanted.
M
I
M
C
So
one
comment
I
had,
I
think
my
hand-
was
automatically
lower
for
me,
but
I
never
had
a
chance
to
speak.
So
one
comment
I
had
is:
instead
of
doing
just
on
the
even
releases
we
extend
for
12
weeks.
Can
we
do
it
four
to
six
weeks
on
every
single
releases?
So
we
would,
I
think,
it's
effectively
similar
workload
for
us
and
it
it
would
reduce
a
lot
of
confusion
around
which
releases
are
supported.
C
J
That
would
not
allow
our
most
complex
users
sufficient
time
to
upgrade.
We
have
heard
from
some
users
that
they
take
the
majority
of
the
quarter
between
waiting
for
the
first
patch
release
and
then
extensive
qualification,
but
those
are
the
edge
case.
Those
are
the
largest
users,
I
would
say
for
the
average
case.
That
should
be
enough
time.
C
J
A
N
A
N
C
B
B
We
are
introducing
skill
level
upgrades
being
stable
now,
for
the
first
time
they
probably
want
to
move
to
111
when
111
comes
out
not
providing
not
extending
support
for
one
nine,
I
don't
think
is
the
right
move,
because
these
two
things
should
go
together.
That's
how
we
enable
our
users
to
move
ahead
right.
B
B
That's
my
two
cents.
We
should
not
make
it
more
complicated.
We
should
take
baby
steps.
We
can
make
one
line,
extend
for
another
three
months,
see
how
it
goes.
If
you
do
it
for
one
time
what
happens
is
you're
just
punting
it
further
down
that
problem
and
again
somebody
will
bring
up
the
point.
Oh,
are
we
actually
extending
it
or
not,
because
110
doesn't
matter,
it's
not
going
to
be
it's
not
going
to
be
out
of
support
the
next
three
months.
I
would
actually
do
it
get
the
feedback
understand
what
happened.
I
B
M
Yeah
I
I
was
just
going
to
agree
with
the
mirror
says
we
don't
fix
every
bug
in
every
release.
We
don't
even
fix
every
bug
in
the
release
we're
about
to
make
right.
We
would
probably
if
there
was
a
p0
critical
bug
right.
That
was
not
a
security
bug,
there's
a
good
chance.
It
would
get
backported
right,
but
the
incremental
delta
between
that
and
bugs
which
are
cves
and
bugs
which
are
not,
is
pretty
small.
B
And
remember:
one
line
has
been
in
production
and
been
released
for
a
long
time.
We
have
made
very
many
matches
there
shouldn't
be
any
reason
that
the
critical
bug
gets
introduced
in
that
like
other
than
a
vulnerability
right.
So
that's
what
louie
is
saying
and
that's
what
I
am
saying
other
than
cves.
I
So
if
I
can
explain
again
so
if
we
start
with
one,
then
what
is
the
problem
and
what
feedback
will
not
get,
because
we
are
going
to
back
for
210.
We
are
just
going
to
announce
that
110
is
going
to
be
supported
longer,
just
like
with
one
line
and
it's
something
that
is
closer
to
the
current
master.
So
it's
a
bit
easier
to
support.
What
is
special
about
one
night.
J
B
Right,
we
are
in
a
situation
right
now
with
one
nine,
where
users
would
have
to
choose
to
go
to
110
immediately
because
they
are
out
of
support
and
then
to
go
to
111
or
they
can
say.
Okay,
we
can
wait
another
month
and
test
the
new
skip
level
upgrades
and
give
us
feedback
on
both
how
the
extended
policy
went
because
we
tried
it
and
then
how
the
skip
level
upgrades
went.
We
can
get
feedback
on
multiple
things.
J
Don't
want
to
do
that,
that's
what
I'm
trying
to
say.
We
already
have
testing
around
the
skip
level
upgrades.
We
don't
need
more
time
for
that
we've
already
committed
to
supporting
it.
The
question
is
the
extended
support
window,
which
I
don't
think
there
would
be
testing
for
an
extended
support
window.
Maybe
I'm
missing
something.
I'd
rely
on
eric
for
that,
probably.
M
I
I
I
I
think
the
combination
of
the
kubernetes
upgrade,
that
is
a
pretty
significant
one
and
the
fact
that
110
is
you
know
a
better
release
than
one
line.
I
would
still
prefer
1.10
for
the
first
experiment
and
and
the
fact
that
it's
bad
karma
to
have
both
releases
smartphones,
long-term
support.
I
mean
all
our
even
releases
traditionally
because
of
the
development
cycle
and
style
whatever.