►
From YouTube: Technical Oversight Committee 2021/02/05
Description
Istio's Technical Oversight Committee for February 5th, 2021.
Topics:
- Istio 2021 Roadmap Themes
- Istio 2021 Roadmap Review - Security
- Backwards compatibility restrictions
- VM Beta Graduation
A
D
A
D
F
A
E
D
F
D
I
I
E
E
D
A
We
we
will
start
that
the
way
I
would
like
to
kick
is
first,
we
want
to
go
over
the
thematic
document
for
stu
2021
roon
pack,
once
we
finished
that
we
would
like
to
go
over
the
ear
road
map
for
security
and
networking.
However,
there
was
a
suggestion
as
well
to
let's
do
just
one
per
week
and
there's
a
good
reasons
for
that,
because
it's
a
yearly
road
map,
so
you
know
it
may
take
some
time
so,
rather
than
rushing
and
having
two
per
week,
we
can
actually
have
one
per
week.
D
A
Awesome
job
everyone
thank
you
and
kudos
to
actually
completing
p0's
every
release
cycle.
I
know
it's
always
a
chaotic,
but
you
know
the
whole
community
helps
to
get
it
done.
Whether
or
not
you
know
we
remove
the
priorities,
but
we
actually
get
it
done.
So
thank
you
again
for
making
it
happen
every
time
in
terms
of
issues.
We
have
zero
release
blockers
from
last
three
days.
I
don't
want
to
jinx
it,
so
it's
awesome
news.
A
We
have
37
p0s
we
have
discussed
with
the
working
group
leads
at
this
point.
None
of
them
are
blockers
for
the
release,
so
we
will
be
triaging
them.
Should
they
be
a
milestone
for
1.10
or
1.9.x.
So
from
this
point
we
are
ready.
The
release
is
getting
built
and
we
are
going
to
push
the
performance
and
qualification
testing,
sometimes
from
from
like
an
hour
to
hour
from
now
other
than
that,
I
think
the
release
looks
good.
A
D
Oh
yeah,
that's
fantastic
thanks
to
all
the
contributors
and
the
release
managers,
so
I
think
one
thing
that
is
on
the
toc
agenda
and
maybe
steering
is
to
actually
look
over
the
release,
notes
and
the
blogs.
I
know
I
signed
up
for
looking
over
jacob's
pr,
I
think
lin.
You
are
also
going
to
review
them
right.
F
I
D
D
We
acknowledge
that
you
know
we
have
made
a
lot
of
significant
improvements
in
this
installation
and
the
overall
usability
aspects
of
sto,
but
still
once
you
get
this
to
install
the
day
two
operations
for
people
to
maintain
them
to
debug
them
and
then
eventually
upgrade
to
newer
releases,
whether
it's
for
patch
releases
or
for
getting
new
functionality.
That
process
itself
is
not
smooth.
D
So
what
you'll
find
in
this
document
is
three
major
focus
areas
and
those
focus
areas
are
all
aligned
towards
making
sure
that
we
can
improve
the
day
two
operations.
So
the
first
one
is
stability
and
maintainability.
The
main
area
focus
there
is
better
upgrade
experience.
We
have
already
approved
a
upgrade
working
group
and,
as
josh
recently
george
just
mentioned,
you
know,
a
lot
of
work
has
already
gone
in
to
make
sure
our
upgrades
are
better
by
detecting
the
backwards,
incompatible
changes
and
notifying
the
users
or
actually
making
sure
we
flag
them.
D
Even
before
we
get
to
a
release
state.
We
are
working
on
the
skip
level
revision
based
upgrades
and
a
lot
of
toolings
to
improve
the
overall
experience
for
users
when
they
are
upgrading
sto
and
then
there's
a
lot
of
tests
and
the
infrastructure
going
on
strange
infrastructure
work
going
on
to
improve
the
integration
test.
D
So
we
can
actually
verify
realistics
realistic
scenarios
for
upgrades
which
will
be
closer
to
users
than
what
we
were
doing
before
so
I'm
gonna
go
over
them
quickly,
since
we
do
have
a
lot
of
items
on
the
agenda,
but
this
document
is
available
for
everyone
to
review.
Most
of
the
toc
members
have
given
their
feedback,
so
hopefully,
today
we
can
actually
officially
approve
this
and
move
on.
The
other
areas
on
stability
and
maintainability
is
enhancing
the
troubleshooting
experience.
D
This
has
got
a
lot
of
good
efforts
and
inputs
from
the
ux
working
group
who
has
increased
overall,
what
this
to
ctl
command
and
the
tool
can
do,
but
not
just
that,
it's
integrating
with
kiali
or
some
other
dashboard.
So
I
think
we
will
continue
down
that
focus
and
making
sure
that
the
day
two
operations
are
much
more
simpler.
D
D
What
sort
of
configuration
should
be
in
that
resource
and
then
what
happens
when
that
resource
is
changed
so
this
year?
Hopefully
the
working
group
leads
and
the
toc
members
can
come
up
with
some
canonical
representation
of
these
are
the
responsibilities
that
sq
users
have,
and
this
is
how
they
can
be
successful
in
achieving
it
again.
Once.
D
You
all
right
going
on.
The
second
focus
is
the
next
focus
is
graduating
of
our
features
and
apis.
In
one
line
we
saw
a
major
push
for
that
that
will
continue
here.
We
have
listed
three
of
the
major
items
that
we
would
like
to
focus
on
cni
ipv6,
dual
stack,
then
virtual
machine
expansion.
I
saw
a
great
talk
by
john
about
the
virtual
machine
architecture,
so
we'll
continue
to
do
that
and
promote
these
features
from
you
know.
D
Alpha
to
data
beta
to
stable
as
it
may
be,
multi-cluster
is
a
focus
area
that
we
have
been
putting
a
lot
of
effort
in
and
will
continue.
I
think
len
you
had
a
bunch
of
great
ideas
around
what
we
should
do
for
multi-cluster.
Do
you
want
to
elaborate
that
I
didn't
get
time
to
fill
the
dock,
and
so
it's
still
lying
in
the
comment
there.
F
Yeah,
the
main
thing
is,
you
know:
we've
been
discussing
with
savann
frank,
kevin,
a
bunch
of
others
and
nathan.
Trying
to
figure
out
you
know,
is
the
multi-cluster
service
api
sufficient?
Is
there
any
higher
level
api?
We
need
to
build
on
top
of
that.
What
we've
seen
from
our
user
is
running
multi-cluster
with
different
administration
domain
and
they
need
to
be
able
to
selectively,
consume
and
expose
services,
so
just
refine
what
we
have
our
multi-cluster.
D
Yeah,
that's
awesome.
So
moving
on
some
of
the
other
topics
we
have,
there
are
helm,
v3,
support
and,
basically
understanding
onward
filter.
We
do
realize
that,
even
though
we
don't
recommend
users
to
use
on
wi-fi
internet,
they
do
end
up
using
it,
because
many
functionalities
currently
are
not
exposed
through
a
higher
level
apis
so
trying
to
reconcile
them,
making
sure
that
we
have
proper
apis
for
use
cases
and
identifying
them
and
then
eventually,
seeing
where
we
want
to
keep
where
the
future
of
onward
filter
itself
is.
D
D
We
want
to
make
sure
we
create
the
ecosystem
around
telemetry
v2,
where
wasm
extensions
can
be
created
not
just
by
the
histo
community
members
and
developers,
but
also
by
end
users
and
vendors.
So,
as
part
of
the
part
of
that
enablement,
we
need
to
have
a
first
class
api
for
loading
and
adding
those
extensions,
improve
developer
experience
for
creating
them
and
then
making
sure
that
the
collectively
community,
whether
it's
end
users,
vendors
or
developers,
they
can
all
find
and
discover
wasm
modules,
and
this
can
be
through
some.
D
We
are
supporting
or
integrating
with
the
kubernetes
service
apis
and,
like
linman's
mentioned
the
mcs
apis,
making
sure
that
not
only
stu
plays
nicely
with
them,
but
sd
also
contributes
some
of
the
api,
goodness
that
we
have
learned
so
that
users
can
natively
use
kubernetes
apis,
but
still
get
all
the
functionality
from
from
sdo
and
most
of
the
apis
already
provide
vendor.
I
shouldn't
say
vendor
extensions
but
implement
implementer
extensions.
So
it's
a
great
way
for
users
to
not
learn
specific
apis,
but
still
get
most
of
the
functionality
by
just
using
kubernetes.
D
The
last
focus
area
here
is
operational
excellence,
and
this
is
for
the
developer
community
in
istio
itself,
ensuring
that
our
operator,
our
operational
day-to-day,
is
optimized
so
that
our
product
or
our
releases
going
out
are
of
better
quality
right.
A
lot
of
the
issues
that
we
have
seen
around
upgrades
and
the
overall
data
operations
inherently
come
from
the
fact
that
we
might
have
some
policies
in
place,
but
either
these
policies
are
not
followed.
All
the
or
the
policies
are
a
bit
too
much
to
follow
to
begin
with
or
they're
incorrect
right.
D
D
So
this
is
the
overall
theme
that
toc
is
providing
as
guidelines.
The
idea
here
is
the
working
group
leads
when
you're
coming
up
with
features
and
you're,
trying
to
prioritize
the
work
for
every
release.
Look
at
these
themes
and
try
to
slot
them
in
they
are,
by
definition,
broad,
so
that
we
can
do
a
lot
of
work.
D
E
F
D
C
A
A
K
K
K
Today,
their
workload
routes
are
only
a
single
route.
You
can
only
support
a
single
route,
which
is
their
route
that
is
signing
their
workload
certificate.
Currently
we
are
working
on
supporting
multiple
through
their
mesh,
config
and
yeah.
This
is
a
p0
and
it's
also
it's
a
foundation
for
doing
smooth
ca
migrations,
because
during
the
migration
you
want
workloads
signed
by
the
oca
and
uca
be
able
to
talk
to
each
other,
which
requires
multiple
routes
of
trust.
E
K
K
Today
we
support
rotating
their
certificate
without
changing
the
private
key
right,
because
the
private
key,
because
the
private
key,
never
changes.
You
can
extend
the
ttl
of
the
root
certificate
without
breaking
your
existing
workloads.
You
and
when
you
say
certificate,
you
mean
the
ca
certificate.
Yes,
ca,
yes,
ci
certificate
without
downtime,
so
without
some
time
and.
L
D
Right
one
more
quick
question
before
you
move
to
p1
for
the
first
item:
next
version:
certificate
management,
api,
my
ask
here
would
be
to
make
sure
whenever
we
implement
it,
we
give
users
a
migration
path
and
test
the
cases
where
users
have
configured
an
environment
variable
and
then
they
want
to
move
to
this
search
management.
Api.
K
All
right,
the
tis
version
and
cipher
switch.
Allow
listing
this
one,
it's
a
p1,
it's
basically,
we
allow
users
like
the
financial
companies,
for
example,
who
have
strong
requirements
on
the
tis
versions.
Their
city
cards
are
using
and
they
want
to
also
enforce
the
restrictions
on
the
cypher
suites.
We
can.
You
can
apply
that
under
on
the
mesh
config
or
some
configuration
and
that
will
be
enforced
on
every
car.
K
This
is
a
ask
from
our
community.
We
want
to
do
that
as
a
p1
integrated
with
external
cas.
We
started
this
work
from
last
year.
Currently,
it's
experimental
users
can
integrate
with
the
istio
is
still
acting
as
an
array,
while
the
kubernetes
certificate
signing
api.
We
want
to
push
that
to
alpha
and
beta
in
this
year.
K
K
This
is
to
specifically
enable
mesh
to
mesh
mtos
between
the
workloads,
so
spire
or
spf
side
is
already
supporting
this
and
tetra
is
also
interested
in
supporting
this,
because
their
customers
are
asking
for
it.
This
one
is
considered
as
a
pc
p2
in
general
and
tetrad
will
contribute
to
this
effort
in
this
year.
O
O
It's
yeah,
it's
already
a
pretty
widely
used
feature,
and
we
also
plan
to
add
a
troubleshooting
tools
for
for
this
authentication
policy
and
oscillation
policies
through
east
decatur
and
yeah.
There
is
actually
a
working
in
progress
design
dock.
For
that,
the
other
feature
we
plan
to
support
is
external
oscillation.
With
the
custom
action
it's
today
is
actually
already
released
as
an
experimental
feature.
We
plan
to
continue
working
on
this
feature
and
make
it
more
properly
supported.
O
O
O
D
K
K
P
B
I
mean
so
real
quick.
I
was
just
going
to
say
that
I
I
agree
generally,
that
debuggability
and
debugging
are
still
areas
to
work
on
for
the
project
and
so
yeah
we
should
have.
We
should
probably
think
about
that
for
each
area,
not
just
security
but
for
each
area-
yes,
yeah
right
so
like
on
security.
Actually,
both
debugging
of
the
you
know,
identity
and
certificates,
but
also
the
policies
right
should
be
in
scope
here.
O
K
K
K
D
Yeah
yeah,
that's
that's
really,
nice.
The
second
point
for
me
again,
coming
to
the
themes
for
the
year
would
be,
if
you
have
done
some
analysis
on
issues
that
users
have
filed
and
whichever
issues
come
to
your
working
group
file
or
your
area
of
focus
and
those
are
around
upgrades.
It
will
be
good
to
understand
if
there
is
an
underlying
fundamental
problem
with
the
area
or
is
it
lack
of
testing
and
then
again
come
back
and
focus
on
it.
D
I
don't
know
if
such
analysis
has
been
done
for
security,
but
since
I'm
bringing
it
up
now,
it's
unfair,
but
if
you
have
and
if
you've
seen
a
trend
like
people
normally
struggle
with
rotations,
for
example,
should
we
add
explicit
integration
tests
for
that?
This
is
just
an
example.
I
don't
know
if
rotations
are
the
thing.
K
Right
for
now,
citations
are
not
a
thing,
but
yes
for
sure
any
feature
that
we
add
or
word
like
gap
there,
that
we
fix
bugs.
We
fix.
We
add
integration
tests
for
that
of
that.
That's
for
sure,
I
think
what
we
are.
We
need
to
do
more,
it's
more
be
more
close
with
our
customers
on
their
github
issues
to
see
what's
their
their
gap
in
the
user
experience
and
improve.
K
F
A
D
P
E
E
Yeah,
so
this
is
this
is
my
intention
when
we
start
with
that,
I
I
think
that
we've
seen
a
lot.
We've
had
a
lot
of
recent
discussions
about
the
backwards
compatibility
breaks,
and
sometimes
we
are
unintentionally
breaking
backwards,
compatibility
and
we're
investing
in
upgrade
tests
to
try
to
detect
those
bring
them
to
our
attention.
E
So
we
don't
do
it
accidentally,
but
I
still
think
that
there
is
this
general
perception
in
the
community
that
it
is
okay
to
just
save
up
your
backwards
compatibility
breaks
for
the
next
minor
release,
and
that's
I
mean
that's
been
the
policy
for
as
long
as
I've
been
on
the
project.
So
I
propose
that
we
change
that
mindset.
I
think
john
had
a
comment
here.
E
E
I
will
I
I
would
say
it
is
for
anything
that
okay,
so
good
great
question
not
for
experimental
alpha
is
the
thing
that
I'm
pausing
on,
because
alpha
is
the
one
where
right
now,
a
lot
of
people
take
alpha
apis
to
production
and
rely
on
them.
So
I
would
say
right
now:
we
should
also
apply
this
to
alpha,
but
if
we
made
it
easier
to
let
the
users
know
that
they're
depending
on
alpha
and
alpha,
is
unstable.
Then
we
could
revisit
it.
H
M
B
M
What
you're,
saying
and
say,
also
for
some
stuff
in
the
past
have
been
some
some
alpha,
because
there
are
a
lot
of
users
that
are
still
using
older
version
of
this
year
and
we
need
to
treat
what
they
are
using
as
part
of
this
guarantee
of
stability,
because
we
cannot
break
them
even
if
they
have
one
one.
Six,
one,
five
one
four.
E
So
I
agree
with
that.
I'm
still
looking
for
something
that
is
really
easy
for
everyone
on
the
project
to
internalize
and
remember
so
the
way
I'd
like
to
handle.
That
is
just
say,
no
backers
compatibility
breaks
for
alpha
and
above
if
you
need
to
do
until
there's
a
major
release,
if
you
have,
if
you
want
us
to
consider
an
exception,
bring
it
to
us
and
the
way
we
would
apply.
That
exception
is
by
looking
say
if
it's
an
alpha
api.
Looking
at
the
actual
adoption
can
we.
B
We
get
to
where
our
api
machinery
is
able
to
help
us
here
so
where
we
could
actually
have
like
an
alpha
one
and
an
alpha
two
and
there's
a
breaking
change
between
them
or
something,
but
users
can
keep
using
alpha
one
and
it
works
fine
like
can
we
get
to
that
point?
Are
we
never
gonna
be
able
to
do
that
as
a
project.
E
E
E
F
Yeah,
I'm
in
favor
of
asking
toc
for
exceptions,
mainly
because
it's
harder
to
think
through
which
ones
the
selective
ones
I
mean.
What's
the
criteria
and
also,
I
think
it's
good
for
the
general
project
to
know
what
could
be
break
and
brainstorming.
What
can
we
do
to
easy?
The
transition?
It's
not
like
saying
you
know
the
alpha
has
to
be
that
way
and
nobody
can
change
it.
It's
more
about.
You
know
what
are
the
exceptions
and
tooling
we
can
put
in
place.
F
Q
B
D
J
E
E
E
Is
okay,
so
not
just
the
api
changes.
It
can
also
be
the
semantic
changes
that
you
brought
up
and
there
is
both
intentional
and
unintentional,
so
we're
getting
at
the
unintentional,
with
the
upgrade
testing
we
still
need
to
get
at
the
intentional
ones,
and-
and
this
policy
is
an
attempt
to
get
the
intentional
ones.
B
E
E
Q
D
Q
Q
Yeah
like
there's
one
later
down
on
the
agenda,
which
we
probably
won't
get
to,
which
is
a
behavioral
change,
that
three
working
groups
approved
and
it's
in
some
ways
a
bug.
It's
it's
complicated
so
like
for
big
things
like
that,
I
mean
exceptions
to
the
tfc,
makes
sense,
but,
like
I
assume,
tlc
is
not
going
to
review
every
single
pr
right.
E
M
M
E
G
D
D
You
don't
mind
me
jumping,
I
agree
with
john
and
that's
what
I'm
trying
to
say.
I
think
this
is
a
much
more
advanced
problem
that
we're
trying
here
as
a
blanket
policy.
If
we
say
yes
anything
above
alpha,
you
can't
break.
I
don't
think
that
alpha
is
alpha
anymore.
Let's
go
back
and
redefine
what
alpha
experimental
and
beta
means.
D
That's.
The
first
statement,
in
my
opinion
that
we
should
consider
second,
is
josh.
What
you're
bringing
up
is
the
reality
of
the
current
state,
where
many
of
our
users
are
deploying
alpha,
because
they
really
want
that
feature,
and
we
have
not
explained
them
well,
we
don't
want
to
break
them.
I
agree
we
shouldn't
break
them,
and
the
third
point
is
what
john
is
talking
about
that
api
changes.
Enforcement
are
actually
possible
semantic
and
implementation
changes.
J
J
B
Yeah,
I
I
want
to
talk
a
little
bit
more
about
the
alpha,
the
beta
thing
too
so
like
I,
I
think
we
should
we.
We
need
to
allow
backwards
compatibility
breaks
from
alpha
debata.
We
should
not
expect
the
user
to
be
able
to
copy
paste,
or
you
know
just
the
string
alpha
to
beta
and
it
work.
I
think
what
we
need
to
do
is
enforce
that.
We
have
a
story
for
migrating
yeah.
Yes,
okay,
good,
call,
yeah,
that's
that's
the
problem
we
had
in
the
past
is
we
had
no
migration.
B
We
just
said:
hey
users,
please,
you
know
sorry.
This
will
stop
working
at
some
point
and
the
kubernetes
model
is
actually
that
you
know.
There's
automated
migration
right,
like
the
old,
the
old
things
get
changed
right
as
different
like
it's
not
necessarily
backwards
compatible,
but
they
can.
At
least
we
should
have
that
as
a
requirement.
Okay,
all
right.
So
so
this
yes,
I
agree.
F
To
add
to
your
point
as
a
toc
member:
if
there
are
things
that
has
semantic
changes,
you
know
at
least
at
the
minimum.
I
would
like
to
have
a
fyi
right,
even
though,
let's
feel
approval
it's
too
strong
to
slow
people
from
execution,
at
least
at
the
minimum.
You
know
we
would
like
to
be.
Like
john
has
for
your
awareness
on
the
item
he
had
on
inbound
forwarding.
You
know
those
are
tremendous
things
over
user.
Can
you
ask
us.
D
F
O
B
F
E
B
I'm
typing
that
I
think
we
should
still
say
that
you
shouldn't
make
backwards
compatible,
that
you
should
avoid
backwards.
Compatibility,
breaking
changes
like
alpha
to
alpha
like
within
alpha,
okay,
great.
What
I'm
saying
is
you
should
save
up
any
breaking
changes
for
beta
for
the
beta
api,
but
as
part
of
that
you
have
to
be
able
to
migrate.
B
D
C
D
Mean
maybe
what
we
are
saying
is
experimental
is
where
you
should
do
whatever
the
hell
you
want
in
alpha
bunch
up
all
your
or
an
experimental.
Do
all
the
mutations
get
it
to
an
alpha
state
in
alpha.
Don't
keep
mutating
them,
but
if
you
have
sufficient
information,
then
just
go
to
beta
or
kill
it
or.
B
Migrate,
I
think
we
could
like
we
would
have
to
invest
in
supporting
you
know
alpha
one,
but
two
migrations
if
we
wanted
to
do
that
like
without
that,
I
don't
think
like
we
shouldn't
make
a
backwards,
incompatible
change
from
alpha
one
to
alpha
one,
just
over
two
minor
releases.
I
think
that's
what
we're
saying
we
should
avoid.
At
least
that's
what
I'm
saying.
D
P
Q
Yeah,
the
migration-
I
don't
think
it's
possible,
but
this
we
probably
don't
have
enough
time
to
discuss
that
here.
What
I
was
going
to
say
is,
I
don't
understand
how
this
will
work
in
practice
like
it's.
It's
easy
to
say
I
think
toc
will
approve
all
breaking
changes,
but,
first
of
all,
unless
you're
approving
every
single
pr.
That
means
that
someone
has
to
identify
it's
a
breaking
change
and
if
they
are
already
identifying
it's
a
breaking
change.