►
From YouTube: Technical Oversight Committee 2021/11/01
Description
Istio's Technical Oversight Committee for November 1st, 2021.
Topics:
- Kubernetes versions for 1.12
- Istio 2022 strategy/roadmap/themes
- Support for contrib images from Envoy
A
C
C
Yes,
there
is
one
that
I'm
not
sure
what
the
discussion
around
that
has
been
it's
about:
contrib
images
for
proxy,
as
some
filters
have
been
removed.
If
you
understand
correctly
from
the
envoy
release
and
in
order
to
maintain
backwards
compatibility,
there
was
a
discussion
around
us,
releasing
two
separate
images:
one
contrib
that
has
all
the
old
filters
and
one
that
is
based
on
upstream
environment.
D
Yeah,
so
we
discussed
this
in
a
test
release
or
networking
or
one
of
the
two,
and
our
tentative
decision
was
that
if
we
need
to
figure
something
out
here,
but
we
don't
have
enough
time,
and
so
the
idea
was
we'll
just
revert
that
change
on
our
fork.
It's
not
really
even
reverting.
We
choose
which
extensions
we
build,
so
we'll
just
make
sure
that
we
include
the
ones
we
used
to
include,
and
you
know,
moving
forward
in
1.13
plus
we'll
figure
out
well,
the
proper
long-term
solution
for
them.
D
F
C
B
E
E
A
A
G
D
B
It
does
one
more
question
follow-up.
I
know
a
long
time
back.
I
was
discussing
with
john,
and
he
mentioned.
Essentially
1.25
is
going
to
be
incompatible.
So
is
this
something
we
should
start
discussing
soon,
because
if
12.1.23
is
out,
it's
hardly
two
quarters
away
from
the
baking
changes.
I
do
not
understand
the
breaking
changes
yet,
but
sun's
light
is
going
to
be
incompatible
like
1.2
2.,.
D
D
I
would
say:
yes
is
the
short
answer
we
should,
but
it's
less
concerning
than
the
other
ones.
I
think,
because
all
the
other
ones
involved
quite
a
bit
of
code
in
the
like
in
natural
code.
The
breaking
changes
here
only
impact
the
install
and
so
like
you
you're
kind
of
like
it's
not
like
you
upgrade
kubernetes
and
you're
instantly
broken
it's
just
you
upgrade
kubernetes
and
then,
if
you
try
to
install
estio
again,
it
wouldn't
work
right
away,
so
we
should
definitely
fix
it.
C
D
C
D
So
they
are
removing
the
horizontal,
auto
scaler,
pod
disruption,
budget
and
endpoint
slice
api.
Well,
sorry,
the
version
of
the
api
that
we
use,
and
so
we
just
need
to
update
the
version.
Friendpoint
slice
we've
already
addressed
that
for
the
other
two
it
would
be
trivial.
But
the
problem
is
the
operator
api.
We
need
to
figure
out
how
we're
going
to
handle
that,
and
so
we
haven't
merged
the
update.
Yet,
but
that's
it.
We
just
need
to
update
the
api
version.
That's
used.
A
H
J
J
I
I
did
add
something
around
performance,
but
not
indeed
great
detail
right.
I
had
something
like
we
won't
continue
to
make
it's
still
the
best
performance
of
smash.
I
think
there
may
be
something
at
the
end
too,
because
I
think
it's
an
important
area.
We
should
focus
on
especially
linkedin's
running
campaign
against
us
on
performance.
I
D
A
G
So
my
my
top
project,
what
I
think
is
super
important
is
interoperability.
I
mean,
especially
since
we
have
the
optical
abilities,
gateway
and
other
apis,
so
making
sure
that
the
subset
of
istio
can
be
used
across
multiple
implementations,
including
proxies
jpc
and
other.
Like
john
said,
you
can
have
a
subset
of
each
student
is
extremely
fast.
G
J
G
J
J
B
J
D
A
A
H
B
So
in
would
it
also
help
if
we
say,
for
example,
for
each
of
those
four
high
level
goals?
What
would
be
the
exit
strategy
so
when
we
say
cleaning
up
and
stabilizing
apis
and
features
what
would
be
the
exit
strategy?
When
do?
I
know
it's
complete,
because
it's
like
continuous
process,
but
then
when
can
I
say?
Yes,
it
is
done
for
2022.
What
is
my
strategy.
D
Yeah,
do
we
want
to
be
that
fine
grain,
it
seems
like
a
lot
of
this-
is
like
high
level
directional
guidance,
not
necessarily
that
in
2020
we
will
complete
each
joe
extensibility.
It
will
have
completed
its
reach
like
this
is
just
from
my
point
of
view,
at
least
like
what
we
want.
Our
quarterly
roadmaps
to
focus
on
we'll
have
more
exact
criteria.
J
B
J
A
A
You
know
there
are
things
that
we've
talked
about
before,
like
you
know,
make
the
customers,
you
know,
perform
fewer
upgrades
right.
Like
you
know,
we
did
skip
level
upgrades.
We
did
six
week
extension
to
release
support
windows,
so
we
could
save
users
one
upgrade
right
every
six
months
or
so
you
know
that's
a
pretty
measurable
outcome.
A
We
could
also
keep
tracking
towards
that,
but
I
don't
know
if
that's
a
that's
the
kind
of
thing
this
document
should
say,
I
think
sven's
right
right.
This
is
guidance
to
the
working
groups,
about
what
the
focus
area
should
be
separately.
We
could
try
and
define
some
concretely
measurable
things,
but
anything
that's
adoption
related
is
going
to
be
hard
unless
people
have
thoughts
about
how
we
might
measure
adoption,
but
so
far
we're
five
years
into
this
and
haven't
really
done
anything
on
that
front.
The
whole
time.
I
H
I
A
I
E
Yeah,
there's
all
kinds
of
caveats
associated
with
it,
like
users
running
their
own
internal
repositories
where
they
download
it
once
in
order
to
clone
it
to
their
repository
and
then
use
it
500
000
times
in
their.
You
know,
internal
cluster.
That
shows
up
as
one
download.
However,
I
don't
think
there's
a
strong
reason
for
those
occurrences
to
have
shifted
substantially
over
the
last
say
two
years,
so
we
at
least
have
apples
to
apple's
measurement
over
time.
I
F
E
So
we
we
have
an
angle
on
collecting
that
information.
However,
it
would
be
an
explicit
opt-in
on
the
part
of
the
user.
The
information
would
be
aggregated
locally
in
some
sort
of
config
file
in
the
home
directory,
and
then
they
could
optionally
send
the
data
to
the
istio
project
for
collection
and
aggregation,
so
that
still
relies
on
a
lot
of
user
behavior.
I
don't
think
any
opt
out
system
is
likely
to
pass
privacy
review.
G
D
We
could
probably
get
the
helm
charts,
but
it
doesn't
necessarily
I
mean
you
can
do
a
lot
of
commands
that
will
fetch
the
home
charts
without
installing
them,
and
I
suspect
that
helm
probably
caches
them
too,
so
you
can
install
it
a
bunch
of
times
and
it'll
only
ever
pull
it
once
so,
and
also
zero
users
are
using
it
today.
So
it
would
take
some
time
to
ramp
up,
but
sort
of,
I
guess,
is
the
answer.
G
D
Well,
we
have
a
lot
of
metrics,
I
guess
like
we
can
get
download
stats.
We
can
get
docker
hub
and
probably
gcr,
although
I
haven't
looked
at
that,
we
could
also
get
the
helm
ones
and
together,
I
think
they'll
give
us
a
reasonable
picture.
We
can
also,
obviously,
obviously
for
gkc
kind
of
what's
deployed
in
people's
clusters,
but
I
don't
know
if
that
helps
us
compare
to
other
products,
necessarily
because
we
don't
have
all
their
metrics
yeah,
which
made
things
a
bit
more
challenging.
A
So
I
mean
the
other
things
that
we
can
look
at
right.
We
can
look
at
the
derivative
effects.
Like
you
know.
The
number
of
people
signing
on
to
the
slack
workspace
the
number
of
issues
or
support
tickets
raised
right
again,
not
really
comparative
with
other
vendors
right
that
the
only
mechanism
there
seems
to
be
survey
right,
market
survey
and
cncf
is
doing
that
today.
So
that's
not
something.
We
need
to
necessarily
try
and
do
ourselves.
H
I
The
report
was
misleading.
We
were
able
to
generate
the
real
data
from
the
spreadsheets,
so
that
was
nice.
I
mean
I
totally
agree
with
what
you
guys
said.
We
can't
we
don't
know
how
other
people
are
doing,
because
we
don't
have
their
data.
What
we
can
do
is
just
compile
with
our
data
from
this
year
with
our
last
year's
data
right.
Hopefully,
they
are
similar
trend,
which
would
definitely
help
us
maintain
the
leader
position.
A
L
E
I
don't
know
if
this
rises
to
the
level
of
annual
roadmap,
but
I
hear
a
lot
of
users
asking
for
reference
architectures,
particularly
for
integrations
with
other
tools.
We've
been
very
diligent
in
not
doing
everything
as
istio.
We
are
not
an
api
gateway,
there's
plenty
of
security
tooling.
That
really
ought
to
be
integrated
with
istio,
but
we
don't
publish
a
lot
of
information
of
how
to
do
that,
how
to
get
istio
to
play
nice,
for
instance,
with
another
api
gateway
or
or
security
tools,
telemetry
tools,
etc.
E
E
Well-
and
I
mean
api
management
is
just
an
example
area
that
I'm
most
familiar
with
the
bottom
line
is
istio
should
live
in
an
ecosystem
of
a
number
of
other
software
tools
that
users
are
using
to
operate
their
services
and
and
publishing
good
information
about
how
to
integrate.
Those
well
could
be
useful.
A
Yeah,
we're
gonna
need
to
be
a
little
bit
more
refined
than
just
that.
Right,
like
we
do
interrupt
in
the
sense
that
we
speak
the
same
protocols
that
everybody
else
speaks.
We
need
some
targets
speeches
except
the
mtls
stuff,
but
that's
that's
right.
We're
trying
just
a
small
detail,
a
small
detail,
but
you
know
most
solutions
out
there
other
than
service
meshes.
Don't
do
mtls,
you
know,
except
for
the
cdns
and
even
some
of
the
cdns
don't
do.
A
So
is
it,
you
know
we
want
to
explicitly
interrupt
with
api
management
solutions.
We
want
to
interrupt
with.
You
know,
enterprises,
you
know
existing
telemetry
and
aggregate
telemetry
aggregation
and
their
their
pipelines.
Basically,
for
that
is
that
where
we
have
gaps,
is
it
you
know
kind
of
next
generation
firewall
and
wash
products
like?
Where
would
we
be
better
off
spending
our
time.
E
I
think
telemetry
is
an
example
of
where
we've
done
a
reasonably
good
job.
Here
we
have
guides
for
how
to
integrate
istio
with
jaeger
and
prometheus
in
such
a
way
that
it
is
production
ready.
We
sort
of
did
that
as
a
result
of
removing
those
from
our
default
install,
because
we
realized
that
our
installs
of
jager
and
prometheus
were
not
production
hardened.
E
A
F
Yeah,
so
so
I
think
that
for
especially
for
a
lot
of
telemetry
vendors,
integrating
through
or
downstream
integration
of
prometheus
is
one
of
the
main
ways
of
integrating
or
had
been
now
with
open
telemetry
coming
online.
Things
may
change
a
little
but
yeah
that's
why
from
getting
integration
with
prometheus,
which
is
what
we
have
gets
us
pretty
far,
because
all
these
vendors
have
their
own
scrapers
for
prometheus
and
then
they
connect
to
their
own
pipelines.
F
G
G
No,
I
heard
it,
you
know
one
or
two
customers,
but
but
in
terms
of
interopen,
and
you
know
kind
of
not
being
isolated
island
that
only
works
with
history.
I
mean,
yes,
you
can
use
gate,
but
that
means
you
can
communicate
with
the
internet.
But
if
you
are
in
a
mesh
meaning
internally
and
you
use
two
products,
you
kind
of
expect
them
to
work
together
and
not
go
to
a
gateway,
and
you
know
to
the
internal
yeah,
so
yeah
I
mean
I
was.
A
A
A
You
know
whether
it's
you
know
on
google
or
on
azure
or
amazon,
or
you
know
others
other
clouds
where
you're
using
you
know
an
edge
load
balancer
that
isn't
our
gateway,
but
you
want
to
stack
our
gateway
behind
it
for
lots
and
lots
of
different
reasons.
Then
you
know
having
solutions
that
help
people
make
that
work
is
probably
going
to
be
valuable,
even
if
it's
just
you
know
some
concrete
docs.
I
think
that
would
probably
be
helpful.
A
E
There
are
also
areas
like
cicd,
where
it's
it's
not
something
we
would
traditionally
think
of
istio
directly
interoperating
with.
However,
if
you
want
to
use
git
ops
on
top
of
your
istio
config,
there
are
some
steps
you
need
to
take
that
are
a
little
bit
different
from
using
git
ops,
on
top
of
say,
a
deployment
and
service,
even
even
reference
implementations
there.
This
is
probably
like
a
no
code
sort
of
thing,
just
documenting
how
we
did
it
would
be
valuable
to
users.
G
I
A
E
K
A
A
I
I
A
Right:
okay,
right,
we
we've
gotten
better
about
delivering
solutions
to
cds.
You
know
we're
know
we're
pretty
good
for
an
open
source
project
on
that
front
at
this
point,
but
each
cve
that
we
have
right.
The
majority
of
them
have
required
data
plane
updates
for
customers
which
have
caused
them
to
need
to
do
rollouts,
which
are
disruptive,
and
so
they
would
probably
appreciate
doing
fewer
of
them
if
they
were
cve
conscious.
I
H
I
A
I
A
I
A
Yeah,
william
morgan
had
an
interesting.
You
know
twitter
thread
response
to
the
the
new
stack
article
you
know.
Well,
I
I
like
to
disagree
with
what
liam
said.
You
know
he
was
you
know
his
points
about
mutual
tls
were
pretty
much
on
point,
so
you
know
that's
that's
something
to
be
considered
anyway.
I
think
we'll
talk
about
it
in
steering,
certainly
that
the
product
managers
here
at
google
were
thinking
about.
A
A
A
A
All
right
well
we're
out
of
time
anyway,
yeah
so
folks
go
through
the
road
laptop
leave
comments.
The
toc
members
will
try
and
resolve,
but
yeah
all
ideas
are
welcome
and
and
we'll
I
guess,
get
this
sorted
out.
But
coming
back
to
schweda's
point,
I
don't
know
that
this
is
blocking
for
113
directionally
like
overall.
If
you
look
at
the
2022
proposed
roadmap
of
the
2021
roadmap,
they
look
very
similar.
A
Our
kind
of
overall
roadmap
hasn't
changed
and
that's,
I
guess,
a
sign
of
the
fact
that
the
project
is
maturing
and
we
don't
need
as
much
feature
or
api
velocity
as
we
once
did,
because
we
have
a
lot
and
our
focus
is
on
stabilizing
it,
and
you
know
improving
our
you
know,
then
we
look
at
the
second
order.
Things
like
improving
our
integration
points
and
that's
really
no
different
in
2022
than
it
was
in
2021,
and
I
would
have
been
surprised
if
it
was.