►
From YouTube: Technical Oversight Committee 2020/12/04
Description
Istio's Technical Oversight Committee for December 4th, 2020.
Topics:
- Level of support for in-place upgrades of Istio
- Istio 1.9 Roadmap presentations by User Experience and Telemetry Working Groups
B
A
G
If
you
don't
use
revisions,
whether
that
means
there
could
be
downtime
whether
it
means
you're
completely
on
your
own
and
we
don't
even
care
about
supporting
it
or
what
that
means,
because
it's
it's
interesting
both
like
when
we're
designing
things
like
everyone
has
a
different
opinion
on
what's
supported
and
our
users
also
don't
have
a
clear
message.
I
think.
H
B
In
other
words,
we
do
not
support
upgrades
in
place
upgrades
with
guarantees
that
there
will
be
no
downtime
users
should
expect.
There
is
a
downtime
and
it's
equivalent
without
installing
these
two
instantly
again
I
mean
shutting
down
traffic
on
install
install
again.
You
should
not
rely
on
on
on
anything
else,
so
why?
Why
is
that
the
case?
What
is.
B
Technically,
we
do
not
have
the
capability
to
to
maintain
synchronicity
between
between
xds
and
voice
sidecars
and
the
htod
itself,
not
only
because
we
don't
have
enough
testing
and
enough
stability
in
the
apis
and
in
the
external
dependency.
But
because
again
we
have
no
way
to
control
the
rollout
of
the
data
plane.
So
when
you're
doing
place
upgrade,
you
suddenly
have
very
hard
to
predict
combination
of
side,
cars
and
and
study,
and
maybe
in
10
years,
we'll
have
enough
testing
to
guarantee
that
xds
is
super
stable
and
nothing
changes.
C
B
I
mean
we
are
getting
better
and
better
and
we
are
minimizing
the
damage.
I
mean
the
downtime
and
the
risk
are
getting
smaller
and
smaller,
but
because
there
is
no
infrastructure
in
place.
That
means
there
is
no
way
to
know
what
the
client
is,
what
the
server
is
and
what
the
differences
are,
and
we
don't
have
enough
testing
across
those
deltas,
nor
any
part
where
we'll
have
enough,
because
there
are
too
many
changes
in
a
way.
B
I
mean
again,
the
system
is
not
designed
for
that.
Revision
are
designed
and
were
designed
to
get
around
this
problem.
That's
a
proper
design!
That's
not
why
we
introduce
revisions
if
you,
if
there
is
a
design
that
will
allow
us
to
do
in
place,
upgrade
and
deal
with
the
delta.
Of
course,
we'll
do
it,
but
the
best
we
have
is
what
john
proposed,
with
with
you
know:
automat
automating.
E
B
E
A
H
F
H
B
You
know
this
fan
claims
that
all
software
programming
software
can
be
solved,
but
there
are
np
problems
that
cannot
be
solved.
This
is
an
np
problem
where
there
are
so
many
combinations,
so
many
variations,
so
many
permutations
that
I
don't
think
we
have
a
way
to
guarantee
anything,
especially
since.
G
E
Chaos
on
so
that
is,
that
is
absolutely
not
true
guaranteeing
backwards.
Compatibility
from
one
version
to
another
is
absolutely
possible.
It
is
just
a
matter
of
us
investing
in
it
right
us
being
the
issue
project
and
the
envelope
project
right.
We
both
projects
would
need
to
invest
in
saying.
Yes,
you
can
have
control
planes
when
you
can
upgrade
the
control
plane
and
then
upgrade
the
data
plane
in
place
and
everything
works.
It.
E
G
Yeah,
so
I
guess
that
solves
the
user-facing
argument.
Do
we
want
to
have
the
same
idea
internally
like?
Should
we
invest
in
making
in-place
upgrade
work,
even
if
we
tell
users
that
it
will
cause
downtime,
or
is
that
something
that
we
don't
even
bother
investing
effort
in
especially
around
like
adding
testing
for
upgrades.
H
A
C
K
B
As
long
as
the
user
is
informed,
that
downtime
may
be
possible
and
they
don't
play
the
issue
for
production
outages
if
they
do
up
in
place
upgrade.
I
don't
think
it's
a
problem,
it's
very
reasonable,
but
we
should
invest
in
what
john
proposed
with,
which
is
to
to
do
the
how
to
to
make
revision
based
look
like
in
place
upgrade
for
users.
That's
mine,
that's.
C
C
K
E
L
B
J
B
L
D
C
B
L
H
H
I
was
just
going
to
close
this
back
to
surveillance
point
I
mean
if
a
revision
based
upgrade
is
really
as
simple
as
in
place
upgrade.
We
definitely
would
love
to
look
into
that,
but
today
it's
not
and
also
there's
also
maturity
time
with
projects,
but
like
istio
right
people
knows
the
new
feature
out
there.
It
may
take
three
six
or
a
year
to
be
mature.
That's
the
other
angle,
we're
looking
at.
E
B
K
B
B
K
H
I
strongly
believe
that's
the
right
way,
in
fact,
I'm
a
big
advocate
for
that
work.
I
actually
highlighted
in
my
one
eight
it's
your
blog.
That's
like
the
biggest
thing
we've
done
in
1.8
for,
and
you
guys
all
know.
Inside
of
ibm,
we've
been
aggregate
that
approach
before
you
guys
standalize
it,
because
we're
being
advocate
people
to
run
their
customer
gateway
outside
of
the
default
gateway
so
that
they
have
the
full
control
of
that
gateway
life
cycle.
So
I
think
that's
definitely
the
right
approach
same.
H
Yeah
thanks
for
checking
with
us.
Okay,
so
are
you
ready?
Okay,
I
guess
I'll
be
next.
This
should
be
quick,
so
we've
been
having
eric
has
been
doing
an
amazing
job,
as
psc
members
represent
from
ibm,
and
I
think
we
intended
that
to
be
a
rotation
role,
so
one
person
doesn't
have
to
stuck
there
forever.
So
with
the
next
release.
Eric
has
graciously
agree
to
help
us
to
make
upgrades
work
better.
H
So
we
have
specific
scenarios
we're
going
to
focus
on
in
place
and
also
revision
upgrade
to
use
revision
to
transition
from
in
place
to
external
sdod.
So
with
that
we're
going
to
have
eric
free
up
from
the
psc
members,
greg
hansen
has
just
been
released.
Manager
for
1.8,
I
think
he's
definitely
qualified,
for
you
know,
switch
eric
out
and
he'll
be
the
representative
from
ibm
as
a
psc
member.
E
H
I
C
C
H
I
D
E
D
D
M
M
The
next
item
is
the
a
partial
bit
of
the
telemetry
api
proposal.
We
tried
to
scope
down
for
one
nine,
to
focus
on
one
small
set
of
features,
the
wisdom
of
that
yet
to
be
determined.
But
that's
the
work
that's
going
on.
This
is
something
that
users
have
been
asking
for
for
a
long
time
having
a
proper
telemetry
api,
and
so
we
want
to
introduce
it
to
give
workload
overrides
workload
level
overrides
for
things
like
tracing
access,
logging
and
metrics
customization.
M
So
that
is
a
p0
and
I
will
be
driving
that
work.
We
have
added
work
in
one
eight
to
support
traffic.
That's
not
in
the
mesh
to
have
metadata
about
that.
That's
restoring
features
we
used
to
have
with
mixer
and
peter
is
going
to
continue
that
work
and
complete
that
work
in
the
one
nine
time
frame
for
traffic
leaving
the
mesh.
M
So
that's
the
other
p0
peter's
also
going
to
work
on
finishing
documentation.
We
had
promised
this,
I
think
last
week
cycle,
but
it
never
happened.
We
worked
on
some
sort
of
workarounds,
but
we
didn't
fully
document
all
the
workarounds
for
the
fact
that
prometheus
metrics
no
longer
expire
with
v2
telemetry.
So
we
want
to
get
that
documentation
up
on
the
website
and
if.
M
There
is
a
much
longer
term,
it's
a
big
fix
effort.
We
don't
have
anyone
working
on
that
currently
a
day
or
two
ago,
someone
from
the
community
reached
out
and
said
they
might
be
interested
in
working
on
that.
I
have
not
heard
more
since
then,
and
because
of
that,
we
don't
have
any
work
ongoing
for
that
long
term.
E
M
E
So
what
I
would
do
is,
I
would
put
in
that
you
know
we
we
will
be
working
on
it
during
this
release,
but
not
finishing
at
this
release
as
part
of
the
road
map.
Okay,
all
right
and
sort
of
say
what
part
you
plan
on
getting
done
right,
like
whether
it's
an
approved
design,
whether
it's
identifying
who's,
gonna
work
on
it,
whatever
it
is,.
M
Okay,
I
think,
for
this
cycle.
We
don't
have
anyone
that's
going
to
work
on
it,
but
maybe
if
this
community
thing
pans
out,
okay,
all
right.
Similarly,
you
know
for
the
wizard
extensions
we've
sort
of
been
working
on
features,
but
there's
no
documented
plan
for
what
it
takes
to
promote
them
up
to
beta
and
so
this
cycle.
The
plan
is
to
develop
the
plan
for
what
it
looks
like
to
transition
those
features
into
beta,
so
that
is
also
a
p0.
It's
going
to
lead,
take
charge
of.
M
E
M
N
E
M
I
M
N
M
N
N
N
That's
that's
a
that's
a
fair,
that's
a
fair
point
and
yeah
we'll
probably
discuss
it
in
the
like
in
in
in
the
specific
details,
but
it
puts
sort
of
additional
burden.
That's
not
needed,
and
many
customer
requirements,
especially
around
policy,
are
such
that
it's
all
done
kind
of
in
the
process.
So
we
don't
want
to
unnecessarily
get
customer
adoption
on
our
own
adoption
and
there
are
other
people
in
the
community
who
would
adopt
it
for
other
things
and
that's
kind
of
ongoing
right
now.
K
H
H
B
M
Okay,
carry
on
doug,
so
the
next
p0
there
is.
We,
we
haven't
really
done
a
good
job,
providing
documentation
on
now
that
mixer's
gone
here
are
exactly
how
you
should
use
the
the
new
functionality
that's
available,
and
so
we
want
to
really
take
charge
of
that
and
fix
that
scenario.
So
we're
gonna.
This
is
a
p0
to
better
document
how
to
transition
and
what
the
existing
extension
models
now
provide.
You
in
particular,
there's
work
going
on
about
rate.
M
You
know
over
time
with
each
release,
and
so
we
wanted
to
to
work
with
the
ux
team
on
developing
an
analyzer
for
envoy
filter.
Some
of
that
work
has
already
been
done,
so
this
has
been
scoped
down
to
a
p1
where
we're
just
going
to
cover
whatever
is
left
whatever,
where
we
think
we
can
be
useful
on
upgrades
and
the
final
p0,
I
think
for
our
working
group
for
one
nine
is
to
continue
to
better
support
multi-cluster
scenarios.
M
This
includes
dashboard
updates,
but
also
stabilizing
support
for
the
labels
in
metrics,
making
sure
they
also
show
up
in
logs
and
trace
bands
and
doing
a
better
job
with
the
integration
tests.
Newberry's
gonna
take
taking
us
back
getting
all
those
transitions,
but
we
want
to
make
sure
that
all
of
our
existing
integration
tests
support
multi-cluster
and
do
a
better
job
with
that
documentation.
E
B
H
H
M
Yeah,
they
don't
right
now,
but
okay,
okay,
good
to
know
the
p1.
That's
sort
of
related
to
that
earlier
wasm
conversation
is,
there
has
been
work
coming
from
a
couple,
different
places
about
how
to
distribute
wasm
extensions
and
what
the
api
for
that
should
be,
and
so
we
want
to
work
this
time.
This
release
on
designing
that
api
and
mechanisms
and
how
that'll
all
work
so
that
we
could
start
implementation
in
110.
E
N
M
M
Some
of
that
work
in
one
eight-
and
this
is
a
continuation
of
that
to
continue
to
support
the
changes
in
telemetry
support
scenarios
like
multi-cluster,
but
also
we
added
grpc
streaming
metrics
there's
been
requests
to
have
gateway,
focused
dashboards
as
well
as
to
have
dashboards
built
on
canonical
services
instead
of
just
kubernetes
services.
So
there
is
work
there
and
that's,
I
think,
that's
it
of
the
one
line
proposed
items.
E
E
H
C
E
D
Alright
great
so,
as
you
all
know
that
one
the
oneline
release,
we
are
focusing
on
stability,
and
so
for
that
reason
we
did
not
just
carry
over
the
items
from
one
eight
that
were
left
over
the
p2s
didn't
just
normally
we'll
promote
p2s
to
p1,
etc
and
kind
of
continue
along
in
the
direction
we're
going.
However,
we're
sort
of
pivoting
this
release.
D
In
the
last
release,
we
were
really
happy
to
see
all
of
the
user
feedback
making
its
way
into
toc,
and
the
theme
for
this
release
is
executing
on
that
feedback.
Around
upgrades,
so
louis
asked
that
we
go
through
our
backlog
of
experimental
features
and
either
promote
or
disable
them.
So
we're
going
to
be
doing
that
in
the
nine
time
frame.
D
D
Yes,
great,
so
we're
also
adding
an
upgrade
checklist.
That's
going
to
bring
together
a
few
features.
We've
been
working
on
in
parallel
like
pre-check
and
verify
install
to
give
users
a
comprehensive
understanding
of
when
they
are
ready
to
upgrade
a
cluster
from
one
version
to
the
next
anything
that
they
need
to
do,
such
as
cutting
over
crds
from
a
version
that's
been
deprecated,
etc.
C
D
E
D
B
E
E
If,
if
we
don't
do
that,
and
people
are
on
one
side,
they
need
to
get
to
one
nine
and
they
have
to
go
through
one
eight
to
get
there
or
you
know
they
have
to
go
like
one
six
one
seven,
and
then
they
can
jump
to
one
nine,
because
we
support
two
jumps
right.
Then
we
consider
whether
the
tool
can
help
you.
C
B
C
D
Yeah,
okay,
I
will
take
a
follow-up
item
to
consider
that
these
individual
tools
there
are
some
upgrade
analyzers
that
are
out
there.
There
are
pre-checks,
there's
verify
install.
These
are
all
already
available,
one
seven
and
forward,
but
they
are
all
separate
tools
and,
and
it's
a
little
confusing
how
to
use
them
all
together.
So
there
could
be
some
improvements
there.
D
H
C
By
the
way,
mitch
and
the
ux
working
group,
one
piece
of
really
good
feedback
that
I'm
getting
from
my
demo
and
that's
the
only
piece
of
feedback
I've
got
for
my
one-year
demo
is
the
everyone
loves
the
bug,
report
tool,
so
great
job
on
it
and
being
able
to
run
that
tool
on
an
old
cluster
and
it
works.
It's
really
nice.
D
B
D
This
is
in
collaboration
with
nathan,
mittler
and
jason
wang.
I
do
think
that
there
will
be
a
little
bit
of
area
that
is
not
covered
api
wise
in
the
one
nine
time
frame.
I
I
don't
think
that
we
can
get
quite
all
the
way
there,
but
in
terms
of
what
labels
and
annotations
and
environment
variables
you're
using
you'll,
understand
the
maturity
of
the
features
you're
using.
K
D
C
D
I
do
expect
that
one
of
the
outcomes
of
this
is
that
we
should
find
a
lot
of
places
where
we're
actually
making
use
of
alpha
level
features
in
very
common
or
perhaps
default
profiles
and
we'll
need
you'll
be
hearing
from
us
on
those
those
will
get
escalated
and
we'll
need
to
figure
out
whether
that
means
we
promote
them
quicker
or
we
change
what
we're
doing
in
terms
of
our
default.
Installs.
D
O
E
O
That,
last
bit,
oh
great,
if
people
can
volunteer
to
work
on
some
of
the
things
here,
that
mitch
is
talking
about
specifically
around
helping
users
with
their
upgrade
problems
or
understanding
them
right.
We
would
prefer,
in
many
respects
that
you
volunteer
to
work
on
this
item,
then
possibly
other
thing.
C
C
Mitch,
quick
question
for
you,
I
I'm
gonna
ask
the
same
question.
I
asked
in
the
previous
item:
what's
the
retroactive
policy
on
this,
because
it's
amazing,
if
you
can
do
this
for
a
customer
who
is
running
the
current
like
I'm
on
one
six,
just
tell
me
what
feature
I
already
know
is
broken,
or
it's
probably
experimenting.
D
B
B
So
a
lot
of
the
things
need
to
be
backported
to
one
sixth
and
then
user
have
five
different
version
of
steel
cattle
any
chance.
We
can
avoid
this
and
fix
this
problem.
I
mean,
especially
if
so
many
people
want
in
place
upgrade
is
your
cattle
that
they
use
on
the
client
side
or
on
cicd,
will
suddenly
break
and
will
not
work
very
well
with
this.
D
We
have
some
commands
with
an
istio
cuddle
that
are
very
easy
to
decouple
from
the
version
of
the
control
plane
such
as
analyzers
and,
realistically,
we
should
be
able
to
run
them
pretty
much
anywhere.
We
have
other
commands,
however,
that
are
much
more
tightly
coupled
such
as
the
troubleshooting
commands
that
we've
been
trying
to
improve
and
not
making
a
lot
of
forward
progress
on.
It
would
be
pretty
challenging
with
the
state
of
affairs
right
now
to
have
multiple
control,
plane
versions,
supported
for
troubleshooting
commands
and
seo
control.
O
Right,
I
mean
custom.
Obviously,
if
we
can
improve
the
tooling
specifically
focused
around
upgrades
to
make
customers
much
more
comfortable
with
upgrading
right
that
that
other
burden
right,
the
debug,
is
a
little
less
pressing.
So
I
think
it's
right
for
them
to
focus
on
analyzing,
like
even
acknowledging
that
we
have
that
problem,
I
think
it's
okay.
D
C
I
I
think
it
will
be
nice
to
have.
I
don't
think
in
one
line.
It
is
realistic
to
assume
we
will
achieve
that
for
one
line.
If
we
are
adding
feature
number
three
that
that
feature
status
definition
I
would
even
take
if,
if
you
run
one
line,
still
cuddle
against
one
six
and
it
just
prints
out
saying
I
understand
these
things,
but
not
everything
like
as
long
as
that,
we
can
do
that.
It
is
pretty
good.
B
E
E
D
E
P
D
H
E
D
D
Okay,
we're
also
going
to
be
re
reorganizing,
the
cli
in
a
non-breaking
fashion,
so
that
it's
clear
what
commands
are
appropriate
for
which
personas
in
particular
we're
seeing
now
that
not
everyone
has
the
same
access
privileges
to
the
kubernetes
cluster
or
control
plane,
and
that's
a
good
thing.
It
means
our
users
are
differentiating
they're
becoming
more
nuanced,
but
we
need
to
make
our
cli
reflect
that.
So
it's
clear
which
commands
are
appropriate
for
which
personas.
D
D
D
D
C
Yeah
normally,
when
I
have
done
this
before
it's
a
longer
initiative
to
get
that
consistent
terminology
throughout
the
documentation
and
messaging,
so
it
will.
I
would
advise
you
to
talk
with
someone
from
the
docs
working
group
to
ensure
like
if
you
have
defined
your
roles.
Let's
use
those
roles
correctly
and
when
it
comes
to
blogs
or
some
other
guides
and
tasks
right,
yeah.
E
D
H
So
michi,
I
have
one
question
I
was
trying
to
ask
ed
but
he's
offline.
I
I
want
to
get
your
thoughts
on.
You
know
how
multi-cluster
has
been
promoted
to
beta
with
remote
cluster
without
histod
in
1.8,
and
an
external
hdld
is
thermal
heat
to
alpha
and
we
are
in
the
process
trying
to
evaluate
have
that
promoted
beta
also.
So
I
want
to
get
your
thoughts
on.
Is
you
kind
of
working
with
remote
cluster
without
issued?
D
Yes,
yeah
you're,
right
lynn,
the
troubleshooting
api
is
something
that
is
important
to
a
lot
of
our
users.
In
a
lot
of
our
different
configuration
profiles,
we
don't
feel
like
we
have
the
bandwidth
to
address
that,
as
well
as
the
upgrade
issues
that
are
pressing
the
project
in
one
line
yeah.
So
unfortunately,
prioritization
means
saying
no
to
some
great
ideas,
and
that
was
one
of
them.
Okay,.
H
D
So
the
existing
troubleshooting,
sorry,
the
existing
prototype
of
the
troubleshooting
api-
does
not
include
functionality.
That
users
would
expect
proxy
status
only
lists
what
proxies
are
connected
to
what
instance
of
sdod,
which
has
minimal
usefulness
to
users
doesn't
include
information
like
which
nonce
version
each
proxy
is
at
for
each
collection.
That
sort
of
thing
I
would
not
consider
I
would
not
recommend
promoting
those
to
users.
I
would
simply
say
that's
a
gap
in
our
user
story
that
we
need
to
fill
it's
important,
but
hopefully
it's
a
lower
priority
than
our
upgrade
story.
D
H
C
Q
F
O
I
think
the
discussion
last
time
was
they
oliver
and
co-presented
in
the
same
toc
meeting
where
we
provided
the
guidance
around
focusing
on
upgrades
and
supportability,
and
so
there
was
a
bunch
of
feedback
about
being
aligned
with
that.
I
think
so,
if
that,
if
that
we
can
take
it
offline
that
part's
fine,
but
that
was
the
reason
why
I
think
mirage.
E
E
E
R
H
O
Yeah,
it
would
be
nice
to
have
a
tlbr,
a
quick
scheduling
question,
so
we
still
have
a
fairly
decent
backlog
for
toc
and
we
are
pushing
into
december
so
other
tlc
members
and
the
community
in
general.
Right.
We
have
one
toc
meeting
next
week
and
one
more
the
week
after
I
I
suspect
next
weeks
will
be
pretty
well
attended
to
the
week
after
we
might
start
to
see,
drop
off
because.