►
From YouTube: Network Plumbing WG Meeting 2018-02-15
Description
Network Plumbing WG Meeting 2018-02-15
A
All
right
recording
is
on
so
first
on
the
list,
a
spec
updates,
quick
recap.
From
last
time.
We
spent
quite
a
bit
of
time
talking
about
the
format
of
what
the
status
map
should
look
like
and
then
also
what
the
network
selection
or
attachment
selection
annotation
should
look
like
as
well.
Mike
had
suggested
using
a
list.
Excuse
me
a
JSON
list
of
maps
for
those
in
which
the
name
would
be
one
key
out
of
a
few
keys.
A
A
Oops
I
forgot
a
Kannamma
now
it's
there,
okay
and
then
also,
if
you
look
below
in
the
status
annotation
that
that
seemed
like
there
was
much
less
dissent
on
that
one.
So
I
just
went
ahead
and
changed
that
network
status
annotation
to
follow
that
as
opposed
to
creating
an
alternate
proposal.
Obviously
that
could
be
changed
back
at
some
point
in
the
future
if
we
find
there
issues
with
it.
A
A
B
C
A
Cool
we'll
just
go
with
this,
then
for
the
moment
see
what
other
changes
I
also
clarified.
The
cluster
wide
default
Network
the
behavior,
therefore
the
status
map,
and
so
that's
also
in
the
network
status,
annotations
section
for
I
added
the
text
saying
the
cluster
wide
default
network
must
have
an
entry
in
the
status
map,
even
though
it
is
not
specified
in
the
network's
annotation.
As
a
runtime
meta
plugin
is
required
to
attach
the
pod
to
the
cluster
wide
default
network.
It's
key
shall
be
at
CNI
network
name.
A
B
A
So
I
think
that
was
it
for
the
spec
changes
that
we
had
talked
about
last
time.
So
are
there
any
other
things
to
talk
about
immediately?
The
only
other
item
on
the
agenda
was
that
we
had
spent
a
while
last
time
discussing
multiple
attachments
to
the
same
network.
I
also
did
bring
that
up
in
the
cni
maintainer
z--
meeting,
and
there
was
recognition
of
the
issue,
but
not
a
ton
of
inertia
to
solve
it
so
and
I
think.
A
The
proposal
that
we
had
sort
of
come
up
with
was
to
also
include
the
interface
name
as
part
of
the
unique
tuple
for
us
CNI
invocation,
so
that
that
tuple
would
then
be
comprised
of
the
network
name,
the
container
ID
and
the
interface
name.
I'm.
Sorry
was
distract.
What
did
you
say
was
the
group's
reaction
to
that
I
said
there
was.
There
was
some
recognition
of
the
problem.
A
D
B
A
A
A
B
A
C
But
that's
what
you
suggested
is
a
much
better
idea,
but
like
that,
that
was
kind
of
mad
Mac
I
plan
to
try
it
out
and
see
if
it
works
and
call
it
like
food
or
like
fulsome
character
that
we
don't
usually
use
in
interface
names
like
interface,
name
right.
That
would,
like
you,
know,
kind
of
keep
the
uniqueness
right
because
we
add
the
interface
name
and
then,
like
you
know
like
and
parse
it
and
figure
it
out.
C
But
I
really
like
the
scene
aspect,
changed
right,
but
if
it
doesn't
fly,
you
know
like
if
you
and
Mike
like
you
know,
cannot
pull
it
off
right
and
then
maybe
we
can
go
down
the
other
path.
I,
don't
like
this
kind
of,
like
you
know,
hiding
data
and
format
of
fields.
But
that's
okay
like
if
that's
the
last
hope.
A
A
So
if
the
C&I
config
jason,
that's
either
in
a
file
on
disk
or
in
this
this
custom
resource
definition,
spec
happens
to
declare
say
version
zero
point:
three
point:
zero
of
the
cni
spec
that
gets
put
into
a
CNI
version
field
in
the
Jason
cube
would
just
pass
that
through
and
if
any
plug-in
in
the
chain
does
not
support
version
zero.
Three
zero,
then
that
invocation
should
fail.
A
B
But
the
the
version
number
I
mean
I.
Still,
you
know
these
files
is
bugging
me.
The
file
is
sort
of
serving
dual
purpose
right.
The
version
numbers
in
the
file,
the
coop-
will
pick
up
the
file
and
stuff
it
into
the
plug-in.
So
whatever
the
plugins
I
mean
that
there's
there's
still
missive
into
something
here
right,
because
if
the
plug-in
says
I'm
old
coop,
just
stuffs
in
it
gets
old
and
the
new
stuff
doesn't
happen
right,
so
a
coop
has
to
inspect
it
and
see
whether
it
likes
it.
No,
not
new
stuff,
nothing
happens.
Mike.
B
Right
now,
no
yeah
I'm
thinking
through
sir
right
we're
gonna.
Have
these
these
things
in
these
resources
and
they'll,
say
the
new
version,
I
guess
what
we'll
say
is
if
you
want
to
have
multiple
attachments
to
the
same,
multiple
uses
of
the
same
attachment
Factory,
then
you
have
to
use
the
newer
version
of
the
C&I
spec
and
that
version
will
be
in
the
resource
and
this
plugin
will
have
to
respect
that.
So.
A
Okay,
yes,
exactly
yeah,
there
would
be
a
little
bit
more
manual
configuration
required
because
you
would
have
to
specify
a
the
version
name.
The
other
thing
is,
though,
that
you
need
to
specify
version
zero,
three,
zero
or
higher
right
now,
anyway,
to
get
the
multiple
IP
addresses
and
multiple
interface
reply
from
a
CNI
plug
in
any
way
which,
of
course,
q
Bernays
does
not
currently
do,
but
so
yeah
I
mean
there
are
already
some
cases
where
you
want
to
specify
the
version
name.
Our
version
number
excuse
me
so
that
kind
of
well,
okay.
A
A
I
understood
suresh,
saying
it
would
be
that
the
plug-in
that
the
meta
plug-in
or
the
runtime
would
do
something
like
add
the
interface
name,
which
needs
to
be
unique
across
invitations
to
the
network
name.
And
so
when
your
plugin
gets
its
network
name,
it
would
get
something
like
you
know:
network
a
eth0
or
network
a
at
eth0,
and
since
it
would
be
specified
that
this
is
the
format
in
which
the
network
name
will
be
plugins.
That
conform
to
our
specification
that
we're
coming
up
with
here
would
be
able
to
parse
that
and
figure
out.
A
E
B
A
C
F
C
B
A
Okay
and
that
I
think
the
next
question
was
the
network
attachment
factory
object,
name
versus
the
cni
jason
name.
There
had
been
some
discussion
about
that
last
time.
The
specification
as
I
had
initially
written
it
had
required
that
those
to
be
the
same
for
each
invocation,
and
that
was
a
problem
for
multiple
attachments.
A
We
are
now
breaking
that
if
we
go
with
suresh's
suggestion,
but
at
least
we'd
be
breaking
that
in
a
standardized
way
and
the
network
attachment
factory
name
would
be
a
component
of
the
final
Jason
name
key
that
was
passed
to
the
C
and
I
plug
I.
Think
the
only
concern
I
had
had
and
the
reason
why
I
wanted
to
keep
those
two
at
least
somewhat
the
same
was
that
it
seemed
confusing
if
you
could
have
kubernetes
api
objects
with
wildly
different
names
from
what
was
actually
passed
to
a
network.
Plugin.
B
So
right
I
mean
I
still
will
I'll
read
about
my
problem.
My
concern
is
kind
of
going
the
other
way,
so
I
I
guess
I
have
a
problem
with
that
that
concern,
which
is
what
do
you
mean
by
a
wildly
different
I,
mean
maybe
in
some
context
some
provider
has
some
kind
of
systemic
relationship
right.
We
don't
know
what
it
is.
B
It's
it's
not,
you
know
equals
right,
but
it
may
be
very
logical
and-
and-
and
you
know
there
for
a
reason
that
more
concern
I
have-
is
that
again
we're
trying
to
reference
networks
that
exist
outside
of
kubernetes
in
right
way?
Among
that's
the
one
thing
we
want
to
do
and
they're
gonna
have
names
that
come
from
outside
kubernetes
they
might
even
follow.
You
know
they
might
have
names
that
can't
be
kubernetes
names.
A
B
F
A
B
A
E
E
So
that's
one
piece.
The
other
piece
which
also,
which
also
is
interesting,
is
happened
over
the
last
week
is,
you
may
have
seen
the
machine
learning
working
group
that's
potentially
being
started
and
that
one
also
has
well
I
believe
will
certainly
have
network
implications
beyond
a
single
machine.
We
need,
you
know
fast
links
to
do
a
distributed
machine
learning
and
whatnot.
So
this
has
been
on
my
radar
for
the
longest
time
to
solve
for
machine
learning
by
having
fast
data
in
kubernetes.
E
Okay,
right,
what's
the
public
forum
where
we're
gonna
discuss
this
yeah
well,
I
hope
it's
either
here
or
the
resource
management
working
group
I
mean
that
that's
the
one,
at
least
that
so
they
own
the
device,
plugins
or
quote-unquote
own
right,
and
then
this
team
is
doing
CR
DS
we're
hoping
to
smash
them
together
to
come
out
with
an
actual
product
out
the
other
side.
You
know
so.
E
A
B
A
E
Yeah,
you
know
what
ends
up
happening.
Is
these
these
males
have
five
SIG's
on
them,
every
male
I
sense.
The
resource
management
sega
ends
up
seeing
the
scheduling
people
because
of
there's
an
intersect
they're.
Almost
always
I'm
just
looking
at
the
initial
male
now
and
I
do
see
sig
network
on
there.
So
you
have
a
copy.
F
E
F
A
I
will
update
the
spec
for
the
comments
in
the
agenda
doc
that
I
have
made
there
and
I'll
probably
include
some
wording
about.
Suresh
is
ugly
hack
for
the
moment
and
yeah
I
think
that's
it
and
if
Doug
is
still
on,
maybe
Doug
wants
to
try
to
update
multi
in
concert
with
Carol
to
this
new
spec.
So
we
can
see
what
some
of
the
issues
there
are.