►
From YouTube: CNCF Network Service Mesh Meeting 2019-10-01
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
CNCF Network Service Mesh Meeting 2019-10-01
A
B
Great,
so
let's
go
ahead
and
get
started
and
I
see
a
couple.
People
are
filling
out
the
agenda,
as
we
speak,
so
feel
free
to
do
that,
while
we
begin
so
welcome
to
the
network
service
mesh
weekly
meeting.
So
we
have
this
meeting
that
occurs
every
every
week
on
every
every
Tuesday.
At
this
time
we
also
have
before
this
a
meeting
at
4:00
a.m.
a
civic
time.
Sorry,
that's
that's
incorrect.
One!
There's
a
there
is
a
version
of
this
meeting.
Do
you
remember
that
the
time
that
it
son
I
think
it's
10:00
a.m.
C
B
Yeah
that
we
could
have
so
much
sure
the
agenda
that'd
be
great,
so
people
can
also
follow
along
an
tickley
I
took
the
meeting
chat
for
the
for
the
location
of
the
meeting,
notes
where
you
can
add
your
name
down.
So
we
have.
We
also
participate
in
the
CNCs
Telecom
user
group
and
that
occurs
every
first
Monday
at
8:00
a.m.
Pacific
and
every
third
Monday
at
4:00
a.m.
Pacific
time.
The
zoom
is
is
linked
in
the
in
the
meeting
notes.
B
C
B
There
there's
a
brand-new
draft
charter
that
I
said
I
saw
linked
today,
so
I
have
I,
have
not
had
time
to
read
it
because
I
just
saw
it
like
10
minutes
before
it's
cold
but
yeah.
That's
it
sitting.
There
I'll
find
the
I'll
find
the
link
later
on
and
I'll
I'll.
Add
it
on
major
events.
So
we
just
finish
up:
oh
s,
Europe
and
so
overall
I
think
it
went
fantastic.
We
had
multiple
talks
and
me
and
Taylor
gave
a
interview
with
telecom.
B
Music,
Group
and
I
also
had
an
interview
with
I
forget
the
name
of
the
group,
but
there
was
a
person
there
named
Swapnil
and
I'll
find
the
name
of
of
his
particular
group
later
on
as
well.
So
we
had
a
lot
of
really
good
a
really
good
participation
in
ons
and
there
was
a
lot
of
excitement
about
it
as
well,
and
there
was
also
some
interesting
news
from
Dan
Kohn
Taylor.
B
Are
you
on
the
call
I
am?
Are
you
able
to
state
what
the
bank
owned
mentioned
upon
his
keynote
sure
so
you're
referring
the
scene,
a
testbed
and
kind
of,
and
where
we
could
go
potentially
yeah?
Since
we're
talking
about
OH&S
and
in
this
particular
one,
can
you
can
you
just
give
Mike
a
quick
blurb
on
what
was
mentioned?
B
Yeah,
and
so
we've
is
kind
of
talking
about
where
we
could
go
with
the
CNN
testbed
and
which
is
I'm
adding
on
to
the
roadmap,
which
folks
may
may
or
may
not
have
saying,
but
we
ended
up
doing
a
tutorial
based
on
where
we
are
now
in
the
cns
testbed,
which
dealt
with
how
you
could
reproduce
the
environment
as
well
as
running
different
yeast
cases.
B
Someone
is
sharing
their
screen
and
they're,
not
sharing
the
the
doc
anymore,
and
so
we
we
dug
into
that
some
and
and
the
tutorial
was
based
around
what
were
what
we
have
now
and
we're
moving
towards
kind
of
the
next
version
of
the
testbed
and
and
what
Dan
had
mentioned
was
potentially
using
it
as
a
dev
platform,
as
one
portion,
so
folks
could
do
development
on
whether
its
network
function
and
soar
use
cases
different
things.
This
expands
on
where
we've
already
gone.
So
this
is
a
good
path.
B
B
To
see
if
whether
your
technology
or
that
network
functions
or
whatever
are
following
cloud
native
principles,
and
what
does
that
mean?
So
those
are
the
two
main
things:
development
platform
and
in
working
with
some
type
of
certification
being
able
to
run
the
certification
test:
cool
Thank,
You,
Taylor,
yeah
yeah.
There
was
definitely
some
interest
in
the
CNT
team
reading
after
ons
as
well.
B
In
this
particular
area,
it
would
be
just
some
feedback
for
you,
so
it'd
be
good
to
make
sure
that
the
messaging
on
what
you're
trying
to
certify
is
is
very
clear,
because
if
it's
going
to
be
an
end-to-end
certification
process,
we'll
get
a
lot
of
pushback.
But
if
we
make
it
clear
that
it's
just
specifically
for
CNS
best
practices
and
principles,
then
I
think
we
can
get
some
really
good.
B
C
B
There's
a
brand
new
slide
deck
attached
to
that,
as
well
with
some
really
fantastic
information,
so
we'll
make
sure
that
that
gets
posted
around.
We
have
open
source
summit
coming
up
in
Leon,
with
an
intro
to
Venice,
Empire,
Ivana
and
ratifies
and
that'll
be
on
October
20th.
Through
30th
we
have
November
18th
through
21st.
We
have
Q
Khan
North
America
occurring
of
San
Diego
with
MSM
Khan.
So
have
we
posted
the
agenda
yet
on
that?
Yes,.
C
B
C
B
Yes,
definitely
make
sure
make
sure
you
register.
That
is
true,
so
we
we
have
limited.
We
have
limited
space
as
well,
so
that's
going
to
you,
you
risk
not
being
able
to
get,
and
if
you
don't
register
now,
if
you've
already
registered
for
cube
con
in
your
registration,
email,
there's
a
there
should
be
a
link
or
a
reference
number
you
can
use
in
order
to
in
order
to
add
it
on.
B
B
B
D
Good
day
great,
so
last
week
we
were
at
open
networking
summit
in
Antwerp,
Belgium
and
gains
nineteen
followers
on
the
n
service.
Mesh
Twitter
account
followed
forty-eight,
folks
and
tweeted
and
retweet
almost
seventy
new
post
I
posted
about
the
webinar
happening
tomorrow.
C
B
Yeah
I
can't
think
of
anything
else
at
this
particular
point
once
once
the
interviews
end
up
being
posted
on
between
Taylor
and
me
then
we'll
we
can
share
those
out,
but
I
don't
know
when
they're
going
to
be
posted,
because
I
noticed
that
the
ONS
North
America
was
seemed
to
trickle
out
between
June
and
July.
So
there
might
be
a
little
bit
of
time
before
they
pop
out.
Do.
B
So
the
president
that
the
only
thing
that
I'm
saying
is
the
guess,
the
keynotes,
those
have
been
released
and
yeah
I,
don't
know
of
anything
else.
Like
Fredrik
saying,
okay,
yeah,
there
definitely
was
not
recording
equipment
in
the
rooms.
That
I
was
in
with
the
exception
of
the
of
the
panel
so
who
they
had
the
panel
that
Taylor
and
I
were
on
I
recall.
B
Seeing
a
video
recorder
there,
there
is
a
playlist,
that's
out
for
the
keynote
I
didn't
look
through
the
entire
list
to
see
if
the
panel
was
on
that,
but
it's
possible
Fredrik
that
it's
already
there
if
that
was
released,
I'm
at
the
same
time,
yeah.
What
they
did
last
year
was
that
the
sessions
that
were
recorded,
they
stuck
them
behind
a
pay
wall
and
gave
access
to
attendees.
B
E
E
C
Don't
know
when
that's
going
to
broadcast
yet
I
think
we're
trying
to
record
it
in
the
middle
of
October,
yeah
and
I'm,
not
sure
exactly
when
it
will
be
broadcast.
But
there
there
is
a
city
on
native
podcast
are
starting
a
new
podcast,
that's
called
the
contributors,
and
so
they
are
yes
they're
there
they're
interviewing
us
for
that
middle
of
October,
and
hopefully
that
will
come
out
before
cube
con.
C
Anybody's
pushed
Patras
this
morning
or
been
looking
at
patches
that
have
come
in
this
morning.
Circle
CI
is
currently
coming
an
issue
and
is
broken.
This
is
purely
a
circle
CI
problem,
but
in
in
typical
fashion
they
are
right
on
top
of
it.
So
they've
already
been
in
communication
with
me
to.
Let
me
know
that
they're
good
working
on
getting
it
fixed.
So
we
expect
that
to
resolve
pretty
quickly
and
like
anything
else,
every
system
has
a
failure
rate.
You
know,
but
they've
been
really
really
good
about.
B
E
Then
we
spent
a
lot
of
time
with
Ilya
on
restructuring
the
makes
big
file
system
and
these
new
ideas
that
are
there
is
PR
and
then
months
I
came
up
with
a
couple
of
questions
and
updates
which
much
if
you
are
here
you're
here,
maybe
maybe
you
want
to
tell
your
updates
what
you're
doing
with
Michael?
Oh,
yes,.
E
F
C
For
a
fact
that
that
that
code
had
been
run
and
injected
into
an
unprivileged
pod,
everything
necessary
for
a
user
space
program
to
run
unprivileged
and
unprivileged
pod
to
pick
up
that
via
and
use
it.
So
that
said,
there's
also
a
set
of
issues
with
DP
DK.
Please
note
this
was
a
year
ago,
so
I
don't
know
they
were
talking
about
fixing
them
they
may
have.
C
But
when
I
last
looked
at
it,
there
were
a
set
of
issues
with
DB
DK
whereby
if
it
did
not
find
it
did
not
find
itself
in
the
Numa
zone,
it
wanted
able
to
get
all
the
huge
pages
it
wanted
and
able
to
get
exactly
what
it
wanted.
It
would
just
crash
yeah
now
with
it
with
a
really
pointed
log
message.
So
it's
not
like
a
nun,
orderly
cry
should
say:
I
can't
help
you
undock,
but
that
was
a
DP
DK
thing,
not
an
SRO
VPS
thing.
C
G
C
F
H
I
was
just
want
to
raise
that
my
to
asked
us
in
the
morning
about
he
DPP,
matrix
and
I,
checked
the
issue
in
the
regatta
repo,
so
they
agreed.
If
fetch
remembers,
you
ask
them:
they
agree
that
they
will
send
my
tricks
with
the
agent
but
make
them
configurable,
and
currently
there
is
no
movement
and
decision.
So
I
think
if
we
want
to
prioritize
that
it's
not
a
priority
for
them,
so
maybe
it's
priority
for
us.
We
should
move
it
forward.
Let.
C
We
have
this
marvelous
word
in
English,
for
this
called
taciturn.
Alright,
how
you
describe
someone
who
just
doesn't
really
say
much
and
they
tend
to
be
taciturn
people,
the
guys
working
on
the
IDP
agents,
so
they
could
be
busily
working
on
things
that
it
didn't
occur
them
to
tell
us,
so
I
will
definitely
check
it
with
them
and.
H
Having
more
about
metrics
observability
is
Westwick,
I
was
more
focused
on
the
ONS
demo,
where
unfortunately,
I
couldn't
attend
for
some
issues.
The
conference,
but
for
the
PRS
are
not
yet
updated
and
I
will
be
able
to
update
them
at
the
end
of
the
week,
because
we
have
another
conference
and
the
Prometheus
PR
and
the
other
PR
for
exposing
pot
names.
This
early
to
that
are
required
for
the
matrix,
observability
and
I
need
to
update
them.
We
take
this
master
and
test
with
master
yeah
yeah.
C
F
F
F
E
E
Quokka
essentially
running
a
mesh
of
Congress
like
750
chorus
meshed
in
kubernetes,
and
he
actually
joint
our
channels.
So
I
spoke
to
him
and
he
agreed
that
we
might
try
to
figure
out
something
that
can
be
done
in
our
example.
Repo
I
can
really
replicate
similar
things
and
the
other
thing
that
happened
that
I.
E
B
Yeah,
so
one
of
the
ones
that
I
that
I
recall
so
I
feel
like
the
number
of
the
in
offenders
who
were
there
was
not
as
high
as
it
would
be
within,
like
the
North
America
one,
so
I
mean
yet
some
of
the
larger
companies
that
has
er
that
has
a
lot
of
pull
in
from
from
a
variety
of
places.
Like
you
know,
Ericsson
and
and
similar
and
I
did
have
some
conversations
with
with
with
them.
B
Interestingly,
though,
the
most
most
of
the
people
I
ended
up
talking
with
and
when
I
went
to
the
CNT
tea
event
were
primarily
people
from
the
from
the
operator
side.
So
so
the
operators
are
definitely
are
definitely
interested,
but
yeah
I
felt
the
participation
from
the
MS
centers
to
at
least
from
from
my
perspective,
seem
to
be
seem
to
be
lower
than
usual,
so
that
which
limits
some
of
the
conversations
there
I.
E
Just
remembered
water,
what
I
want
to
say
also
Taylor
is
here
on
the
call
and
micro
and
other
participants
that
are
doing
this
wonderful,
conf,
testbed
so
on
the
road
on
the
road
map
for
CNF
testbed
is
an
interesting
demo
with
kind
of
5
GTA
GTA,
5,
GTA,
pay
and
I.
Don't
know
if
there
are
specific
times,
but
I
would
assume
something
probably
based
on
porting
or
make
on
top
or
something
like
that.
So,
if
guys
are
interested
in
this,
probably
we
can
try
to
form
some
form
of
special
interest
group
I.
I
J
And
that
then,
from
Bell
I
haven't
done.
The
discussion
that
was
I
was
not
at
the
one
s
last
time,
but
from
my
conversation
with
a
lot
of
the
VNA
vendors,
we
currently
use
right
now.
My
guess
feeling
is
they're,
not
even
at
the
discussion
of
should
we
use
an
SM
or
not
they're,
just
trying
to
figure
out
how
the
heck
do
we
continue
eyes
or
make
our
application
cloud
native.
How
do
we
sell
them
to
us
and
as
the
resounding
sound
I
seen
right
now?
J
Is
that
and
that's
part
I
think
why
the
telco,
a
user
group
and
the
white
papers
or
need
to
be
a
I'm
fitting
faster
than
we
talked
we
think
about,
is
because
that's
where
the
day
they
we
have
a
kind
of
an
architecture
around
this
and
people
start
building
code
to
do
those
things.
Then
it's
actually
makes
it
more
prevalent.
Why
should
we
use
network
servers
measure
or
not
right
now,
that
I
think.
J
B
Yes,
exactly
my
feeling
on
it
as
well,
like
one
of
the
things
that
I
mentioned
in
the
C
NTT
group
for
the
people
are,
there
was
like
there
was
a
lot
of
a
lot
of
talk
that
was
centered
around.
How
do
we
container
eyes?
That's?
How
do
we
container
eyes
that,
and
so
one
of
the
things
I
brought
up
was
to
keep
in
mind
that
containerization
and
cloud
made
application
are
two
different
things
and
that
they
need
to
talk
about
them
as
separate
things
where,
except
for
quantification,
requires
a
good
container
ization
story.
B
E
So
in
one
of
my
conversations,
I,
don't
remember
where
it
was,
but
someone
told
me
yeah:
there
is
this
tool
that
you
just
throw
a
VM
at
it
and
then
it
gets
you
a
container
like
it
extracts
everything
and
then
currents
and,
as
you
can
imagine,
the
essentially
the
contents
of
this
virtual
machine
came
from
just
recompiling,
more
or
less.
You
know
the
bare
metal
images
of
what
did
exist,
so
it
kind
of
starts
to
creep
in
integral
native
world.
If
you
think
about
it,
so
I
don't
know.
Maybe.
B
Oh
yeah,
just
wait
till
you
are
having
things
like
keepers
into
it
as
well.
Like
people
say,
oh,
it
runs
on
a
VM
controlled
by
camera
Nettie's,
and
so,
but
they
don't
gain
the
benefits
of
kubernetes
beyond
a
couple
beyond
a
couple
minor
areas.
So
it's
we
definitely
have
our
work
cut
out
for
us
in
this
education
process.
The.
C
Other
thing,
too,
is
that
these
tools
that
convert
beams
into
containers
they're
only
really
operating
at
the
level
of
user
space,
so
in
addition
to
all
the
inefficiency
that
comes
from
the
conversion,
because
you
get
these
trying
containers,
if
you
have
anything
going
on
that,
actually
involves
like
tail
ends
which
most
see
most
vns
do
these
days,
then
you
will
not
work
for
that
purpose.
B
B
Cool:
let's
talk
about
fuzzing
now.
A
B
A
shredder
I
was
meeting
trying
to
respond
this
Taylor.
If
we
do
have
network
functions
that
we
can
define,
whether
were
one
was
the
match,
was
a
4G
type
of
network
function
versus
5g
I
think
it
would
be
useful
to
have
the
functionality
and
the
specifics
of
how
you
would
test
it
from
the
outside.
B
If
we
can
get
all
of
that
the
front
and
that's
helpful
along
this
path,
we're
going
to
keep
educating
people
on
all
the
principles
and
stuff
and
and
then
how
you
could
implement
those
using
something
using
network
service
mesh
or
whatever,
and
but
along
with
that,
just
having
examples
of
code.
We've
we've
been
lacking
on
that
side.
So
what
what
do
people
actually
want?
B
And
we
didn't
get
a
lot
of
feedback,
as
mentioned
from
vendors
on
the
specific
network
functions
for
whatever
reasons
we
did
get
a
little
bit
ons
so
from
operators,
including
a
one
from
Swisscom
that'd,
probably
be
talking
about
after
getting
a
little
bit
more
feed
but
next
time.
But
if
you
have
specific
network
functions
that
you
can
point
out
and
go,
we
can't
release
it
because
it's
proprietary,
but
we
can.
We
can
give
the
specs
on
how
it
should
work
and
the
functionality
we
could
end
up
writing
into
end
tests
and
re-implement
it
ourselves.
B
Yeah,
that's
something
option
and
by
my
preference
would
definitely
be
to
get
the
vendors
dude
can
jump
in
and
buy
em
and
help
us
with
writing
those
tests
out,
but
I
mean
that
is
only
an
option
that
we
that
we
have
is
to
try
to
work
out.
What,
where
we
think
things
are
going
to
be
going
and
what
what's
considered
to
be
of
high
value
and
just
help
defining
what
that
particular
path
would
be.
So
that
is,
that
is
nothing
an
option.
B
Yeah
I
agree:
I
think
it.
It
is
a
good
place
to
get
a
lot
of
feedback
and
and
then
from
there
it
can
go
to
other
projects.
So
maybe
network
service
mesh
says
okay,
we
see
what
y'all
are
trying
to
do,
we're
going
to
implement
some
functionality
to
support
that
and
then
on
the
scenic
testbed
side.
Okay,
we're
going
to
create
an
example
with
different
pieces
that
are
available
and
so
on,
but
it
gives
a
place
to
talk
and
then
and
go
out
to
all
the
other
projects
and
probably.
F
B
It'll
be
it'd,
be
I
would
think
that
we
could
get
to
usable
documentation
papers
pick
then
the
white
paper,
the
white
paper,
is
trying
to
cover
so
much
and
I.
Think
that's
why
it's
it's
been
a
lot
harder,
but
if
we
can
get
something
smaller
like
this,
get
people
to
jump
in
from
vendors
and
their
experience
and
operators
and
what
they've
been
saying
and
we
can
generate
those
and
maybe
have
a
specs
SPECT
documents
or
something.
C
B
C
Yeah,
so
just
a
quick
note:
we've
been
getting
some
fussing
bugs
some
folks
from
closing
community
showed
up
and
have
been
kind
enough
to
run
some
buzzing
testing
so
as
they've
been
finding
things,
we've
been
adding
bugs
for
them.
These
happen
to
be
an
amazing
place
to
start,
if
you're
in
criminalities,
because
sorry,
if
you're
in
never
service,
match
and
wanting
to
pick
up
a
shovel
and
do
some
work
because
effectively
at
the
end
of
day,
they're
really
easy
bugs
to
fix,
and
so
I
wanted
to
be
from
people's
attention
to
them.
B
B
C
I
wanted
to
have
a
brief
discussion
about
API
stuff,
just
so
that
we
can
socialize
some
of
this
a
little
bit
and
get
input.
So
I've
actually
got
a
separate
deck
for
this
because
I'm
talking
to
Nikolaj
this
morning,
he
suggested
that
I
draw
pictures,
and
you
know
what
happens
when
you
ask
me
to
draw
pictures.
C
I
always
rushed
for
time.
This
rings
they're,
not
quite
so
basic
a
45
perfectly
about
the
current
state
of
things.
So
we
have
this
remote
local,
API
splice.
We
have
you
know
the
remote
network
service,
national,
local
memory,
surface
mesh
API.
We
have
remote
connections
and
local
connections.
We
have
remote
mechanisms
and
local
mechanisms.
C
We
have
remote,
monitor,
connection
and
local
monitor
connection,
and
this
was
done
for
relatively
straightforward
reasons
in
the
early
days
of
network
service
mesh,
but
it
turns
out
that
having
two
api's
for
everything,
even
that
are
very
similar,
is
actually
creating
a
bunch
of
internal
headaches.
Trying
to
make
the
total
system
software
it
easier
to
maintain
for
people
and
I
think
we
figured
out
a
better
way
of
doing
it
so
just
to
sort
of
drive
through
the
particulars.
So
you
can
see
how
much
they're
the
same.
C
This
is
side
by
side,
the
remote
network
service
mesh
in
the
local
network
service
mesh
and
literally
other
than
the
fact
you're
talking
about
local
versus
remote
mechanisms.
They
are
exactly
the
same
API
when
you
look
at
connections
they're
very,
very
similar.
The
only
differences
are
for
remote
connections.
We
talk
about
the
source
network
service
manager,
the
destination
network
service
manager,
I'm
a
network
service,
endpoint
name,
but
it
turns
out.
We've
already
got
people
asking
us
to
get
the
network
service
in
point
name
into
the
local
API
as
well.
So
these
are
very,
very
close.
C
The
mechanisms
right
so
remote
mechanisms
and
local
mechanisms,
structurally
they're
identical
the
only
difference-
was
the
emu
types
and
we
already
have
an
issue
out
requesting
that
we
change
from
in
ohms
to
strings
for
mechanism
type
in
order
to
allow
for
easier
extensibility
and
then
for
the
monitor
connection.
Likewise,
they
both
got
connection
events,
types
that
are
the
same.
The
connection
events
are
structurally
the
same.
The
monitor
connection
call
differs
only
and
whether
you
have
a
scope
selector
where
the
scope
selector
lets.
C
You
say
whether
you're
wanting
the
you
know
basically
the
source
and
destination
and
of
what
connections
you're
interested
in,
and
so
these
are
incredibly
alike
and
it's
creating
all
kinds
of
complications
inside
the
implementations
to
have
them
be
separate
at
this
time,
and
so
as
we're
doing
a
lot
of
refactoring,
the
idea
came
up
to
bring
them
together,
and
so
the
proposed
state
is
that
we
do
this.
We
take
the
local
and
remote
versions
of
these
and
we
unify
them.
C
So,
instead
of
having
local
and
remote
network
service
api's,
we
just
have
the
network
service
api
same
with
connections
same
with
mechanisms
same
with
monitor
connection,
and
to
give
you
some
idea
of
what
that
would
look
like
in
the
case
of
the
network
service,
where
the
two
api's
are
basically
the
same
other
than
the
local
and
the
remote
part.
You
just
end
up
with
a
network
service
that
is
structurally
the
same.
Only
you're
dealing
with
unified
things.
C
For
the
unified
connection
object,
essentially,
you
know,
you've
got
the
remote
and
the
local.
The
only
difference
is
you
bring
those
together
as
a
single
connection
where,
rather
than
having
the
source
network
service
manager
and
the
destination
serviceman
every
service
manager,
we
just
have
an
ordered
list
of
network
service
managers.
C
This
gives
us
a
little
bit
more
extensive,
and
then
you
have
the
network
service,
endpoint
name
which
people
already
wanted
for
the
local
connection
in
any
way,
and
then
on
the
mechanism
types
people
are
already
requested
that
we
move
to
using
a
string
type
to
improve
extensibility,
because
there
were
people
wanting
to
be
able
to
add
mechanisms
without
necessarily
having
to
update
the
enum
and
so
the
mechanisms.
What
we've
really
done
is
to
make
this
all
doable.
Is
we
added
a
class
to
the
mechanism
that
class
being
either
remote
or
local?
C
The
reason
the
name
here
is
CLS
instead
of
class,
is
because
all
kinds
of
comedy
ensues
in
languages
like
Java.
If
you
try
and
use
classes
or
as
a
variable
name
but
effectively,
this
is
either
remote
or
local,
and
this
way
we
can
tell
the
difference
between
the
mechanisms
were
dealing
with,
because
you
should
be
able
to
tell
the
difference,
but
you
don't
have
to
have
two
separate
objects
for
them
anymore.
C
Then,
for
the
monitor
connection,
where
we
had
the
remote
in
the
local,
we
would
unify
those
down
to
a
single
connection,
monitor
where
we
would
simply
have
everything,
have
a
monitor,
scope,
selection
and
have
a
repeated
list
of
network
service
managers.
Just
like
we
went
to
a
repeated
list
of
network
service
managers
in
the
network
service
request
for
flexibility,
and
then
everything
comes
in
with
a
monitor
scope,
selector.
C
Yeah
absolutely
and
then
obviously,
there
has
to
be
a
transition
plan
for
the
shift,
and
so
the
thinking
was
that
we
go
ahead
and
create
adapters
to
the
server's
so
that
we
can
switch
over
to
the
new
API
and
simply
wrap
the
original
server
code
rather
than
having
to
try
and
rework
all
the
code
at
once
and
then
anywhere
in
the
original
server
that
we're
using
clients.
And
this
is
true
for
either
network
service,
endpoints
or
network
service
managers.
C
We
have
an
adapter
for
the
client,
so
the
original
code,
if
it
thinks
it's
calling
a
local
client
for
the
network
service
management
API
it
just
instead
of
instantiating,
that
from
one
place
that
instantiates
it
from
a
compatibility
library
and
that
ends
up
wrapping.
The
unify
client
call
when
making
the
call
to
the
the
out,
and
so
in
this
way
the
original
server
code
only
changes
in
using
the
client
adapters
internally
at
first,
and
we
wrapped
them
around
around
them
and
the
service
adapter.
C
And
then
we
can,
at
our
leisure,
pull
the
pieces
out
of
the
original
servers
into
things
that
use
the
unified
API
in
order
to
complete
the
transition.
This
should
let
us
switch
to
the
new
API
fairly
quickly
and
then
do
the
transition
in
a
more
leisurely
fashion.
So
we
don't
get
giant
PRS
that
change
everything
all
at
once
and
to
give
you
some
idea
of
how
that
flow
would
go.
You
know,
essentially
the
stuff
that
comes
in
now
to
any
of
the
servers
would
be
the
unified
API.
C
It
then
makes
its
call
out,
via
whatever
clients
it's
making,
which
goes
to
the
client
adapters
they
convert
to
the
unified
API
and
they
use
the
unified
API
going
out,
and
so
this
should
allow
us
to
do
a
fairly
quick
transition
and
then
deprecated
the
old
API
on
the
ternal
old
original
internal
code
as
quickly
as
it
happens
to
go,
but
it
doesn't
have
to
happen
in
one
piece.
It
can
happen
step
by
step
in
small
pieces,
so
I
wanted
to
sort
of
come
here.
C
If
we
could,
let
them
know-
and
you
know
anyone
else-
you
know-
of
who's
building
things
on
top
of
Edison-
please
let
them
know
this,
you
know
effectively.
You
know
the
part
of
why
the
deck
is
here
is
to
sort
of
help.
Explain
what's
going
on,
there's
also
in
the
meeting
minutes
a
link
to
the
PR,
all
right
that
that's
actually
working
on
the
new
API.
C
If
you
want
to
sort
of
see
the
walking
in
tackling
it
also
has
to
start
on
the
converter
routes
and
adapters
as
well,
but
yeah
I
do
let
them
know
this
is
happening,
but
be
one
of
the
reasons
that
I'd
like
to
get
this
done.
If
folks
think
it's
a
good
idea
fairly
expeditiously
is
the
the
more
time
passes,
the
more
people
will
be
building
things
on
network
service
mash,
and
so
you
know
we
don't
want
to
have
beats
better
to
switch
the
API
like
this
sooner
rather
than
later,.
B
Yeah
I
completely
agree,
especially
as
we
do
the
march
to
the
1.0
release
and
so
I
think
right
now
is
the
perfect
time
to
do
it
and
yeah
we're
just
going
to
get
it
done
like
this.
Has
a
series
of
other
really
nice,
a
really
nice
properties,
so
that
once
once
we
start
to
bring
in
things
like
multiple
multiple
data
planes.
At
the
same
time,
we're
like
you
could
have
PvP
is
identifying
your
SRO.
The
things
can
be
a
its
own
data
playing
or
maybe
have
some
of
the
controls
and
tarek
tunnel
type.
B
That's
not
supported
by
yours
by
your
common
infrastructure.
So
it'll
help
with
like
the
dynamic
selection
of
these
type
of
these
type
of
things,
and
so
this
edge
I
change.
You
really
helps
simplify
that
entire,
that
entire
process
with
that
is
there
anything
else.
We
want
to
talk
about
on
the
API
discussion.
B
C
A
F
C
The
other
thing
that
came
in
was
a
comment
on
one
of
the
PRS
from
someone
who
said
that
they
were
having
some
issues
with
the
interaction
between
spire
and
an
on
docker
CR
ice.
So
I
am
trying
to
find
out
what
CRI
they're
playing
with
and
what's
going
on
so,
but
they
they're
comfortable.
They
have
a
workaround,
so
they
can
they're
not
blocked,
but
we
obviously
want
to
make
sure
we
work
in
general.
C
E
E
C
The
number
of
different
things
that
live
in
the
main
repo
is
kind
of
large,
and
there
is
a
desire
to
try
and
break
this
up
into
sub
repos
over
time
and
sort
of
the
first
step,
for
that
was
to
have
multi
modules
in
the
main
repo.
This
also
helps
a
lot
for
people
developing
network
service
in
points,
because
it
means
that
you
only
have
to
depend
on
the
bits
that
the
sdk
itself
actually
depends
on.
You
don't
end
up
pulling
through,
like
all
the
kubernetes
dependencies
that
are
only
used
in
the
Cades
directory,
for
example,.
E
D
C
B
E
C
This
was
a
response
to
about
what
we
found
for
auto
heal
and
the
bug
was
that
when
we
were
testing
auto
heal,
we
would
start
getting.
You
get
a
few
ping
failures
on
auto
heal
and
whatever
to
be
was.
It
was
an
RPR
issue.
So,
basically,
when
you
auto
heal,
you
were
getting
reconnected
to
somebody
who
had
a
different
Ethernet
MAC
address
on.
C
There
have
different
MAC
address
on
their
end
of
the
connection
right
because
you
just
reconnected
to
them,
and
so
you
had
a
and
now
you
have
an
incorrect
ARP
entry
in
your
cache
and
so
the
the
way
we're
looking
at
fixing.
That
is
to
add
to
the
connection
context.
Just
like
we
have
an
IP
context
in
a
DNS
context
to
add
an
Ethernet
context
so
that
when
you
go
to
auto
heal,
you
can
say:
look
I'm,
Auto
healing
the
guy.
C
E
I
was
I
was
I,
was
thinking
something
along
the
lines.
You'd
remember
like
I,
don't
cause
bug
or
two
cause
bug,
but
discussing
that
today,
I
piece
are
more
or
less
mandatory
in
the
way
that
we
have
our
API
implemented,
but
yeah,
that's
probably
something
that
has
to
be
tackled
separately.
Okay,
well,.
C
C
We
definitely
need
to
fix
that,
if
orders
or
requiring
it,
because
they
shouldn't
be
I,
mean
it's
another
thing.
If
we
happen
to
have
very
heavily
encourage
that
kind
of
behavior
with
our
SDK,
they
you,
as
you
observed,
you
need
to
be
able
to
run
without
an
IP
context,
just
like.
We
also
need
to
be
able
to
run
without
an
Ethernet
context.
Frankly,
so
because
you
you,
you
you're,
there
are
definitely
use
cases
where
you
actually
don't
want
I
pan
happening.
C
B
The
document
is
dated
in
April
2009
teen,
but
there
seems
to
be
quite
a
few
people
looking
at
it
right
now
because
of
the
email
later
sent
and
it
was
written
by
Lee,
Cal
cooked
with
contributions
by
Matt,
Klein
and
Ken
Owens
and
we'll
leave
it
at
that
and
revisit
this
stuff
next
week.
Anyways.
Thank
you
all
for
your
time
and
we'll
see
you
again
at
the
same
time
here
next
week,
take
care.