►
From YouTube: CNCF Service Mesh Interface Community Meeting 2020-04-15
Description
CNCF Service Mesh Interface Community Meeting 2020-04-15
A
Hey
everyone.
Thank
you
for
joining
us
at
the
SMI
community
call
it
is
Wednesday
April,
15
2020.
We
have
a
fantastic
agenda.
Today
we
are
going
to
kick
it
off
with
solo,
they're
gonna
present
a
service
mush
hub,
then
we're
gonna.
Kick
it
off.
I
believe
Nick
Jackson
who's
going
to
give
us
an
overview
of
project
Hamlet.
Then
we
have
some
discussion
items
like
the
SMI
spec
conversion,
webhook
and
versioning,
and
backwards
compatibility,
which
is
always
an
excellent
and
very
entertaining
and
very
crazy
conversation,
but
very
very
necessary.
So
that's
always
fun.
A
Then
we
have
the
SMI
blog
launches
announcements
and
then,
let's
see,
we
also
have
a
link
to
the
webinar
about
SMI,
featuring
our
very
own
Lackey,
Tomas
and
Stefan,
and
then,
after
that
we
are
going
to
open
up
to
any
other
discussions.
There
probably
won't
be
that
much
time
so
I'm
going
to
time
box
everyone
to
whatever
I
feel
like
congratulate
I'm
just
kidding.
Okay,
so
first
up
I
mean
handed
off
to
a
solo.
Can
we
actually
do
it?
After
is
Nick?
Please,
okay,
pushy
is
Nick
on
or
anybody
from
project
Hamlet
hi.
B
A
B
B
Just
pulling
the
cola,
we
know
about
the
project,
because
this
was
in
community
more
or
less,
by
the
same
time
that
SMI
walls
and
a
basically
the
idea
with
the
underlying
use
cases
of
the
Federation
respect
that
we
have
created
in
community
and
led
by
VMware
has
been
to
pretty
much
a
similar
objectives
to
SMI.
That
is
how
to
a
enable
the
inter
operation
of
two
different
service
meshes
where
these
two
service
measures
are
not
necessarily
compatible
between
them.
Alright,
so
there
are
different
problems
that
we
have
in
this
space.
B
The
ones
we
are
trying
to
solve
with
a
hamlet
are
a
the
identification
discovery
and
communication
services.
So
this
is
more
layer.
Four
problems,
more
networking
focused
problems,
and
the
idea
is
that
we
can
help
our
customers
to
a
bootstrap
integrations
with
other
products
they
already
have,
or
we
can
help
them
with
that.
We
can
help
them
to
expand
the
service
mesh
to
more
places
and
movies
that
they
need
a
plan.
B
B
B
The
project
itself
is
only
solving
one
small
problem,
that
is,
a
service
interconnection
and
service
discovery
in
that
biggest
base
that
is
mesh
Federation.
This
is
aspect
that
we
built
and
during
several
months
with
different
companies.
Pivotal
now
is
part
of
VMware,
as
you
know,
but
it
was
a
by
the
time,
and
this
is
something
we
have
also
done
with
a,
as
you
may
know,
with
a
console
and
on
Google.
B
More
recently,
there
have
been
some
discussions
in
the
SEO
community
to
incorporate
this
into
is
do
something
that
we
have
a
I
would
say
that
one
of
the
objectives
of
the
project
is
to
keep
it
independent,
so
we
are
not
tied
to
any
specific
technology.
So,
just
to
give
you
an
example:
Hamlet
has
two
things
today:
one
is
a
vendor
neutral
platform,
neutral
service
entry
that
you
can
use
to
interchange,
information
about
services
across
platforms
and
the
other
one
is
a
protocol
to
do
that,
interchange
so
for
the
protocol,
many
things
can
be
used.
B
The
important
thing
here
is
the
data
model
is
the
object
that
we
are
sharing
not
so
much
the
protocol.
The
protocol
can
be
anything
as
I
said,
and
there
have
been
some
discussion
in
the
SEO
community,
naturally
because
they
were
part
of
the
initial
spec
around
adopting
some
of
the
existing
is
to
a
protocol
more
precisely
MCP,
but
because
we
wanted
to
maintain
Hamlet,
vendor-independent
and
and
I
have
its
own
life
cycle.
We
decided
to
keep
it
to
keep
it
its
own
protocol
and
not
tie
it
to
MCP
a
little
bit
later
than
that.
B
Then
Google
announced
that
a
steel
was
never
going
to
be
part
of
C
and
C
F,
and
that
meant
that
we
made
the
right
decision
by
the
time,
because
we
were
not
attaching
Hamlet
to
something
really
existing,
so
open
and
extensible.
So
no
constraints
at
all.
No
interference
at
all,
so
the
idea
is
that
this
is
this
should
be
hey,
it
should
be
shouldn't,
be
imposing
constraint
on
existing
vendors
or
technologies.
So
this
should
be
non
disruptive
and
the
problem
we're
trying
to
solve
is
not
multi
clustering.
B
The
very
people
was
confused
or
you
doing
multi
class
Torino
multi
class
phrase
when
you
own
all
of
the
infrastructure,
and
you
can
make
conventions
for
a
network
addressing
namespacing
policy,
etc.
The
problem
we
are
solving
is
a
multiple
administrative
domains,
and
these
ones
do
not
share
information
between
them
and
it
is
not
possible
to
normalize
or
to
make
conventions,
and
this
can
be
situations
as
easy
as
to
service
message
with
one
cluster
each
or
can
be
multi
clustering
in
each
of
the
service
measures
that
we
are
federating.
B
Those
details
about
how
many
clusters,
or
what
is
the
infrastructure
type
or
where
is
the
infrastructure
located,
are
not
shared
in
the
protocol,
and
that
is
the
purpose
of
the
protocol
precisely
so,
there
are
many
problems
in
this
space
to
be
solved
in
the
interconnection
space
we
have
to
have
a
way
to
interoperate
is
measure.
It
is
to
interchange
the
service
discovery.
A
object
is
the
object
model
between
the
two
measures.
We
have
to
have
an
object
model.
B
We
have
to
have
a
way
to
federated
entities
if
the
measures
are
not
trusted
between
them
and
we
can
relay
on
the
single
root
CA
and
we
have
to
have
a
way
to
implement
the
automation
required
in
each
of
the
participants
in
the
Federation,
in
with
regards
to
roading
of
the
of
the
service
measures
in
terms
of
how
a
mesh
is
going
to
expose
services
and
how
much
is
when
to
consume
services
exposed
by
other
measures.
All
these
are
problems
to
be
solved
so
far
we
have
solved
these
two
problems
and
the
first
one
we.
B
B
So
for
as
the
differentiation
between
Hamlet
and
SMI
is
that
SM
is
targeting
more
api's
which
are
user
facing
for
practitioners
and
in
the
case
of
Hamlet,
this
is
more
machine-to-machine.
What
is
required
to
make
that
communication
happen
between
mesh,
so
we
can
really
make
the
traffic
flow
between
them
and
not
only
have
a
single
object
model
to
do
configuration
management
across
virginius
meshes
I,
hope
that
makes
sense.
This
is
a
proof
of
concept
that
we
did
with
Hoshi
Corp,
and
this
is
a
working
proof
of
concept.
B
We
federated
a
nice
accessories
mesh
that
is
now
called
tansu
service
mesh
with
console
console
had
VMs,
and
this
was
a
super
early
version
of
console
with
beta
ingress,
but
it
worked.
We
basically
used
the
invoice
of
the
both
a
sense
of
service
mesh
that
is
using
eesti
under
the
hood
and
a
console
that
was
also
injecting
still
alongside
the
VMS.
B
In
this
case,
we
had
as
the
common
root
CA,
so
the
avoid
have
certificates
signed
by
the
same
CA
and
the
ingresses
were
doing
pass-through
of
the
traffic
to
the
to
the
other
ingress
which
terminated
the
MPLS
of
the
opposite
direction
is
exactly
the
same
from
console
to
menaced
attack
service
match.
So
the
protocol
is
saying
synchronizing
the
catalogs
in
both
service
measures,
as
services
are
created
and
destroyed,
there
is
no.
B
There
are
no
as
specifics
in
the
protocol
about
how
the
user
experience
should
be
in
each
of
the
measures
regarding
regarding
a
how
to
expose
or
consume
or
how
to
decide
which
services
are
exposed
or
consumed
in
each
of
the
measures.
That
is
something
that
we
have
preferred
to
leave
to
each
of
the
products.
This
is
a
product
decision
and
not
necessarily
a
protocol
decision.
A
A
C
B
Example,
yes,
we
used
ingress
as
an
aggressors,
and
but
it
is
not
a
requirement
there
can
be
multiple
implementations
of
these.
The
protocol
does
not
really
require
having
an
ingress
or
an
egress.
It
is.
It
is
strongly
a
encouraged
to
have
an
ingress
because
it
allows
you
flexibility
to
do
different
implementations
of
the
of
the
protocol
and
also
because
him,
you
know
in
production,
for
the
environments,
you
are
going
to
be
required
to
have
an
egress
of
an
address.
A
Right
we
gotta
cut
it
off
here.
I
know
there
are
several
other
questions:
let's
go
ahead
and
move
on
to
solos
presentations.
We
have
time
at
the
end,
we'll
come
back
for
questions.
Thank
you
so
much
for
for
presenting,
sir,
do
you
have
a
link
to
the
deck
and
any
information
you'd
like
to
draw
up
into
the
notes?
That'd
be
really
great.
Thank.
A
E
A
E
Cool
so
I
service
myself,
we
announce
it
basically
a
week,
I
think
even
less,
maybe
a
week.
Basically
just
I
wanted
to
give
you
that's
kind
of
like
an
extension
of
the
project
that
we
did
super
cool
before
that.
To
be
honest,
it's
exactly
the
same
way
that
we
did
super
glue.
It's
on.
It's
basically
just
a
better
implementation
for
everything
that
we
did,
but
the
vision
is
the
same.
E
Basically
we're
working
a
lot
on
with
super
glue
community,
as
well
as
with
SMI,
and
when
we
worked
on
all
of
this,
we
got
five
a
tree
push
back.
One
of
them
was
about
the
common
Dell
or
common
denominator.
People
basically
really
was
against
it.
They
felt
that
this
is
a
limited
them
and
they
it
was
also
hard
for
them
to
do
not.
You
know
to
basically
be
slowed
by
the
mesh.
E
That
is,
is
moving
slower
and
it
was
a
very
hard
problem
for
us
to
come
to
it
to,
for
instance,
for
our
customers
using
SEO
I
tell
them.
You
cannot
use
circuit
breakers,
because
one
of
the
automation
is
not
support
that.
So
that's
a
really
really
problematic
problem
and
we
got
a
huge
pushback
read
all
of
us,
but
a
huge
pushback
from
the
community.
E
So
that's
number
one
number
two
that
we
got
a
lot
of
requests
in
Super
Glue
is
basically
to
support
the
last
version
of
each
matches,
specifically
I
still
1.5
and
the
last
one
was
multi
class
they're
all
about
the
multi
cluster.
So
basically
what
we
announced
last
Wednesday,
it's
pretty
simple
Kristin-
will
show
us
a
demo
in
a
second,
but
it's
very,
very
simple:
you
can
register
a
class
there
once
you
register
a
class.
Are
we
managing
it?
We're
discovering
a
lot
of
thing
about
this
cluster.
We
discover
every
match
that
running
in
this
cluster.
E
We
discovering
their
workload
that
belong
to
those
match,
so
basically
be
going
we're
looking
at
this.
You
know
we're
basically
detecting
the
side
current,
that
we
know
that
it's
belong
to
the
mesh
and
we
basically
have
all
those
information.
You
can
also
install
a
mesh
right
and
an
upgrade
if
you
need
to
we
basically
abstract
the
operator
of
anvil
of
Sto
and
link
at
the
installation,
and
so
on.
Once
that
happened,
we
add
an
API,
we
extended
the
SMI
API,
it
looks
more
like
the
glue
API
and
the
point
of
like
it's
actually
also.
E
You
can
choose
source,
not
only
destination,
and
it's
not
a
lot
of
common
denominator.
We
also
change
the
access
policy
a
bit
and
again,
Chris
I'll
show
you
in
a
sec
but
I
think
it's
a
really
really
simple
way
to
actually
describe
a
mess
configuration.
There
is
a
source.
There
is
a
destination.
There
is
stuff
going
on
the
pipe
and
the
other
thing
that
we're
integers
is
basically
the
grouping
book
those
measures
and
we
calling
it
virtual
match.
So
you
can
take
two
matches
group
them
together.
E
We
are
doing
behind
the
scene,
all
the
mess
of.
Actually
you
know,
identity
and
and
a
rotation
and
roots
of
it.
You
know
a
certificate,
rotation
and
so
on,
and
basically
just
making
sure
that
those
two
meshes
be
able
to
talk
and
again
we
will
get
to
the
detail
in
a
second
all.
The
team
is
here,
so
they
can
talk
in
more
details
and
we
would
call
it
virtual
mesh,
and
we
also
and
I
am
a
another
feature
that
I
think
it's
pretty
cool
and
a
quick,
a
quick
show.
E
The
way
several
a
service
much
is
working
is
that
when
you
apply
a
new
rule,
if
it's,
if
we
cannot
honor
it
we're
just
going
to
we're
out
of
this,
the
status
will
be,
it
will
not
apply.
So
it's
it's
not
going
to
break
it's
just
not
going
to
be
applied.
So
that's
kind
of
fun:
I'm
not
going
to
talk
more
I'm,
all
about
let's
eat,
so
I
will
move
my
screen
to
Kristy
and
Kristy
I
will
show
you
them.
D
D
Okay,
yeah,
so
sorry
with
some
of
you
season
all
right.
So
what
we
have
here
is
we
have
two
different
clusters
running
on
gke
and
in
cluster
number
one.
We
have
an
sto
installation
we
can
see.
We
have
the
book
info.
Part
of
the
book
info
is
ciose
book
info
demo
install
where
we
have
reviews
v1
and
reviews
v2
and
in
a
second
cluster
we
have
a
different
sto
installation
and
over
there
we
have.
D
D
We've
read
these
two
clusters
and
inside
of
service
mesh
hub
and
then
we've
discovered
automatically
discovered
the
two
different
service
specials.
So
this
happened
before
I
was
setting
up.
I
know
we
had
time
constraints
so
I
kind
of
set
up
that
stuff.
If
we,
if
we
check
service
Mashhad,
we
should
see
and
cross
my
fingers
that
everything
is
installed.
Everything's,
looking
everything's
looking
good
now,
the
first
thing
we're
going
to
do
is
now.
We
have
two
different
service
messages.
D
They
have
been
installed
individually
and
separately
and
they
have
different
trust
routes
so,
for
example,
on
cluster
one,
when
reviews
calls
ratings,
we
should
see
a
certificate
chain
right
here.
We
can
see
the
route.
That's
that
signed,
that
certificate
chain
ends
in
whatever
G
a
G
right
on
the
on
the
second
cluster.
We
should
see
a
different
route
when
reviews
calls
ratings.
Alright,
this
was
it
two
different.
Those
are
two
different
clusters
here:
shouldn't
be
G
a
G
anymore.
D
It
should
be
something
else
alright,
so
we
have
two
different
route:
trust
domains
here
now,
as
we
didn't
mentioned,
the
virtual
mesh
resource
in
service
mesh
hub
allows
us
to
group.
Multiple
different
service
meshes
in
this
case
will
be
two
ISTE
oats.
If
we
look
at
the
virtual
mesh,
we
can
see
that
will
will
automatically
generate
a
root
CA
from
which
those
two
meshes
will
derive,
so
that
we
want
to
federate
this
I
identity.
We
want
to
include
these
two
messages
and
they're
defined
here
now.
D
We
won't
enable
our
back-end
and
policy
control
book
we'll
do
that
in
a
little
bit
later
and
the
Federation
mode
that
we're
going
with
is
permissive,
which
means
as
we
unify
them.
We
will
enable
service
discovery
for
all
of
the
services
between
D
the
two
meshes.
So
let's
cross
our
fingers
and
apply
this
virtual
mesh
and
let's
take
a
look
at
it,
we
should
see.
D
D
Please
no
errors,
please
no
errors.
Okay,
sorry,
that's
a
new
thing,
a
little
bit
older
version,
but
that's
that's
fixing
a
new
version,
but
so
when
we,
when
we
create
the
virtual
mesh
abstraction
what
we,
what
we
end
up
doing
now
is
telling
each
of
the
meshes
you
go
off
and
create
your
own
intermediate
certificates,
send
it
to
the
management
plane
that
will
be
signed
by
the
root
and
then
now
now
use
those
intermediates
with
signed
by
that
root.
Shared
group
for
each
of
the
different
meshes,
so
no
keys
get
transferred
over
the
network.
D
What
we're
doing
is
sending
switcher
to
get
signing
requests,
so
we
can
see
here
on
the
management
plane
the
virtual
mesh
CA
cert
that
gets
created.
This
has
ends
up
being
the
route.
Let's
see,
if
we
can
try
to
remember
this,
why
a
and
a
couple
of
equal
signs
and
then
what
we
see
on
the
remote
clusters
and
any
of
the
remote
clusters
is
this
certificate
signing
request?
D
So
this
certificate
signing
request
ends
up
being
sent
to
the
management
plane,
and
then
we
should
see
that
the
root
octave,
a
64
encoded
but
I'll
show
in
a
second.
We
should
see
that
this
was
signed
by
the
the
root,
the
root
certificate
that
was
created
by
the
management
plane.
So,
ultimately,
what
we
end
up,
having
then,
is
secrets
created
on
each
cluster.
We
can
see
the
CA
search
for
this
do
here
on
cluster
one.
D
We
can
see
this
the
a
search
on
cluster
two,
both
of
them
signed
by
the
same
root
which
lives
on
the
management
plane
and
now
because
of
a
kind
of
an
issue
issue
with
sto,
though
we
have
to,
we
have
to
balance
the
two
control
plane
to
pick
up.
This
new
CA
will
give
that
a
second
that's
on
both
clusters
so
that
they
both
pick
up
their
new
source
of
trust.
D
D
On
honesty,
we
should
see
the
the
workloads
should
now
be
provisioned
with
their
new
source
of
trust,
and
now,
if
we
check
the
certs,
when
we
call
all
right
well
so
they're
coming,
hopefully
they're
coming
up
and
they're
fine,
let's
cross
our
fingers
for
that
now.
Well
now
the
search
chain
that
we
see
when
reviews
calls
ratings
in
cluster.
D
E
So,
for
instance,
when
you're
starting
you
can
you
need
demo
and
that's
spinning
up
all
the
environment,
for
you
already
to
kind
of
like
go
and
try
it
I
think
this
is
really
really
really
strongly
recommended
and,
as
I
said,
there's
way
more
functionality
and
get
awfully
pleased
and
Emma
will
work.
Yeah.
D
D
A
Much
we
don't
have
time
for
questions
so
I
really
like
to
run
by
both
the
folks
from
Hamlin
and
solo
back.
This
is
recorded.
So
if
you
want
to
take
another
look
at
the
demos,
please
do
I,
encourage
the
community
to
do
that
and
then
come
back
next
meeting
to
ask
your
questions
or
ask
them
in
the
SMI
community.
Slack
Bridget
posted
a
link
to
our
blog
post
about
SMI,
going
into
the
CNC
f
as
a
sandbox
project
in
the
notes.
If
you
have
a
blog
that
you'd
like
to
write,
please
contact
her.
A
Is
that
the
right
thing
to
do
Bridget,
sure,
absolutely
okay,
cool-
and
there
are
so
many
new
people
here,
which
is
really
really
great,
come
back
next
time.
So
you
can
introduce
yourselves
to
the
community
and
we
can
talk
a
little
bit
more
about
the
project
in
triage.
But
until
then
see
you
all
next
time.