►
From YouTube: Technical Oversight Committee 2021/05/03
Description
Istio's Technical Oversight Committee for May 3rd, 2021.
Topics:
- Test & Release WG Roadmap
- API Versioning Woes
- Istio at the Application Layer
A
B
B
D
D
A
E
E
B
B
E
Last
week
that
was
marked
as
being
completed
in
january,
which
was
before
110
was
really
started,
so
cleared
that
out,
and
there
was
a
lot
left
over,
I'm
just
catching
up
on
it.
Now
from
I
don't
know
wednesday
or
whenever
the
last
time
I
looked
at
it
was,
but
I'm
not
sure
where
that
stands
right
now,.
E
E
H
G
I
H
G
A
I
I
I
feel,
like
the
automation,
is
great
for
things
that
are
command
line
only
and
I'm
gonna,
hopefully
in
a
few
hours
or
days
I'll,
know
why
the
automation
is
succeeding
for
this
particular
item,
but
in
general
I
would
rather
not
have
the
security
of
an
automated
test
if
the
person
didn't
test
the
appearance
of
the
gui,
which
is
the
problem
right
for
for
a
tracing
tool,
the
traces
have
to
be
there.
So
it's
not
just
enough
that
I
can
do
all
the
commands
like
deploying
jager
and
that
sort
of
thing.
J
B
Should
sync
up
with
doug
or
somebody
like
that
and
then
okay
what's
covered,
and
then
you
guys
kind
of
have
a
discussion
about
it
and
certainly
testing
gui
tools
is
is
hard
and
if
they
don't
have
apis
behind
them
right
to
verify
their
own
behavior,
then
that
makes
it
right.
You
have
to
use
other
mechanisms.
F
G
I
I
guess
I
can
you:
you
talked
about
the
doc
stuff,
so
yeah
so
most
of
these.
Well,
I
shouldn't
say
most
most,
but
most
of
them
are
probably
in
our
yearly
roadmap.
They
all
weren't
in
there
and
we
didn't
have
a
1.11
spreadsheet
created.
Yet
so
that's
why
we're
sort
of
doing
it
here
we
want
to
continue
with
the
promotion
of
the
features
process,
brian
and
schwetta.
G
G
One
of
the
things
that
we
want
to
try
to
do
this
release.
If
we
can
is
to
rename
the
branches
from
master
domain.
I
know
envoy's
done
that.
I
know
john
had
made
the
comment
that
this
might
be
a
slightly
bigger
hassle
than
what
we
thought
we
were
going
to
get
for
free
from
github,
but
I
think
we
can
probably
use
the
private
repos
to
do
some
testing
between
the
various
repos
as
we
move
over
to
maine.
G
We
want
to
make
sure
we
continue
promoting
external
istio
data
beta.
I
think
this
was
probably
on
the
environments
list
as
well.
I
know
there's
a
couple
issues
there
that
I'm
going
to
work
on
and
I
believe
miriam
also
said
she
would
work
on
some
things
there,
so
that
was
all
the
p
zeros
a
p2
brian
was
looking
at
making
sure
we
get
the
distress
images
promoted
to
beta.
I
know
there
was
a
couple
of
issues
open
in
that
space
that
have
to
be
solved
as
well.
G
G
In
terms
of
the
testing
for
generation,
so
this
is
basically
related
to
the
automation
of
the
branch
cutting
which
is
work.
We
started
a
couple
of
releases
ago
and
just
trying
to
finish
that
up,
as
as
things
change
every
release,
we
have
to
make
some
updates,
so
we
find
some
things-
and
I
know
sam
and
brian
had
made
a
list
of
things
that
were
done
during
the
last
branch
cut
to
to
work
on
with
automation
and
then
finally,
sam
was
going
to
work
on
some
release.
G
Notes
tooling,
so
we
want
to
do
some
things
related
to
release
notes.
I
know
sam
was
talking
earlier
this
morning
and
there's
some
some
issues
with
validation
and
running
the
tooling
and
some
things
end
up
going
missing,
because
area
names
are
specified
in
the
release.
Notes
that
we're
not
capturing,
so
we
end
up
skipping
over
those.
G
G
G
I
actually
get
a
quick
question
on
that.
What
what
work
is
involved
there,
mostly
adding
additional
test
cases
in
terms
of
the
external
stod?
Yes,
we
need
to
do
so
yeah.
We
need
to
do
some
test
cases
there.
I
think
linda
actually
got
most
of
the
docs
done
as
well
as
testing
in
the
docs.
So
now
it's
just
making
sure
we
add
some
stuff
to
the
integration
test
framework
and
some
tests.
Okay
and
who's.
G
Doing
that
work
I
had
said
I
would
do
some
of
it
and
I
didn't
put
stephen
up
here,
but
I
think
I
had
heard
that
stephen
was
also
stepping
up
to
do
some
of
that
work.
I
haven't
been
involved
with
the
meetings,
but
I
think
stephen
and
greg
hansen,
and
maybe
another
person
have
been
talking
about
that.
B
E
Yeah
one
of
the
big
things
that
tfc
asked
for
which
we've
laid
the
groundwork
for,
but
we
haven't
really
done
anything
with,
is
a
way
to
keep
features
moving
forward.
So
this
feature
has
sat
in
alpha
for
three
years.
We
should
decide
whether
we
want
to
get
rid
of
it
or
whether
we
want
to
actually
promote
it
or
that
sort
of
thing.
So
that's
really
what
this
focuses
on.
A
H
H
A
A
F
H
We
obviously
have
the
ability
to
name
that
to
to
call
the
apis
whatever
you
want.
I
mean
it's
not
really.
A
problem
of
not
being
able
to
have
cps
move
to
better,
so
only
program
is
how
the
string
you
know,
type
url
in
kubernetes
looks
like
and
that's
a
kubernetes
problem.
You
know
the
infrastructure
in
kubernetes
and
even
if
they
fix
it
today,
it
would
be.
You
know,
six
months
to
a
year
or
two
years
until
all
kubernetes
versions
support
it,
and
so
it's
it's
it's
a
sorry.
M
Yeah,
I'm
so
for
what
it's
worth.
I
put
together
the
original
transformation
to
get
us
that
go
client,
stuff
and
the
kubernetes
api.
I
don't
quite
understand
why
we
don't
just
want
to
move
to
a
kubernetes-like
api
for
everything
and
make
that
like
what
we're
starting
from
for
all
this
other
stuff.
I
think
that
would
certainly
simplify
things.
M
Those
are
mostly
for
third
party
folks,
but
in
doing
that,
and
using
a
more,
I
guess,
kubernetes
centric
approach
right
with
kubernetes
schema
and
those
kinds
of
things
have
stuff
built
in
for
doing
api
conversion.
All
this
stuff,
I
mean
it's
an
extra
web
hook
to
get
the
conversion
library
in
there,
but
that's
pretty
much
a
singleton,
but
I
think
you
know
adopting
approach
like
that
and
trying
to
move
to.
It
would
certainly
give
us
a
the
ability,
at
least,
to
support
multiple
versions
of
a
given
resource.
H
B
B
F
A
M
I
mean
I
could
write
something
up.
It's
really
just
a
bunch
of
grunt
work
to
go
and
convert
all
this
stuff
up
to
regular
types.
I
don't
know
what
work
would
be
involved
to
convert
the
existing
proto
stuff
that
we
have
into
kubernetes
types
resources,
because
right
now
we
kind
of
do
it
backwards
right.
We
start
with.
H
M
So
the
first
step
would
be
moving
off
of
that
and
on
to
like
a
native
kubernetes
thing
and
once
you're
on
that,
then
you
have
the
ability
to
start
looking
at
okay.
Now
I
can
version
an
api.
Here's.
What
the
converter
looks
like
if
anything
and
then
begin
to
to
make.
You
know,
I
guess
more
more
usable
changes
to
the
api
other
than
just
saying
we're
going
from
v1
alpha
to
b1
beta,
and
it
just
works
because
we
didn't
change
the
structure.
M
L
A
H
K
H
M
Yeah,
I
think
that's
kind
of
a
bunk
argument,
because
all
you're
doing
is
using
that
kubernetes
type,
which
just
has
a
metadata
field
and
everything's
in
spec.
So
it's
not
like
you're.
You
know,
jumping
off
a
bridge
here
and
can't
support
anything
else.
It's
just
saying
if
we
adopt
that
as
our
standard
type,
it
works
really
well
in
kubernetes,
which
is
I'm
guessing,
is
where
a
majority
of
people
are
using
istio
in
the
first
place,
and
it
doesn't
preclude
you
from
using
those
same
types
and
using
proto
and
all
this
other
stuff
external
to
kubernetes.
H
H
A
Beta
as
long
as
we
can
convert
right,
so
that's
the
whole
point,
and
today
we
don't
have
that.
So
I
think,
like
the
status
quo
is
not
is
not
good
enough,
because
we're
getting
pushback
on
making
simple
string
changes
right,
so
we
we
clearly
need
to
do
something
better.
I
think
the
question
is
who
is
willing
to
own
this
problem?
A
B
H
H
H
B
H
C
C
B
L
L
B
B
K
I
A
J
J
B
H
Move
on
to
my
other
topic,
I
have
one
one
more
question
for
on
this
topic
before
so
then,
if
you
would
prioritize
your
your
goals
here
is
moving
to
v1,
presumably
is
a
primary
goal,
but
is
making
backward
incompatible
changes,
maybe
a
v2
or
p1
or
or
or
would
it
be
okay?
If
we
have
a
solution
that
just
moves
to
v1
with
what
we
have
with
blackboard
compatible
and
maybe
deprecating
fields,
but
without
semantic
renaming
or
do
we
want
all
to
answer
all
generic
solutions
that
does
translation,
conversions,
automatic
everything.
H
F
H
M
H
Do
we
have
any
backgrounding
of
changes
that
we
are
planning
to
make
in
the
next
two
or
three
releases
I
mean?
Can
we
have
a
solution
that
is
just
moving
to
v1
and
that's
I'm
trying
to
do
to
to
to
figure
out
how
how
much
we
want
to
break
things
and
how
much
instability
we're
going
to
to
to
get
to
towards
the
benefit
of
hypothetically
making
the
product
yeah.
M
Yeah,
I'm
not
underestimating
anything
right
because
we're
swapping
out
that
entire
mechanism
and
moving
to
kubernetes
first
for
our
controller
pattern,
which
I
think,
makes
things
easier
for
everybody
right.
We
don't
no
longer
have
to
maintain
this
weird
translator
that
translates
from
erd
to
client
go
libraries
and
proper
kubernetes
api
types
right.
We
start
with
kubernetes
api
types
and
everything
else
flows
out
of
it.
M
We've
got
the
controller
gen
tools
that
manage
all
this
stuff
for
us,
so
we
can
offload
all
of
the
extra
tooling
that
we
have
in
our
builds
and
I'm
not
saying
that
it's
not
that
it's
going
to
be
a
small
change
at
all.
So
don't
get
me
wrong,
but
I
think
that's
what
needs
to
be
done
in
order
to
get
to
the
point
where
we
can
start
doing.
Api
management
is.
H
That
that's
that
one
approach,
also
don't
forget.
We
also
have
other
protocols.
Like
you
know,
former
ncp,
I
mean
history
used
to
send
protocols,
and
that
I
mean
it's
it's
it's
both
design
and
implementation
are
are
massive.
If
we,
if
we
need
to
achieve
all
those
goals
at
once,
that's
why
I'm
trying
to
clarify
the
strict
requirements.
B
B
And
so
I
I
don't
want
to
get
into
it:
a
proto
versus
not
proto
as
the
primary
authority
of
discussion
here
I
know
I'm
gonna,
no
cussing,
I'm
gonna.
Let
the
the
folks
who
have
spent
most
of
the
time
doing
this
come
back
with
a
recommendation
and
have
a
a
discussion
about
it,
because
the
tlt
isn't
going
to
have
a
strong
opinion
about
that
unless
there's
clear
evidence
that
there's
going
to
be
disruption,
one
way
or
the
other.
I
take
your
point
about
it
being
very
expensive.
B
C
A
B
You
know
other
p0s
here
is,
you
know,
can't
disrupt
the
whole
development
process.
I
can't
destabilize
the
release
right
all
the
usual
engineering
things
right,
and
so
you
know
it's
either.
If
it's
big
bang,
it's
cheap
and
quick
right
or
it
can
be
done
incrementally,
and
we
can
prove
that
we
can
do
so
safely
right
because
we
can't
stall
all
the
other
teams
right.
While
this
is
happening
right,
that
is
not
allowed
like,
we
could
install
users
yeah.
M
B
A
So
my
other
topic,
so
let
me
this
was
yeah
an
interesting
discussion,
so
I
I
have
been
thinking
about
how
to
frame
what
istio
does
and
so
we're
not
going
to
get
too
much
into
detail.
I
think
today,
because
only
15
minutes
or
less
but
I'd
like
everyone
to
you
know
on
toc
to
take
a
look
at
this
and
provide
feedback
like
some
people
have
already
there's.
A
You
know
a
way
to
look
at
what
issue
does
as
really
just
being
networking
done
at
the
application
layer
instead
of
at
the
you
know,
other
layers
and
actually
there's
a
lot
of.
You
know
existing
discussion
actually
from
folks
about
about
that,
and
basically
I
tried
to
write
up
what
would
happen
if
we
leaned
more
heavily
into
that,
and
really
you
know,
rather
than
talking
so
much
about
services
and
service
mesh
started
talking
about
applications
and
application
networking.
A
H
A
A
If
we
did
that,
so
that's
one
and
then
another
is
that
today
the
we
have
this
sort
of
disjointed
identity
model
where
we
have
this
indirection
between
the
applications
and
the
service
accounts
and
there's
sort
of
this
mapping
you
have
to
do
kubernetes
makes
it
pretty
easy
to
do
because
it
gives
everything
a
default
one
in
the
namespace
so
like.
If
all
you
care
about
is
name
space.
A
A
There's
a
a
pretty
long
discussion
here
of
what
that
would
lead
to,
but
there's
some
nice
benefits
that,
like
what
you
end
up
monitoring
and
what
your
authorization
policies
look
like
then
become
symmetric
right.
Everything
becomes
kind
of
lined
up
on
the
same
things,
and
you
don't
have
to
do
this
mapping
of
oh
okay,
wait.
I
have
calls
from
this
client
it's
running
as
a
service
panel.
A
B
H
Identities
you
you
cannot
have,
you
cannot
have
according
to
the
spec.
As
far
as
I
know,
there
is
only
one
switch
identity,
but
you
can
have
additional
sun,
so
you
can
have
dns
plus,
but
that's
perfect,
because
for
intervality
I
mean,
if
we
express
canonical
service
name
is
a
service
name.
It
is
not
a
spf
identity,
so
it
is
basically
perfect
matching
to
have
both
identity,
because
spiffy
plus
the
suns,
which
allow
interoperability
with
other
crimes
that
are
not,
let's
be.
A
When
we
were
when
we
were
sort
of
designing
spiffy,
there
was
actually
a
discussion
about
this
exact
situation,
and
you
know
I
think,
at
the
time
I
was
pushing
for
servants
against
that's
what
we
had.
We
didn't
really
have
this
other
model
and
sticky
intentionally
is
more
general
very,
and
there
was
a
lot
of
discussion
of
like
application
identity
when
we
were
talking
about
this
and
building
this
50
model.
So
it
is
unfortunate
if
you
can
only
have
one
sticky
identity
that
makes
this
harder
yeah.
H
Or
it
makes
it
better,
I
mean
you
look
at
it
as
a
feature
because
it
allows
us
to
put
the
identity
in
in
sni,
which
is
perfectly
in
in
in
the
sun,
which
is
perfect
match
with
snare
routing
we
are
doing,
which
is
also
based
on
on
dns
name
hostname,
so
it
it's
a
perfect
fit
for
for,
inter
rarity.
So
there
are
a
lot
of
benefits.
If
we,
if
we
implement
it
as
a
you,
are
a
dns.
A
A
H
J
Like,
for
instance,
you
in
your
proposal,
you
talk
about
right
instead
of
using
service
account,
which
kubernetes
provides
to
us
today.
We
use
that
in
authorization
policy
right,
so
you
are
proposing
okay,
we
could
using
application
names
instead
of
service
account.
I
was
just
wondering
regarding
your
proposal,
some
of
these
application
name
and
the
identity.
J
If
it's
coming,
naturally
from
kubernetes,
I
think
it
would
be
pretty
transparent
for
our
user
to
adopt,
instead
of
they
would
have
to
mentally.
Do
a
mapping
between
service
account
to
the
application
name
right,
because
they
could
still
like.
If
I
deploy
book
info
today,
I
could
create
service
account
for
each
of
my
booking
for
services,
which
is
probably
recommended
by
user
running
services
in
production.
So
I
mean,
if
kubernetes
have
that
native
concept
of
application,
name
and
application
identity,
it's
just
so
much
natural
for
people
to
leverage
from
a
service
perspective.
A
J
J
J
H
A
And
the
you
know,
like
we
had
this
huge
internal
to
google
discussion.
Also
about
this
and
like
ideally,
we
would
have
been
able
to
call
this
thing
a
service,
but
kubernetes
has
the
name
service
already
for
something
different,
and
it's
like
that.
We
need
another
name,
and
so
we
just
added
canonical-
and
I
don't
know
that
that
was
necessarily
the
best
thing
to
do.
We
maybe
should
have
just
at
the
time
sucked
it
up
and
chose
an
application
and
I'm
kind
of
saying
hey.
Let's
just
do
that.
H
By
the
way,
speaking
of
kubernetes,
there
is
also
a
discussion
about
in
the
gateway,
api,
kubernetes
gateway
about
how
you
know,
ownership
and
and
how
those
names
can
be
authorized
and
mapped
to
different
workloads
and
and
delegated
and
and
basically
the
whole.
The
whole
model,
for
you
know
who
is
allowed
to
to
claim
a
particular
name.
M
H
B
H
Yeah,
I
know
that's
happening
speaking
of
api
revisioning.
No,
but
but
again,
if
you
claim
to
your
application,
name
is
example.com,
and
then
you
have
gateways
that
forward
due
to
example,
common
and
so
forth.
Then
we
run
into
all
kinds
of
problems
who
can't
claim
that
it's
example.com,
if
it's
something.namespace,
we
can
vary
that
and
so
forth.
But
otherwise
it's
it's
a
it's
an
issue
about.
B
A
So
real
real
quick,
I
think
I
I
only
went
through
the
first
two
points
here,
so
the
last
two
are
slightly
less.
I
think
crazy.
So
remember
three
is
that,
basically,
we
should
just
make
it
simpler
to
target
configuration
at
applications
so
right
now
you
can
do
it,
but
you
have
to
you
just
use
the
same
label
selector
right.
That
was
basically
you
say:
you
know:
label
canonical
service
equals
whatever
in
your
in
your
policy,
I'd
like
to
make
that
more
first
class.
A
So
basically
you
can
just
say
as
part
of
your
configuration
you
know:
application
equals
whatever
this
was
actually
always
part
of
the
plan
for
canonical
service.
So
it's
just
saying:
hey,
let's
finally,
do
it
when
we
first
did
this
we're
like
hey
later
we
can.
You
know
we
can
just
make
it
easy
to
talk
configuration
then
we
never
never
did
that
so
hey.
We
should
do
it
all
right.
A
J
Yeah
you
were
not
presenting
that
portion,
so
I
wasn't
sure
if
you
were
referring
to
that
yeah.
So
so
I
I
agree
with
you,
I
mean
workload.
Selector
is
actually
very
confusing.
I
was
just
looking
over
documents
like
like
the
in
the
gateway
resource.
Today
we
use
a
selector
right
in
the
envoy
filter,
we're
using
workload
selector
and
in
our
authorization
and
authentication,
which
includes
the
peer
authentication
and
also
the
user
authentication.
We
use
like
label
selector.
A
A
A
Basically,
if
you
think
about
like
an
application
layer
network,
that's
inherently
multi-network.
So
just
let's
lead
into
that
more
and
say
you
know:
multi-network
is
kind
of
a
big
part
of
what
istu
does
and
kind
of
a
big
part
of
the
value
and
describe
it
in
terms
of
these
application
layer,
overlays
et
cetera,
but
we're
at
a
time.
So
please
please,
read
the
doc
and
comment
and
we'll
figure
out,
but
if
we,
if
we
actually
want
to
take
on
some
of
these.
A
Yes,
I've
looked
at
them
a
couple
times.
I
probably
should
have
put
them
again.
Aren't
they
not
applicable
here,
so
they
they
are
and
they
aren't.
So
the
main
the
main
problem
is
they're
optional,
and
so
we
have
this
model
of
everything.
Is
you
know
everything
is
a
canonical
service
and
there's
this
like
every
every
endpoint
is
part
of
a
canonical
service.
Always
if
you
don't
label
it,
we
have
heuristics
that
figure
it
out
and
I
think
that's
the
perfect
missing
from
the
next
film
and
that's
what
I
want
to
talk
about.
B
A
Yeah,
what
we
do
is
we
have
a
controller
that
injects
them,
if
not
there
right,
and
so
I
think
that
would
be
the
main
proposal
to
talk
to
them
about
and
then
the
question
is:
can
we
do
it
with
our
existing
label
or
do
we
need
a
new
label
that
like
what
we
did
right?
We
invented
a
new
label
and
we
just
copy
from
there
but
yeah.
That's
the
whole
discussion.