►
From YouTube: Technical Oversight Committee 2021/07/12
Description
Istio's Technical Oversight Committee for July 12th, 2021.
Topics:
- Welcome John and Brian as new TOC members
- Istio 1.11 Feature Freeze
- Compatibility Flags
A
D
C
F
A
A
F
Yeah
we
do
so.
We
have
the
telemetry
api
implementation.
It's
roughly
halfway
done
right
now,
some
of
it's
already
merged
some
of
it's
not
yet
merged.
It
may
be
good
to
get.
I
don't
think
we
need
to
delay
the
freeze,
but
it
may
be
good
to
get
an
exception
to
kind
of
backward
that
in
once
it's
merged.
It
should
be
new
functionality
really,
so
it
shouldn't
be
too
risky,
hopefully,
or
if
it
is,
we
will
make
sure
to
de-risk
it,
and
the
other
thing
is
the
wasm
api.
H
G
D
D
I
I
think
we
don't
want
a
broken
experience,
even
if
it's
alpha
right.
So
my
question
here
is:
if
you're
rushing
the
implementation
like
what's
the
trade-off
here
since
it's
additive
and
the
api
pr,
I
think,
is
merged,
I
don't
remember,
is
it
okay
to
have
the
implementation
come
out
in
a
patch
release,
or,
though,
is
this
too
much?
A
I
J
A
D
H
D
D
D
D
I
H
D
H
Okay
and
then
then,
I
think
that
the
second
thing
that
I
think
needed
you
raised
about
the
api
goes
in
and
yeah
it's
declared
kind
of
usable
in
the
past
release,
it
seems
seems
weird,
but
it
solves
this
problem,
so
I
like,
I
would
like
to
get
other
people's
thoughts
on
this
as
well
like.
What's
the
it
definitely
circumvents
some
rules,
but
does
it
also
circumvent
the
spirit
of
the
rules?
That's
the
question.
K
Yeah
is
there
any
reason
to
you
know
ship
with
this
particular
data,
very
important
feature
in
911
that
we
must
ship
or
is
just
we
got
three
years
ago.
We
started
to
release
every
x
months
and
we
kept
doing
it
without
you
know
realizing
why
we
are
why
we
are
doing
it.
I
mean
what,
if
we
just
delay
one
month
release
and
then
get
everything
in
a
good
shape,
and
will
the
user
benefit
from
having
another
upgrade
that
does
not
matter
it's
an
important
api.
That's.
D
I
think
that's
a
valid
question
question
I
was
going
to
raise
this
up
myself
in
general.
I
believe
having
some
predictability
in
the
release.
Cadence
is
good
for
the
community
in
the
phase
vr
right
just
so
that
people
don't
have
to
understand.
Okay,
is
this
really
this
push
like?
If
you
make
a
conscious
choice,
the
release
is
late
because
of
stuffing
or
some
critical
bugs
that's
a
different
asian.
If
you
fall
into
the
pattern
of
x,
number
of
features
need
to
go
in
and
as
long
as
they
don't
go
in
the
release
is
getting
pushed.
D
J
Not
clear
that
that
matters,
it
does
envy's
support
policy.
If
we
were
to
move
to
a
four-month
release
cadence,
we
would
not
be
able
to
stay
within
a
supported
envoy
release
in
each
of
our
shipments,
and
we
explored
that
brian
avery
and
I
did
in
the
document
for
extended
support
releases.
I
think
it's
in
the
test
and
release
working
group
folder.
If
you
wanted
to
follow
up
on
it.
D
A
G
F
These
days,
it's
it's
pretty
rare,
like
we
find
you
know
very
localized
bugs
sometimes
they're
fairly
impactful,
but
they're
still
like
this
happens
on
egress
gateway
with
the
re-tries,
or
something
like
that,
like
very
localized,
just
because
their
test
coverage
is
better
to
answer
schweda's
question.
These
new
features
would
be
you
know
experimental,
so
we
either
have
no
docs
officially
or
they
would
be
probably
untested
initially.
F
A
A
Well,
we
can
make
the
decision
right
right.
So
that's
that's
the
other
thing
if
we're
happy
with
the
test
coverage,
if
it's
met
all
the
requirements
for
alpha
right,
so
the
concern
was
community
testing
finding
a
bug
caused
by
these
two
exceptions,
given
that
both
of
these
things
happen
in
the
processing
flow
of
the
control
plane,
they're
pretty
well
covered
by
the
automation.
At
this
point.
D
A
H
Yeah
the
api
dock
in
both
these
cases
is
actually
like
fairly
comprehensive.
Maybe
we
could
add
a
little
bit
towards
them,
so
so
the
the
api
log
itself
is
enough
for
people
to
get
started,
especially
those
that
are
interested.
So
so
I
think
I
think
that
we
can
definitely
like
having
a
proper
doc
separate
dog
just
from
the
api
doc.
I
don't
think,
is
a
requirement
to
get
some
mileage
out
of
this
okay.
A
I
think
we
can
somewhat
short
circuit.
This
conversation
lena
had
a
timeline
expectation
right.
We
have
another
toc
meeting
next
week.
Okay,
I
would
suggest
that
we
check
in
on
the
state
of
this
and
that
if
it
looks
like
it's
going
to
go
beyond
next
week,
then
maybe
we
don't
allow
it
right.
So
what
do
other
toc
members
think
about
a
week
to
get
the
feature
and
the
implementations
checked
in
with
their.
F
Tests
that
sounds
fine
to
me,
but
I
want
to
make
sure
who,
like
what
are
we
actually
blocked
on
on
the
telemetry
api?
I
think
it's
mostly
reviewing
of
the
pr
on
the
wasm.
I
think
it's
review
of
the
api,
so
that
would
be
the
toc
blocking
for
now
and
then
review
the
implementation
once
that's
through.
Is
that
accurate?
F
E
So
yeah,
I
think
that
that's
reasonable.
I
I
remember,
I
think
it
was
a
week
or
two
amanda,
you
hold
a
meeting
and
you
invite
us
to
we'll
give
you
the
final
feedback
on
the
tonometry
api.
So
if
you
need
such
a
thing
for
wasm
feel
free,
just
let
us
know
because
we
don't
want
to
block
you
also,
because
I
do
find
out
having
a
meeting
to
discuss
is
actually
really
helpful.
Then
just
you
know,
comment
on
the
pr
and
then
two
days
later,
you
know
we
forgot
to
follow
up.
A
H
C
A
G
G
G
A
H
H
The
the
fact
that
the
request
came
means
that
the
three
release
thing
wasn't
enough
right
and-
and
both
these
were,
I
mean-
are
actually
like
good,
specific
examples
of
especially
the
use
legacy
selectors,
so
so
yeah.
So
the
request
was
that,
can
we
can
we
keep
the
compatible
behavior
longer
than
just
two
or
three
releases
or
three,
which
is
what
it's
today.
H
So
use
legacy,
selectors
change,
the
behavior
of
how
of
which,
when
sidecars
energy
injected
so
in
the
in
the
new
behavior.
Even
if
you
don't
have
the
name
space
marked
for
sidecar
injection,
but
you
have
a
workload
mark
for
sidecar
injection,
then
it
will
work
in
in
the
new
behavior,
whereas
in
the
old
one
you
had
to
have
the
name
space
selected.
D
K
K
F
F
I
mean
it
was
over
three
releases,
but
it's
more
aggressive
than
say
the
original
destination
change
process
is
because
it's
like
the
only
way
it
could
be
impacted
is,
if
you
happen
to
put
a
label
that
does
nothing
on
a
pod
and
then
like
you,
have
to
also
put
in
a
namespace
that
has
a
weird
labeling
setup.
It's
like
this
incredibly
bespoke
configuration
that
it
could
impact
you.
So
while
I
do
agree
that
for
impactful
changes
like
the
inbound
cluster
one,
we
should
definitely
keep
it
around
longer.
F
D
F
We
shouldn't
focus
on
just
one
customer,
but
in
this
particular
case
it's
actually
not
that
they
want
to
stay
on
older
versions,
but
that
they
want
to
upgrade
new
versions
but
turn
off
certain
changes
in
that
version
so
that
they
can
more
quickly
upgrade
without
having
to
handle.
Everybody
can
change
at
once.
So
like
they'll,.
F
D
K
That
that
happens-
and
you
it's
very
hard
to
predict
and
people
will
be
nervous
about
upgrading
they'll,
stick
with
old
version
longer
than
necessary,
because
they're
scared
that
the
new
operator
breaks
them
and
then
so
on,
and
we
keep
the
cycle
of.
I
mean
until
we
have
a
clear
beta
apis
that
that
is
an
and
and
we
we
are
clear
that
only
better
icbps
are
supported
in
reality.
All
alpha
apis
are,
you
know,
used
by
people.
F
F
It's
just
you
know
an
if
statement
in
the
code
and
it's
not
that
big
of
a
deal,
but
once
you
add
you
know
10
20
of
these
flags,
then
over
time
they
kind
of
start
to
accumulate
some
in
the
past,
we've
had
ones
that
are
extremely
high
cost,
but
we
don't
currently
have
any
of
those
active
now,
but
I
could
see,
for
example,
once
we
add
some
like
bts
or
I
don't
that's
the
only
example
I
can
think
of
in
the
future.
We'll
probably
have
some
of
these.
K
E
A
H
H
F
F
K
One
more
thing
I
want
to
add
here:
we
are
also
discussing
the
tags
and
and
introducing
a
new
new
mechanism
to
selection
and
and
other
things,
so
maybe
just
wait
until
we
have
the
replacement
in
place,
stable
and
move
to
better
and
and
clearly
you
know
we
used
before
we
delete
so
and
then
we
can
or
wholesale
delete
the
whole
selection.
If
you
want.
A
H
Afford
it,
okay,
so
so
so
one
actually
that
there
are
a
couple
of
things
right.
One
is
sort
of
this
policy
decision
forward.
Looking
of
what
should
the
guideline
be,
right
is
three
releases
enough
or
should
we
just
say
you
know
what
the
standard
is?
Five
releases
four
releases
and
if
we
need
to
make
it
sooner,
then
then
that's
an
exception
and
then
we
can
bring
it
to
the
toc
and
say
yes,
why
do
we
need
to
remove
this
code
earlier?
H
A
A
H
You
can
just
have
instruction
that
says
hey
when
you
upgrade
use
this
flag
and
that's
it.
There
is
no
there's
no
decision
point,
whereas
you
run
the
tool
and
if
you
are
like,
if
you
are
affected,
then
you
go
fix
it
now
and
then
you,
then
you
come
back
after
you
fix
and
you
install
it
again.
So
I
think
that
I
mean
yeah,
that's
that's
what
I
suspected
it
would
be
that.
K
I
I
would
remind
her
that
that
you
know
people
running
manual,
easter
cattle,
to
install
whatever
is
not
something
that
works
everywhere,
because
there
are
managed.
You
know,
versions
where,
where
the
students
is
automatically
upgraded
and
and
users
main
stories
are
never
touched
again,
because
they
expect
someone
else
to
manage
it
for
them
and
this
kind
of
stuff.
K
I
mean
in
this
particular
case,
it's
not
a
problem,
because
because
it's
values-
and
it's
specific
to
to
to
this
new
cattle,
install
an
operator
that
installs
not
but
for
any
features
in
mesh,
config
and
anywhere,
where
you
know
it's
not
installer
only.
I
think
it's
super
dangerous
for
because
a
lot
of
people
do
not
actually
install
themselves
for-
or
there
are
many
teams
and
it's
very
complicated-
that
would
still
be
something
that
the
control
plane
operator
could
run.
Wouldn't
it
cost
him?
K
D
D
D
A
H
K
Can
I
mention
an
alternative
solution
to
this
problem,
which
we
briefly
discussed,
which
is
to
give
power
to
the
users?
Basically,
I
mean
like
we
do
with
gateways
and
other
things
where
we
let
them
control
the
web
hooks.
However,
this
is
it
we
already
kind
of
have
a
stable
protocol.
It's
pretty
clear
how
it
works,
and
you
know
there
are
some
samples
charts
we
can
provide,
and
then
they
can
control
label
injection
to
their.
You
know,
whatever
they
feel
necessary
for
their
cluster.
A
A
H
For
most
users,
it
would
represent
additional
unwanted
burden
right,
like
the
the
way
it
is
today
actually
works
for
kind
of
many
most
users.
So
if
we
say
that
now
it's
your
responsibility
and
they
haven't
actually
considered
it
a
problem
to
begin
with,
I
I
think
I
think,
having
an
option
for
advanced
users.
That's.
K
No,
it
doesn't
solve
a
preference
for
serious
users
who
have
this
kind
of
concerns
because
hey
you
have
this
helm
chart
that
you
apply.
You
can
customize
if
you
need
it
and
it
deserves
all
behavior.
We
don't
have
to
to
to
put
it
part
of
the
main
code.
We
just
provided
hey
for
backward
compatibility,
user
job
just
apply
this
chart
and
you
have
the
behavior
that
we
had
in
the
past
or
apply
this
other
and
you
can
customize
to
have
label
foobar.
Do
the
same
thing.
K
E
D
D
You
shouldn't
make
exceptions
to
that
without
an
approval
from
toc
right.
So
that's
the
first
thing
second
thing
is,
in
my
opinion,
whether
we
should
extend
this
to
four
releases
or
five
releases
or
six
digits.
I
don't
have
enough
signals
to
say
four
is
the
right
magic
number
here,
but
I
do
think
on
a
case-by-case
basis.
We
should
be
able
to
extend
for
few
backward
compatibility
options
to
more
releases
or
say
you
know
what
the
cost
is
fairly
low,
magically
fairly
low
and
we're
gonna
not
remove
it
at
all.
D
But
I
don't
think
generically
in
my,
at
least
in
my
mind,
we
should
just
say
it's
four
or
five
until
we
have
more
information,
and
the
third
is
the
specific
issue
that
you
brought
up,
this
one
is
interesting.
I
don't
know
I'm
still
thinking
about
it.
I
don't
have
a
good
answer
yet
someone
let
others
talk
about
it.
H
Okay,
so
so
this,
so
we
can,
I
mean
it's,
it's
okay.
We
like
we
can
think
about
this
offline
asynchronously
on
on
the
dock.
But
now
everyone
knows
what
the
what
the
issue
is
there
is,
I
mean
like
one
or
two
weeks
is
fine.
There
is
no
actually
sorry
if
we
decide
that
we
need
to
bring
back
use
legacy.
Selectors,
yeah.
H
D
Yeah,
I'm
just
worried
about
the
running
state
and
john.
You
can
correct
me
so
basically,
I
have
no
name
space
annotation
and
currently
I
did
my
check
all
none
of
my
parts
in
the
name
space
I
don't
want
psycho
injected,
have
the
injection
labels,
but
then
in
future
somebody
adds
it
now
that
pod
will
get
the
sidecar
injected,
because
I
had
not
explicitly
disabled
it
on
the
namespace.
F
F
F
E
E
F
E
Okay,
yeah,
I
I
mean
I
don't
see
any
breakage
issues
honestly,
but
I
do
recall.
I've
spent
a
lot
of
time
learning
the
differences
and
the
impact
for
the
user
about
the
months
ago.
Now
I
can't
remember
most
of
it
I
so
it's
complicated
that
that's
the
key
takeaway
for
me.
It's
like
many
scenarios.
People
have
to
think
through
and
then
probably
perform
a
lot
of
testing
to
make
sure
you
know
their
existing
behavior
are
not
impacted.
E
K
And
lynn,
thank
you.
That's
I
completely
agree
with
you.
I
mean
the
statement
that
it's
complicated.
It's
absolutely
correct
in
this
kind
of
situation.
That's
that's
why
I
think
you
know
having
giving
users
a
chat
and
explaining
them
how
they
can
set
a
simple
label
that
they
control
and
they
don't
have
to
understand,
very
complicated
helm
chart.
You
know
templates,
maybe
better
for
some
users,
because
I
don't
think
anyone
I
mean
except
john.
Probably
nobody
fully
understand
all
the
combinations
and
options
and
interactions
that
exist.
H
F
D
F
F
K
K
F
F
D
H
I
think
that
yeah,
so
the
two
will
be
useful,
but
just
some
guidance
on
how
they
can
change
the
yaml
files
to
get
the
old
behavior
would
actually
be
just
as
or
or
kind
of
more
useful
here,
because
then
that,
then
that
moves
us
to.
I
think
what
costume
was
saying
earlier,
which
is
that,
okay,
if
you
need
something
different
or
more
okay
here,
you
can
use
this
other
part.