►
From YouTube: Technical Oversight Committee 2021/10/11
Description
Istio's Technical Oversight Committee for October 11th, 2021.
Topics:
- Handling periodic test failures
- Graduating Multicluster to Stable
- Reworking working group meetings
A
B
C
D
A
A
E
B
G
We
don't
have
a
really
good
way
of
improperly
escalating
test
failures
in
the
periodic
jobs
on
the
you
know,
just
making
sure
they
get
to
people
that
can
actually
fix
them,
and
so
we
wanted
to
bring
this
question
up
to
the
toc,
which
is
just
kind
of
how
do
we
want
to
go
about
distributing
test
failure?
Notifications
for
these
kind
of
jobs?
G
I
I
know
that
you
know:
we've
have
the
ability
to
kind
of
direct
each
class
of
failure
to
different
locations,
but
it's
unclear
whether
we
want
to
you
know
direct
these
to
a
mailing
list.
You
know
for
each
group
directed
to
a
big
bucket
mailing
list,
but
typically
gets
ignored
or
start
like
selecting
people
to
send
them
to,
or
if
this
should
be
something
that
each
of
the
working
groups
should
cover
before
they
start
their
normal
course
of
business.
They
go
look
through
any.
G
I
I
believe
they
are
the
test
failures
that
are
in
this
live
channel.
The
problem
is
that
they're
so
like
that
that's
just
kind
of
a
bot
channel
and
the
way
that
that's
typically
handled
as
people
just
ignore
the
bot
channels,
and
so
there
are
different
ways
to
handle
it
like.
We
could
redirect
that
to
a
mailing
list
as
well
as
the
bot
channel,
or
we
could
have
it.
G
So,
potentially
you
know,
rather
than
throwing
all
of
the
issues
into
the
same
bot
channel
it
detects
like
you
know,
potentially
what
type
of
error
it
is
and
sends
it
to
the
main
channel
for
whatever
that
kind
of
like
group
like
area
of
responsibility,
is
so
like.
If
you
have
a
networking
test,
it
will
go
to
like
a
networking
channel
and
just
you
know,
paste
the
post
there
or
something
like
that.
G
F
G
F
Yeah,
I
usually
do
too,
but-
and
sometimes
I
will
tag
people
on
some.
If
I
know
it's
a
particular
group,
but
it
appears
that
that's
not
adequate
enough
and
I
guess
I'm
curious
if
we
would
remap
some
of
them.
For
example,
security,
tested
a
security
channel.
Would
that
or
you
know
some
to
the
networking
channel?
Would
that
cause
somebody
to
look
at
that
more
or
not.
G
A
G
H
E
E
A
C
J
E
J
C
J
Sure
I
cannot
agree
with
you.
I
mean
it's,
it's
it's
a
problem
that
we
are
mixing
too
many
things
in
one
feature
and
and
we
document
multi-cluster
and
flood
networks
or
multi-network
in
the
same
time,
and
because
it's
confusing
for
the
user
to
to
is
that
completely
orthogonal
features
a
minute.
One
is
networking
and
the
other
one
is
multi-class.
You
can
have
one
without
the
other.
A
I
J
Yeah,
I
mean
it's
first
of
all,
lack
of
support
for
for
stateful
sets,
which
is
big
abysmal
and
cannot
be
fixed
until
you
change
the
protocol.
Second
is
the
security,
because
you
have
to
expose
a
public
id
and
from
that
public
you
can
reach
pretty
much
everything
and
that's
scary.
For
some
people
and
again
it
cannot
be
fixed
without
the
multi-clustered
ingress
or
significant
changes.
So
it's
it's
not
even
close.
In
my
opinion,
it
works,
but
it's
you
know
with
limitations.
I
C
I
C
J
To
be
honest,
I
don't
I
don't
even
know
if
multi-primary
is
something
that
we
need
to
mention
because
it's
you
know
it's
a
normal
way
of
supporting
to
install
istio.
The
separate
feature
is
remote.
I
mean
you're
using
issue
remotely,
basically,
but
that's
not
related
multiculturalistic
readings
of
the
discovery,
the
secrets
and
and
the
endpoints
from
other
clusters.
That's
really
the
core
feature.
J
D
E
D
K
D
Mechanisms
to
do
that
that
we
don't
really
have
documented
and
we
have
like
different
things
that
have
trade-offs.
I
think
I
describe
that
towards
the
top
of
this,
so
I
just
want
to
add
a
document
for
that
and
also
document
things
like
our
staple
set
and
headless
support,
because
it
confuses
people
a
little
bit
and
then
their
last
thing
is
probably
documenting
how
to
use
the
bug
report
tool
with
multi-clusters
some
people
do
it
right
and
some
people
just
assume
to
do
once.
E
J
On
the
first
one
as
a
cluster.local,
there
is
some
you
know,
instability
coming
with
the
multi-cluster
ingress
naming
and
sorry
the
kubernetes
multi-cluster,
and
they
have
slightly
different
name.
Would
it
make
sense
to
keep
this
as
beta
until
kubernetes
replacement
is
ready,
not
necessarily
connected?
I
mean
multi-cluster
doesn't
necessarily
require
this
cluster
to
local
special
routing.
D
J
C
A
Yeah
so
from
my
perspective,
I
do
think
calling
this
multi-cluster
multi-primary
is
very
confusing
because
I
think,
given
a
lot
of
our
users
are
using
multi-network
they're
going
to
assume
this
is
multi-primary.
Multi
multi-cluster
reach
stable,
but
the
reality
is
not.
Maybe
we
could
clarify.
This
is
only
for
flat
network
even
somewhere
in
the
title,
just
to
be
super
clear
to
our
user.
E
E
J
Maybe
being
more
precise
about
what
it
is,
I
mean
multi-cluster
defined
as
discovery
of
endpoints
in
multiple
clusters
or
routing
to
enhance
multiple
class
without
mentioning
that
its
primary
remote
network.
The
feature
is
actually
just
that
these
two
is
looking
for
endpoints
from
other
clusters.
That's
really
what
it
is.
J
J
C
Yeah,
we
just
need
that
clarity
in
the
documentation.
That's
it
that's.
Why
I'm
saying
directionally,
I'm
okay
with
it,
let's
see
in
the
docs.
How
are
you
gonna
mention
this?
So
it's
not
confusing
right,
we
can
say
multi-cluster
discovery
is
getting
promoted
and
permutation.
These
permutations
now
are
stable
and
these
are
not,
but
just
we
have
to
be
clear
about
it.
That's
what
I
think,
let's
say.
J
F
H
Yep,
so
we
were
looking
at
sort
of
working
group
meeting
attendance
and
I
I
I
also
kind
of
looked
at
how
much
how
many
things
were
on
the
agenda,
how
many
meetings
got
cancelled
and
that
kind
of
stuff.
So
the
past
four
months
there
were
17
possible
meetings
and
extensions
and
telemetry
met
seven
times
out
of
fish.
Realistically,
we
could
have
consolidated
it
even
more,
because
yeah
security
only
met
three
times:
ux
12
and
then
ember
environments
and
networking
made
most
of
their
full
quota.
H
Even
though,
in
the
past
month
networking
has
had
two
calculations,
so
there
is
a
there's
kind
of
a
directional
thing
that
that
we
need
to
look
at
and
then
there's
also
one
or
two
specific
things
that
that
we
want
to
do
so.
One
is
that
we
want
to
now:
rework
the
extensions
and
telemetry
with
rooting
into
the
networking
meeting
itself,
so
so
that
many
times
the
discussions
are
aligned,
like
all
the
api
discussions
and
their
implementation,
and
all
that
that's
very
closely
delivered
to
that
working
anyway.
H
What
group
should
look
at
this
closely
is
that
it
seems
that
even
security
meeting
could
be
folded
into
the
environment.
But
that's
just
that's
just
a
strong
observation
that
I
have
so
someone
from
security
should
look
at
that
sure.
Security
can
also
go
in
networking
like
the
customer's
saying
either
way
either
way
is
fine,
so
the
the
reason
why
we
should
look
at
these
two
consolidations
is
that
it
it
increases.
H
I
H
F
K
K
Particular
thing
for
like
ent
and
networking
combining,
but
I
would
think
like
security
environments,
they
don't
really
have
anything
related
to
each
other
and
I
think
you
could
end
up
driving
attendance
even
lower
for
one
of
them,
just
if
they're
meeting
it
regularly
unless
there
was
like
a
schedule
that
got
changed.
But,
like
you
spurs
the
meetings,
I
think
it's
just
going
to
be
a
hodgepodge.
J
K
C
H
Actually
I
I,
I
cannot
speak
for
security,
so
I
hope
someone
from
security
says
something
here,
but
for
for
ent
there
is,
there
is
slightly
less
than
than
before
for
for
sure
and
the
kinds
of
work
that
is,
there
is
now
even
more
closely
tied
with
networking,
so
some
of
the
other
work
on
like
open,
telemetry
and
kind
of
that.
That
is
starting
again
and
that's
not
strictly
related
just
just
to
networking.
H
L
It's
almost
been
more
effective
to
have
out
of
band
meetings
anyways,
and
so,
when
appropriate,
having
ad
hoc
meetings
for
design
and
discussion
related,
specifically
telemetry
to
the
parties
that
are
interested,
I
think,
is
probably
better
than
having
weekly
meetings
where
there's
three
people
sort
of
talking
to
themselves
again.
So
I
I
would
be
in
favor
of
switching
the
meeting
cadence
that
way.
I
I
H
M
Yeah,
to
be
honest,
I
think
there
are
security
meetings.
It's
just
we
don't
have
many
agendas
to
discuss.
I
think
a
lot
of
those
issues
are
like
resolved
through
some
other
channels,
so
yeah,
that's
why
like,
unless
we
have
some
like
big
designs
to
discuss
or
like
load
maps,
otherwise
we
just
thought
we
could.
We
can
solve
it
offline.
We
don't
need
to
like
put
it
into
agenda.
I
think
that's
most
of
the
reason
yeah.
So
in
terms
of
immerging
this
into
networking-
I
I
don't.
M
M
M
If
we
like
merge
them
together,
it
could
make
the
networking
meeting
a
little
bit
longer,
which
I
think,
I'm
not
sure
if
the
current
networking
meeting
is
already
pretty
long.
If
you
want
to
do
that,
but
if
we
are
the
networking
meeting
right
now
is
okay,
we
could
merge
and
that
will
be
more
efficient.
M
I
M
I
H
Yeah
yeah
so
yeah.
So
this
this
was
kind
of
yeah.
I
I
raised
it
because
it
potentially
affects
the
whole
structure,
but
right
now
it's
just
kind
of
between
extension,
telemetry
networking
and
then
also
between
the
security
network,
and
I
think
so
we
we
will
already
make
the
change
then
for
ent
networking
and
then
once
oliver
can
get
back.
H
H
I
C
I
I
mean
this
feels
like
just
making
sure
we
have
the
right
combination
of
meetings
to
maximize
attendance,
eyeballs
and
minimize
time
waste
here
right.
So
if
there
are
any
combination
of
two
two
or
three
meetings
a
week
where
we
can
get
more
people,
let's
just
do
it
and
yeah
more
like,
like
only
what
you
said,
I
mean
like,
we
were
saying
most
of
the
security
meetings.
Only
get
cancellation
updates,
I'm
guessing
ent
is
having
less
attendance
like
daggerman.
That
said,
so
I'm
fine
with
this.
M
Yeah,
I
think
we
can
make
it
like
flex
flexible.
I
don't
know
if
we
can
just
keep
the
slot
and
say
in
our
meeting
notes.
We
just
say
temporarily:
we
are
merging
this
security
meeting
into
networking
and
then
we
just
resolve
everything
the
networking
meeting
and
like
maybe
after
a
few
months,
we
feel
oh,
there
might
be
a
need
for
a
like
security
meeting
and
then
we
just
add
an
item
there
and
and
we
consume.
We
like
restart
this
resume.
This
secure
meeting
just
make
it
flexible.
M
I
E
B
B
F
And
I'll
make
one
comment,
and
I
haven't
looked
at
it
yet,
but
I
did
see
after
I
got
back
that
the
correct
istio.io
testing
against
the
master
branch
is
against.
The
current
master
branch
is
failing.
I
think
we
moved
up.
I
want
to
say
two
weeks
ago
and
got
everything
fixed
and
running,
but
I
think
when
I
was
out
on
vacation
things
broke
again
and
I
haven't
looked
to
see
what
the
failure
is.
So
some
of
the
test
cases
are
broken,
so
we'll
want
to
work
on
getting
those
fixed
as
well.