►
From YouTube: CNCF Service Mesh Interface Project 2020 07 22
Description
CNCF Service Mesh Interface Project 2020 07 22
A
Everyone
today
is
the
Wednesday
July
22nd
2020,
welcome
to
the
service
mesh
interface
community
hall,
we're
going
to
kick
it
off
today
with
I'm
gonna,
say
introductions
because
I
do
see
a
few
new
faces
and
then
we'll
go
ahead
and
go
into
stand
up
for
discussion
items.
We
have
a
few
and
we
have
like
the
reminder
to
submit
your
blog
posts,
support
for
personas
topic
and
then
support
for
routes
and
the
metrics
spec
topic.
So
without
further
ado,
does
anyone
new
want
to
introduce
themselves.
C
D
E
A
B
Yes,
I
know
solo
and
I.
Think
a
couple
of
other
organizations
we're
thinking
about
writing
blog
posts
and
my
urge
to
you
is
hate.
Coo
Connie,
you
is
coming
up.
A
lot
of
people
are
going
to
be
looking
at
stuff
in
the
kubernetes
space.
Now
could
be
the
moment
to
write
a
blog
post
about
what
you're
doing
to
use
service
mesh
or
what
you're
implementing
in
the
service
mesh
ecosystem
and
then
submit
that
as
a
PR
to
the
SMI
spec
website
repo
and
the
link
is
in
the
notes.
A
Super
cool
will
do
thanks
for
Jay
I.
Think
another
really
good
topic
to
would
be
like
HP
header
matching
support
like
that
recent
addition
I
feel
like
we're,
not
really
talking
about
it
and
stuff,
so
we
should
definitely
make
that
now
and
that
that's
a
thing
and
that
people
should
check
it
out
and
implement
it.
A
I,
don't
know
why
I
made
it
myself,
okay,
so
the
next
topic
is
support
for
personas
Jason
I
know
you
wrote
an
intro
here,
but
hopefully
you
can
or
Jason
and
Michael.
It
says
Michael
on
the
side.
There
can
you
all
kind
of
give
us
an
idea
of
like
what
you
want
to
see
here.
We
summarized
the
summary
yeah.
C
Sure,
yeah
so
I
guess
the
kind
of
the
where
this
is
kind
of
come
up.
I
guess
it's
as
we
sort
of
look
at
at
least
more
in
depth
with
the
SEO
it
yeah
I.
We
haven't
really
adopted
SMI
I'm
directly.
Most
people
use
it
AC,
okay,
but
as
we
look
at
that
and
how
we
can
bring
it
into
like
the
enterprise,
there's
a
couple
of
challenges
with
it.
So
the
first
challenge
is
the
kind
of
there
there's
there's
different.
C
You
know
you
know,
even
though
they're
like
maybe
a
service
publisher,
but
I'm
kind
of
acting
in
different
roles,
depending
on
what
I'm
trying
to
do
so
when
I'm,
trying
to
you
know,
offer
author
like
routing
configuration,
for
example,
I'm
sort
of
controlling
how
traffic
gets
to
my
service
or
I'm
controlling
access,
for
example,
with
the
split
stuff
like
that.
So
it's
more
from
like
this
service
owners
perspective
and
also
maybe
there's
some
like
defaults
of
how
my
service
should
be
consumed
like
this
is
the
timeouts
that
I
would
expect
on
the
service.
C
Maybe
some
default
retries
and
stuff
like
that,
but
there's
also
this
the
client
persona
aspect
of
it
where
I'm
consuming
a
service
and
I
want
to
be
able
to
override
some
of
those
things.
So
I
want
to
be
able
to
set
like
the
timeouts
or
my
circuit,
breakers
or
retries,
because
upstream
I
only
want
to
retry
once
with
a
one
second
timeout',
because
the
UI
is
gonna.
C
You
know
it's
gonna,
timeout
beforehand,
stuff
like
that,
so
you
kind
of
need
that
ability
to
override
sort
of
that
consumption
profile,
I,
guess
who
say
in
a
way
that
is
also
isolated
as
well.
So
that's
one
of
the
like
without
having
that
configuration
broken
out
as
a
separate
entity.
It
makes
it
really
hard
to
put
kind
of
authorization
rules
around
it,
so
we
can
run
it
in
a
multi-tenant
environment.
C
It
makes
it
pretty
challenging.
So
the
reason
why
I
kind
of
brought
this
to
this
group
is
we
were
going
to
look
to
actually
solve
this
problem
kind
of
in
our
admiral
project
and
just
use.
Seo
configuration
introduce
a
couple,
CR
DS
to
do
this
and
then
just
put
orchestration
to
manipulate
their
configuration,
that's
kind
of
a
popular
word
going
down,
but
I
figured
it
would
be
maybe
useful.
C
C
So
it's
not
necessarily
cloning
best
practices
back
in
this
would
be
a
little
bit
more
from
the
edge
perspective
of
what's
going
on
in
the
mesh
and
folding
into
the
spec,
which
I
don't
know
if
that's
appropriate
for
SMI
or
not,
but
I
know
as
I
thought.
I
would
just
bring
it
up
with
you
guys
and
kind
of
something.
That's
like
an
end
consumer
mesh
and
how
we're
trying
to
get
the
API
is.
F
F
C
Yeah
for
like
for
traffic
access,
like
you
so
at
least
from
again
this
is
this-
is
just
a
view
of
things
that
I've
done.
You
know
within
the
stuff
that
we
write,
but
what
we'll
do
is
we'll
author?
You
know
there'll
be
a
different
set
of
kind
of
rules
right,
the
kind
of
almost
like
scope,
definitions
in
a
lot,
I
guess
right
where
it's
like
this
is
sort
of
this.
This
sort
of
set
of
rules
gives
me
access
to
this
chunk
of
the
API.
C
In
this
chunk
of
the
API,
and
by
default
a
consumer
would
get
chunk.
Would
we
get
a
chunk
of
maybe
the
most
generic
part
of
the
API,
but
more
sensitive
api's
might
be
left
to
only
select
the
clients
right.
So
as
a
service
owner
I
might
say,
you
know
this
is
a
client
that
you
know
I
know
about
and
I'm
gonna
give
them
access
to.
This
particular
chunk
of
the
administration
part
of
the
API,
or
something
like
that,
so
that's
sort
of
where
I've
seen
it
from
an
access
perspective
be
useful.
C
F
I
guess
it
goes
back
to
the
identity
problem,
how
you
manage
identity
for
all
these
clients
in
in
SMI,
we
define
identity
in
a
very
common.
At
this
way.
It's
a
service
account,
so
we
define
how
things
get
access
based
on
the
service
account
that
initiates
the
call
and
the
service
account
that
let's
say
he's
running
the
workload
which
once
secured.
F
C
I
think
so
service
or
the
system
identifier,
is,
is
fine.
The
so
where
we
run
into
problems
using
service
accounts
is
especially
as
we
run
as
we
look
at
running.
A
servlet
like
a
typical
service
itself
will
end
up
being
at
least
a
lot
of
our
services
used
er.
So
we
end
up
running
the
same
service
across
multiple
clusters
and
those
clusters
are
isolated
from
each
other.
We
don't
use
like
Federation
or
anything
like
that.
C
So
so
we
actually
don't
use
a
service
account
really,
as
our
services
identity,
we
actually
use
it
a
different
mechanism
doing
that,
but
I
guess
I
guess
so
the
I
guess
to
like
to
make
SMI
useful
I
guess
it
might
need
to
have
a
be
able
to
have
identities
that
are
represented,
that
maybe
a
little
larger
than
one
cluster
or
make
that
part
pluggable
just
sorting
sense.
So
there's
there's
a
type
of
identity
that
can
be
used
or
something
that's
extensible
in
there,
because
the
identity
as
a
tricky
is
a
tricky
thing.
F
Well,
that's
debatable,
because
if
we
look
at
what
code
vendors
are
doing,
there
is
I
enrolled
to
service
account
is
a
DKE.
I
am
to
GCP.
I
am
to
service
accountants.
Also
in
a
way.
Even
if
you
have
different
ways
of
identities,
you
can
link
them
back
in
kubernetes
to
service
account
and
SMI
works
service
accounts.
So
if
you
can
link
a
service
account
to
an
external
identity,
then
SMI
doesn't
have
to
deal
with
it.
C
You
kind
of
come
in
from
other
class
results
a
little
bit
tricky
right,
so
I'm
calling
in
from
one
cluster
to
another
cluster
now
I
have
to
have
like
a
transitive
like
service
account
knowledge
in
between
the
clusters
and
so
but
so
like
then,
the
multi
cluster
kinda.
It
gets
a
little
bit
tricky,
but.
C
I
guess
I'm
not
really
like
I
guess:
I'm
not
really
debating,
like
the
the
service
account
aspect,
I'm
just
saying
more
fun
like
that.
The
idea
of
a
set
of
api's
that
are
focused
on
the
consumption
of
services
and
the
attributes
that
are
tailored
towards
service
consumption
I
think
that
would
that
would
be
valuable
as
a
way
to
build
sort
of
an
administration
boundary
around
that.
So
it
can
be
used
in
a
multi-tenant
fashion,
because
that's
more
of
the
the
thing.
A
C
A
Think
one
way
to
kind
of
like
make
the
logic
around
what
is
accessible
on
your
service.
What
routes
and
one
condition
is
accessible
on
your
service
is
to
kind
of
like
reuse.
The
traffic
spec
object,
topic
specs
object
across
different
traffic
targets,
which
would
be
used
for
different
services
to
configure
different
how
different
services
can
access
a
particular
service.
A
So
maybe
that's
something
to
kind
of
look
into,
but
I'd
love
to
like
dig
in
further
a
little
bit,
because
I
think
what
you're
talking
about
from
the
user
experience
side
is
very
interesting
and
there
might
be
like
a
higher
level
concept
that
we
could.
We
could
think
through.
We
haven't
really
tackled
retries
and
circuit
breaking,
although
that's
something
that
comes
up
repeatedly,
so
I
think
I
may
be
a
good
way
to
go
about.
C
B
F
A
Yes,
so
then
this
makes
sense
to
do
as
a
discussion
because,
like
so
usually
and
Jason,
we
just
like
okay,
how
people
open
up
an
issue
and
a
pull
request
with
the
changes
that
they
specific
changes
that
they
propose.
But
since
this
might
need
a
little
bit
more
async
back
and
forth,
the
discussion
makes
more
sense
here
for
sure
and.
C
A
F
F
It
why
it's
good
wise,
not
not,
if
she's
more
complicated
in
terms
of
things
you
have
to
fill
in
I,
felt
like
the
current
tissue
template
is
enough
or
what
we
are
seeing
but
yeah.
If
we
we
could
evolve
to
an
RFC
prototype,
but
yeah
I
feel
like
we
should
start
with
the
github
discussion
for
big
topics
that
we
we
didn't
touch
yet
in
a
semi
and
de
stand
from
there
create
issues
after
we
brainstorm
and
so
on.
I
think
that
in.
F
C
A
So
I'm
just
gonna
move
forward
here.
The
only
other
thing
that
we
have
on
the
agenda
is
a
link
to
issue
129
I
think
his
name
is
Adam.
Oh
Alex
long
had
proposed
that
we
extend
the
SMI
metrics
specs
to
support
metrics
per
route
and
I
think
this
is
a
great
idea
and
any
issues
with
a
proposal
I
approved
it
and
I
staphon
approved
it,
but
it
just
needs
to
be
rebased.
I
ping
them
on
slack
if
anybody
has
any
feedback
or
issues
or
anything
like
that.
A
E
Sorry,
I
I
share
an
office
with
my
wife,
so
when
I'm
talking
I
need
to
do
that,
but
yes,
indirectly,
the
key
Olli
team
is
involved
with
me.
That's
part
of
the
reason
kind
of
why
I
was
here
both
dropping
in
to
see
if
any
of
them
showed
up
as
well
as
do
a
little
bit
of
an
audit.
You
know
we
have
a
number
of
concerns
and
interest
where
we
would
really
like
to
be
more
closely
conforming
with
the
SMI
spec
and
some
other
ideas
around.
E
A
Directly
yeah
I
know
our
community's
super
interested
in
getting
us
my
support
in
in
key
ollie
for
sure
everybody's,
like
obsessed,
so
that
would
be
great
anything
to
make
that
happen
would
be
great
I'm
happy
to
help
John
hyuna's
on
this
call
he's
on
on
my
team
and
is
working
on
metrics
related
stuff,
so
he's
gonna
be
touching
SMI
metrics
pretty
soon
and
yeah.
There's
a
there's
a
lot
of
interest
around
there.
A
E
F
F
F
F
F
B
F
A
F
A
F
A
Sounds
good,
oh
and
then
the
other
thing
I
was
gonna
focus
on
it.
I,
like
maybe
Thursday
or
Friday
of
this
week,
is
like
kubernetes,
ingress
and
kind
of
like
adding
some
documentation
around
how
SMI
thinks
about
north
sorta
north-south
traffic.
I
know
you
opened
a
proposal
or
open
an
issue
around
that
stuff
on
so
I.
Just
I
meant
to
get
to
it
before
this
meeting,
but
I
didn't
so
on
the
back
tomorrow.
A
A
We're
still
having
some
issues
around
like
how
to
think
about
if
you
install
a
traffic
split
but
there's
a
traffic
target
that
doesn't
allow
the
traffic
split
to
actually
happen
like
what
the
error
code
should
be,
that
bubble
up
and
how
to
modify
the
status
object.
Thanks
thanks
for
the
status,
so
so
we're
just
still
thinking
through
that.
But
I
will
just
update
the
issue.
I
think
Stefan
you're
applied
to
it
right,
yeah.
F
B
F
F
A
Okay,
that's
literally
all
that
I've
been
thinking
about
any
anything
else.
Anyone
want
to
add
I
mean
I
have
sessions
at
coop
crime
Redbeard,
you
not
this
time.
No,
all
right
cool.
All
right,
I'll,
just
give
everyone
three
minutes
back.
Thank
you.
Everyone
who
is
new
and
introduce
themselves
and
everybody
else
for
being
here,
have
a
great
day.