►
From YouTube: Technical Oversight Committee 2020/10/30
Description
Istio's Technical Oversight Committee for October 30th, 2020.
Topics:
- Release blockers for 1.8
- Doc testing for 1.8 and improvements for 1.9
- What versions of Kubernetes to support for 1.8
- RFC for locality label
- Release Manager nominations for 1.9
B
D
E
B
Actually,
I
think
in
the
past,
though,
it's
good
to
do
a
prioritization
pass
to
see
which
one
of
these
are
really
p
zeros.
I
I
think
what
I've
seen
in
the
past
is
that
we
tend
to
copy
the
priorities
from
the
prior
release
and
really
it
should
be
more
about
what's
changed,
or
what
do
we
expect
to
require
additional
scrutiny.
C
E
Also
frank
from
dev
working
group
leader
mentioned
that
the
test
cases
which
are
automated
and
say
it's
done-
we
need
attention
there
as
well,
so
it's
good
to
test
them
as
well.
So
I'm
not
quite
sure
what
your
suggestions
are
there
like
we
are
trying
to
automate
them,
but
I
think
frank
also
mentioned
some
of
them
do
get
into
issues.
So
do
we
want
to
test
them
manually
as
well?
That
is
something
I
would
like
to
bring
up.
F
G
H
H
G
A
A
E
Yeah
we
can
do
that
also
if
they
want
to
work
offline
like
we
have
requested
it,
but
if
they
can
review
it
offline,
that
will
be
great.
Otherwise
we
can
use
the
work.
It's
just
that
it's
30
minutes.
It's
not
everyone
is
there,
so
we
can
do
it
offline.
Otherwise,
I
will
repeat
it
again
in
the
working
room.
B
E
B
What
I'd
like
to
understand
is
what
wasn't
actually
tested
in
week,
one:
where
are
the
gaps
you
know
so
basically,
this
this
list
is
is
too
big.
I'd
like
to
scope
it
down
to
the
true
p
zeros,
and
also
make
sure
that
we're
not
read.
You
know
redundantly
testing
stuff
that
was
already
done
in
week,
one
which
is
the
separate
tab.
A
H
D
H
D
H
I
guess
I
can
see
that
for
maybe
upgrade
pages
which
we
typically
have
issues,
but
maybe
for
tasks.
You
know
if
it's
the
same,
and
the
primary
purpose
of
the
task
is
to
execute
the
steps
it
would
be.
You
know
it
would
be
lower
priority
really,
in
my
opinion,
to
have
a
human
to
manually
review
those.
A
D
So
historically,
these
p
zeros
reflected,
I
think,
either
they
were
untested
or
historically
we
have
found
many
many
issues
with
that
particular
doc
page.
I
think
possibly
automation
negates
that,
possibly
not
depending
on
how
good
the
automation
is
right.
So
I
don't
know
if
you're
still
finding
bugs
in
that
dock.
A
A
E
I
think
the
best
one
is
automate
do
not
release
until
all
the
p0s
at
least
are
automated
obvious.
I
mean
it
will
take
some
time.
I
know
it's
brutal,
but
at
least
it
will
get
it
done
like
had
hands
on
heads
down
on
automation,
for
one
week
complete
like
stop
the
release
take
one
week
off
and
just
automate
all
the
p
zeros
at
least.
E
D
A
G
Let's
get
those
done
so
we
don't.
We
actually
had
this
discussion
with
sean
in
the
docs
meeting.
I
think
last
week,
and
you
know
the
funny
thing
is
a
lot
of
our
documentation.
Isn't
exactly
testable,
because
it's
just
saying,
oh
you
can
you
can
do
this
to
do
this
thing.
You
know
there's
no
verification
or
anything
like
that.
G
So
a
lot
of
our
a
lot
of
the
docs
that
are
reference
config
are
are
in
that
category,
so
I'm
I'm
actually
taking
the
approach
for
locality,
load,
balancing
which,
which
was
in
that
form
prior,
so
I'm
actually
doing
the
heavy
lifting
I'm
actually.
Turning
that
into
an
actual
real
task.
Where
I
can,
I
can
you
know,
say,
do
this
do
this?
Do
this?
Do
this
and
then
you
know
verify
so
we
can
actually
write
a
test
for
it,
so
I
suspect
you
know
I
mean
that's
obviously
heavy
lifting
right.
A
Yeah,
so
I'm
wondering
if
someone
can
help
put
together
a
prioritized
list
of
those
and
then
we
can
actually
try
to
get
people
to
sign
up
to
do
that.
Work
right,
it's
like
so,
rather
than
a
scramble
towards
the
end
of
each
release.
It's
as
part
of
the
release.
We
have
a
backlog
of
things
that
need
to
get
automated
and
we
automate.
You
know
the
top
ten
percent
or
whatever.
I
I
I
B
A
A
A
E
I
think
it's
a
good
idea,
since
all
all
of
your
working
group
leads
have
started
working
on
the
roadmaps,
so
this
is
a
perfect
time
to
add
it.
However,
I
would
request
for
all
the
test
cases
if
we
have
the
ownership
of
the
working
group
currently
like.
I
do
not
know
which
test
cases
belongs
to
which
working
group,
which
is
a
problem,
then
how
do
we
distribute
or
or
if
it
is
anybody
can
pick
up
anything
then
it's
fine
with
me.
H
J
D
I
can
I've
been
helping
doug
out
for
this.
If
he's
not
online,
we
are
in
a
reasonable
spot
with
where
this
proposal
is.
We
have
been
a
lot
of
back
and
forth
to
massage
it
so
yeah.
I
think
what
you
said
much
makes
sense.
Let's
review
it
offline,
bring
make
sure
all
the
other
members
are.
Okay
with
it
add
comments,
and
then
next
week
probably
do
a
a
short
presentation:
doug,
I'm
speaking
for
you
and
signing
up
for.
G
E
So
swain
one
thing
on
this
one:
this
comes
every
release
around
the
end
of
the
release,
right
which
kubernetes
version
to
support,
and
we
spend
a
lot
of
time.
Is
there
a
way
we
can
produce
a
doctor?
I
think
john
created
one,
but
that
was
offline,
but
this
comes
up
like
every
time.
We
start
the
testing.
F
Oh,
we
made
the
dock
and
then
we
approved
the
dock,
and
then
we
decided
that
it
wasn't
a
good
idea.
So
we,
I
guess
we
need
to
re,
I
mean
we
can
take
the
dock
and
just
change
the
numbers
around,
but
we
need
to
have
a
consensus
on
what
versions
we
want
to
support,
which
we
don't
really
have
right
now.
H
A
H
D
A
F
D
H
F
I
I
don't
think,
there's
that
much
the
the
main
downside
is.
I
think
it
may
be
odd
if
we
were
to
say
we
support
115
now,
but
then
say
the
next
release.
We
say
we
only
support
118
to
120.,
like
that
would
be
a
huge
jump
which
I
don't
think
would
be
a
good
idea,
so
we're
kind
of
if
we
do
it
once
we're
kind
of
permanently
sticking
us
at
least
slightly
delayed,
which
maybe
is
a
good
thing.
B
H
B
D
D
B
H
B
K
I
B
I
D
B
D
I
A
D
B
I
That's
where
that's
where
that's,
where
the
the
I
mean.
First
of
all,
they
can
install
straight
in
150
and
see
so
if
they
have
kubernetes
115,
they
don't
have
to
move
they
just
installed,
and
the
alpha
or
development
style
cross
version
migration
would
allow
them
even
to
move
from
from
one
point
because
they
can
install
crash.
It
is,
you
could
actually
say,
yeah.
I
B
I
We
actually
use
a
bottle
for
testing.
I
mean
you're
saying
for
some
features:
okay,
do
the
manual
testing
for
other
feature,
it's
okay
to
have
the
stuff
what
we
are
doing
today
for
115,
and
but
now
we
are
saying
that
we
want
to
have
all
the
tests
everywhere
automated
for
150.
I
mean
we
need
to
be
realistic
and
pragmatic.
Here
it's
so.
I
H
I
D
D
I
D
A
A
A
Okay,
so
like,
if
someone
finds
a
cbe
right
like
the
person
fixing,
the
cv
does
not
have
to
go
back
toward
that
right.
Okay,
all
right!
It's!
Okay!
It's
okay!
For
people
on
the
team
to
break
it;
and
if
people
want
to
support
it
like
it's
on
the
person
supporting
it
to
go,
fix
that
right,
it's
not
on
the
person
breaking!
It
makes
sense
thanks.
So.
A
A
I
D
A
D
A
G
Are
you
okay,
yeah
yeah,
so
this
came
out
of
some
work
that
I've
been
doing
to
write
tasks
for
locality
load
balancing.
I
wanted
an
easy
way
to
have
the
user
just
kind
of
like
configure
various
pods
that
were
just
in
whatever
clusters.
Maybe
it's
kind
that
that
they
don't
have
like
locality
or
whatever.
So
I'm
kind
of
building
on
like
a
two
cluster
scenario,
where
we
actually
deploy
four
pods
and
put
them
in
different
zones
and
regions.
G
Load
balancing
it's
just,
allowing
you
to
basically
set
locality
for
a
pod
which,
which
is
a
very
nice
feature.
It
already
exists
today.
We
it
already.
So
let
me
let
me
let
me
say
that
this
already
today,
but
it's
a
hidden
api,
it's
not
public.
I,
the
the
trick
was:
is
that
I'm
writing
this
doc
that
I
want
to
be
public
and
it
would
be
awkward
to
use
a
a
label
that
we
don't
officially
document
anywhere.
G
So
it
seems
like
you
know,
we
need
to
pop
that
up
to
like
an
actual
api,
okay,
so
that
I
can
actually
document
it
and
feel
comfortable
that
you
know
I'm
not
doing
something.
You
know
magical
that
that
isn't
clearly
documented
somewhere,
so
so
anyway,
this
there
are
a
few
use
cases.
We
talked
about
a
network
working
group
meeting
yesterday,
so
I'll
just
go
through
the
the
use
cases.
So
as
a
service
owner,
I
want
to
assign
locality
for
my
workload
instances.
G
G
So
similarly
number
two
as
a
service
owner,
I
want
to
override
kubernetes
provider
provided
locality
for
my
workload
and
also
I
do
not
have
permission
to
set
the
node
labels
so
similarly
to
number
one
and
then
finally
number
three
as
as
a
developer
or
a
service
owner.
I
I
just
want
to
test
istio
locality
without
having
to
rely
on
that.
Muckety-Muck
of
you
know
actually
having
real
regions
and
real
zones,
and
you
know
which
is
effectively
the
use
case,
I'm
in
with
my
my
task.
G
So
so
it
does
have
valid
use
cases.
The
the
name
of
the
label
today
is
istio-locality,
however,
putting
it
in
the
api,
as
that
looks
a
little
awkward
because
we
don't
use
that
kind
of
form.
So
I
propose
topology.istio.io
locality.
We
don't
currently
document
anywhere
on
this
uio
the
old
label
at
all
anyway,
so
I'm
not
even
sure
if
we're
telling
users
ever
to
use
this
thing,
I
suspect
it's
only
been
there
for
our
internal
testing
to
this
point.
There
may
be
a
few
people
using
it.
G
D
G
B
B
A
J
C
B
A
G
The
one
thing
I
want
to
say
about
all
this
is
I
I
in
the
process
of
all
this.
I
realize
that
we're
actually
not
currently
documenting
labels,
the
same
ways
we
do
annotations.
We
actually
have
the
special
kind
of
like
processing.
We
do
to
generate
html
for
all
of
our
our
annotations
and
I
I
basically
want
to
just
do
the
same
thing
for
our
labels.
We
we
have
labels
under
istio
api
that
are
currently
they're.
G
Just
you
know,
manually
entered
fields
while
annotations
are
put
in
a
yaml
and
we
auto
generate
go
code
and
html
for
them.
So
I
want
to
do
something
similar,
maybe
for
1
8,
if
possible,
so
I'm
actually
working
on
a
pr
for
that
as
well.
The
other
the
other
bit
is
in
doing
that.
I
realized
that
there
are
a
few
annotations
in
in
the
api
that
begin
with
alpha
dot.
G
G
D
You
have
alpha
labels
by
vendors
like
ingress,
so
it's
a
rat's
nest
and
I
think,
as
far
as
I
know,
kubernetes
does
not
schematize
or
formalize
annotations,
and
last
I
chatted
with
louis
in
istio.
We
were
trying
to
be
similar
where
formal
apis
start
from
mesh
config
and
then
the
crds
that
we
have
so
either.
We
say
our
annotations
are
always
alpha
and
at
some
point
we'll
formalize
it
in
a
proper
api
or
we
just
remove
them.
A
G
Routing
so
so
I
have
a
suggestion,
so
we
do
have
this
like
auto
generation
of
html.
I
you
know
from
a
user's
perspective.
I
think,
starting
with
alpha
dot
as
a
name
and
then
having
to
change
is
just
a
huge
pain
right.
So
I
I
I
mean
we
have
this
table.
We
can
just
add
a
column
to
the
table
and
and
add
to
the
to
the
yaml
like
we
can
specify
manually
what
feature
level
it
is.
A
We
can
we
could
treat
this
the
same
way.
We
are
trying
to
treat
like
new
fields
in
existing
apis
that
are
maybe
alpha
right.
The
same
kind
of
thing
where
you're
saying
we're
not
going
to
call
the
field
like
alpha
underscore
something
we're
just
going
to
use
the
name
for
it,
but
we're
going
to
indicate
in
comments
or
whatever
that
that's
an
alpha
field.
A
H
So
back
to
your
requirement,
I
think
the
question
we
had
on
the
networking
world
group
yesterday
was,
when
you
don't
have
permission
to
set
your
note
label.
Wouldn't
it
be
reasonable
to
ask
your
admin
to
do
that,
for
you.
Do
you
think
your
admin
would
actually
want
you
to
specify
locality
yourself
as
a
service
owner?
Wouldn't
that
makes
more
sense
to
have
the
admin
to
give
the
proper
node
enabled,
so
it
still
can
automatically
discover
the
node
label
for
you
and
figure
out
the
topology
for
you,
I'm
trying
to
understand.
H
G
F
D
F
Yeah
to
even
go
further,
like
one
thing
that
I've
heard
about
our
dos
is
negative,
is
that
we
provide
a
bunch
of
examples
and
not
a
bunch
of
explanation
of
how
things
work
is
the
real
end
goal
that
you
can
go
and
copy
and
paste
a
bunch
of
commands
and
it
works,
or
that
you
actually
understand
what's
going
on
like
do?
We
really
need
a
copy
and
pastable.
F
C
F
G
F
G
G
F
We're
writing
things
that
are
not
these
simple
copy
space
demo
book
info
things
like,
for
example,
cert
manager.
We
have
a
document
on
how
to
provision
a
real
certificate
with
back
media
and
stuff.
We
don't
have
a
doc
test
for
that,
because
it's
somewhat
hard
to
test.
Instead,
we
need
to
explain
how
to
do
it
and
we
give
them
examples.
We
point
to
the
documentation,
but
it's
not
a
copying
tasteful
task.
F
G
A
G
We're
dealing
with
time,
though,
right,
like
our
tests,
are
running
in
kind.
Sorry
and
that's
what
we
do
we're
gonna
need
so
right
right
now
for
multiple,
we
create
three
clusters,
but
you
know
you
don't
know
what
node
things
are
going
to
be
assigned
to.
So
you
can't
you
know
what
I
mean
like
I
mean
we
could
we
could
just
we
could
just
not
document
the
label
and
actually
use
it
under
the
covers
that
that's
what.
A
A
Under
the
cover,
when
we
deployed
it,
sounds
like
something
we
should
see
if
we
can
fix
in
the
way
that
we're
setting
up
our
tests
separately,
like
we
should
see
if
it's
fixable
in
the
test
to
have
different
nodes
and
being
able
to
like
you
know
this
cl
these
this
cluster
on
this
set
of
nodes,
and
this
cluster's
on
this
is
the
nodes
and
the
nodes
have
different
labels.
So
we
should
test
that
question
here
is:
why
did
we
have
this
label
in
the
first
place?
Was
it
just
for
testing
or
was
it
like?
I
But
what
I
want
to
say
is
that
this
kind
of
feature
shows
that
we
need
some
way
to
run
this
for
real
infrastructure,
where
you
know
some,
some
jiggy
and
and
azure
and
so
forth
provides
a
label.
Officially,
we
have
some
clusters
where
we
don't
have
the
label,
so
we
need.
We
need
to
find
a
way
to
test.
Also
an
infrastructure,
I
know
kind
is
running
most
of
the
tests.
F
I
A
Another
relationship
hold
up
because
that's
the
same
thing
that
gk
does
yeah
go
ahead,
so
this
discussion
is
not
about
how
to
do
our
testing
right.
This
discussion
is
about
what
should
be
like.
Should
there
be
a
public
api
for
overriding
locality
on
a
basis
right,
like
the
user
question,
we
can
try
separately
right
like
we
shouldn't.
We
shouldn't
mix
these
two
things,
so
things
should
be
about
whether
this
should
be
a
public
api
and
the
question.
A
D
So
I
think
that's
what
we
have
the
meeting
yesterday
ended
networking
working
group
write
down
the
use
cases
and
then
we
should
evaluate
what
to
do.
Maybe
nathan,
you
have
it
in
the
use
case
here.
I
could
didn't
get
a
chance
to
see
your
doc
from
yesterday's
meeting,
but
unless
you
need
it
in
one
eight
I
would
say:
let's
just
go
back
networking
working
group
with
your
dog
there.
I
don't
think
it
needs
an
doc
approval.
Just
yet.
G
A
E
F
A
A
A
A
J
F
F
A
E
D
B
E
D
B
H
H
E
Yeah,
I
think
we
can
also
add
the
release
manager
responsibilities
because,
for
example,
every
release
I
meet
with
the
release
managers
every
week
and
we
do
a
lot
of
improvements.
I
don't
think
that's
reflected,
so
we
should
add
those
responsibilities
while
they're
becoming
a
release
manager.
What
else
is
coming
for
them?.