►
From YouTube: Technical Oversight Committee 2021/01/15
Description
Istio's Technical Oversight Committee for January 15th, 2021.
Topics:
- How to manage untested platforms that have documentation on istio.io
- Chartering the Upgrade Working Group
- Field vs. Feature status
- CRD Status feature promotion to Beta
- Istio 2021 Roadmap planning
- Update on 1.9 Release
A
Yeah,
so
we
should
probably
make
an
announcement.
Not
everybody
knows
I
guess
so.
Dan
is
actually
ending.
He
ended
his
22
years
with
ibm
at
end
of
december
and
he
is
joining
a
new
start.
Well,
I
shouldn't
say
new:
it's
actually
cash
flow,
positive,
startup
called
digital.ai,
so
great
opportunity
for
him.
He
said
that
he
maybe
is
your
customer.
A
D
E
G
Awesome
so
community
testing
sheet,
the
test
case,
has
been
prioritized
by
all
the
working
group
leads.
So
thanks
for
working
on
it,
there
was
another
request
to
pick
three
test
cases
by
each
working
group.
Two
of
the
working
group
have
already
done
that
the
asynchronous
testing
is
starting
next
week.
So
it's
a
request
for
the
remaining
working
groups
to
please
pick
at
least
two
to
three
dots
which
needs
automation,
and
if
you
can,
please
automate
that
during
this
cycle,
then
the
fourth
one
is
going
back
to
that.
F
E
F
F
G
Awesome,
thank
you
so
much
on
the
same
line.
There
are
at
least
one
or
two
working
group
leads
which
were
which
were
missing
from
the
working
group
needs
meeting.
So
it's
a
request
that
at
least
one
of
the
working
group
lead
please
be
available
during
the
working
group
leads
meeting
okay,
so
the
next
one
is.
I
G
Okay,
okay,
let's
work
offline,
because
I
I
want
to
make
sure
all
the
working
group
leads
are
available
on
on
a
new
timing
that
everyone
is
comfortable.
So,
let's
work
off
them
thanks
costume,
the
next
one
is
features
planned
for
spo
2021.
So
this,
since
I
keep
on
hearing
the
istio,
2021
roadmap
is
going
to
be
stability.
G
B
B
G
A
Yeah
so
I'll
tell
me,
I
think
it's
definitely
helpful.
You
know
a
lot
of
users
are
wondering
and
asking,
and
so
last
year
we
published
a
roadmap
blog.
It
was
received
really
well.
Certainly
like
you
said,
not
everything
may
be
able
to
stay
on,
but
at
least
you
actually
able
to
publish
something.
That's
significant!
J
John
wasn't
actually
for
a
previous
topic,
but
I
can
comment
on
this
too.
I
think
when
I
looked
at
the
2020
roadmap,
a
lot
of
it
didn't
it
really
make
sense
to
me,
like
we
had
a
bunch
of
stuff
like
zookeeper
support
and
like
azure
functions
or
something
I
may
have
never
heard
anyone
mention
those
outside
of
the
roadmap,
but
things
like
high
level
stuff
like
we
want
to
focus
on
wasm.
I
think
that's
both
obvious
to
everyone
here,
but
could
be
useful
to
someone.
J
That's
you
know
not
following
all
their
working
group
meetings,
but
if
we
try
and
go
too
low
level
in
the
details,
then
it
probably
gets
just
way
too
far
off
like
we
know
where
we
want
to
focus
on.
We
know
we
want
to
focus
on.
You
know:
convergence
with
kubernetes
and
I
don't
know
other
you
know
broad
strokes
like
that
would
be
useful.
I
suppose.
B
B
G
Mira,
you
are
absolutely
right,
I'll
tell
you
what
happened
last
year
last
year
I
joined
in
january,
I
I
helped
create
this
roadmap.
The
gap
was,
we
never
went
back
every
quarter
and
review
that
you
know
what
has
been
done.
What
has
been
changed
so
that
has
been
a
gap
right.
Every
working
group
lead
has
done
a
great
job
in
bringing
the
representation
and
the
visibility,
but,
as
we
said,
the
gap
was
not
reviewing
it
every
quarter.
G
However,
the
the
as
lynn
mentioned
that
has
been
very
helpful
to
have
a
one-year
roadmap
published
because
people
look
at
the
steer
right.
They
want
to
see
what
is
coming
along.
However,
with
any
product,
you
cannot
imagine
that
it
has
to
be
a
setting
stone.
None
of
the
road
map
I
have
worked
in
the
past
is
actually
not
even
like
committed
after
a
quarter,
even
the
second
little
flaky.
From
that
angle
right,
I
I.
I
share
your
thoughts
on
having
a
little
detail
and
more
granule.
G
A
A
Yeah,
so
just
make
sure
you
know
what
we
published
in
the
last
year:
it's
only
high
level,
it's
nothing
detail
as
far
as
this
particular
spreadsheet.
I
don't
think
we
are
actively
exposing
the
detail
level,
especially
to
our
users,
so
it
could
be
perceived
a
little
bit
less
valuable
than
the
higher
level
strokes.
That
niraj
is
talking
here.
I
think
those
are
the
things
people
are
more
looking
for.
Must
you
have.
B
G
Yeah,
let's
do
this.
If
you
go
into
the
agenda
item,
I
have
asked
the
guidance
from
the
toc
on
the
these
right
yeah.
So
there's
a
sto
2020
roadmap
themes,
I'm
I'm
looking
for
guidance
from
the
toc.
If
you
can
get
that
high
level
guidance
on
you
know,
I'm
not
looking
beyond
four
themes
so
that
all
the
in-group
leads
can
align
their
sorry
go
ahead.
Swing.
G
G
Okay,
I
think
then,
the
right
set
of
templates,
let's
discuss
all
of
that.
I
think
that
will
be
helpful
even
for
the
working
group
leads
to
have
that
guidance,
okay,
yeah,
so
I'm
not
touching
the
future
reminder
right
now,
because
that
is
still
under
review
for
the
achievements
thanks
to
jacob
who
actually
had
put
through
this
banner.
G
However,
there
is
a
question:
if
this
is
what
would
it
was
intended,
because
we
wanted
to
put
up
the
banner
for
all
the
platforms
which
are
not
getting
tested,
or
should
we
just
remove
the
platforms
which
are
not
getting
tested
or
move
it
to
some
other
place
in
the
in
the
istio
website?
So
if
you
can
bring
up
that,
thank
you,
spain,.
F
B
B
J
B
A
Some
background
information.
I
think
we
did
discuss
this
in
one
of
the
work
group
meeting
this
year
and
the
consensus
which
I
actually
thought
from
the
toc
was
at
one
point
is,
you
know
we
want
to
show
when
was
this
particular
page?
Lastly
being
tested,
let's
say
alibaba
or
azure,
you
would
say.
Maybe
it's
your
1.1
was
lastly
tested.
L
A
F
L
M
M
A
A
B
F
B
So
I
know
for
some
of
them.
Having
like,
I
will
give
you
an
example
for
cops,
because
sto
by
default
only
works
with
third
party
projections,
and
there
was
a
period
in
which
it
wasn't
easy
to
find
out
those
options.
It
is
helpful
to
have
this
document.
You
can't
find
those
settings
after
googling
for
half
an
hour.
I
don't
know
if
that's
the
case
like
there
is
some
requirement
in
sdo
which
necessitates
some
of
these
setups.
If
not,
then
this
looks
like
pure
vendor
platform
setup
to
me.
H
We
should
fix
that.
I
mean
we
should
figure
out
why
it
doesn't
work
and
try
to
fix
it.
Can
you
keep
only
the
stuff
that
is
different?
I
mean
go
over
the
documentation
and
remove
everything
that
is
not
it's
just
I
mean
if
you
need
it,
it's
hard
to
find
what
is
described
by
niraj
in
the
sea
of
instructions,
how
to
set
up
properties.
B
A
I
know
yeah,
I
think
I
would
be
okay
to
have
the
instructions
as
long
as
the
current.
So
how
about
this?
For
people
we
know
who
are
testing
these
platform.
We
make
them
first
citizen
for
the
ones
who
are
not
like
niraj
said
we
put
them
all
under
something
like
unsupported
or
untested,
so
they
would
be
like
a
third.
You
know
a
second
level
citizen
I'll.
B
H
L
Yeah
that
sounds
good.
The
other
thing
was
that
I
was
trying
to
use
the
boilerplate
like
like
a
functionality,
so
I
had
tried
to
include
the
specific
date
in
the
warning,
but
then
I
was
kind
of
instructed,
like
you
know,
please
use
a
book
because
otherwise
it
was
just
like
copied
and
pasted
like
on
different.
You
know
docker
and,
like
you
know
the
other
ones,
so
that's
fine.
Let's
just
keep
that
in
mind.
F
Yeah,
I
was,
I
was
actually
wondering
if
we
want
someone
to
go
through
these
and
figure
out
like
how
to
clean
them
up
just
because,
ideally,
these
would
be
you
know,
create
your
cluster
like
here
are
the
differences.
You
need
to
do
the
things
you
need
to
think
about
when
creating
a
cluster
on
environment
x
platform
x.
If
you
want
to
install
seo
right
like
here,
are
the
requirements
rather
than
just
all
the
instructions
right
like
we
shouldn't
have
copies
of
how
to
install
a
cluster.
F
Instead
of
this
other
step
or
something
so,
someone
would
need
to
go
through
and
figure
out
how
to
clean
all
those
up.
Alternatively,
we
could
just
say:
hey:
these
are
just
vendor
the
vendors
own.
These
they
decide
what
they
want
to
put
there
and
we
don't
care,
but
then
they'll
just
keep
getting
out
of
deep.
F
A
No,
it's
actually
just
tell
you,
how
do
you
deploy
iks
cluster
and
make
sure
your
cluster
is
big
enough?
The
the
one
that
I
think
is
most
useful
is
actually
the
openshift
one,
because
I
just
went
suited
this
week.
What
they
did
a
nice
job
is
they
didn't
tell
you
how
to
stand
up.
Openshift,
like
you
guys
said
all
they
said
is
these
are
the
additional
things
that.
F
D
B
F
B
B
G
E
E
G
B
F
K
F
K
However,
we
we
we
kind
of
ran
into
the
issue.
We
we
we've
kind
of
brushed
by
it
a
couple
times,
but
I
think
it's
about
time.
We
actually
address
it
like
we're,
not
really
feeling
we're
dealing
with
future
status.
At
this
level,
at
least,
we
don't
feel
like
we
are
we're
dealing
with
one
particular
knob.
That
might
be
a
part
of
a
greater
feature,
calling
a
feature
status
is
kind
of
conflating
and
two
things
and
ultimately
ends
up
being
confusing.
K
During
discussions,
it's
been
confusing
during
our
discussion,
so
so
I've
been
proposing
that
we
we
call
this
something
different,
be
it
field
status
or
whatever
we
decide.
However,
that
brings
its
own
baggage,
because
you
know,
then
we
need
yet
another
progression
defined
a
process
for
progressing
individual
fields
through
some
sort
of
graduation
process.
K
And
so
that
that
means
that
basically
every
single
knob,
we
call
a
feature.
So
that
means
we
have
this
incredibly
long
list
of
features
in
istio
and
and
that
that's
that's,
that's
going
to
be.
In
my
opinion,
that's
going
to
be
hard
to
elevate
to
the
user
like
how
is
the
user
going
to
make
sense
of
every
single
knob
being
a
feature
of
istio?
K
I
I
don't
see
a
third
option.
Maybe
there
is
one,
but
I
kind
of
I
kind
of
feel
like
those
are
our
two
paths
to
go
with
all
this
if
if
the
granularity
is
per
field,
as
as
we've
been
doing
so
as
we've
been
assuming
so
far,
then
I
feel
like
these
are
the
two
options,
but
I'm
I'm
just
kind
of
going
to
leave
that
open
for.
B
K
B
So
you
want
to
signal
to
the
user
that
that
particular
subfield
is
different
in
maturity
compared
to
the
overall
encompassing
thing
right.
That's
one
use
case,
the
other
you,
the
other
use
case
in
terms
of
annotations
is
this
is
the
only
way
to
know
the
maturity
of
that
field,
because
there
is
no
outer
housing
to
tell
you
right.
B
K
That
that's
specifically
true
of
labels
and
annotations
right,
there's
no
greater
context.
I
mean
one
thing
we
could
do
is
we
could
certainly
link
to
the
field.
Assuming
that
there's
a
you
know,
a
one-to-one
between
field
and
feature
that
it
controls,
which
I
think
is
probably
a
fair
assumption.
Then
we
can
certainly
make
a
link
to
hey
here's
the
feature,
maybe
a
link
to
the
website,
showing
the
feature
status
of
the
feature
it's
controlling,
but
that
that
that
wouldn't
tell
you
that
this,
oh
by
the
way.
B
B
K
I
mean
I
would
assume
that's
true
anytime,
you,
you
know,
maybe
change
the
the
configuration
for
something
you
know
you
might,
you
might
say,
deprecate
an
old
field
in
favor
of
a
new
field
yeah.
Something
like
that
right,
like
that.
That
sort
of
stuff
happens
a
lot
there's
a
little
bit
of
api
churn,
especially
if
it's
not
stable
yet,
but
but
it
might
be
like
beta
and
but
but
this
this
new
thing
is
experimental.
D
F
I'm
wondering
here,
if
we're
going
about
this
a
little
bit
the
wrong
way.
That's
my
goal,
if
we
just
so
forget
about
feature
status
for
a
second.
So
if
we
look
at
our
like
reference
for
our
apis
right,
we
have.
We
have
apis.
Each
resource
has
a
maturity
level
and
then
we're
saying
that's
not
fine-grained
enough.
F
F
B
B
A
F
I
F
B
H
How
about
how
about
just
just
removing
anything
that
is
alpha,
because
most
users
should
not
even
see
that
if
it's
something
that
it's
not
stable,
why
would
they
care,
I
mean,
put
it
in
a
wiki
or
put
it
somewhere
else,
and
you
know
just
assume
that
every
single
ship
is
used
usable
in
production
and
and
everything
that
is
not
ready.
Yet
is
not
confusing
users,
because
we
don't
want
people
to
use
alpha
stuff.
Well,.
H
Sure,
but
there
is
a
wiki
they
can
use.
I
mean
the
documentation.
The
official
documentation
studio
should
reflect
things
that
the
production
user
should
use
safely,
not
what
a
developer
or
someone
who
wants
to
experiment,
or
to
I
mean
it's
one
thing
to
have
it
in
in
the
you
know,
doc
comments
you
know
and
and
some
developer
site
or
or
someplace,
where
people
who
want
to
experiment
use
it's
another
thing
to.
If
I'm
a
user
of
history,
I
go
to
the
site,
and
I
get
stuff
that
I
can
no,
I
can
use
not.
A
F
B
F
F
K
Is
it
the
avenue?
Is
it
the
same
enumeration
that
we
currently
have
today
for
feature
status?
Experimental
alpha,
beta,
stable
api's
got
it
in
the
same
type
of
maturity
level,
yes,
okay,
same
same
maturity,
levels
and,
and
then
we
also
have
deprecated
and
retired
tired,
but
but
I
think
we're
gonna
track
those
separately
so
that
we
we
actually
have
historic
information
of
what
the
final
api
status
was
before
it
was
deprecated
or
retired.
Anyway,
that's
a
that's
a
detail.
We
can.
H
K
F
D
K
F
K
B
K
G
D
C
C
The
only
checkboxes
that
are
not
checked
at
this
point
are
either
related
to
documentation,
which
I
don't
want
to
change
until
it's
confirmed
that
it
can
be
beta.
I
don't
want
to
like
publish
that
it's
beta,
if
you
guys,
aren't
going
to
approve
it
and
certain
test
cases
that
will
begin
to
be
covered
when
this
is
enabled
by
default.
D
O
J
J
C
J
M
B
H
C
Yeah,
so
we've
we've
limited
the
number
of
requests.
This
will
make
on
the
api
server
concurrently
in
such
a
way
that
it,
the
gke
and
kubernetes
scalability
sig,
signed
off
on
our
architecture
as
well
as
it
limits
the
impact
on
sdod.
So
we
don't
just
like
build
up
an
indefinite
go
routine
or
an
indefinite
list.
We're
capped
at
how
big
this
this
queue
will
become
so
in
cases
where
we
get
overloaded
with
and-
and
it
takes
a
lot
to
overload
this
system.
C
F
D
F
D
C
Once
this
feature
is
enabled
by
default
in
istio,
which
which
it
has
to
be
beta
in
order
to
do
it
will
be
covered
by
the
stability
stress
test
suite.
I
have
run
through
the
stress
test
suite
manually
with
this
feature
enabled
and
it's
stable,
okay
and
that's
the
isotope
stress
test
with
the
three
name:
spaces
of
20
pods
each
and
only
one
instance
of
sdod.
H
So
you
want
both
beta
and
to
make
it
default,
I
mean,
can
we
at
least
let
user
opt
in
if
they
want
this
feature
enabled
because
I
don't
think
everyone.
My
question
is:
most
people
do
not
look
at
status
and,
and-
and
you
know
it's
not
something
that
is
easy
automatically
for
debugging
and
understands
other
tools
for
debugging
and
and
I
I
I
can
live
with-
having
it
better
and
but
but
having
it
on
by
default
for
everyone.
Even
if
people
don't
use
it
doesn't
seem
reasonable.
C
H
B
C
C
B
H
H
J
H
E
C
C
E
F
H
F
F
P
Effectively,
if
we
backward
right
so
so,
I
think
I
think
that
if
we,
if
we
turn
it
on
by
default
for
all
the
tests
today,
do
we
have
enough
time
until
one
line
goes
out
to
say:
okay
leave
it
that
way,
and
it's
fine
or
we
can
have
a
last-minute
pr
that
says:
okay,
flip
it
back
to
to
off
so
is
there?
Is
it
enough
time?
Is
that.
H
P
I
know
yeah
right,
the
the
the
most
tractable
simple
mechanism
to
actually
do.
That
is
turn
it
on
default
by
default
today
or
like
to
do
it
and
test.
But
it's
simpler
to
just
turn
on
by
default
today,
and
we
can
flip
it
back
if
it
doesn't
pass
the
pass
all
our
gates
by
release
date
and
if
it
does
pass,
but
but
it
has
to
be
deliberate,
so
the
the
the
risk
is
if
it
cannot
just
slip
in
and
say,
oh
well,
so
yeah,
so
it
has
to
be
deliberate
yeah.
I
think.
J
C
Yeah,
so
this
has
been
in
ci
testing
since
one
six,
the
tests
are
part
of
the
regular
pre-submit
gate
and
k-native
has
been
working
on
on
adopting
this
feature
for
about
three
months
now.
The
actually
the
bug
that
you
and
I
are
working
on
right
now,
john-
that
pull
request
is,
is
blocking
their
particular
adoption.
J
Yeah
for
the
testing,
I
did
not
mean
that
testing
of
the
feature
I
mean
using
this
in
our
test,
like
the
whole
point
of
the
feature,
is
so
that
users
can
deploy
a
virtual
service
and
then
wait
for
it
and
then
do
something
right,
which
is
what
all
of
our
tests
do.
That
was
kind
of
one
of
the
motivations
for
the
feature,
but
as
far
as
I
know,
we're
not
actually
doing
that
in
our
own
tests,
like
we're
testing
the
feature
in
isolation,
but
we
have
hundreds
of
tests
that
apply
configms
than
traffic.
C
F
A
J
F
I
did
want
to
talk
about
the
2020
roadmap
thing
that
we
said
we'd
get
to
later,
so
we
don't
have
time
to
go
into
too
many
details,
but
schweda-
and
I
and
louis
were
talking
about
this
earlier
this
week
and
we
wanted
to
see
if,
if
someone
in
toc
wanted
to
take
the
lead
on
kind
of
driving,
the
overall
themes
for
2021
and
the
roadmap,
we
didn't,
we
didn't
want
to
take
that
by
default.
So
if
anyone
else
is
interested
now's,
the
time.