►
From YouTube: Technical Oversight Committee 2021/03/12
Description
Istio's Technical Oversight Committee for March 12th, 2021.
Topics:
- Environments 2021 and 1.10 Roadmap presentations
- Approval of Oliver Liu to PSWG
- Discussion of how to improve communication channels for contributors
- Discussion of tooling to help users know what features are Alpha/Experimental
A
B
We
follow
up
with
folks
from
kubernetes
who
have
a
pretty
good
system
in
place
for
kind
of
having
a
pipeline
of
release,
managers,
doing
shadows,
managing
the
entire
process,
thanking
people
promoting
their
efforts,
that
kind
of
stuff
swag
so
and
swag
yeah,
giving
them
gifts
of
bribes
depending
on
how
you
look
at
it.
So
I
think
april
was
going
to
reach
out
to
you
with
someone
from
the
kubernetes
community
that
could
give
some
advice
and
suggestions
to
help
us
arrange
that.
D
G
A
A
A
C
C
Also
there's
a
there's.
A
couple
of
features
actually
with
one
of
them
is,
is
here
but
there's
there's
some
other
other
ux
improvements
that
we
have
planned,
but
label
stability
is,
is
a
major
one
that
users
have
asked
for,
and
that's
that's
a
feature.
That's
well
on
the
way,
at
least
it's
in
in
terms
of
development.
C
C
We
came
close
to
getting
it
to
beta
we're
going
to
try
again
vms
it's
it's
at
beta.
I
think
in
terms
of
feature
completeness,
it's
pretty
good,
but
there's
quite
a
lot
of
work
to
be
done
with
usability
and
and
debuggability
and
so
on,
but
that's
a
major
area
for
istio,
so
we
we
do
want
to
put
a
significant
effort
behind
it
to
get
it
to
stable
by
the
end
of
the
year
operator.
C
So
that's
been
in
beta
for
quite
some
time
and
it's
probably
time
to
try
to
get
it
to
stable,
which
we'll
try
to
do
in
the
next
release.
I
guess
also
multi-cluster
has
been
around
for
for
quite
some
time
and
it's
in
beta.
It's
been
in
beta
for
an
awfully
long
time,
so
it's
time
to
try
to
get
it
to
stable
as
well.
C
And
finally,
we
we've
had
some
soak
with
home
v3,
it's
been
in
alpha
for
a
while,
and
we
know
that
there's
quite
a
lot
of
user
demand
in
seeing
this
installation
and
upgrade
method
being
you
know,
you
know
fully
supported
and
and
fully
endorsed
states.
So
that's
also
something
that
we're
going
to
target
for
beta
in
q2.
H
J
C
Yeah,
so
so,
actually,
the
common
theme
in
in
this
road
map
and
110
as
you'll
see
is
that
quite
a
few
of
these
features
have
significant
development
cycles
already
behind
them
and
are
in
a
internally
functioning
state.
But
more
work
is
required
to
get
them
in
a
usable
state
to
for
casual
users
to
to
be
able
to
use
easily.
H
I
H
J
A
So
I
I
have
two
a
couple
of
questions
about
helm,
so
one-
and
maybe
I've
missed
the
artifact,
but
how
do
we
expect
helm
to
interact
with
revision
based
upgrade
and
the
second
part
and
they're
probably
related
questions?
Is
we're
obviously
wanting
to
build
tooling
to
help
users
evaluate
the
state
of
their
cluster
prior
to
an
upgrade
right?
If
there
are
api,
usages
or
other
things,
that
they've
done,
customizations,
etc,
that
might
put
them
at
risk
from
breakage
when
they
perform
an
upgrade,
and
so
how
does
helm
interact
with
that.
J
It's
you
pass
the
parameter,
revision
and,
and
then
it
works
as
intended
for
for
label
stability.
We
there
are
some
additional
steps
that
will
probably
be
performed
with
your
cattle
to
trigger
the
rollout
and,
and
you
know,
kind
of
switching
from
one
to
a
traffic
shift.
Basically,
now
pre
checks
are
usually
the
equator
analyzer
and
similar
tools
that
need
to
be
done
manually
by
user
ahead
of
time.
J
J
No,
but
helm
is
just
a
way
to
say
hey.
I
have
this
revision
that
I
installed
and
I'm
100
sure
that
is
not
going
to
attach
anything
else
in
the
cluster.
Now,
when
you
want
to
shift
for
the
new
revisions,
that's
when,
when
different
tooling
came
into
place,
but
coming
out
of
the
picture
at
that
point.
C
A
Right
because
I
mean
tying
in
the
validation
into
istio
couple,
install
instio
couple
upgrade
or
operator
behavior
right
is
something
that
we
can
make
not.
We
can
make
declarative
and
not
a
documentation
test.
So
if
there's
a
way
that
we
can
achieve
a
similar
effect
with
helm
all
right,
it
would
at
least
be
worthwhile.
J
C
Yeah,
so
whatever
we
can't
do
in
helm,
I
I
think
it
makes
sense
to
add
to
istio
cuddle.
You
know,
probably
at
some
point
once
you
start
involve
involving,
is
your
cuddle.
It
it
takes
away
from
some
of
the
benefits
of
of
using
purely
helm,
but
so,
as
far
as
possible,
I
think
we
should.
We
should
try
to
push
those
type
of
features
into
helm
itself,
but
where
it
where
it
stops
to
make
sense,
I
I
guess
we
can
have
a
fallback
plan
of
having
istio
cattle
support
for
it.
J
A
I
mean
I
mean
any
complex
validation,
right
or
recommendations
about
pre-work
people
might
need
to
do
before
performing
an
upgrade
like
that's
a
lot
of
work,
and
so
we
can
probably
only
afford
to
put
that
in
istio
cattle
in
one
place.
I
don't
think
we
can
afford
to
implement
that
many
times.
We've
found
that
very
hard
in
the
past,
so.
A
F
Sense
to
me
I
wouldn't
want
to
add.
I
would
like
to
see
like
the
progression
for
revision
based
upgrades,
because
if
I'm
looking
at
the
dark
now
like
multiple
revision
with
gateway
is
experimental,
and
I
notice
that
the
future
promotion
you
had
for
a
different
feature,
but
not
with
revision
based
upgrade,
especially
this
is
the
one
we
are
promoting
everybody
to
move
to.
C
J
J
F
F
F
J
B
B
F
J
I
I
I
my
take
is
that
what
we
are
promoting
is
what
people
are
currently
using.
You
know
production
and
with
with
it
is
tested,
I
mean
the
features
that
are
case.
We
need
to
identify
them
and
mark
some
force,
but
the
fact
that
you
can
have
the
same
service
same
name
spacing
across
multiple
clusters
and
it's
load
balanced
and
everything
works.
That's
kind
of
the
core
feature
in
multi
cluster.
M
Yeah
yeah,
so,
like
the
question
of
apis,
I
think
the
api
that
we've
been
talking
about
so
far
has
been,
like
the
istio
operator
crd
effectively
that
that's
what
we're
using
to
configure
during
installation,
so
installation
effectively
in
configuration.
An
initial
configuration
of
multi
cluster
is
what
we're
getting
mcs
doesn't
cover.
M
B
H
J
J
A
I
tend
to
agree
with
carsten
right,
that's
kind
of
been
a
baseline
proposition
right.
Obviously,
mcs
from
kubernetes
is
changing
things,
and
so
we
have
to
maybe
have
some
refinement
of
our
definition,
where
what
dns
names
actually
mean
and
right,
whether
we
want
right,
we
treated
multi-cluster
as
a
load
balancing
problem
initially
not
as
a
name
partitioning
problem,
what
mcs
treated
it
as
a
name,
partitioning
problem
right
so
now
do
we
consider
that
the
existence
of
mcs
sufficient
for
us
to
change
our
approach
or
not.
B
J
B
J
C
G
J
C
C
C
I
think
I
think
generally
it's
right
now,
it's
it's
more
of
a
making
what's
already
there,
which
is,
which
is
pretty
functional,
more
usable
to
casual
users
and
just
making
it
more
amenable
to
production
environments
as
far
as
debuggability
and
just
understanding
where
logs
come
from
and
so
on.
So
that's.
C
J
It's
a
proposal
we
discussed
some
time
ago
and
and
it's
it's
it's
about
providing
integration
with
some
message:
bus
system,
either
kubernetes
events
or
or
or
other
pub
subs
to
allow
users
to
have
control
over
what's
happening.
Besides
the
control
plate
to
have
some
some
information
when,
when
events
happen
in
the
control
plane,
nothing
and
it
helps
for
for
the
capability
for
use
cases
like
a
native
or
other
applications
that
want
to
know
when
a
particular
change
has
been
propagated
and
for
automation,
rules
and
other
things.
J
I
C
Right
yeah,
so
so
I
think
I
think
this
is
something
that
that
kosten
has
already
done
quite
a
lot
of
work
and,
and
it
may
be,
it
may
be
a
stretch
goal.
I
I
think
it's
more
of
an
aspirational
goal,
any
work
that
we
we
do
towards
this,
I
think,
will
be-
will
be
beneficial
anyway,
even
if
even
if
we
can't
have
you
know
daily
releases
that
are
perfect
of
master,
I
think
work
towards
this
is
is
valuable.
J
J
C
C
C
C
J
I
I
would
add
that
one
of
the
biggest
challenges
that
we
confused
users
a
lot
about
mesh
config
stability,
mesh
config,
is
an
alpha
api
and
almost
everything
inside
mesh
config
is
not
something
that
is
considered
to
be
stable
or
a
stable
feature.
And
always
the
plan
was
to
have
you
know
better
apis
that
are
supported
and
alpha
apis.
That
are
kind
of
you
know.
Subject
to
change,
obviously,
is
no
guarantees
made,
but
user
expectations
are
different.
So
that's
really
the
main
challenge
and
cleaning
up
mech.
L
L
F
L
N
Yeah,
so
I
have
a
couple
of
things
here:
the
first
one
here
is
right
now
for
the
release:
management-
stuff,
we
say
tag
say
jasmine
when
a
release
is
ready
to
post
it.
On
twitter
jasmine's
been
the
point
of
contact,
we
don't
actually
have
a
group
and
the
list
changes
often
enough
that
it
can
be
hard
to
figure
out
how
to
get
things
posted.
So
my
proposal
is,
we
create
a
group
on
github
that
you
can
just
tag
and
say:
hey
release
is
going
out.
L
F
G
N
N
P
L
D
D
H
L
D
L
E
L
N
The
next
one
here
is
at
least
intestine
release
we're
seeing
the
number
of
attendees
to
the
work
group
drop.
We're
also
looking
through
the
work
groups
list.
There
is
currently
every
work
group
except
for
security,
is
missing,
leads
and
we've
got
release,
manager,
issues
and
other
issues.
Kubernetes
has
a
twitter
that
they
use
for
communicating
with
contributors
as
well
as
a
mailing
list.
B
Yeah,
I
kind
of
feel
like
the
one
pushing
us
not
to
have
mailing
lists
was
martin
and
he's
long
gone,
so
we
should.
We
should
have
a
contributor's
mailing
list
and
use
it.
I
I
have
not
found
discuss
as
a
useful
replacement
just
because
of
the
way
it
sends
mail.
You
kind
of
can't
filter.
Okay,
it
just
doesn't
work
out
for
me,
so
I'd
rather
have.
L
B
L
L
D
L
Q
L
L
Q
L
L
Q
F
L
G
Q
H
Q
H
L
Also,
just
in
the
interest
of
time,
I
do
want
to
get
to
the
ux
working
group
roadmap
because
we're
not
going
to
build
to
review
it
with
mitch's
vacation
plans,
so
maybe
for
this
one.
We
just
stick
to
the
reviewing
comments
on
the
pr
and
if
somebody
wants
a
champion,
you
should
discuss
them
in
the
future.
We're
open
to
that.
N
B
L
L
O
O
O
O
We
really
feel,
like
other
working
groups,
understand
the
rules
of
istio
much
better
than
we
do
we're
not
subject
matter
experts
here
and
so
we're
going
to
be
holding
some
workshops
on
analyzer
writing
and
making
sure
that
our
documentation
is
up-to-date
and
accessible
for
our
users
and
sort
of
we're,
even
kind
of
considering
maybe
like
a
hackathon
model
of
encouraging
people
to
show
up
and
contribute
analyzers
to
help
our
users.
Is
it
possible.
L
O
It's
more
of
a
blank
decision.
It's
absolutely
wrong
and
cannot
evaluate
multiple
objects
because
of
eventual
consistency.
I
was
working
with
john
howard
on
there's.
There
is
the
ability
now
for
validation,
to
produce
warnings,
and
I
think
john
was
working
on
making
sure
that
our
analyzers
produce
warnings
and
validation
as
well,
but
that's
not
part
of
the
ux
roadmap,
necessarily.
Q
Yeah,
so
what
I,
what
I
do
actually
think
is
important
is
there
are
a
lot
of
analyzers
that
do
work
on
single
resources
and
those
don't
get
run
in
the
validating
web
hook.
So
we
have
warnings
that
are
omitted,
but
they're
only
the
warnings
that
are
written
in
the
validation
logic,
and
then
we
have
like
the
same
type
of
things
going
on
in
the
analyzers,
but
those
don't
show
up
in
the
web
books.
So
we
kind
of
have
a
split
brain.
Q
That
would
be
something
that
would
be
be
great
to
resolve.
Yeah.
We
we
should
be
like
you
forget,
you
know,
pushing
out
more
analyzers
it'd,
be
good
to
make
sure
like
the
analyzer
core
functionality
is
because
you
know
as
we.
If
we
get
15
analyzers,
then
we
have
to
go
migrate
them
over
to
something
else
that
kind
of
sucks
yeah.
We
we.
O
Should
look
through
the
catalog
and
make
sure
that
all
of
the
analyzers
that
exist
should
be
analyzers,
and
so
I
would
assume
that
that's
part
of
the
the
march
towards
beta,
if
we
have
a
decision
that
could
be
done
at
validation
time
and
could
actually
block
the
cr,
that's
a
much
better
user
experience
than
telling
them
after
the
fact
cool
all
right.
Next
up,
we
in
2020,
we
came
up
with
the
istio
roles
and
personas
document
that
we
presented
here
a
few
months
ago.
O
We've
seen
it
be
helpful
for
a
few
design
processes
across
the
project,
but
it
still
doesn't
have
what
I
would
call
consensus
where
people
are
thinking
in
terms
of
these
roles
in
their
designs
frequently.
So
this
is
sort
of
an
advocacy
line
item
to
help
to
either
modify
the
rules
in
a
way
to
make
them
more
helpful
or
to
help
other
user
groups
or
user
working
groups.
O
K
Talking
this
morning,
sure
we
we
me
some
of
the
commands
that
talk
to
the
control
plane
are
rapidly
having
the
door
closed
on
them
by
the
external
studio
work.
So
we're
going
to
make
it
much
more
clear
which
commands
are
which
in
perhaps
even
separate
it
out
so
there'll,
be
some
commands
that
only
cloud
providers
can
run.
O
Today,
our
troubleshooting
tools
have
mixed
to
no
functionality
in
those
environments
because
they
rely
on
administrative
access
to
the
control
plane.
So
we
need
to
move
away
from
that.
We
also
are
going
to
be
rethinking
some
of
our
troubleshooting
operations
and
retooling
it
more
around
the
user.
As
we
go
about
doing
this,
our
debug
tools
today,
we've
mentioned
this
before
they're
very
much
oriented
towards
root
causes.
If
you
know
the
root
cause,
then
of
your
problem
then
run
this
tool
and
you'll
be
able
to
validate
that
it's
the
root
cause.
O
O
O
I
think,
but
we
also
would
like
to
move
the
research
forward
in
the
latter
half
of
the
year
and
start
seeing
how
we're
doing
at
the
day,
two
operations,
which
is
what
we've
sort
of
themed
the
whole
projects
year
around,
and
I
I
believe
this
tvd
is
likely
to
be
fulfilled
by
google.
It
sounds
like
we
have
a
ux
researcher
who
will
be
putting
some
time
towards
this
effort.
So
that's
great
cool.
O
O
O
O
This
is
the
ability
for
users
to
understand
the
maturity
of
the
various
levers
they're
pulling
on
istio
and
I'm
using
the
word
levers
which
we've
not
defined
very
particularly
because
we've
struggled
really
with
whether
we're
operating
on
apis
or
on
features
and
what
exactly
the
meaning
of
those
terms
are,
but
the
bottom
line
is
the
user
story
should
be.
I
understand
the
stability
level.
O
I
can
expect
out
of
the
way
I'm
using
istio
we're
continuing
to
move
towards
that
it's
going
to
stay
experimental
for
some
time,
but
I
think,
if
you
scroll
to
the
right,
I
believe
we
said
we'd
like
to
have
it
at
alpha
level.
Before
the
end
of
the
year,
honestly,
I
obeyed
a
little
yeah,
it's
a
really
valuable
feature.
O
How
do
you
do
that
blocking
is
a
stretch
goal,
but
because
of
the
various
ways
that
you
can
configure
istio,
I
I
think
it's
going
to
be
pretty
difficult
to
actually
block
the
use
of
features.
Instead,
it
will
be
a
command
that
you
can
run
either
against
the
live
cluster
or
against
a
git
ops
repository,
and
it
will
tell
you
the
maturity
level
of
various
features.
O
So
that's
it's
something
it's
not
perfect,
but
I
I
really
do
think
that
actually
failing
in
the
control
plane
itself,
when
we
activate
an
alpha
feature,
it
opens
up
a
can
of
worms
in
terms
of
how
users
know
that
we're
not
acting
on
their
config
et
cetera.
I
mean
the
only
so.
The
only
issue
is
just
that
that
check.
H
Yeah,
I
had
a
quick
question
here,
so
this
is
essentially
tooling
right.
So
a
tooling,
as
long
as
it
doesn't
give
false
positives,
is
there
a
way
to
accelerate
it
and
make
it
more
mature?
What
I'm
trying
to
get
to
this
is
like
the
whole
point
of
making
upgrades
safer.
This
tooling
is
really
essential.
O
The
other
dimension,
though,
is
around
what
we're
communicating
to
the
users.
We
have
a
framework
for
this
in
place
today.
However,
what
it
tells
users
is
that
everything
they've
ever
done
is
alpha
their
use
of
revisions
alpha
their
use
of
it's
not
a
useful
signal
to
the
users
today,
so
we
also
need
the
features
themselves
to
stabilize,
because
I
don't
think
we
would
be
doing
the
user
a
service
by
throwing
out,
you
know
hundreds
or
even
thousands,
of
warnings
on
a
default
installation.
Today.
H
K
So
the
last
item
is
measurement
of
what
benefit
we're
getting
from
istio
cuddle.
We
have
no
idea
what
analyzers
are
reporting
errors
that
are
helping
people.
We
have
no
idea
what
commands
is
to
cuddle
users
are
actually
using,
so
we
would
love
if
there
was
some
kind
of
way
that
we
could
get
statistics
about
which
analyzers
are
reporting,
errors
which
commands
people
are
using,
it
would
have
to
be
opt-in
and
there
would
have
to
be
something
to
catch
it.
O
To
be
very
clear,
the
work
here
is
not
mostly
technical
in
nature.
The
majority
of
the
work
is
ensuring
that
we
are
respecting
our
users,
privacy,
since
this
data
will,
by
definition,
be
open
data
to
the
public
and
then
getting
the
steering
committee
to
sign
off
on
whatever
that
particular
privacy
and
data
collection
plan
is.