►
From YouTube: CNCF Service Mesh Interface Project 2021-03-17
Description
CNCF Service Mesh Interface Project 2021-03-17
A
Hi
everyone
today
is
wednesday
march
17th.
Thank
you
so
much
for
joining
today's
smi
community
meeting,
I'm
going
to
moderate.
My
name
is
michelle.
Nearly
bridget
has
volunteered
to
take
notes
and
run
all
the
things.
So
thanks
bridget,
we
have
several
discussion
items
today
that
we're
going
to
breeze
through
first
we're
going
to
talk
about
bridget
is
going
to
talk
about
kubecon
cloudnativecon
europe.
A
I
have
a
discussion
topic
on
traffic
split
and
also
the
another
discussion
topic
about
the
cid
crd.
Excuse
me,
crd
api
group
inversion
and
then
bridget
has
a
topic
around
supporting
custom
off
filters
to
allow
delegating
off
logic
to
third-party
components.
So
if
you
do
have
a
discussion
item,
please
feel
free
to
throw
it
in
the
agenda
and
then
we'll
have
time
for
introductions
and
any
other
topics
at
the
end
as
well.
B
All
right
so
nice
and
easy
and
short
we
have
in
the
past
cloud
native
austin
in
fact
has
arranged
for
us
to
do
a
community
session
during
kubecon,
and
I'm
wondering
if
anyone
would
like
to
volunteer
to
be
in
charge
of
scheduling
and
running.
A
call
for
you
know
to
promote
the
project
during
kubecon.
Eu
coming
up
may
4th
to
7th
it's
okay
if
lee
doesn't
want
to,
but
if
he
does
not
want
to,
I
probably
will
end
up
having
to
do
it
and
it's
terrible.
B
D
Hopefully
you
know
anyway,
you
guys
were
there,
you
all
were
there,
you
know
the
format,
and
so
this
time
it
is
well.
I
take
the
box
for
both
that
plus
a
bit
of
booth
time
so
that
we
can
show
things
in
action
and
so
that
we
can
interact
with
folks
there
and
I
figured
shoot
if,
if
nobody
else,
if,
if
it
isn't
going
to
be
the
case,
that
none
of
y'all
are
going
to
sign
up
and
everybody's
raising
their
hand
now,
so
that's
that's
great.
B
A
A
So
and
actually
it's
been
brought
up
once
before
by
someone,
but
I
wanted
to
just
kind
of
follow
up
and
give
everyone
a
brief
overview.
So
you
can
throw
your
thoughts
into
that
issue,
so
essentially
in
traffic
target
we
have
a
source
and
a
destination.
We
have
some
rules
that
we
apply
to
traffic
from
the
source
to
that
destination
from
from
a
set
of
sources
to
a
destination,
so
each
rule
is
basically
a
reference
to
a
traffic
spec,
so
an
http
route
group
or
a
tcp
route
group
or
udp
route.
A
If
we
have
that
in
there
so
anyways
there's
some
attributes
that
apply
to
those
roles
and
a
rule
can
have
an
optional
match
condition.
So
you
can
say
in
an
hp
route
group,
you
can
specify
different
types
of
matches,
so
one
match
condition
would
be
you
want
to
match
on
user
agent,
chrome
or
something,
and
then
an
another
match.
Condition
might
be
like
you
want
to.
You
know
match
on
some
path
with
some
other
header,
for
example.
So
that's
all
well
and
good.
A
But
traffic
split
doesn't
have
a
set
of
rules.
It
has
a
set
of
matches
and
matches
is
just
a
slice
of
typed
local
object,
references
in
kubernetes,
so
you
can
say,
hey
match
on
these
hp
route
groups,
but
there's
not
necessarily
to
my
knowledge.
A
way
to
specify
like
within
that
hp
route
group
object
like
the
actual
match
condition.
It
could
have
a
set
of
match
conditions
so
right
now.
A
C
So
I've
I've
I've
hit
this
issue
a
number
of
times,
and
the
key
thing
that
I
always
fall
down
on
is
the
lack
of
a
virtual
service.
Now
I
know
that's
a
kind
of
a
like
a
a
meta
element,
but
that
like
to
be
able
to
do
traffic
split
and
to
be
able
to
say
I
want
to
root
20
of
traffic
to
api
primary
and
20
to
api
canary.
C
C
Yeah
so
so
I
think
it's
it's
I
mean
it
might
be
specific
to
console,
but
but
console
has
has
the
concept
of
of
I'm
saying
some
virtual
service,
but
you
can
basically
create
a
a
service
which
is
an
aggregated
collection
of
end
points,
and
you
can
basically
specify
metadata.
So
I
could
say,
hey
give
me
all
of
the
end
points
which
are
tagged
with
v1
and
the
service
name
is
api,
and
then
I
could
create
like
a
virtual
service
which
is
like
api
v1.
C
So,
but
that's
fine,
like
I
could
still
reference
the
service
and
have
the
meta
criteria
from
from
within
smi,
but
I
have
to
create
the
virtual
service
definition
out
of
bound
of
smi,
which,
which
always
feels
a
little
istio,
has
exactly
the
same
thing.
Istio's
got
traffic.
I
forget
the
name
of
the
thing.
Leel
tell
me
better,
like
traffic
director
or
traffic
thingy,
whatever
it's
called,
there's
a
block
where
you
can
basically.
C
A
A
C
Which
is
out
of
bound
of
smi?
That's
that
was
you
know.
It's
not.
I
say
it's
not
a
problem.
It
just
feels
disconnected
that
I've
got
to
do
some
stuff
in
smi
and
some
stuff
in
in
my
native
platform,
and
you
would
have
exactly
the
same
issue.
I
believe
with
istio
that
you
would
end
up
setting
up
the
you
know
the
traffic
route,
which
then
creates
the
service
and
stuff,
but
it's
out
of
bound
and
probably
with
with.
Maybe
I
don't
know
osm
it
could
benefit
as
well.
A
Yeah,
let's
chat
more
about
it.
I
think
this
might
be
parallel,
though,
to
the
matches
conversation,
if
I'm
not
mistaken,
right,
okay,
on
the
matches,
if
we
did
want
to
go
continue
down
that
route,
do
we
would
we
want
to
specify
on
certain
match
conditions
or
do
we
want
to
leave
it
so
that
you
just
reference
the
typed
local
object
reference,
which
is
an
http
route
group
which
we
don't
validate
but
and-
and
you
just
apply
all
the
match-
conditions
in
there.
A
C
A
Yeah,
okay,
cool
sounds
good
all
right,
so
one
other
thing
I
had
was
just
an
update
on
moving
crds
to
v1.
Is
this
issue?
I
I
picked
it
up
like
yesterday
and
I'm
just
I'm
working
on
it
and
I
just
wanted
to
say:
hey
I'm
working
on
it,
so
it's
coming
and
basically,
if
we
don't
update
it
c
s,
1.22
of
kubernetes
is
not
gonna
work.
So
that's
it.
That's
all
I
got
what's
the
next
topic,
bridget
I'll.
B
Pass
it
back
to
you,
oh
yeah,
so
I
was
taking
a
look
at
anything
that
had
come
up
since
our
last
meeting,
and
I
think
this
issue
actually
came
in
right
before
our
last
meeting.
But
since
we
haven't
commented
on
it
at
all,
I
thought
maybe
I
should
make
sure
that
we
at
least
update
it.
If
we
are,
you
know
going
to
have
any
input
for
this
person
and
they
were
asking
about
supporting
a
custom
authorization
filter
to
allow
delegating
authorization
logic
to
a
third
party
component
component.
B
Specifically,
they
wanted
to
configure
smi
to
use
the
in
the
envoy
authorization
filter,
and
I
thought
we
should
at
least
bring
it
up
without
we're
not
going
to
necessarily
cover
in
detail
here,
but
we
should
at
least
bring
it
up
so
that
we
can
figure
out
if
there
is
somebody
on
the
call
who
wants
to
take
this
on
and
put
some
comments
on
it,
you
know
completely
say
no.
This
is
not
something
that's
going
to
happen
at
all.
I.
C
C
D
C
C
Both
of
those
may
have
a
comparable
feature,
but
it
obviously
certainly
wouldn't
be
with
an
envoy
and,
and
I
as
popular
as
envoy,
is
it
kind
of.
I
don't
think
we
should
basically
write
it
direct.
You
know
we
shouldn't
be
directly
exposing
envoy
features
without
considering
an
abstraction
as
as
such,
but
as
a
as
an
abstraction
it.
It
feels
like
a
sensible
thing
to
do
and
I
would
I
would
recommend,
like
yeah,
I
think
the
person
who
certain
issues,
probably
the
best
person,
be
able
to
come
up
with
the.
C
So
the
question
is
as
well
do
we
do?
We
also
jump
the
future
proof
and
just
think
in
general
filters
and
define
filter
types,
because
wasm
filters
are
like
whether
you,
you
think
was
in
filters
or
the
new
hype
or
or
not.
I,
I
think,
wasm's
pretty
pretty
interesting,
so
we
could
even
start
thinking
about
how
smi
could
support
that
side
of
things
as
well,
and
it
might
just
be
something
where
it's
filter
type
authorization
or
type
request,
filter
or
something
like
that,
and
you
can
get
away
with
a
generic
abstraction
which
would
be.
A
I
just
want
to
jump
in
here.
I
think
that's
an
interesting
idea
supporting
optional
wasm
filters,
but
I
also
think
that
there's
maybe-
and
I
agree
like
I-
would
really
love
to
see
a
spec
change
or
what
this
user
is
envisioning,
so
I'd
love
a
contribution
from
them,
but
also
like
it's
up
to
the
implementation
and
decide
what
like
other
technologies
they
integrate
with
so
you'd
have
to
like
for
osm
you'd
have
to
like
enable
opa
integration
or
opa
usage,
and
we
have
to
be
able
to
support
that.
A
So
I
think
like
specifying
that
filter
is
the
implementation
level
and
then
for
us
like.
We
need
to
be
able
to
support
the
type
of
identity
that
folks
need
in
order
to
use
that
auth
filter.
So
right
now
we
support
service
accounts
and
I
think
we
might
need
to
support
like
to
other,
like
maybe
something
else
in
order
to
support
oppa.
So
I
think
that
there's
like
two
ways
we
can
go
about
it.
A
A
E
A
A
So
bridget,
I
think
we
have
some
next
steps
right.
We
want
to
ask
the
user
for
or
the
person
who
submitted
the
issue
for
like
what
they,
what
they're
looking
for
and
and
we
can
also
talk
to
them
about
our
thoughts
around
what
kind
of
identity
needs
to
be
supported
and
also,
if
they're,
looking
for
some
sort
of
high
levels,
filter
specification
and
then
I'll.
Add
that
link
to
the
service
account
stuff
for
marlo.
C
No,
I
haven't,
I
haven't
done
anything.
The
proof
of
concept
around
the
sdk
has
been
pretty
good.
I've
just
been
getting
the
service
splitting
stuff
working
really
good
with
console
so
that
I
can
use
flagger
and
been
kind
of
working
through
that
which
has
been
keeping
me
busy,
but
it
works
great
and
I
love
flagger.
I
am
the
biggest
convert
in
the
world
to
canary
deployments
with
flagger
the
I've
got
all
of
the
like
the
build
stuff
so
being
able
to.
C
C
A
C
C
C
A
C
A
C
F
C
A
G
Yeah
I
had
one-
hopefully
it's
quick,
so
during
the
last
meeting
there
we
were
talking
about
multi-cluster
federation
and
scheduling
a
call
on
the
off
week
to
kind
of
dive
into
more
detail
of
what
folks
and
requirements
were
there.
I
didn't
see
anything
on
any
agendas
or
in
slack
of
whether
that
call
was
scheduled.
I'm
wondering
if
that
happened,
and,
if
not,
is
that
something
we
still
plan
to
get
on
the
calendar
and
dig
into.