►
From YouTube: CNCF Service Mesh Interface Project 2021-04-21
Description
CNCF Service Mesh Interface Project 2021-04-21
A
All
right
welcome
to
our
special
edition
of
smi
meeting.
This
one
is
the
working
group
on
multi-cluster
and
if
you
haven't
yet
please
add
your
name
to
the
attendees
list
and
the
last
time
we
had
this.
A
A
and
obviously,
for
the
benefit
of
everyone
else
out
there.
We
want
to
any
kind
of
discussions
or
or
resolutions
agreement.
We
should
also
document
that
that
issue,
so
that
everyone
who
is
watching
on
that
issue,
not
looking
at
our
google
launcher,
sees
where
we
are
so
any
any
question
to
what
we
discussed
the
last
time
april.
7Th
is
anyone
who
is
who
has
not
been
in
the
previous
call,
any
questions
where
we
are
with
with
this
multi-cluster.
A
If
you
look
at
april
7,
you
should
see
where
we
were
so
general
consensus.
Yes,
we
want
to
do
that
and
today
is
coping
yeah,
I
think,
depending
on
how
fast
or
how
far
we
get
and
we
might
be
able
to
do
more.
Also,
you
know
what
are
the
implications
in
terms
of
the
charter.
A
There
might
be
some
housekeeping
or
whatever
to
do
with
the
ncf
regarding
the
smi
charger
and
then
how
we
proceed
in
terms
of
timeline
and
what
do
we
need
a
draft
probably
a
poc,
etc,
yeah,
any
any
questions
so
far.
A
It's
a
really
good
question.
So,
if
you
look
at
the
issue
212,
it
offers
a
number
of
opportunities
or
possibilities
options
and
at
least
from
from
buyer,
with
my
aws
head
on
our
point
of
view,
it
would
be
really
great
to
support
what
nick
called
heterogeneous
workloads
or
I
just
called
cross
compute.
So
think
of
you
know,
you
have
a
monolith
running
on
a
virtual
machine.
You
have
some
functions,
you
have
some
managed
or
not
so
many
communities
and
ideally,
in
other
words
we
would
be
able
to
mesh
across
these
different
compute
environments.
A
That's
at
least
our
point
of
view.
Yeah
thoughts
do
other
people
have
other
like.
I
would
specifically
be
interested
in
if
anyone
says
like
no,
we
should,
you
know,
focus
only
on
communities.
We
should,
you
know,
address
anything
outside
of
communities.
That
is,
I
think,
the
gist
at
the
core
of
this
discussion.
B
D
There
I
definitely
agree
with
asura.
In
fact,
I
think
it
was
about.
A
year
ago
I
opened
up
a
kind
of
a
proposal,
pr
against
smi
and
thomas
rampelberg,
and
I
kept
going
back
and
forth
discussing
various
options
to
bring
in
heterogeneous
payloads
super
interested
in
that
as
well.
Can
you
share
that?
That
sounds
awesome?
I
I'm
not
aware
of
it.
I
have
to
yeah.
Let
me
pull
it
up.
I've
been
thinking
about
it.
It's
now
a
closed
pr
authored
by
another
version
of
me.
D
It's
actually
prs67
june
10th
2020,
and
I
will
share
it
in
a
second
now.
Whether
pr
is
the
right
form
to
have
this
kind
of
a
discussion,
it's
a
separate
story,
but
it
kind
of
has
a
few
proposals.
Myself
lockheed
thomas
rampelberg
kind
of
discussing
and
going
back
and
forth
on
various
options.
A
Well,
that's
awesome.
Thank
you
very
much.
That's
super
helpful
and
I
think
yeah
the
right
way
to
go.
What
is,
I
think,
first
to
have
that
discussion
in
terms
of
scoping
and
everything.
Otherwise,
it's
a
little
bit
like
here's.
A
pr,
please
merge
by.
D
D
And
it's
interesting,
I
should
comment
because
we're
talking
about
multi-cluster
and
it
almost
sounds
like
heterogeneous
payloads
is
slightly
orthogonal
and
I
know
we
talked
about
that
last
time,
but
then,
if
you
think
really
deeply
well
multi-cluster,
perhaps
on
the
one
end
of
the
spectrum,
it
seems
like
heterogeneous
payload
is
something
very
different
than
multi-cluster.
D
Yet
it
might
be
the
exact
same
thing.
So
I
wonder
how
folks
think
about
that?
Are
they
the
same
thing?
Are
they
different.
E
E
Make
it
yeah
that's
right,
let's
make
it
interesting.
I
think
what
you
articulated
was
was,
from
my
perspective,
probably
spot
on
that,
like
yeah,
depending
upon
the
angle
from
which
you
look
at
this,
like
that's
a
an
orthogonal
but
slightly
related
problem,
and
if
you
kind
of
look
at
it
from
another
angle,
it's
like
well,
we
could,
probably
you
know,
two
birds
with
one
stone
kind
of
a
thing
and
like
that
it
certainly
makes
it
until
it's
proven
that
you're
gonna
have
to
pick
up
two
stones.
E
Maybe
we
should
just
pick
up
one
and
see
if,
if
that
works,
so
yeah.
E
Speaking
of,
if
I
may,
and
sergio
does
refresh
my
memory
does,
does
hamlet
account
for
so
clearly
accounts
for
multi-cluster
sort
of
service,
catalog
exchange,
but
heterogeneous
workloads
is
that
that's
accounted
for
as
well.
In
this
spec.
F
But
when
we
go
one
level
down
right,
if
we
double
click,
let's
say
we
have
two
platforms:
we
double
click
on
one
of
them,
for
that
platform
is
going
to
be
homogeneous
workloads
right.
So
behind
that
platform
we
may
have
multiple
clusters
or
single
clusters,
or
not
even
clusters,
right,
depending
on
what
the
platform
is
and
for
homogeneous
platforms,
you
may
want
to
interchange
richer
data
right
because
it
is
a.
F
Maybe
it
is
a
proprietary
platform
and
you
may
want
to
you
know,
do
more
things
than
the
ones
you
would
do
with
hamlet.
So
I
think
that
objectives
may
be
different.
That
doesn't
mean
that
hamlet
cannot
do
multi-clustering
as
well
right.
So
we
have
used
that
internally
in
vmware
to
do
some
plc
with
multi-cluster,
and
the
conclusion
we
reached
is
that
for
multi-cluster
you
may
want
to
expose
richer
endpoints.
A
Cool
thanks
for
the
clarification
that
helps
a
lot.
I
just
realized
that
I
I
failed
to
ask
new
people.
So
if
you're
first
time
on
this
call
or
in
this
working
group,
please
feel
free
to
introduce
yourself.
I
at
least
don't
recognize
every
name
and
or
face
so
you
don't
have
to.
But
if
you
want
to
first
time,
if
you're
the
first
time
around,
please
please
do.
G
Sure
I'll
go
first,
my
name
is
johnson.
I
just
joined
the
microsoft
open
service
team
about
two
three
weeks
ago
three
weeks
ago.
I
think
and
still
learning
stuff-
and
you
know
you
know
I
I
decided
to
be
more
proactive
in
the
smi
project.
It's
a
very
noble
project,
noble
goals,
trying
to
unite
all
of
the
capabilities
of
various
service
messages
to
have
a
standard
spec.
You
know
it's
very
noble
and
nice,
so
yeah,
I'm
still
learning
and
you
know.
Hopefully
I
get
to
contribute
in
the
future.
C
Yeah,
we
can't
hear
you
allen,
but
I
am
interested,
though
michael,
because
you
put
a
few
other
notes
about
where
we
take
this
discussion,
while
ellen
sorts
out
his
audio
and
I'm
curious
what
you
mean
by
changed
in
the
charter.
I
just
looked
at
like
the
repo
for
the
spec
and
it
says
specification
for
service
messages
that
run
on
kubernetes.
It
doesn't
say
exclusively
so
if
we
needed.
B
C
A
A
I
think
I
I
I
can't
remember
who
brought
it
up.
I
think
it
was
last
time
where
I
was
like.
Oh,
we
need
to
look
at
if
our
chart
actually
allows
us
to
do
it
and
if
everyone
agrees
fine,
I
just
want
to
avoid
the
situation
where
you
know
at
some
point
in
time
on
tc
level,
whatever
someone
says
like
whoa,
what
are
you
folks
doing?
You're
not
charged
to
do
that
right
so
to
make
sure
that
we
do
the
homework.
A
If
everyone
is
on
the
same
page,
saying
like
yep,
we're
absolutely
chartered
to
do
it,
fine,
we
can
cross
that
off.
We
can
say
yeah,
you
know
smiles,
says
yeah.
We
we
all
agree
on
that.
We're
allowed
to
do
that,
just
to
make
sure
that
we
we
are
in
charge
of
water,
so
to
speak.
E
A
couple
of
very
positive
thoughts,
actually
that
one
I
when
I
had
that,
so
it
was
brendan
burns
that
I'd
asked
this
of
a
time
or
two.
E
When
you
know
a
year
and
a
half
ago
when
smith
came
around-
and
I
was
dismayed
by
the
answer
at
the
time,
which
was
exclu
like
an
exclusive
focus
to
kubernetes
and
that's
why
I'm
on
this
call,
because
I'm
because
this
is
because
I'm
a
proponent
of
this
discussion
and
and
then
I
think
the
other
good
news
to
this-
is
that
well
one.
I
would.
E
From
my
vantage
point,
I
would
say
that
it's
that
approval
from
the
toc
is
not
required
and
if
there's
any
amount
of
formality
to
be
done
in
this
regard,
that
that
there's
a
level
there's
a
step
before
the
toc,
which
is
sig
network
within
the
cncf
cncf
sig
network,
that
this
is
a
forum
in
which
this
could
be
presented,
and
then
some
amount
of
rubber
stamping
can
happen.
E
And
since
I
I
share
that
I'm
working
or
that
sig
that's
also
helpful.
I
mean
not
that
it
wouldn't
be
evaluated
abstractly
and
things,
but
in
general
in
general.
The
the
answer
here
is
that
unless
there
was
something
really
unless
it
was
like
to
not
work
with
kubernetes
like
if
that
was
the
change
of
the
charter,
it
would
be.
I
think
the
the
sentiment
of
a
few
different
toc
members
would
be
more
like.
Well,
I'm
not
sure
why
you're
asking
us
this,
like
that's
more.
That's.
A
A
This
is
the
way
how
we
we
interpret
the
charter
and
we
are
perfectly
fine
with
as
long
as
we
continue
to
support
communities,
obviously
that
to
me
that
goes
without
saying,
I
think
no
one
suggests
to
drop
that
part.
It's
just
really
are
we
beyond
that
also
allowed
to
to
cover
other
compute
environments
or
whatever
and.
C
I
would
suggest
we
have
a
mechanism
for
this
in
that,
if
you
wanted
to
just
put
a
an
you
know,
pr
or
or
I
could
make
a
pr
that
just
changes
the
language
instead
of
service
messages
that
run
on
kubernetes,
saying
service
meshes,
including
those
that
run
on
kubernetes,
and
then
we
could
get
an
lgtm
from
everyone
who
cares
that.
A
Sounds
awesome.
Let's
please
do
that
and
and
also
if,
if
I
don't
know
if
you
find
it
necessary
to
kind
of
like
surface
that
towards
tlc
or
like
you
know,
fyi
or
whatever,
otherwise
we
can
just
you
know,
have
that
pr
and
see.
If
anyone
you
know
says
hey
here,
major
objection
sounds
good
to
me.
Let's
do
that.
E
Nice
yeah.
I
think
that
it
is
that
servicing
it
within
sig
network
and
to
the
extent
that
the
toc
liaisons,
that
focus
on
sig
network
that
it's
like
to
bridge
bridget,
has
like
a
fair
point
which
is
like
well
technically
technically
the
language
didn't.
You
know
it
doesn't
say
that
it
won't
work
on
mars
either
like
what
you
know.
What's
going
on
like
why
don't
we?
Why
is
this
an
issue?
E
It
sounds
good
yeah,
but
I
think
that
doing
so
briefly
doing
so
like
actually
there's
there's
two
benefits,
there's
one
that
might
be
somewhat
tangible
and
it
is
awareness
and
solicitation
of
interest
from
others
exactly.
A
Exactly
exactly
exactly
yeah
doesn't
cost
us
anything,
and
it
shows
the
good
will
that
we
are
not
really
trying
to
hide
anything
right.
It's
not
like
twitching
to
do
something
in
in
secret,
but
but
you're
spot
on
bridget.
We
have
a
process
for
that.
That
is
a
pr,
and
if
you
kick
that
off,
it
would
be
very
clear
if
there
is
someone
objecting
to
it
or
everyone
in
agreement.
Yes,
let's
do
that
cool.
Then
we
have
another
12
minutes.
If,
given
that
we
have
figured
out
that
part
again,
let's
try
l
nyu.
H
Yeah,
I
just
dropped
a
message
in
the
chat
I
was
going
to
skip.
I'm
a
new
member
and
just
like
johnson
just
joined
the
open
source
smash
team
yeah
so
because
I'm
a
little
bit
interested
in
the
multi-clustered
vertical.
So
that's
my
first
time
joining
the
this
meeting
and
say
hi
to
everyone.
Welcome.
I
Okay
cool,
so
my
name
is
sanya,
I'm
also
on
the
open
service
mesh
team.
I've
been
here
for
a
bit
longer,
but
hadn't
made
it
up
to
an
smi
community
goal.
Yet
so
just
wanted
to
come
on
here
and
see.
What's
going
on
with
the
community
and
say
hello.
A
A
Well
then,
let's
move
on
to
the
to
the
next
steps
in
terms
of
timeline,
in
terms
of
I
initially
had
this
in
mind
where,
if
we
have
a
draft
of
that,
and
then
we
have
a
plc
kind
of
like
trying
trying
to
see
how
that
feels
if
we
implement
it
or
when
we
implemented
and
then
obviously
the
overall
timeline
right
now,
is
that
something
that
we
want
to
do
within
the
next
couple
of
weeks
is
that
by
end
of
year
like,
where
are
we,
which
obviously
has
to
do
with
you
know?
A
Who?
Who
is
volunteering
their
time
to?
You
know
four
different
parts
for
the
drafting,
the
the
stuff,
the
poc,
etc
yeah,
any
any
ideas,
any
volunteers,
any
suggestions,
anything
in
that
direction.
Next
steps.
D
A
So,
just
to
be
clear,
that's
great
to
hear
and
just
to
be
clear.
I
would
not
necessarily
jump
directly
into
into
a
pr,
but
I
would
say,
like
you
know,
really
in
the
the
way
it
is
kind
of
common
that
you
know
you
have
a
design
document
where
you
talk
about
you
know
this
is
this
is
the
actual
scope.
This
is
what
we're
trying
to
achieve
here
are
some
examples
of
these
environments
and
then
actually
fleshing
out
a
design
document
right.
That
is
roughly
what
at
least
what
I
had
in
my
again.
D
That
matches
kind
of
my
my
thinking
as
well
in
in
the
open
service
mesh
repo.
We
have
one
issue
which
says
start
a
design
dock
around.
What
multi-cluster
may
look
like,
so
I
would
love
to
kind
of
leverage
that
and
open
it
up
just
broader
and
and
then
think
about
what
sergio
said.
What
we've
been
discussing
here,
kind
of.
A
A
If,
like
10
people
say
like
oh,
we
love
to
work
on
it,
but
like
no
one
is
responsible,
but
having
like
two
or
three
people,
maybe
two
is
this:
is
the
right
number
to
own
that
design
document
to
say
like
this
is
what
we
suggest
and
everyone
else
on
the
call
wider
smi
community,
obviously
putting
in
requirements
saying
like
you
know
here
we
want
to
be
able
to
do
whatever
it
is.
You
want
to
do
whatever
your
environment
is.
Maybe
it's
something
we
haven't
been
thinking
about
right.
A
It
might
be
some
raspberry,
podcast
or
whatever.
I
I
don't
know
right
and
to
answer
pritchett's
question,
I'm
more
than
happy
to
provide
feedback
to
review
and
provide
feedback.
So
it's
great
to
see
dylan
and
search
you
to
to
co-own.
That
and
again
this
is
not
like.
If
someone
else
wants
to
you
know,
try
a
minute
and
say
yeah
happy
to,
for
example,
there
might
be
some
work
around
compliance
right,
for
example,
just
say
hour
or
test
cases
or
whatever
right.
A
So
there
is
plenty
of
work
to
be
done,
but
having
having
two
people
to
volunteer
to
say
yep,
we
want
to
lead
this,
this
design
document-
that's
already
super
awesome,
that's
much
more
than
I
I
was
hoping
for
today.
To
be
honest,
that's
great.
J
And
yeah,
but
I'm
potentially
interested
in
experiencing
the
design
dock
too
less
likely
to
focus
on
like
early
like
proof
of
concept
code
writing
stuff,
but
like
design
docs.
Certainly
that's
like
within
what
I'm
anticipating
like
working
on
for
from
constant
perspective
anyway
and
like
that's
kind
of
like
the
stage
of
the
project
that
we're
at
look
at
more
of
like
a
longer
term,
something
by
end
of
year,
proof
of
concept,
kind
of
timeline,
right,
yeah,
right,
happy
to
help
like
scoop
out
the
problem
early
on
for
sure
yeah.
A
I
mean
the
natural
place,
would
I
guess,
be
kubecon
north
america?
If
we
set
ourselves
to
go
that
we
can
present
the
poc
or
whatever
how
far
we
get
there,
then
we
have
something
that
we
can
work
towards.
We
can
say:
okay,
you
know
we
know
this
is
x
month
and
you
know
how
long
will
we
spend
on
the
design?
A
How
long
you
know,
maybe
even
already
in
parallel,
starting
with
poc
and
and
potentially
different
other
folks
who
are
not
on
that
call
today
say
like
oh
yeah,
if
there's
a
design
document,
I'm
happy
to
you
know:
do
a
test
implementation
against
that
or
pc
against
that
cool.
We
have
some
six
minutes
left,
so
any
comments.
Anyone
else,
volunteering
with
something
any
thoughts.
C
It
sounds
like
by
this
working
group
meeting
and
that
happens
again
in
two
weeks:
we'll
have
a
regular
community
meeting
next
week.
It
sounds
like
by
two
weeks
from
now.
It
would
be
nice
if,
during
that
meeting,
sergio
and
deleon
want
to
give
us
an
overview
of
what
they've
started
sketching
out
so
far.
That
would
be
kind
of
cool.
That's
an
agenda
item
for
two
weeks
from
now
that.
C
A
A
I
don't
think
that
we
can
resolve
it
within
five
minutes
but
being
able
in
the
design
document
to
say
yes
we're
going
to
tackle
that
or
you
know,
here's
what
we
think
about
it
or
not.
That
would
be
super
helpful
and
I
mean
now
you
have
two
weeks
time,
for
you
know
some
I
mean
20
pages
would
be
enough.
That's
perfectly
fine
right,
don't
do
don't
overdo
it
right.
D
A
Use
this
like
channel,
that's
it's
transparent!
Just
assume
that
not
everyone
who
is
interested
in
is
necessary
on
that
call
or
will
see
that
recording
so
used
selection
used
mainly
in
this
thing
like
here's.
What
we
intend
to
do
here
is
where
you
should
look,
etc,
etc,
so
that
everyone
asynchronously
has
a
chance
to
catch
up
and
contribute.
F
I
think
I
think
there
is
another
important
point
that
this
and
then
we
can
already
see
that
in
the
latest
issue
that
we
opened.
That
was
the
the
way
we
kicked
off
this
conversation,
that
is,
which
are
the
use
cases
we
try
to
accomplish
right
because
there
are
different
people
from
different
companies
with
different
opinions,
different
backgrounds,
right
and
I'm
sure
you
know
because
of
you
know
different
company
strategy
and
all
these
different
things.
There
are
going
to
be
different
ideas
right.
F
So
if
we
can
consolidate
all
that
between
all
of
us
and
enumerate
at
least
briefly
describe
in
a
best
case
scenario,
which
are
the
use
cases
and
differentiate
between
them,
I
mean
not
saying
that
we
should
have
this
in
two
weeks
time
right,
because
that
is
going
to
require
discussion
as
well,
but
I
think
that's
maybe
some
direction
we
can
take
before
we
dig
any
deeper
into
any
of
these
use.
A
Cases,
that's
that's
a
great
call
and
I
think
if
you
have
that
as
part
of
that
design
document,
where
we
then
kind
of
a
call
for
for
action
to
the
wider
smart
community
saying
like
hey,
you
know
we
we
want
your
input
there.
You
know
either
directly
right
into
that
google
docs
or
let
us
know,
and
then
we
can
flash
it
out.
That's
absolutely
spot
on.
Yes,
yeah.
A
Colors
all
right,
we
have
two
minutes
left
any
any
party
words.
So
thanks
a
lot
for
for
that
super
discussion,
it
was
really
very,
very
productive.
As
I
said
I
didn't
expect.
We
had
to
get
that
far
thanks
a
lot
both
dylan
and
sergio
for
leading
that
and
mike
for
offering
your
your
help
there
any
any
other
comments,
anything
from
anyone
who
hasn't
spoken
up
during
during
the
call
did
we
miss
anything,
I'm
sure
we
missed
them
anything
you
want
to
add.