►
From YouTube: Network Plumbing WG Meeting 2018-05-24
Description
Kubernetes Network Plumbing Working Group meeting 2018-05-24
A
A
All
right,
so
the
first
one
I
think
we
added
last
time,
and
that
was
interface
requests
as
part
of
extended
options.
I,
don't
remember
what
the
conversation
there
was
about,
but
I
think
it
was
about
if
we
wanted
to
let
the
user
request
a
specific
interface
name
as
part
of
the
extended
annotation
options
desiring
a
bell
with
anybody.
B
A
B
B
A
I,
don't
think
it's
a
bad
option,
and
actually
let
me
move
up
the
it's
right
underneath
it
anyway.
Well
I
mean
that
probably
leads
into
a
larger
discussion
around
how
to
handle
the
extended
options.
There
were
some
comments
on
specification
around
whether
the
set
of
keys
for
the
extended
annotation,
like
IP,
request,
Mac
requests,
that
kind
of
thing
was
final
or
would
it
be
able
would
we
be
able
to
pass
arbitrary
keys
through
to
plugins
and
as
the
spec
had
been
written,
this
list
was
final
and
all
other
keys
were
reserved
I
suggested.
A
B
A
B
A
The
convention
for
IP
request
is
actually
IPS,
and
so
the
name
that
we
have
in
the
spec
is
not
the
same
as
the
actual
CNI
Convention
for
something
like
hosts
local
and
obviously
Mac
request
does
not
exist
in
C
and
I.
Yet
nor
does
interface
requests
so
I
think.
The
decision
that
we
would
want
to
make
here
is:
do
we
want
to
be
able
to
pass
these
keys
through
directly
to
the
CNI
plug-in
and
give
some
flexibility
around
customization
in
the
network
annotation
or
do
we
want
to
basically
say
this
list?
B
Yeah
I
think
so
yeah,
which
you
said
could
be
the
best
way
to
go
all
right,
because
the
if
the
siene
libraries
already
support
right.
So
we
don't
need
to
reinvent
the
wheel.
What
is
that
say
na
is
doing
I
was
thinking
reuse,
maybe,
as
in
the
libraries
of
whatever
it's
providing
right
now,
I
think
it's.
There
was
one
port
request
from
Mike.
It
was
much
I
don't
know.
Do
you
know
that
that
was
good
much
for.
A
B
A
A
A
It's
just
gonna
take
a
look
okay,
but
that
should
basically
solve
the
multiple
attachment
problem
once
that
happens,
but
again
that's
going
to
require
a
bump
of
the
C&I
spec,
which
we've
already
done
for
other
reasons,
but
then
a
new
release
of
the
cni
plugins,
the
reference
plugins
I,
mean
obviously,
if
you're
not
using
a
reference
plug-in.
You
can
implement
this.
However,
you
want
right
away,
but
if
I'm
good
reference
plugins
it'll
take
an
update
of
those.
A
A
B
A
Your
first
second
okay,
so
the
the
idea
there
is
that
when
the
meta
plugin
is
reading,
the
extended
Jason
lists
annotation
form
that
it
would
take
those
options
and
then
essentially
translate
those
into
something
that
C
and
I
would
work
with.
Does
that
make
sense
because
a
it
looks
like
ip's
is
okay,
a
mac
does
not
exist
yet,
and
so
we
either
need
to
add
the
mac
request
to
see,
and
I
as
a
convention
and
then
have
the
reference
plugins
actually
use
it.
C
Sabattus
server
is
not
here
when
you
create
a
certain
type
of
network,
you
really
want
to
set
it
back
as
well
right,
and
there
is
some
UI.
There
is
no
need
some
user
for
coming,
the
DHCP
private
e6.
We
actually
can
also
an
implementation
can
mask
for
mac.
Addresses
an
item
can
sort
of
support
mac
addresses
as
well
too
late
to
a
device
for
similar,
or
in
this
case
it
could
be
to
the
CMI
itself
on
a
machine.
A
D
C
B
A
I
mean
to
be
clear:
you
can
request
this
stuff
through
the
annotations
in
the
pod
on
a
pod
specific
basis,
but
you
can
also
always
add
it
through
the
CNI
configuration
itself
where
that's
on
disk
or
in
configuration.
But
if
you
do
it
through
the
CNI
configuration
itself,
then
it's
going
to
be
requested
for
all
pods
that
attach
that
network.
So
that's
not
extremely
useful.
A
So
that's
what
we're
referring
to
alright
back
to
the
agenda.
A
So
I
think
the
next
item
was
around
the
versioning
and
you
had
brought
that
up
Corral
when,
for
a
thick
plug-in
version
and
I
think
had
a
really
good
point
there.
As
the
spec
specifies
it
would
basically
lock
to
a
specific
version
and
I
don't
know
of
any
good
ways
to
get
around
that
besides
requiring
the
meta
plug-in
to
call
version
on
that
other
plugin
and
then
figure
out
some
compatible
version
between
then
what
the
meta
plug-in
understands
and
what
the
thick
plugin
understands,
and
that
seems
like
a
lot
of
work.
B
A
A
Well,
two
ideas,
really,
let
me
start
go
up
in
the
spec
to
where
it
is
in
my
computer.
A
B
A
B
B
B
B
B
One
thing
I
was
in
the
network
spec:
they
there
was
one
sentence.
It
was
mentioned
that
if
both
plug-in
and
the
config
exist,
then
the
key
will
take
precedence
over
the
plug-in
actually
in
section
3.2
right.
So
I
mentioned
that
currently
in
the
reference
provement
ation.
If
the
both
the
things
present,
it
will
turn
out
to
be
a
error,
whatever
I'm,
using
whether.
A
B
A
A
Though
okay,
what
do
you
think
the
benefit
or
the
trade-offs?
There
would
be
only
the
because
the
the
problem
there
is
going
to
be
that
we
don't
really
get
good
resource
validation
for
custom
resources.
It's
basically
just
a
map,
I,
don't
think
you
can
say,
or
you
can
enforce
any
kind
of
error
handling
mm-hmm
in
kubernetes
itself.
So
what
would
end
up
happening
would
be
you
know,
as
a
user,
you
would
set
both
these
fields
and
then
you
try
to
start
a
pod
with
this
particular
network
and
then
it
would
just
error
out.
C
A
C
B
A
A
A
You
know
a
couple
seconds
after
they
start
up
and
that's
how
they
actually
signal
kubernetes
to
begin
starting
pods
on
that
node,
and
it
occurred
to
me
that,
as
we
had
worded
readiness,
the
meta
plugin
should
not
write
its
own
file
to
Etsy
CNN
ad
until
it
was
sure
that
the
default
network
was
ready
and
so
I
was
wondering.
How
actually
would
that
work,
because
most
thick
plugins
currently
writes
their
file
to
the
standard
CNI
directory
at
CCI,
netd
and
aware
of
plugins
that
allow
that
directory
to
be
changed.
A
So
you
know,
basically
what
would
happen
would
be
if
the
meta
plugin
is
waiting
for
the
default
plug-in
to
write
its
file,
then
the
default
plug-in,
writes
its
file
and
then
kubernetes
picks
up
that
default
plug-in
and
then
finally,
the
meta
plug-in
writes
its
file,
and
you
know
we've
got
a
problem
and
cube.
Is
it
using
the
right
thing.
B
A
Yeah
yeah
I
mean
the
other
option.
Here
is
actually
I
just
thought
about
this.
If
you
want
to
use
a
meta
plugin,
we
could
require
that
kubernetes
be
pointed
at
a
different
CNI,
config
directory
and
I.
Think
as
of
110
communities
or
111
I.
Forget
which
communities
has
that
option,
yeah
yeah
very
different
place,
so
yeah.
B
C
D
B
A
B
What
we
are,
if
we
have
a
automated
Malta's,
writing
I,
think
daga
is
a
demon
set
of
Maltese
if
the
demon
set
of
the
monsters
have
like
zero
0
multi-store
config,
that
multis
got
the
president,
the
cubelet
and
then
currently
we
have
a
shoes.
Like
I
mean
there
is
a
intermediate
solution,
daggers
provided
that
you
provide
the
default
networking
delegates,
but
in
future
me
we
can
change
that
to
the
config
file.
C
C
B
A
C
A
The
issue
and
looking
at
the
cube,
CNI
driver
code,
it
does
look
like
yeah,
it
does
look
like
cube,
will
actually
I
mean.
Obviously
it
watches
that
directory,
but
it
looks
like
if
something
else
writes
a
file
with
higher
precedence.
Kubernetes
will
actually
change
the
network
plugin
out
underneath.
So
it
could
be
the
case
that
if
flannel
writes
out
its
count,
file
first
community
starts
up
to
pods
with
flannel
and
then
MultiJet
surround
to
writing
its
file
and
then
starts
calling
Malta's
for
everything,
which
is
a
little
unfortunate.
B
A
B
A
A
B
This
one
I
was
thinking
that
we
all
didn't
have
created
this
big
right.
I
think
you
mentioned
the
name
was
version
1,
so
I'm,
seeing
thinking
that
whether
we
want
to
do
it
like
how
the
CNA
spec
is
right,
we
can
make
like
a
standardization
on
this
one
like
spec
numbers,
something
like
that.
So
whoever
wants
to
work
on
one
thing
and
working
there
should
follow
this
kind
of
the
standard.
B
Currently,
it's
we
not
putting
this
as
a
standard,
but
if
you
make
it
as
a
standard
right
who
would
want
to
implement
wanting
and
Fokine
whatever
ways,
instead
of
doing
it
differently,
they
could
put
go
for
a
standard
way
of
doing
this.
One
I,
don't
all
to
achieve
that.
One
I
just
put
it
as
a
idea.
Actually
I
was
discussing
with
Fang,
Fang
and
Tomo
last
year
on
this
one,
and
they
said
it
would
be
better
for
me
to
bring
it
as
open
for
the
meeting
yeah.
A
I
mean
it
was
sort
of
always
at
least
I'd,
always
thought
of
it
as
a
standard
and
the
reason
I
had
always
called
it
de-facto
when
I
was
writing
up
stuff.
Was
that
it's
not
formally
blessed
by
you
know
signet
work
or
anything
like
that,
and
it's
not
a
formal
camera
is
standard,
but
you
know
we
couldn't
explore
how
to
formalize
it
more.
A
B
A
B
B
Telemetry
yeah,
the
networked
Elementary's
was
I,
was
looking
into
the
network
status
one,
so
that
was
a
use
case
came
to
my
mind,
like
currently
kubernetes
support,
only
one
networking.
So
in
this
case,
if
we
want
to
send
this
network
telemetry
information,
there
is
no
way
you
can
express
the
multi
networking
part,
but
we
provided
this
network
status.
I,
don't
know
who
introduced
this
one,
but
I
really
like
this
sure
of
including
the
network
status
as
a
PA
in
the
annotation
part.
B
So
the
there
is
some
third
party
like
promises
or
something
which
read
the
annotation
and
then
say
this
particular
part
is
a
multi
networking
part.
So
I
have
to
monitor
two
different
interfaces
in
this
part.
Something
like
that.
So
we
can
say
this
particular
interfaces.
How
much?
What
is
the
bandwidth
and
what
is
a
input
and
output?
Two
packets,
and
something
like
that.
I
was
thinking
on
this
particular
thing.
A
B
B
A
Mean
I
would
definitely
think
in
whatever
you
know,
final
multi
network
implementation
cube
actually
ends
up,
using
that
this
kind
of
stuff
would
somehow
be
available,
whether
it's
through
you
know
an
annotation
like
this
or
whether
it's
through
Prometheus
or
something
you
know
even
more
formal.
If
kubernetes
was
to.
B
C
B
Very
static
actually,
so
if
you
see
the
meta
plug-in,
it's
not
like
a
demon,
so
it
can
yeah
yeah.
So
that
should
be
someone
so
the
meta
plugin
information
should
known
for
someone,
so
they
can
monitor
the
work.
So
my
de
plugin
is
a
guy
will
say:
okay,
this
is
what
it
has
this
pot
ass.
So
please
check
these
things.
B
Currently,
we
didn't
not
exploring
much
on
the
network
of
a
scheduling
part
actually.
So,
if
you
see
like
this
particular
box
haves
like
10
Nick's,
okay,
so
all
these
techniques
or
consumed
by
this
much
workload,
so
I
can't
place
this
particular
for
any
more
here,
because
kubernetes
doesn't
care
about
network.
C
B
A
B
A
B
A
Not
too
much
and
aware
that
we've
discussed
it
in
the
past
is
that
you'd
essentially
have
kind
of
like
a
shim
that
would
implement
gr,
PC
and
then
exec
the
reference
CNI
plugins.
If
that's
what
you
wanted
to
use
so
I,
don't
think
that
there
would
be
a
huge
change
for
the
reference
plug-in
users
at
least.
B
B
C
A
A
Not
even
that
low,
it's
more
about
just
replacing
or
not
replacing,
but
adding
a
and
always
on
API
option
to
see
and
I
plugins
or
that
of
the
current
exact
model
and
there's
two
reasons
for
that.
The
first
one
is
that
it's
a
lot
harder
or
it's
a
lot
heavier
to
exec
processes
on
Windows,
and
so
the
windows
people
had
sort
of
wanted
that.
But
then
it
also
allows
for
asynchronous
communication
of
like
error
and
state
and
stuff
back
from
the
sea
and
I
plug
into
kubernetes.
A
So
that
cube
doesn't
have
to
pull
that
and
again
I
mean
this
has
only
been
proposed
and
brought
up
a
couple
of
times
nobody's
actively
working
on
it.
Yet,
but
that's
mainly
because
people
don't
have
time,
there's
general
agreement
from
the
CNI
maintainer.
This
is
you
know
something
that
would
be
interesting
to
do.
B
So
I
put
it
in
the
chat,
the
implementation,
actually
it's
very,
very
early
stage,
actually
that
but
this
project
actually.
So
this
shame.
This
is,
like
a
shame,
does
a
it's
a
dead
dance
idea?
Actually,
so
we
had
a
chat
in
slang,
I
think
like
one
month
or
two
months
before,
maybe
because,
a
while
ago,
yeah
yeah.
A
B
Yeah,
so
we
developed
resist
depending
upon
dancer
idea
like
we
can
funnel
the
all
the
see
anything
off
and
then
send
it
back
to
a
daemon
set
and
the
daemon
set
will
provide
the
provide
networking
information
and
then
its
impact
do
the
cubelet
actually.
So
the
we
are
not
changing
anything
on
cubelet
actually
in
this
case,
but
the
demon
set
will
be
alive
overall.
The
pod
life
cycle,
so
yeah.
B
Logs
yeah
I
think
currently
the
CNA
doesn't
provide
any
logs
like
pro.
If
you
that
is
in
a
any
error,
you
have
to
check
with
the
cubelet
logs
the
cubular
logs
CEO,
to
check
each
and
every
times
on-the-spot
creation.
You
have
to
go
through
all
the
part
creation
and
three
where
the
CNA
is
invoked.
Then
after
that
meta
plugin
is
invoked,
then
you
have
to
go
through
the
errors
and
even
in
errors,
you
won't
get
exactly.
B
Sometimes
it
will
say
let
unexpected
Jason
output
or
something
most
of
the
time
so
I
was
thinking
like
we
should
develop
some
kind
of
logs
and
generate
the
logs
separately
in
here's.
A
Val
log
like
might
a
plug-in
slash
something
so
that
we
can
say
like
whenever
the
pod
starter
right.
So
what
is
the
error
happened?
But
I
don't
know
like
whether,
because
it's
a
binary
invoke
whether
we
can
able
to
create
such
a
long,
I
am
Not
sure,
but
thinking
with
whether
creating
or
logs
will
be
a
good
option
or
not
I'm
thinking.
B
B
We've
got
most
of
the
time
when
someone
wants
to
use
a
mentor
plugin.
They
always
ask
me
like
this
is
not
working
that
it's
not
working,
then
I
will
say:
okay
go
and
check
the
cubelet
logs
and
they
are
not
ever
out
what
is
accu
blog
on
how
it
works.
So
it's
very
difficult
for
some,
like
a
beginners
to
debug
the
issues
within
networking.
So
that's
what
I
was
thinking.
A
It
might
also
be
useful
for
the
meta
plug-in
to
capture
all
of
standard
out
and
standard
error
from
the
plug-in
and
then
write
that
to
a
debug
file
or
have
some
mechanism
to
be
able
to
do
that,
because
I'm
trying
to
remember
if
writing
stuff
to
standard
out
or
standard
error
will
cause
an
error
if
it's
not
the
correctly
formatted
JSON
response
or
if
that
gets
ignored.
Maybe
I
should
go
look
at
that,
but
it.
C
C
B
A
B
B
The
last
one
we
had
some
feedback
actually
some
of
the
folks
Abdul
and
Louise.
Last
week
they
present
at
about
the
SRV
network,
a
base
plug
into
the
missus
management
working
group
yesterday,
and
we
got
some
feedback
like
week
on
the
device.
Plugin
can
invoke
the
CNA
binaries,
actually
the
same
thing
as
like
what
well.
A
D
A
Problem
that
I
see
is
that
a
device
plug-in
that
implements
multi.
Essentially,
the
implements
of
this
specification
doing
something
like
Malta's
does,
would
have
to
be
duplicated
in
every
single
device
plug-in,
and
it
was
my
understanding
that
originally
device
plugins
were
meant
to
be
more
Hardware.
Specific
yeah,
like
Nvidia,
would
have
a
device
plug-in
from
their
gpus
and
InfiniBand
cards
and
install
might
have
a
device
plug-in.
That
knows
how
to
do
specific
things
for
their
cards
and
if
we
rely
on
every
device
plug-in
to
implement
the
Malta's.
Excuse
me
this
CRD
specification.
B
A
B
A
And
I
think
Tim
had
a
comment
in
the
meeting
where
the
device
plug-in
stuff
got
demoed,
that
it
seemed
like
overkill
for
like
logical
networks
or
you
know,
Sdn
type
stuff,
so
I
don't
know
if
that's
really
been
addressed
yet
I
mean
obviously
it
might
work
for
those
networks,
but
it
seems
like
through
that
kind
of
stuff,
yeah
so,
but
also
I,
think.
The
last
thing
that
was
brought
up
was
the
confusion
or
the
unnecessary.