►
From YouTube: Technical Oversight Committee 2020/10/16
Description
Istio's Technical Oversight Committee for October 16th, 2020.
Topics:
- API for external authorization plugins
- Release managers for 1.8
A
A
C
D
A
A
B
E
B
E
Okay,
go
ahead.
Go
ahead,
all
right,
so
I
mean
for
those
who
don't
know.
This
will
be
my
very
last
day
in
istio
onward
that
trade
and
all
of
those
stuff,
and
so
I'm
moving
on
to
do
something
completely
different,
and
so
I
just
wanted
to
tell
people
in
person.
This
will
be
probably
my.
This
will
be
my
last
doc
meeting
and
anything
has
to
do
with
istio
kubernetes
the
whole
land.
E
E
E
No,
it
was
actually
I
mean
it
was.
I
mean
I
think
I
don't
know
if
dan
burke
was
actually
here,
but
I
think
he's
probably
the
only
one
here
who
who
he
and
I
go
back
like
five
six
years
back
in
this
entire
space
but
yeah,
it's
been
a
wild
ride
and
I
still
remember
the
very
first
time
we
presented
amalgamate
to
eric
prover
and
I
don't
know
who
else
was
actually
on
the
caller.
E
H
C
C
Sure
it's
been
a
pleasure
we've.
You
know
we've
been
working
together
for
a
long
time
in
this
project.
You
know:
we've
made
huge
contributions
to
it,
so
we're
all
really
thankful
for
everything
that
you've
done
and
you're
not
really
going
to
be
allowed
to
escape.
I'm
sorry,
I'm
going
to
ensure
that
personally
so
yeah.
E
E
K
E
D
A
I
L
A
L
I
think
I
think
they
are
all
oh
actually,
two
of
them
are
missing
assignments
like
the
sds,
but
like
the
line
from
line
to
your
line,
five
are
assigned
to
william
and
I
think,
and
which
changes
in
progress.
So
I
don't
worry
too
much
about
those
two,
but
the
second
one.
Oh
sorry,
the
crd
regression,
I
don't
think
it's
assigned
to
everyone.
A
M
L
L
L
A
I
A
D
K
N
I
A
A
D
I
H
O
A
A
A
I
A
I
I
A
A
P
P
Some
of
those
things
are
related
to
the
general
difficulty
in
using
our
filter.
Some
of
those
things
are
specific
to
the
external
oc
process.
Here,
for
example,
the
pipe
character
is
invalid
to
be
used
in
the
xlrc
grpc
client,
but
that
is
the
default
cluster
format
we
generate
in
pilot
and
also
the
only
filter,
it's
generally
hard
to
use,
not
only
because
of
the
syntax,
the
transparent
lecture.
It's
also
because
of
it's
exposing
the
native
onward
filter
api.
P
So
whenever
a
small
change
in
the
upstream
away
api,
it
could
cause
the
user
applied
onward
filter
to
fail.
Sometimes
it
will
fail
silently,
for
example,
we
have
seen
many
users
complaining
this,
that
the
version
of
the
object
in
the
onboard
filter
is
dependent
on
the
version
of
visual
is
using,
and
this
was
a
huge
pain.
P
So,
additionally,
the
other
big
pain
point
in
using
the
exclusive
flow
is
that
it
currently
cannot
support
to
trigger
the
extra
flow
conditionally.
You
have
to
enable
it
either
for
all
of
your
requests
or
you
disable
it
even
technically.
It
allows
you
to
use
the
per
route
override
to
find
controls
or
triggering
rule,
but
practically
it
is
very,
very
hard
and
mostly
impossible
to
use
because
of
the
complexity
in
dealing
with
the
rotting
rules
that
is
already
generated
by
istio.
P
P
A
Skip
ahead
a
little
bit
and
summarize
so
this
is
this
is
basically
the
same
api
as
mixer's
check
api
in
a
sense
right.
It's
it's
forming
the
same
place
in
istio,
where
you
can
say
you
know
or
like
the
external
tech
apis
right.
It's
like
when
this
match
occurs
in
this
in
this
situation.
Please
call
this
service
to
check
if
this
action
is
allowed.
G
H
K
P
H
J
B
A
A
A
P
I
H
C
C
C
Q
P
A
H
M
P
Yes,
so
this
is
one
example
of
the
deployment
as
a
namespace
owner
or
nmc
admin.
You
can,
of
course,
deploy
your
own
extra
oc
server
in
your
opening
space
and
configure
your
workload
in
your
namespace
to
use
that
extra
oscillator
server-
and
this
is
just
like
you-
can
apply
the
other
other
history
api
in
your
namespace
to
control
the
workloads
in
your
namespace.
P
N
A
H
Q
Q
C
Here
I
guess
there
are
like,
without
an
example
of
a
user
needing
to
override,
let's
say
right,
so
there
are
kind
of
three
things
right:
the
mesh
white
admin
could
say
there
is
one
alt
z
policy
server
for
the
mesh
one.
Next
to
all
these
servers
for
the
batch,
or
they
could
save
for
many
right
because-
and
I
don't
know
have
we
seen
any
use
case
where
companies
or
users
have
more
than
one
xbox
server.
C
Q
Q
C
Q
All
right,
it
is
in
the
injection
time
because
the
the
site
card
needs
to
connect
to
this
server.
So
we
need
to
get
this
address
and
that's
the
only
way
to
get
there
yesterday.
We
can
have
a
default
if
we
want,
but
so
you
need
to
restart
your
workloads
today
for
tracing
ca
and
other
things.
You
need
to
restart.
H
H
Q
If
it's
mesh
config
default,
we
don't
have
to
restart
the
pose
every
time
you
change
proxy
configuration
it's
just
if
we
want
to
restart
them
for
some
things,
but
even
proxy
config
changes.
Many
of
them
are
actually
enforced
by
by
pilot
and
sending
configuration.
So
it
doesn't
really
make
a
difference,
but.
C
Q
A
Q
A
C
All
right,
that's
the
nice
thing
about
right.
We
should
be
able
to
do
this
in
a
disruptive
way,
so
we
should
be
able
to
design
like
if
we
have
multiple.
What
would
the
schema
look
like
in
the
future
and
walk
the
schema
be
today
if
we
only
had
one
and
if
this
the
change
between
those
two
schemes
is
only
additive,
then
that's
good
right.
C
A
H
P
P
Config,
in
addition
to
the
address
of
the
target,
we
have
some
other
final
control
here
over,
like
a
one
headers
to
be
sent
to
the
extra
server
and
what
headers
the
extra
server
can
modify
in
the
original
request,
because
the
modification
part
is
often
needed
in
many
advanced
us
flow
today,
like
the
old
dc
flow,
it's
controlled
by
currently.
This
is
still
in
this
oc
policy,
but
I
will
just
use
this
as
an
example
here.
Q
So
one
comment
here
is:
if
you
deploy
on
a
particular
oc
server,
that
oc
server
will
have
some
particular
behavior.
I
mean
what
supports
whatever
does
it?
Support
so
typically
will
be
the
system
admins.
The
measure
means
that
deploys
other
server.
That
will
know
what
headers
need
to
be
forwarded
and
whatever
should
be
written.
It's
not
booking
for
developers.
That
needs
to
know
that
yeah.
P
C
H
H
Q
C
C
H
R
R
Q
Q
H
I
I
I
think
louis
you
can
correct
me
if
I'm
wrong
here,
we
should
start
simple.
Most
of
the
use
cases
that
are
going
to
come
across
are
going
to
be
ingress
enforcement,
let's
start
with
global
service
discovery
and
mesh
config
and
the
bindings
and
the
audsy
headers
that
you
need
in
the
api,
the
authorization
api
and
you
can
bind
it
to
ingress.
If,
if
the
feedback
is
no,
we
need
defaults
for
that.
C
Ingress
is
like
an
ad
like
it's
a
sub-admin
thing
right
if
it's
managed
infrastructure,
so
they
can
control
there
too.
So
I
I
don't
know
if
we
need
like
customers.
Well,
I
I
buy
your
argument
about
standardization
for
sure
I
don't
think
having
the
api
actually
represent.
The
information
presents
a
problem.
H
C
R
R
Q
N
A
P
C
Just
a
use
case
in
in
in
the
business
sense
right,
so
I
I
get
the
overviews
and
I
want
to
ensure
that
when
traffic
comes
into
my
network
happens,
I'm
the
owner
of
a
service
and
when
traffic
comes
into
my
service,
I
want
blah
to
happen
and
I'm
the
admin
of
a
mesh
and
for
all
traffic
in
the
mesh.
I
want
to
have
that
right.
P
A
P
C
So
right,
because
the
y
has
a
lot
of
impact
on
the
shape
of
the
api
right.
If
there
was
no
ad
like
mesh
wide
admin
use
case
for
this,
we
wouldn't
put
things
in
mesh
convex
or
we
would
put
very
little
in
mesh
config.
If,
if
there
was
only
an
ingress
use
case,
then
we
wouldn't
bother
trying
to
make
mesh
white
default
management
for
mesh
admin
a
priority
in
the
shape
of
the
api.
A
H
Want
enforcement
at
ingress
where
they
want
to
consult
an
external
system
for
authorizing
their
services
just
like
they
want
to
consult
an
external
server
for
doing
jwt
verification
right
and
they
fail
miserably
when
using
onward
filters.
So
this
is
creating
a
first
class
api
to
support,
at
least
that
use
case
now,
yang
min,
you
might
have
more
use
cases
where
people
have
asked.
I
want
to
enforce
it
on
sidecar
workloads,
but
I
have
not.
H
Q
H
H
A
Q
A
It
might
be
that
the
right
answer
is
still
a
single
api
call
for
optimization
and
performance
reasons,
but
like
we
should
at
least
make
that
decision
based
on
data,
so
be
good
to
know
like
do.
We
actually
think
we
need
to
have
authentication
use
cases
separate.
Could
we
actually
do
all
the
authentication
in
history
rather
than
forwarding
it
externally?
Do
we
need
to
do
that
or
like
that
part
needs
to
be
thought
through
separately
from
the
authorization
use
case.
C
C
I
think
that's
reasonable
and
we
should
aim
to
achieve
that,
even
if
we
would
have
like
if,
if
we
can
process
yvc
flows
in
a
snap
like,
we
would
still
have
an
api
to
process
industry,
standard
authentication
flows
right,
including
things
like
external
group
resolution
like
we
do
today
right,
but
plenty
of
people
have
facebook
stuff,
there's
not
much.
We
can
do
to
do
right.
We
can't
force
people
not
to
have
that,
but
we
should
agree
with
them.
A
A
C
So
so
it
doesn't
seem
like
there
was
a
lot
of
controversy,
at
least
with
starting
out
with
one
external
service
in
mesh
config
in
in
the
the
runtime
aspects
of
mesh
config
and
proxy
config.
I'm
not
trying
to
resolve
that
question
here
and
there's
a
separate
subject
about
whether
we
need
to
default
the
headers,
whether
they
can
be
overridden
or
whether
we
should
just
let
them
be
defined
in
line
every
time.
H
C
A
G
I
think
one
of
one
of
the
one
of
the
issues
that
we're
having
here
is
that
x,
dot
c.
Is
it
it's
not
a
standard
but
ydc
flow
is
a
standard
and,
like
rest
of
the
odds,
see
stuff
that
we're
talking
about
are
like
standard
things,
and
now
this
is
mixing
standards
with
an
escape
hatch,
and
I
think
that,
like
that's
where
we
are
having
these
use
case
issues
even
because
escape
hatch
use
cases,
I
mean
it's.
A
G
So
so
I
mean
there
is
like
there
are
things
that
that
we
need
to
do
at
kind
of
the
low
level
of
either
defining
which
headers
are
like
what
is
sent
out.
What
context
is
sent
out,
but
that's
mostly
on
a
a
lot
of
it,
is
on
the
efficiency
of
efficiency.
Side
of
and
it's
like
mesh
admin
is
fine
to
define
that
you,
you
don't
need
individual,
like
name
space
or
service
owners
to
define
it.
So
sorry,
I
don't
think
we
need
to
go
deeper
than
that.
A
So
we
could
start
with
this,
basically
all
being
defined
in
mesh
config
in
terms
of
that
block
kind
of
highlighted
there.
The
external
block
saying
here
is
the
external
office
service,
here's
the
here's,
the
headers,
it
takes,
here's
the
editors
it
responds
with
and
then
in
the
namespace
admin.
All
they
would
say
is
here's
the
here's.
The
match
conditions
called
the
external,
obviously
service.
C
Q
One
comment
about
dimension
efficiency
says
the
word:
efficiency
and
probably
human,
also
stability,
scalability
and
so
forth.
The
mixer
has
this
wonderful
facility
to
you
know
cash,
some
some
requests.
So
if
the
server
goes
down,
it
will
keep
you
know
not
failing,
which
relied
on
the
fact
that
requests
were
were
very
important
or
cashable.
So
I
think
that
would
be
pretty
important
to
address,
because
one
of
the
problem
with
mixed
reasoning,
drop
mixer
was.
Q
Q
P
H
C
M
M
Then
I
don't
think
we
would
have
come
up
with
this
api
and,
like,
furthermore,
like
we
is
this
something
that
we
want
to
support,
because
we
got
rid
of
mixer
policy
and
then
now
we're
basically
adding
back
mixer
policy.
So
I
want
to
make
sure
we're
not
just
doing
it,
because
this
is
better
than
the
envoy
filter.
So
let's
do
it
because
now
we're
committing
to
it
we're
going
to
be
supporting
it
for
years,
et
cetera.
So.
C
So
there
are,
I
think,
there's
a
couple
things
like
certainly
john.
I
would
agree
with
you
on
the
http
versus
grpc
stuff
right
if
we
have
service
declaration-
and
we
already
have
all
that
information
in
service
right
right,
so
we
don't
need
to
expose
it
in
this
api
right.
We
know
a
port.
Is
the
rpc
a
it's
going
to
be
a
grpc
service?
That's
what
you
should
call
right.
We
should
just
rely
on
the
existing
service
method,
the
right
and
that
that
goes
for
timeouts
and
other
things
right.
C
C
As
for
whether
it's
a
good
api,
I
think
there's
some
interesting
questions
right.
I
think
we
all
agree
that
we
need
the
ability
for
third
parties
to
integrate
like
authorization
systems
that
are
not
ones
that
we
provide
all
right.
That's
pretty
clear,
like
we
have
very
strong
use
cases
for
that,
so
I
don't
think
we
should.
We
should
recognize
that
we
should
try
to
deliver
an
api
experience
that
covers
that,
and
so
you
know
we
could
provide
it,
maybe
a
better
abstraction
than
we
think
the
envy
filter
is
providing
right
like
so
we
can.
C
C
M
C
A
P
H
S
Q
C
C
H
So
for
enforcement
like
whether
it's
implemented
with
an
onboard
native
api
or
a
wasm,
that
should
always
that's
the
problem.
That
applies
to
almost
all
of
the
configuration
we
supply
right
now
right,
so
many
things
that
we
configure
in
mesh
config
tomorrow
can
be
implemented
in
wasm
by
a
custom
filter.
So
we
should
think
about
it,
generically
and
not
just
for
authorization.
C
Yeah,
it
is
becoming
a
bit
like
a
generic
trigger
api
yeah.
That's
not
necessarily
bad
by
the
way.
Right,
like
we
have
pretty
good
user
feedback
that
it's
a
good
trigger
api
for
authorization
use
cases
like
people
seem
pretty
happy
with
the
api
right,
modulo
feature
gaps
but
which
is-
and
it
may
be
an
interesting
paradigm
to
consider
for
the
future
of
envoy
filter
right,
maybe
instead
of
doing
a
whole
bunch
of
matching
in
the
control
plane
to
try
and
figure
out
what
to
do.