►
From YouTube: Technical Oversight Committee 2020/11/20
Description
Istio's Technical Oversight Committee for November 20th, 2020.
Topics:
- TOC Guidance for Istio 1.9
- Istio 1.9 Roadmap Review for Environments and Security Working Groups
D
Okay,
so
continuing
our
conversation
from
the
working
group
leads
meeting,
we
want
to
focus
our
efforts
for
one
night
towards
stabilizing
our
code,
particularly
around
addressing
upgrade
pinpoints,
and
as
part
of
that,
I
think
the
guidance
to
the
working
groups.
We
will
focus
on
features
that
have
been
there
in
istio,
which
is
an
experimental
alpha
phase,
how
we
can
promote
them
and,
following.
E
F
D
C
D
And
if
there
are
bugs
related
to
upgrades
that
fall
in
your
domain,
expertise
evaluate
that
and
then
in
general,
look
at
the
environment,
variables
annotations
and
the
entire
cluster
of
things
where
users
don't
really
know
what
they're
getting
into,
but
they
use
it
and
then
they
upgrade
breaks.
So
we
can
fix
them
by
having
better
documentation,
upgrade
testing
but
also
create
some
tooling,
so
that
users
are
and
users
are
aware
of,
okay
you're
using
the
feature
which
is
experimental
so
probably
when
you
upgrade
it
might
break.
D
G
Yeah
a
couple
of
other
kind
of
points.
I
I
very
much
agree
with
what
nirar
said:
if,
if
there
are
apis
or
features
that
you
don't
want
to
bring
to
stable,
that
are
experimental,
it's
also
good
to
start
getting
rid
of
them
right,
because
anything,
that's
a
latent
option
that
a
user
might
use
is
a
support
problem
waiting
to
happen.
G
You
know,
if
you
have
users
using
experimental
features,
that's
obviously
dangerous
unless
you
really,
particularly,
if
you
don't
plan
to
bring
it,
I
think
other
things
we
talked
there
will
be
a
dedicated
effort
around
improving
the
upgrade
process
and
stabilizing
the
update,
upgrade
process.
That
work
is
already
kind
of
kicked
off,
and
so
we'll
we'll
figure
out
how
to
make
that.
G
Right
now,
you
can
kind
of
think
about
as
a
tiger
team,
but
it
might
become
a
working
group
and
then,
lastly,
right.
We
know
that
there
is
functionality
in
flight
that
is
not
yet
released
and
working
groups
are
going
to
want
to
progress
that
you
should
kind
of
establish
a
budget
right
within
your
working
group.
H
D
D
So
that's
another
thing
that
we
can
have
in
our
mindset
that,
even
if
you
can't
like
some
of
these
apis,
we
we
have
not
been
very
sure
like
metrics
default.
Metrics
are
these
apis
are
not
should
be
changed
or
not.
So
it's
okay
to
have
a
discussion
and
say:
hey:
should
we
document
them?
Should
we
document
the
impact
so
that
users
are
aware
and
how
can
they
disable
it
so
that
process
probably
will
just
continue
assuming
we
can
start
following
it.
I
I
You
know
per
our
support
policy
because
we
really,
I
mean
we
have
a
lot
of
functionality.
That
is
sorry
that
is
undocumented,
and
you
know
we
sort
of
just
leave
it
as
like.
Well,
you
weren't
using
that
or
you
shouldn't
be
using
that,
because
it's
not
documented
and
it's
like
well,
a
lot
of
stuff
isn't
documented.
How
do
I
know
what
is
stuff?
I
G
I
I'm
not
I'm
not
saying
it's
not
happening,
I'm
just
saying
like
in
addition
to
what
what
niraj
was
saying
that
you
know
if
we're
looking
and
we're
gonna
delete
something
we
should
say.
Okay,
I
need
to
delete
this,
but
I
need
a
way
to
release
so
that
I
can
at
least
tell
people
that
we're
going
to
delete
it,
so
they
can
prepare.
J
C
I
know
it
has
to
right
here
the
costume
brought
up
a
good
point
in
the
in
the
chat
too.
That,
like
one
thing
we
could
do
is
when
we
upgrade
we
can
let
users
know
of
things
that
will
be
removed
soon,
that
they're
still
using
all
right.
We
can
do
a
much
better
job
there
of
not
just
documenting
it,
but
actually,
like
letting
users
know
during
an
upgrade.
K
C
M
M
I
E
I
Of
the
injection,
but
they
were
in
the
in
a
container
version
of
the
injection,
and
that
was
really
what
it
came
around
right.
So
I
think
I
where
I'm
coming
from
is
we
do
have
things
that
aren't
documented,
that
people
are
likely
to
be
using,
but
we
don't
even
know
it,
and
then
we
just
say:
well,
that's
not
documented.
You
know
you
get
what
you
get
so
I
I.
N
Feel
like
we're
talking
about
a
hypothetical
problem
that
doesn't
exist
in
my
opinion,
because
we
have
already
all
the
tooling
to
expose
this
information.
We
have
anything
that's
configured
in
easter,
cr,
that's
deprecated.
We
have
warnings
now
that
are
exposed
pretty
much
everywhere.
We
can
stick
them
and
at
install
we
have
a
bunch
of
deprecation
warnings
and
I
don't
know
that
we've
ever
really
removed
something
without
a
release
note.
So
I
I'm
not
sure
I
I
totally
agree.
It
is
something
that
we
should
solve,
but
I'm
not
sure
it's
really
a
problem.
I
A
N
A
A
If
you
actually
want
to
make
use
of
say
an
alpha
or
an
experimental
feature,
you
need
to
basically
specify
some
sort
of
flag
that
yes
you're
willing
to
use
those,
and
if
not,
you
know
basically
during
that
installer
or
upgrade
we'll
actually
just
spit
out
an
error
message
basis,
saying
no
sorry
we're
not
going
to
do
this
you're
using
that
feature.
Unless
you
override
us
with
this
flag,
so
it
forces
people
to
it,
doesn't
stop
them
from
doing
anything.
It
just
forces
them
to
be
aware.
G
G
G
Yes
right
so
you
know,
obviously
we
don't
have
detail
yet,
but
people
have
been
asked
specifically.
Working
groups
have
been
tasked
with
following
up
on
specific
subjects,
and
so,
if
you
have
ideas
for
what
an
ideal
ux
is
right
to
help
users
understand
their
exposure
to
issues
that
would
span
in
particular
span
upgrades
right
where
we're
very
sensitive.
I
suggest
you
engage
with
ux
working
group.
K
K
G
Okay,
yeah
and
there
are
degrees
of
stability.
Some
things
are
horribly
unstable
right.
Some
things
have
no
tests
at
all,
even
though
they
may
actually
be
used,
which
is
like
those
others
are
bad
yeah.
So
this
is
all
part
of
the
api
inventory
management.
And
yes,
one
of
things
I
asked
jason
to
do
is
to
be
able
to
like
to
be
able
to
track
that
state.
G
A
C
D
Okay,
no,
I
mean
yesterday,
I
identified
few
annotations
and
things
like
that
that
I
found,
but
I
think
working
group
leads,
are
experts
in
this
domain
already,
so
you
don't
have
to
wait
for
the
work
that
louie
is
talking
about.
You
can
preempt
it
if
you're
already
aware
of
you
right
and
plan
it
for
one
night
now.
G
Well,
we'll
just
make
the
other
thing
is
we
have
to
make
sure
we
capture
it
in
a
sustainable
way.
Right
like
I,
don't
want
to
go
into
a
document
that
then
dies
a
week
later,
so
it
needs
to
be
worked
into
the
development
process.
That's
part
of
the
thing
I
asked
jason
to
look
at,
so
you
can
start
writing
your
document
now.
You
know,
take
your
inventory,
but
then
expect
it
right
at
some
point
to
convert
it
into
something.
That's
part
of
the
ci
cd.
C
Yeah
so
I
moved
I
had
put
this
one
in
as
part
of
the
earlier
topics
and
moved
it
out
as
a
separate
one,
which
is,
I
feel
like
we.
We
are
delivering
this
guidance
a
little
too
late,
because
a
lot
of
the
working
groups
were
already
putting
together
their
one-nine
presentations
and
already
done
that
work.
C
So
we
should
establish
as
part
of
our
process
that
toc,
you
know
as
part
of
the
toc
meeting
before
we
go,
tell
the
working
groups
to
create
the
roadmaps
that
we
figure
out
what
our
guidance
is
for
the
next
release.
So
maybe
we
can
just
like
remind
ourselves
next
time
to
do
that
ahead
of
time
and
not
wait
until
after
they
start
presenting
and
they
go
wait
wait.
Actually
you
should
do
this.
J
G
I
I
guess
the
the
question.
A
question
seems
we
have
a
pretty
large
group
of
folks
here.
What
would
be
the
ideal
time
for
working
groups?
Do
people
have
opinions
like?
Is
it
a
month
before
we
ship
the
release
that
work
that's
in
flight?
Is
it
more
than
that?
Is
it
less
than
that
like?
What
would
be
the
kind
of
the
ideal
timeline
for
getting
that
guidance.
L
I
think
a
month
before
shipping
is
a
great
timeline.
That's
usually
the
feature
complete
deadline
for
or
the
branch
cutting
deadline
for
the
prior
release,
so
we're
gonna
be
busy
with
one
nine
right
up
until
that
time,
the
earliest
we
would
begin
thinking
about
110,
I
think,
would
be
up
right
after
that.
H
D
A
H
N
It
it
may
be
nice
to
do
it
even
slightly
earlier,
because
a
lot
of
times
we
have
changes
that
we
were
lined
up
for
like
the
day
or
week
after
the
branch.
So
if
there
was
something
that
was
conflicting
with
that,
it
would
be
too
late.
Usually
that's
just
cleaning
up
old
stuff,
though
so
it's
pretty
unlikely,
but
depending
on
what
you
are
going
to
recommend,
I
suppose
it
it
could
matter
like
mixer,
for
example,
we
killed
it
like
a
day
after
we
cut
the
branch.
G
Certainly,
if
you
know
that
the
counterbalance
this
is
a
working
group,
have
a
a
big
sprawling
feature
that
they're
trying
to
take
on,
and
they
want
explicit
guidance
about
when
it
would
be
good
to
take
on
the
risks
associated
with
that
within
the
project.
It's
it's
good
to
bring
that
directly
to
the
toc.
F
O
J
N
Yeah
so
kubernetes
just
something
similar
to
this,
but
I
don't
think
that
we
can
just
apply
their
policy.
I
was
trying
to
find
it.
I
couldn't
find
the
exact
details,
but
if
I
remember
writing
can't
stay
as
an
alpha
api
for
more
than
I
don't
know
some
number
of
releases,
but
unlike
us,
they
have
like
better
versioning
of
their
resources,
so
they
go
from
alpha
one.
Then
they
go
to
alpha
two.
N
N
C
J
G
C
B
C
B
D
C
J
L
C
P
A
K
J
K
Oh,
oh,
that's
yeah,
so
it
it's
a
collection
of
small.
You
know,
documentation
things
that
are
not
necessary
development,
but
but
you
know
making
sure
that
everyone
is
aware
that
features
are
you
know
state,
and
you
know
that
mesh
config
is
a
proper
way
to
configure
and
everything
else
is
not
supported,
and
it's
not
stuff
because
it's
not
really
up
an
item
that.
G
D
K
K
K
D
E
K
E
D
L
K
L
D
D
E
K
D
K
D
E
E
K
A
D
J
N
S
A
J
T
K
T
D
D
A
K
Yeah
for
for
eight
it's
it's
basically,
we
want
to
to
you
know
kind
of.
Apparently
there
are
some
weekly
builds
that
are
produced
and
we
want
to
make
sure
that
stability
is,
is
good
release
during
a
weak,
weak
tweak
to
avoid
the
big
bank
at
the
end
totally
discovers
that
symptom
broken
basic.
So
we
because
there
are
kind
of
changes
that
may
introduce
subtle,
behavior
changes,
subtle
problems,
and
we
want
to
make
sure
that
we
catch
them
faster.
So.
K
K
J
N
K
K
D
D
H
N
Q
J
N
A
A
H
Also
a
quick
question:
since
we
were
talking
about
the
promotions
of
from
alpha
to
beta
and
a
time
box,
should
we
have
another
column
that
says
path
path?
Two.
So
if,
if
a
feature
is
an
alpha,
then
path
two
would
be
beta,
then,
whatever
timeline
two
months,
whatever
I
mean,
does
that
make
sense
or
it
can
be
a
discussion
or
maybe
I
can
take
it
since
that's
the
proposal
we
thought
maybe.
A
H
H
D
A
R
G
R
A
R
D
Oliver
quick
question
before
you
move
on:
will
this
allow
users
to
specify
a
dtl
for
all
the
certificates,
because
that
functionality
at
the
higher
level
was
kind
of
taken
away?
We
have
environment
variables,
but,
like
constant
says,
we
normally
don't
want
users
to
use
environment
variables
for
those
right.
R
We
we
support
ttl
for
the
users
to
configure,
but
there
are
ways
how
to
support.
It
is
like
kind
of
changing
from
release
to
release
right,
so
we
just
need
to.
If,
if
we,
I
think
we
still
need
to
make
the
dc,
we
still
need
to
support
the
customizable
tpl,
but
how
to
support
it.
It's
a
question.
We
need
a
better
way
to
support
it.
I
agree
so.
K
D
R
D
Q
U
U
A
A
U
U
U
U
U
Yeah
the
1.8
plan,
so
we
can
change
it.
Thank
you.
Yeah
line.
5
is
a
better
support
for
josh
authentication
in
ecm
so
currently
institute.
The
standard
authentication
institute
is
to
forward
the
cognitive
charge.
Token
to
api
server,
basically
called
token
review
api,
and
we
want
to
provide
some
native
authentication
mechanism
in
sdlt.
U
This
will
work
well.
This
will
support
the
case
like
a
remote
institute
case,
in
which
case
you
cannot
hold
the
request.
Api
server
and
the
also
vm
case
will
also
be
benefit,
but
we
also
benefit
from
this,
because
the
token
you
get
is
not
this
all
not
always
kubernetes
chart
which
could
be
other
jobs.
U
J
Mimi,
I'm
I'm
also
interested
in
your
thoughts.
We
can
take
offline
for
certainly
on
the
relationship
of
this
particular
item
with
external
hd
promotion
and
how
is
it
impacting
the
existing
multi-cluster
which
we're
also
using
remote
cluster
without
hdod
inside
of
the
remote
cluster,
which
already
reaches
beta.
K
But
this
is
an
alpha
feature
supposed
to
be
an
alpha
feature
I
mean
the
rest
is
better,
so
probably
doesn't
have
any
effect,
because
we
cannot
use
alpha
in
beta.
I
mean
you
cannot,
you
cannot
depend
on
it.
Basically,
so,
even
if
it
reaches
alpha,
it's
not
something
that
external,
h2d
or
other
things
can
depend
on.
R
K
K
K
A
J
Asking
I
think
a
couple
of
us
just
come
from
steering,
so
we
look
at
what
is
the
most
important
feature
of
the
security
work
group?
Certainly
it's
neutral
tls,
so
we
would
love
to
have
your
thoughts
on
you
know.
Is
there
any
plan
to
promote
mutual
tls
from
beta
to
stable,
because
we
do
believe
that.
A
A
R
J
D
R
R
We
give
them
the
way
to
configure
through
environment
variable,
but,
yes,
there
are
missing
pieces
there.
I
think
probably
we
need
to
in
our
in
the
previous
releases.
We
can.
Users
can
still
configure
it
through
the
template
through
their
helm
and
now
it's
missing
and
we
lost
track
of
it.
It's
more
like
a
box.
R
R
G
G
G
T
K
K
K
G
R
Is
because
there
are
some
things
that
are
related
to
their
mutual
dls
itself
or
their
certificate
management.
Those
we
will
do
some
assess,
as
louis
was
saying
like
we,
we
evaluate
what's
missing
for
a
stable
and
we
promote
them
for
the
policies.
Maybe
they
mean
you
can
work
separately,
because
there
are
a
couple
of
different
things.
Maybe
you
can
prune
some
of
them
deep
demote
them
to
p1
or
p2,
and
but.
E
K
H
N
N
It's
been
a
consistent
thing
that
pops
up
every
release
are
these:
are
these
an
envoy
in
the
istio
agent?
Where
are
the
bugs
no
they're,
typically
an
envoy?
Actually
I
mean
I
would
love
to
see
the
easter
agent
code
cleaned
up
as
well,
but
it's
that's
more
of
like
a
code.
Health
than
a
convoy,
crashes
or
envoy
never
gets
certs.