►
From YouTube: CNCF Service Mesh Interface 2021-03-31
Description
CNCF Service Mesh Interface 2021-03-31
A
Hey
everyone
today
is
wednesday
march
31st.
Welcome
to
the
smi
community
meeting
I'm
going
to
be
monitoring
today.
My
name
is
michelle
and
bridget
is
going
to
be
taking
notes.
Thank
you
bridget.
So
we
have
a
few
discussion
items
today,
but
it's
a
light
meeting.
So
if
anybody
wants
to
introduce
themselves
at
the
end
or
want
some
bring
up
some
ad
hoc
discussion
topics,
you're
welcome
to
do
so.
A
B
All
right,
I
apologize
hey.
I
just
got
some.
I
just
got
details
on
the
virtual
sessions
that
are
available
to
us
and
the
well,
I'm
sorry,
the
breakouts,
the
office
hours
and
the
virtual
booth
that
will
be
available
to
us.
I
was
just
put
a
link
into
the
meeting
minutes,
and
so
that
might
be
something
to
share
here
briefly.
B
The
gist
of
it
is
time
is
against
us.
I
think
there's
a
I'm,
I'm
not
too!
I'm
only
like
a
day
tardy
and
sharing
this
info.
So
I
so
please
don't
kill
me
as
I
say
that
some
of
the
materials
for
the
booth
would
need
to
be.
I
guess
the
deadline
is
this
friday,
so
there's
I've
kind
of
copied
and
pasted
nearly
all
the
details
into
the
into
a
shared,
a
google
doc
that,
hopefully
all
of
you
can
get
to
like
as
you
digest.
B
So
so
the
the
project
booth
off
hours
are
listed
in
there.
Hopefully,
we
would
get
enough
maintainers
to
try
to
have
a
person
covering
most
of
the
time,
but
the
materials
that
we
would
leave
behind
for
people
to
pick
up
as
and
when
or
watch
a
recorded
video.
What
have
you
it
would
be,
would
be
there.
B
In
the
absence
of
any
of
any
of
us,
I'm
sitting
there
there's
as
a
sandbox
project,
we're
afforded
up
to
two
office
hours
or
up
to
two
sessions
so
kind
of
a
question
to
all
of
all
of
us.
Hey.
Do
we
we're
looking
for
one
of
those
or
two
of
those,
and
do
people
have
an
opinion
on
the
format
of
those
or
should
they
be
about
you
know?
Should
we
do
two,
and
should
they
be
the
same
or
should
we
do
one.
C
A
D
D
A
A
A
C
B
Yeah,
the
other
thing
that
we
can
do,
there's
a
maybe
like
two
other
things
we
can
do.
One
is,
I
just
grabbed
the
template
for
kubecon
eu
and
put
it
out
there
for
all
of
us
to
figure
out
what
slides
we
might
want
to
talk
about
over
the
office
hours
and
or
potentially
slides
to
also
loop
through
in
the
virtual
booth.
B
It's
a
little
some
of
the
wording
in
the
instructions
a
little
bit
confusing
as
to
how
many
different
videos
could
be
shared
in
the
virtual
booth,
because
some
of
that,
like
some
of
that,
is
stated
in
terms
of
your
sponsorship
level,
not
necessarily
in
terms
of
your
project
level,
so
I'll
clarify
with
the
organizers
about
that.
Also,
I've
sent
out
an
in
clarification
on.
B
C
A
A
Okay,
so
I
think
the
calls
to
action
lee
are
to
sign
up
for
the
booth
and
to
I
guess,
sync
with
you
async
on
who
can
do
which
slide.
I
think
it
like,
in
my
opinion,
just
from
doing
these
in
the
past.
It
helps
to
just
have
two
or
three
people
from
the
group.
Two
people
really
ideally
to
just
do
the
presentation,
rather
than
spreading
it
across
a
bunch
of
people.
Would
you
be
down
for
that
strategy,
or
do
you
have
another
specific
way
that
you
want
to
go
about?
It.
B
B
B
A
Okay,
so
just
the
presentation
before
friday-
okay,
great
that
sounds
good.
Okay.
Thank
you
I'll
review
the
slides
as
well.
Okay,
cool
next
conversation
is
about
the
smi
controller
sdk
project,
which
has
been
moved
over
to
the
service
mesh
interface
because
it
was
donate
or
service
mesh
interface,
github
org.
So
it's
donated
by
nick
jackson.
Thank
you
nick.
So
much
for
your
contribution.
A
I
did
get
a
chance
to
review.
It
left
some
pr's
and
some
issues,
so
we
can
kind
of
like
work.
Async
on
how
to
you
know,
do
the
next
steps.
I
had
a
build
error
that
we
talked
about
earlier
and
then
I
also
added
a
contributing
dock
and,
like
all
the
you
know,
the
oss
hygiene
stuff,
but
kind
of
going
back
to
the
build.
Oh
actually,
two
things
I
wanted
to
just
discuss
quickly:
one
is
governance
and
like
pr
reviews,
so
in
the
contributing
doc.
D
B
D
That
needs
to
be
done
around
the
go
sdk
to
do
the
the
conversion
web
hook
stuff.
I've
done
some
examples
of
that.
It's
it's
pretty
easy
going.
It's!
It
actually
makes
a
really
great
first
contribution
for
any
go
programmers
or
folks
who
are
learning
how
to
program
go
and
would
like
to
contribute
to
smi.
D
D
D
I
would
definitely
love
some
some
help
around
specifically
the
the
conversion
web
hook
code
that
needs
to
go
onto
the
main
sdk
and
please
you
know
ping
me
around
that
and
I'll
happily
show
people
what
needs
to
be
what
needs
to
be
done
to
implement
that,
but
it
is
just
kind
of
converting
one
object
to
another
using
the
the
sort
of
the
the
coupe
builder
interfaces
and
things
it's
a
great
opportunity
to
learn
some
goals.
Well,
if
you're
interested
in
doing
that,
oh
awesome,
well,
michelle
michelle
wins
for
losers.
A
D
Right
awesome:
well,
let's,
let's
chat
async
after
the
after
the
meeting
I'll
fix
the
bug,
which
I'm
pretty
sure
is
just
a
reference
and
I'll
get
that
uploaded
for
you
and
then
then
we
can
chat,
because
I
can
put
some
time
together
tomorrow
morning
to
to
work
on
some
stuff
as
well
and
maybe
get
the
first
of
the
initial
pr's
from
my
private
branch.
Well
now,
it's
not
private
branch.
My
my
folk
of
the
go
sdk
merged
merged
upstream,
it's
yeah!
E
A
I
think
we
did
correct
me
if
I'm
wrong,
but
I
think
that
we
were
talking
about
that.
We
were
saying,
I
think
we
landed
on.
This
might
be
something
that
the
implementation
handles
rather
than
smi,
or
did
we
want
to
kind
of
further
explore
and
propose
a
way
for
people
to
plug
and
play
the
auth
piece
via
smi
nick
lee?
I
think
y'all
were
involved
in
that
discussion
as
well.
A
D
D
I
would
also
say
that
if
we
were
going
to
support
spiffy
id,
we
would
we
need
to
support
some
form
of
grapping
or
globbing
within
the
spiffy
id,
because
the
spiffy
id
is
obviously
composed
of
the
service
identification,
the
unique
id
the
service,
the
group,
etc,
etc.
Depending
on
how
you
you
cut
that
up
so
potentially
for
for
to
make
spiffy
id,
you
would
need
to
have
you
know
a
way
to
kind
of
say
it's
this
part
of
the
spiffy
id
either
the
domain
part
or
the
the
the
service
part.
D
As
I
say,
there's
there's
no
hard
rules
on
on
how
you
define
that,
but
it's
it's
just
a
uri,
so
regex
with
a
uri-based
syntax
would
would
probably
work.
I
mean
I
think
that
makes
sense
to
to
me
to
support
that.
I
don't
know
whether
we
would
need
a
filter
and-
and
I
don't
know
I
mean
I'm-
not
against
the
idea
of
the
extensibility
mind.
D
My
concern
is
that
with
filters
you
you're
starting
to
talk
about
implementation
details.
So
it's
can.
We
create
a
a
method
that
allows
to
to
not
worry
about
implementation,
detail,
the
other
problem
that
we
have
when
we
start
talking
about
the
sort
of
the
hard
coding
aspect
around
spiffy
id,
and
I'm
not
saying
it's
a
reason
why
we
shouldn't
do
it,
but
it's
something
you
have
to
bear
in
mind.
D
Not
all
service
meshes
use
spiffy
id
as
their
as
their
identifier.
So
if
you,
if
you
have
a
traffic
target
which
depends
on
a
spiffy
id,
you
break
the
ability
to
have
a
portable
implementation
of
smi.
So
that's
that
you
know
that.
That's
it's
not
necessarily
a
problem
depending
on
what
your
use
case,
but
it's
it's
certainly
something
that
that
should
be
considered.
I
think.
A
A
Oh
you
have
to
like
embed
the
spiffy
id
in
a
like
service,
account
object
or
a
secret
object
or
a
config
map
object,
because
that
seems
like
a
barrier
to
entry
and
like
I
don't
want
to
like,
create
a
new
kubernetes
object
for
and
also
like.
You
know
what,
if
folks
want
to
like,
not
use.
Kubernetes
like
we
were
definitely
going
towards,
like
hybrid
scenarios,
at
least
on
our
side.
So
so.
B
That
that's
a
topic
onto
its
own
about
smi.
Like
I
I
happy
to
hear
you
say
that
kind
of
thing,
sorry
to
interrupt.
I
just
like
it,
but
it's
just
it's
stated
like
so
like
front
and
center
on
the
smi
spec
page,
that,
like
the
word
kubernetes
and
how
centric
it
is,
and
how
that
said,
something
that
I'd
poked
at
brendan
and
gave
about
a
couple
years
about
a
year
and
a
half
or
what
a
couple
years
ago,
whatever
it
was
that
but
yeah.
B
So
I'm
supportive
of
that
statement,
michelle
and
and
kind
of
the
same
thing
that
nick
was
articulating
around
around
marlo's
use
case
or
the
use
cases
described
in
the
issue
being
really
intriguing
to
me
or
like
interesting
and
like
yeah.
Why
hey?
Why,
wouldn't
you
know,
smi
is
a
you
know,
have
a
spec
that
covers
this
kind
of
a
thing
that
it's
been
entirely
a
coincidence,
but
the
fact
that
I'm
wearing
an
hpe
shirt
is
like
is
weird
because
of
the
interactions
that
I
have
with
folks
there.
E
D
A
Yeah,
like
some
stuff
in
the
sdk,
would
have
to
change,
but
I
don't
think
that
that's
an
issue.
I
like
the
idea
of
kind
of
going
with
that
simplest
approach.
I
don't
think
anybody
disagrees
on
like
wanting
to
support
spiffy
identities
or
really
any
I
mean.
There's
gonna
be
a
multitude
of
types
of
identities.
We
should
support,
and
even
in
the
spec
it
highlights
that
we
only
support
service
count
for
now
and
we
want
to
add
other
identities.
A
A
D
A
That
brings
up
a
good
point
like
who
actually
exposes
the
spiffy
ids
to
the
end
users,
and
I
think
sdo
does,
if
I'm
not
mistaken,
maybe
it'd
be
worth
looking
at
other
implementations
that
use
spiffy,
but
regardless
I'm
not
like
opposed,
and
I
think
we
should
be
adding
a
multitude
of
identities.
Anybody
else
want
to
chime
in.
On
the
this
conversation.
F
Yeah,
I
think
that
that
particular
section
there's
two
schools
of
thoughts
here
and
they're
both
likely
to
be
used
in
both
environments,
that
it
is
important
to
have
something
where
you
can
have
a
transparent
mode.
They're
just
going
to
be
applications
that
have
no
understanding
of
spiffy.
They
don't
care
about
it
and
security
is
around.
The
network
is
the
infrastructure's
problem.
F
They
may
have
their
own
tokens
or
things
that
they
drive,
but
they
don't
really
care
about
what
they're
what
they're
running
on.
And
then
you
have
other
environments
that
they're
looking
to
drive
that
identity
down
to
the
application
level
itself,
so
that
the
application
consumes
and
and
validates
at
the
tls
layer
itself
and
applies
its
policy
and
it
makes
decisions
on
what
to
do
with
the
at
the
l4
l7
layer,
even
with
including
things
using
like
the
jwt
token.
F
So
spiffy
can
can
do
a
x509
or
you
can
do
a
jwt,
that's
signed
by
that
same
x509
certificate
to
to
use
as
a
token,
and
you
set
the
audience
as
to
what
you're
communicating
with
so
there's.
There's
multiple
paths
towards
that,
but
some
of
the
some
of
the
infrastructure
that
that
I've
been
looking
at
is
less
about.
F
How
do
you
identify?
How
do
you
create
an
identity
within
a
cluster
but
is
more
and
is
leaning
more
towards?
How
do
I
identify?
How
do
I
create
an
identity
for
a
workload
in
a
in
an
enterprise
that
I
can
then
use
that
identity
to
validate
against
services
that
are
not
in
my
cluster?
That's
so
I
can
do
cross-cluster
or
even
organizational
identity
strategies
that
are
holistic
for
the
whole
organization,
and
one
of
the
big
problems
we
run
into
right
now
is
that
all
of
the
identity
strategies
for
most
service
meshes?
F
Are
they
weld
identity
to
the
cluster,
and
when
you
try
to
do
a
multi-cluster
identity,
it's
it
just.
Doesn't
it
just
doesn't
work,
and
so
that's
those
are
some
of
the
things
that
I'm
seeing
in
this
particular
in
this
particular
space,
and
I
think,
there's
a
lot
of
value
in
trying
to
work
out
well.
Is
it
possible
to
do
something
that
that
smi?
Yes,
we
do
something
on
identity,
but
also
in
the
long
run.
D
Yeah
I
mean,
I
think
I
think
we
have
to
be
careful
about
implementation.
I
mean
I'm
I'm
pro-spiffy
and
I
would
recommend
folks
folks
use
that,
but
I
think
we've
got
to
be
appreciative
of
of
other
methods.
Just
for
a
very
quick
bit
of
context.
The
the
reason
behind
service
mesh,
sorry
service
measure
service
account
was
that
it
was
down
to
the
implementation
to
the
id
lookup
based
on.
D
So
you
would
basically
look
for
application
instances
or
pods
or
whatever,
which,
which
use
the
have
a
service
account
applied
to
it
service
account,
which
obviously
you
can
control
the
application
using
rbc,
etc,
and
then
the
the
implementation
would
would
look
up
the
the
actual
underlying
id,
but
you're
100,
frederick.
That
falls
down
when
you're
outside
of
kubernetes,
and
we
you
know,
I
think
it's
valuable
for
smi
to
support
a
broader
picture.
So
I'm
I'm
totally
supportive
of
this.
If
you.
F
And
if
you
want
some
prior
art,
look
at
before
kubernetes
existed
things
like
histrix
and
netflix,
which
surface
meshes
are
a
downstream
or
the
descendant
of
that
and
you'll
see
that
that
was
originally
a
company-wide
strategy,
not
a
lot
of
cluster
strategy
and
then
the
way
we
developed
service
mesh
within
clusters
was
a
hyper
focus
of
those
technologies
into
a
single
cluster.
So
in
a
way
it's
I'm
not
saying
it
was
a
bad
move.
F
F
And
I
don't
know
what
the
right
balance
of
that
is
like?
That's,
that's
going
to
be
a
a
fun
area,
so
it's!
I
think
it's
about
finding
that
flight.
That
framework
that
allows
you
to
to
do
either
that
if
your
service
mesh
doesn't
really
let
you
do
that,
then
you
don't
really
have
a
choice,
but
if
it
does,
then
you
have
the
option
to
to
bring
that
into
into
the
picture
and
striking
the
balancer
is
going
to
be
important.
D
F
Yeah,
I'm
happy
to
put
together
some
some
material
and
see
what
we
can
do
in
that
in
that
particular
space,
and
I
I
think
this
is
something
that
we
have
to
look
at
iteratively.
I
don't
want
to
just
draft
something
and
throw
it
out
and
say:
okay,
it's
part
of
the
stack
and
I
don't
think
you're
suggesting
that
either.
But,
but
I
think
it's
it's
an
area
that,
like
I
don't.
F
A
You
can
always
volunteer
me:
hey
we're
at
we're
overtime,
but
thank
you
so
much
everyone
for
a
great
discussion,
frederick,
let's
let's
definitely
talk
via
slack
and
also
post
on
the
issue
just
so
everyone
can
follow
along
next
week.
We
have
a
discussion
on
multi-cluster,
so
this
is
super
relevant
for
that
as
well.
If
you
could
join
and
if
anybody
else
who
wants
to
join
that,
please
see
the
slack
channel
for
more
information,
and
does
anybody
want
to
moderate
next
week.