►
From YouTube: CNCF Service Mesh Interface Project 2021-03-03
Description
CNCF Service Mesh Interface Project 2021-03-03
A
Hey
everyone
today
is
wednesday
march
3rd
2021.
Welcome
to
the
bi-weekly
smi
community
meeting.
We
have
several
really
interesting
agenda
items
today.
The
link
to
the
agenda
is
pasted
in
chat.
Please
add
your
name
if
you
are
an
attendee
and
feel
free
to
add
discussion
items
to
the
to
the
discussion
items
list
and
with
that
I'm
just
going
to
go
ahead
and
kick
it
off
well,
an
overview
of
the
agenda.
Actually,
first
we're
going
to
talk
about
the
generic
smi
controller.
A
That
nick
has
been
working
on
there's
also
an
update
on
the
issue.
Adapter
on
that
bridgette
has
a
call
to
edit
the
smic
and
annual
review.
So
we'll
talk
about
that.
She
also
had
an
agenda
item
around
you
know:
how
do
we
get
our
roadmap
going?
How
do
we
deal
with
compatibility
between
integration
so
I'll
help
facilitate
that
conversation
since
she's,
not
here
today?
There's
a
few
other
notes
that
she
has.
A
I
have
an
item
around
traffic
split
and
clarifications
around
what
a
root
service
can
be,
and
then
michael
is
going
to
lead
us
in
the
multi-cluster
discussion
and
then
I'm
going
to
talk
about
the
contributing
guide
for
the
spec.
So
we
have
a
lot
going
on
and
I
may
apologize
cut
you
off
if
I
feel
like
we
could
maybe
have
a
better
discussion
or
a
longer
discussion
offline
about
it
or
at
the
end
of
the
meeting.
If
you
want
to
extend
that
so
just
to
help
us
get
through
everything.
B
A
B
Thanks
yeah:
yes,
there
we
go
okay,
awesome!
Thank
you.
I'm
going
to
caveat
this
with
an
apology,
because
I
about
30
seconds
ago
developed
a
migraine,
so
I
can't
actually
see
out
of
my
right
eye
at
the
moment
until
that
disappears,
but
we'll
go
through
okay,
so,
where
I'm
at
with
the
the
the
smi
sdk
the
kind
of
the
things
that
I've
been
working
on
recently,
I
haven't
made
many
advancements
in
like
things
like
adding
additional
specs
to
it,
because
that's
a
known
entity.
B
The
key
thing
that
I'm
interested
in
is:
how
do
you
test
it?
How
do
you
develop
it?
How
do
people
contribute
to
to
the
sdk
and
ultimately
does
it
work
like?
Is
it?
Is
it
possible
to
create
something
which
is
flexible
enough,
and
I
I
think
the
answer
to
all
of
that
is:
is
yes,
so
the
first
thing
around
the
repo?
What
I've
added
to
to
the
repo
is,
is
a
well.
I
updated
the
readme
the
other
day,
there's,
which
has
got
some
instructions
on.
B
It's
very
brief
on
how
you
can
kind
of
create
things,
but
also
instructions
on
building
and
developing
locally,
and
things
like
that.
I
also
added
a
bunch
of
functional
tests.
So
now
not
only
are
there
unit
tests,
but
there
are
functional
tests
which
you
follow.
The
the
sort
of
coup
builder
ginkgo
specification,
which
I'm
I'm
on
the
fence
on
and
I'd
love
to
get
people's
comments
on
on
ginkgo
tests
and
also
end
end-to-end
tests,
which
checks
the
the
controller
sdk
against
a
real
kubernetes
cluster.
B
So
we've
got,
we've
got
all
of
that.
It's
working
pretty
good.
I've
been
working
on
getting
the
development
experience
working
pretty
nice,
so
I'm
using
a
tool
called
shipyard
which
allows
you
to
create
a
docker,
a
kubernetes
cluster
running
inside
a
docker.
So
you
can
develop
everything
locally,
it'll
install
all
of
the
bits
and
pieces
in
the
helm,
chart
and
everything
that
you
need
and
as
an
added
bonus,
what
you
can
do
is
debug
it
because
any
of
the
web
hooks
stuff
is
forwarded
to
your
local
machine.
B
B
Hopefully,
so
I'm
applying
that
k
apply
examples:
traffic
split
v2!
You
can
see
that
the
break
point
has
been
hit,
so
this
has
hit
the
kubernetes
api.
The
kubernetes
api
has
called
the
web
hook
defined
in
the
crd,
which
has
been
forwarded
to
the
local
instance
on
my
my
computer
here,
and
I
can
step
through
this
and
and
do
everything
that
you
would.
You
would
like
to
do
around
that,
so
that
side
of
things,
I
think,
is
looking
really
good.
B
We
have,
as
I
say,
the
the
sort
of
the
the
tests
so
everything's
in
the
unit
tests.
Sorry
in
the
make
file
you
can
build
run,
functional
tests
run
the
unit
tests,
yeah
everything's
there
and
it's
getting
there.
So
so
that's
that's
a
kind
of
a
quick
update
on
on
that.
I'm
pretty
pretty
happy
where
that's
at
it's
pretty
good.
Now
I
managed
to
put
the
the
health
end
points
and
the
ready
end
points
in
which
I
will
expose
to
to
people.
B
I've
been
doing
some
work
on
the
console
as
a
side
of
things.
Do
the
dog
fooding
and
that's
been
working
really
good
and
the
next
side
of
the
dog
food
is
I'm
going
to
implement
the
some
of
the
stuff
around
the
the
sdo
adapter,
which
which
actually
will
be
really
really
easy
to
to
implement,
because
literally
all
you
have
to
do
is
implement
the
methods
that
you
are
interested
in
and
just
in
case
anybody's
not
seen
that
before.
B
If
I
can
find
the
right,
here's
an
example:
logging
implementation,
so
you
don't
have
to
worry
about
anything
around
the
controller.
You
don't
need
to
worry
about,
like
the
the
sort
of
hierarchy
that
children
objects
don't
exist.
The
controller
will
deal
with
all
of
that.
As
a
consumer,
all
you
handle
are
the
upsets
and
the
delete
events
which
you
you
receive,
and
then
you
can
execute
whatever
logic
you
need
to
do
so
it's
it's
pretty
rapid
to
to
be
able
to
to
use
this
and
yeah.
A
To
this
whole
thing,
I
was
really
excited
to
get
a
code
walkthrough
from
nick
him,
and
I
went
through
kind
of
like
the
pros
and
cons
of
updating
the
seo
adapter
as
it
is
today
versus
like
using
this
smi
controller
sdk,
and
we
kind
of
thought
it
was
like
really
awesome
to
kind
of
just
switch
over
and
use
this
controller
sdk
it's
in
a
good
place.
It
essentially
does
what
we
needed
to
do
so.
A
All
the
smi
configuration
that
we
need
to
actually
like
watch
all
those
resources
and
do
something
on
them
and
that's
essentially
what
the
istio
controller
is
doing
as
well,
so
it's
just
or
the
seo
adapter
is
doing
as
well
is
just
it's
watching
smi
resources
and
then
building
like
an
sdo
virtual
service
or
whatever
the
istio
equivalent
of
you
know
that
functionality
is
it's
just
building
the
resource
for
that.
So.
A
Yeah
I
mean
from
an
osm
perspective,
we're
really
excited
about
the
conversion
web
hooks
and
we
can
actually
go
ahead
and
we're
planning
our
next
release
cycle
and
stuff
and
we've
kind
of
talked
about
how
we
want
the
upgrade
story
to
be
smoother
in
terms
of
smi
resources
and
stuff.
So
we
can
definitely
help
out
there
too.
Yeah.
B
The
the
other,
the
other
thing,
which
I
think
just
to
add
on
that
is
that
I
I
did.
I
am
using
the
v1
spec
of
the
the
custom
resource
apis,
not
the
beta
which
the
current
go.
Sdk
is
using
and
the
rationale
behind
that
is.
I
hope
that
we're
you
know,
like,
I
think,
that's
api,
16
or
something
where,
where
that
was
compatibility,
was
introduced,
you
get
so
much
better
benefit
around
the
validation
side.
B
A
A
Okay,
thank
you
nick
okay,
so
the
next
item
we
have
is
bridget
is
putting
out
a
last
call
to
edit
the
smi
cncf
annual
review.
So
if
you
gave
a
talk
or
did
a
blog
post
on
smi
or
saw
something
cool
about
smi,
this
is
kind
of
our
yearly
report
card
to
the
toc
and
to
the
rest
of
the
cncf
community
around
like
things
we've
done
and
accomplishment
accomplishments
we've
had
so
please
throw
that
in
there.
A
We
also
have
a
the
next
agenda
item
is
around
spec
evolution
plans
so
getting
apis
to
beta
and
stable.
We
have
had
our
apis
kind
of
an
alpha
for
a
while
implementations
have
implemented
it.
I'm
kind
of
wondering
you
know
we
kind
of
need
a
road
map.
We
tried
to
do
this
before,
but
we
need
to
have
a
plan
for
how
to
get
our
apis
to
beta
and
stable.
A
Are
there
parts
of
traffic
split
and
traffic
access
and
traffic
metrics
that
we
want
to
change
and
add
features
to,
or
do
we
feel
like
it's
in
a
good
place,
and
we
can,
you
know,
start
moving
into
beta
and
then
I
guess
we
can
still
add
features
after
after
it's
you
know,
b1
or
whatever
it
is.
We
just
kind
of
need
to
get
it
to
some
sort
of
a
stable
place
where
we
know
that
conversion
web
hooks
will
work
and
we
won't
be
changing
fields
all
the
time.
B
A
A
B
No,
I
don't
have,
I
don't
know
much
much
thoughts.
I
think
the
there's
there's
definitely
a
couple
of
bits
and
pieces
that
I'd
I'd,
love
to
see,
love
to
see
in
the
spec
and
and
be
more
than
happy
to
help
push
this
forward.
But
I
think
you've
got
a
really
valid
point
that
what
we
have
right
now
works
really
well
and
a
lot
of
people
have
been
using
it.
So
should
it
just
be
promoted
and
then
we
can
always
run
another
beater,
all
right,
yeah.
A
C
A
C
That's
why
I
skipped
the
last
couple
of
times
is
because
it
was
we
were
so
close
on,
like
basically
a
final
like
more
or
less.
We
was
why
I
haven't
joined
is
because
last
time
we
ended
up
meeting
with
the
nginx
service
mesh
folks
to
help
because
they
had
missed
the
initial
kind
of
deep
dive
into
that
conformance
and
they're,
really
interested
and
they're
gung-ho
to
have
their
implementation
verified
and
the
tool
is
able
to
do
it
it.
C
The
problem
is
that
their
software
to
get
access
to
service
nginx
service
mesh-
you
have
to
sign
in
a
a
eula
which
means
that,
like
as
the
meshery
is
the
tool
to
pull
down,
install
files
and
deploy
the
service
meshes,
it
becomes
an
issue
for
it.
Just
we
got
wrapped
up
in
their
corporate
legal
system.
C
The
as
a
matter
of
fact,
so
like
a
blog
post,
is
very
much
needed.
The
thing
the
the
the
brief
update
is
that
the
the
the
the
tool
works
you
can
go
test,
different
service
meshes
conformance.
This
is
we're
ready
for
our
first
or
the
tool
is
ready
for
its
first
real
customer.
I
guess
like
the
for
the
first,
like
the
the
statistics
are
actually
published
on,
like
I
think
four
or
five
service
meshes
on
how
what
percentage
compatible.
B
So
if
we
added
a
step
to
do
the
compatibility
test,
theoretically,
the
reference
implementation
in
the
sdk,
which
is
like
logging
controller,
should
be
100
compliant.
So
it
would
be,
and
I'd
also
like
to
integrate
that
on
the
console.
Rework
that
I'm
doing
as
well.
So
I'd
love
to
play
with
that,
and
maybe
we
talk
async
nice,
that's
great.
C
C
A
C
A
I
totally
get
that
I
totally
fail
you,
okay,
so
going
forward.
I
had
a
topic
about
traffic
split
root
service
which
I'll
briefly
give
you
an
overview
of,
and
then
we
can
just
have
a
one
minute
conversation
on
how
we
can
move
on
in
the
traffic
split
part
of
the
spec.
It
there's
like
a
paragraph,
and
I
have
an
issue
that
links
to
the
paragraph,
but
it
just
says
that
the
root
service
should
be
in
fqdn,
fully
qualified
domain
names.
So
that's
cool.
A
That
makes
sense
because
you
want
to
be
able
to,
you
know,
be
able
to
have
a
client
access
food.com
and
then
that
service,
that
traffic
should
be
routed
in
whatever
way
the
split
has
defined.
But
then
it
says
that
later
in
the
paragraph
it
says
that
you
know
the
the
backup
should
be
like.
Actually
there's
there's
some
language
around
there.
That
says
something
about
that.
A
If,
if
the
root
service
isn't
there,
then
the
standard
kubernetes
configuration
should
work,
and
it's
just
like
slightly
confusing
because
it
sort
of
couples
the
root
service
to
a
kubernetes
service.
And
I
don't
think
that
if
you
really
think
about
it,
that
doesn't
make
sense
because
you
should
be
able
to,
you
know,
go
to
food.com
or
bookstore.bookstore
namespace
or
whatever.
That
is,
you
should
be
able
to
use
either,
or
so
it
could
be
a
kubernetes
service
or
it
could
not
be
a
kubernetes
service
and
I'm
talking
about
the
root
service.
A
So
I
would
just
love
to
add,
like
maybe
a
sentence
or
two
clarifying,
that
there
is
not
a
coupling
there
unless
there's
some
background
that
I
don't
really
know
about.
Okay
nick
is
shaking
his
head.
He's
been
here
for
a
while,
so
cool
sounds
good,
so
anyways
that
issue
is
there.
If
y'all
wanna
comment
or
anything
any
comments
right
now,
no
okay,
I
figured
it
would
be
pretty
pretty
standard.
A
B
B
So
we,
I
started
an
issue
which
I've
just
left
to
to
canvas
sort
of
feedback
on
for
the
last
sort
of
13
days,
and
ultimately,
it
kind
of
just
covers
the
fact
that
we're
looking
for
help
and-
and
I
think
the
general
consensus
is
that
people
want
to
see
what
multi-clustering,
which
includes
different
mesh
variants
as
well
as
different
clouds
and
things
like
that,
and
that
was
always
the
purpose
of
of
what
we
were.
We
were
trying
to
achieve
with
that
which
is
good,
so
yeah.
B
The
example
cited
here
is
around
spiffy,
which
I
think
is
a
great
format.
The
problem
with
spiffy
is
it's
a
very
loose
format
you
know,
spiffy
is
is
if
it's
a
uri
you're
pretty
much
good
to
go,
but
the
problem
with
the
uri.
You
can
compose
it
many
different
ways.
You
could
use
sort
of
dot
notation.
So
I
could
say
you
know
cluster.region.application.
B
Or
I
could
use
something
like
cluster
business
unit,
slash
application.
So
this
you
know,
there's
a
number
of
different
ways
that
you
can
compose
a
spiffy
id
and
and
actually
what
you
probably
want
to
be
able
to
do
with
multi-clustering
is
be
able
to
sort
of
trust.
A
a
you
know,
a
broader
thing
than
just
a
one-to-one
mapping.
So
I'd
love
some
feedback
and
some
comments
on
on
that
area,
about
how
how
we
could
deal
with
that.
B
B
A
All
good,
am
I
healthy
all
right,
thanks
yeah,
let's
do
a
meeting
next
week,
since
we
don't
have
an
smi
community
call
like
specifically
on
multi-cluster
if
that
works,
and
then
everybody
go
put
your
opinion
on
that
issue
between
now
and
next
week.
Is
that?
Does
that
work,
okay,
cool
I'll,
make
sure
that
happens?