►
From YouTube: Kubernetes Resource Management WG 20180523
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
Mm
okay,
silly
recording
is
not
turned
on
welcome
to
yet
another
meeting
of
resource
management.
Working
group
and
today
is
23rd
of
May.
We
have
quite
a
few
topics
in
the
agenda,
so
I
think
the
first
one
is
what
I
saw
IO
V
device
plugins,
not
sure
who
that
is
I'm
assuming
you're
in
this
call.
Can
you
like
speak
up
and
get
going
with
the
topic.
C
So
basically,
what
we
wanted
to
bring
this
forward
for
was
to
kind
of
start,
a
discussion
to
create
kind
of
a
unified
story
for
network
devices.
So
our
plan
is
to
present
about
this
resource
management
group
and
Signet
work
to
get
kind
of
a
unified
view
on
whether
this
is
a
good
way
forward,
and
so
the
plan
today
is
to
talk
about
our
s,
Riv
implementation.
What
with
the
view
that
this
could
work
further
networking
devices?
This
is
just
an
example
implementation.
C
So
if
there's
any
questions,
churches
staff
me
I
know
I'll
take
those.
So
the
motivation
behind
starting
this
was
that
CNI
is
very
good
at
what
it
does,
but
it
does
not
cover
the
entire
lifecycle
of
a
network
device.
So
for
the
cases
where
there's
limited
network
availability,
so
in
arc,
CSRA
vvvf
and
there's
no
mechanism
to
advertise
these
and
to
have
the
scheduler
account
for
those
when
pods
are
being
rendered.
C
So
if
you
are
running
your
pods
with
just
C
and
I,
enabled
with
SR
IVC
and
I,
and
you
run
out
of
EF
C
or
pods
gonna
fail
and
you'll
have
to
look
into
the
cube.
Ctl
described
with
the
part
to
see
why
it
failed,
as
opposed
to
seeing
that
the
the
scheduler
is
out
of
VF
s--.
So
that's
the
first
major
reason
we
wanted
to
have
a
more
granular
view
of
limited
network
availability.
C
So
then
as
well,
there's
no
plan,
no
alignment
with
C
and
I.
So
a
lot
of
the
late
intensity
applications
that
we
have
from
customers
use
CPU,
pinning
and
also
required
that
the
the
network
traffic
comes
from
the
same
new
node
as
the
the
CPUs
they're
pinned
to.
So
with
the
new
manager
proposal,
we
have
device
plugins
and
the
CPU
manager
coordinating.
So
that
was
all
of
that
issue
for
us
and
then
lastly,
CNI
has
no
mechanism
to
manage
device
erupts.
C
C
So
there's
been
a
couple
of
other
work
done
in
this
area
and
so
because,
as
a
proposal,
which
kind
of
also
outlines
going
to
be
a
unified
network
and
CNI
plug-in,
and
then
there
was
some
proposal
by
Fabian
and
Peter
extending
the
the
resource
API,
that's
returned
cubelet
to
account
for
for
networking
resources.
So
our
proposal
isn't
brand
new.
It
builds
on
these
and
kind
of
tries
to
create
one
unified
story
for
network
devices,
so
there's
four
components
to
the
project.
C
So
there's
the
SR
IV
Network
device
program,
which
is
a
device
program,
implementation
for
s,
er
IV,
then
there's
a
CNI
shim,
which
is
basically
a
bridge
to
communicate
between
the
device
program
and
the
CNI,
and
it
does
Feig
RPC
and
then
there's
a
meta
plugin
which
in
our
case
is
multi
which
enables
us
to
do
multiple
interfaces
in
our
pod.
And
finally,
we
have
SRA
vci.
So
with
the
the
work
in
the
network,
roaming
group
for
network
objects.
We've
aligned
this
project
with
with
that
work
as
well.
So
that's
a
lined
up.
C
So
this
kind
of
the
the
block
diagram
of
our
components,
so
the
SRA
be
device
plug-in,
is
responsible
for
discovering
the
SRA
v.
Vf
is
available
on
the
node
and
then
sending
those
back
to
cubelet
advertised
as
extended
resources
on
the
node
and
then
on
allocate
the
SRA,
V
device
plug-in
will
store
the
mapping
of
pod
information
to
VF
information
which
can
be
used
later.
So
in
this,
where
we're
proposing
extending
the
device
plug-in
API
to
pass
the
pod
information
to
SRA
V
device
plugin
as
opposed
to
reading
the
checkpoint
file.
C
So
we
just
think
it's
a
cleaner
option.
If,
if
the
information
can
be
passed
from
the
Q
brush
to
the
device
plugin,
so
then
Malta's
is
responsible
for
delegating
to
the
CN
eyes.
So
it
reads
the
network
CR
DS
in
the
pod
spec
and
then
cause
relevant
to
see
a
nice.
So
in
our
example
case
we
use
flannel
and
the
CNI
shim.
So
what
the
CNI
Shin
does
is.
It
creates
a
gr,
PC
connection
to
the
SRA
V
device
program
and
using
the
container
Eric's
passed
into
the
CNI.
C
Shama
gets
the
the
pod
named
pod
namespace
and
sends
after
the
device
program.
The
device
program
can
then
use
this
information
to
get
the
pod
UID
and
get
the
correct,
VF
mapping
and
send
that
back
to
see
you
know
ship
and
then
CNI
sham
will
send
that
information
to
SR
IV
CNI,
which
can
do
the
actual
plumbing
of
the
VF
to
the
pods
network
namespace.
C
A
C
C
B
So
I
will
just
briefly
go
over
the
configuration
that
I
have
on
my
setup.
So
as
Luis
mentioned
that
we
have,
we
are
using
Maltese
as
our
CNI
plugin.
That
will
enable
us
to
add
additional
network
on
top
of
that
default
kubernetes
network.
So
here
we
can
see
the
multis
configuration
for
the
CNI,
so
this
configuration
called
small,
T's
and
Maltese
will
call
other
as
an
eye
plugins
as
required.
B
So
for
this
we
we
are
using
the
latest
version
of
Maltese
so
which
follows
the
the
standard
the
recently
proposed
and
implemented
by
the
the
network
working
plumbing
group.
So
this
new
merged
is
just
we
have
some
standard
way
of
specifying
the
specs
for
the
CNI
and
the
plugin.
So
as
the
next
the
file.
Here
we
have
this
EML
files
that
describe
the
network
objects
for
the
CNI
shim
network,
and
then
we
have.
This
simple
part
is
back
here,
so
here
we
can
see.
B
B
B
B
B
So
you
can
see
the
default
gateway
is
the
routing
information
as
well
so,
and
we
see
that
I
survived
ESRI.
We
plug
in
actually
successfully
added
the
routing
as
well
for
this
interface,
and
also
we
can
see
that
device
plug
in
here.
If
you
top
of
the
screen
it
caught
the
request
from
the
CNI
plugin
and
it
sent
the
response
of
this
VF
for
this
part
allocated
before
when
the
pod
was
created.
B
So
this
is
the
phase
one
in
fermentation.
We
have
done
in
this
demo
actually
shows
that
one.
So
there
were
way
as
we
can
see
in
the
our
proposal
document
there,
the
Phase
two.
There
are
some
other
few
tasks
we
need
to
do
so.
Yes,
we,
it
would
be
great
to
get
some
feedback
from
this
community
and
maybe
we
can
improve
before
so
I.
Think
that's
the
end
of
this
demo.
Is
there
any
questions
regarding
demo
or
the
configuration.
A
So
one
of
the
claims
there
on
the
dock
is
that
you
need
a
you,
need
a
one-to-many
or
like
many-to-many,
nothing
between
Network,
C,
IDs
and
device
plugins.
That
sort
of
feels
like
an
anti-pattern
in
the
sense
that,
as
of
now
each
device
plug-in
is
exposed
through
compute
resource
name.
So
there's
a
one-to-one
mapping
there
I
wonder
why
you
need
that
many
to
many
mapping.
B
D
So
I
was
working
with
both
Louise
and
Abdullah
on
this
one
too.
So
the
question
regarding
the
one-to-one
mapping
right.
So,
if
you
take
the
for
networking,
it's
each
and
every
network
object
is
quite
different.
So
in
this
case
we
have
this
Hashim
CNI,
which
acts
just
like
GSPC
client
to
connect
to
the
server,
so
it
connecting
to
the
device
plug
in
get
the
piece
a
PC
address,
and
it's
giving
back
that
information
to
the
already
CNI.
So
in
this
case,
what
happened
like
each
network
object
will
have
different
ipam
information
or
different
VLAN
ID.
D
So
that's
why
we
said
like
it's,
not
a
one-to-one
mapping,
so
the
device
plug
in
in
this
case
is
like
intelligent
agent,
which
gives
us
the
resources,
but
at
the
end
of
the
day,
the
network
object,
which
is
not
a
one-to-one
mapping
with
the
device
plug-in
because
we're
just
getting
the
resource
information
and
after
that,
we
putting
the
network
configuration
on
top
of
that
resources.
So
those
resources
will
be
different
for
each
networking.
So
that's
why
there
is
a
difference
actually
in
the
previous
proposals.
D
D
B
B
So
the
cni
shim
don't
need
to
know
about
the
resource
name
in
here
all
it
need
to
know
that
which
device
plug
in
II
need
to
connect
to
and
the
device
plugin
will
actually
do
the
resource
allocation
itself.
So
here
we
only
want
to
communicate
from
CNI
ashame
to
that
device
plug-in
in
this
case,
every
device
plugin.
A
B
A
B
A
B
B
We
we
don't
have
a
define
particle
procurement.
We
still
need
to
figure
out
how
to
how
to
approach
this
best
so
right
now,
because
there
is,
when
we
actually
consider
we,
this
works
now
as
it
is,
but
when
we
take
into
account
the
new
my
alignment
that
will
make
things
more
difficult
because
you
might
have
memory
and
CPU
from
one
Numa
node
and
then
you
need
to
make
sure
that
network
device
also,
for
example,
there'll,
be
also
coming
from
the
same
Numenor
if
we
want
to
give
a
good
performance
for
the
application.
B
A
B
A
E
Okay,
because
I
think
during
the
initial
teaser
OD
was
packing.
The
reason
which
was
to
allocation
also
start
the
even
measuring
in
the
local
chat
panel
power
to
make
device
back
in
stateless
and
now,
if
we
say
that
could
post
the
best
packing
and
the
cutest,
this
information
is
something
that
was
new
to
us.
F
To
actually
build
on
James
points
and
if
the
device
plug
in
is
also
storing
the
device
information,
it
seems
prone
to
errors,
especially
in
terms
of
device
plug-in,
might
have
a
different
states.
So
it
might
be
more
interesting
for
you
that
when
you
register
the
device
plug
in,
if
qubit
has
information,
it
could
give
it
to
the
device
again.
E
B
B
E
B
B
We
don't
need
to
watch
the
C
or
D,
so
basically,
I'll
go
over
the
poorest
back
there.
So
here
is
the
sale
item
y
ml
file.
So
we
create
a
network
object
using
this
file.
Okay-
and
this
is
the
name
we
we
given
the
see,
an
item-
net
1-
and
this
is
the
parties
for
spec
here.
We
specify,
in
this
part,
want
to
connect
to
this
for
this
net
network,
on
top
of
the
additional
the
default
for
under
network
that
we
have
configured.
So
this
will
be
additional
network
I.
B
C
A
B
A
A
C
Just
the
other
thing,
the
when
the
device
program
allocate
is
called
the
network
namespace
isn't
created.
So
we
probably
I
saw
some
proposal
where
you
plumbed
the
into
the
network
namespace
of
the
actual
device
plug-in
pod
and
then
watch
for
the
namespace
being
created
and
then
plummet
in
there.
But
that
seems
kind
of
a
key
workaround
as
opposed
to
a
good
interface
to
follow
and.
B
A
A
In
case
you
need
something
at
the
so
in
theory
like
I
might
be
missing
or
glossing
over
some
major
pain
points,
but
in
theory,
if
you
are
able
to
get
a
hook
in
the
device
plugin
between
a
pod
sandbox
and
a
container
first
container
being
stalled
in
there,
so
you
should
figure
the
network
namespace
right.
So
all
you
need
is
the
network
namespace
information.
A
Like
in
theory,
we
could
just
imagine
C
and
I'm
being
in
work
from
within
the
device.
Plugin
I
was
recommending
creating
a
new
interface.
Well
I
just
want
us
to
like
really
like
think
aloud
on,
like
all
possibilities
before
we
constrain
ourselves.
Whatever
interfaces
we
have
today,
but
that's
probably
the
reality
in
a
sense
and
if
you're
on
a
ship
it
today,
you
you
have
to
make
do
with
water
is
appealable,
but
if
the
discussion
is
about,
how
do
we
improve
this,
and
I
would
want
this
to
not
have
too
many
constraints.
F
A
B
E
C
Should
in
theory,
if
the
the
current
Numa
manager
proposal
were
to
go
through
and
with
the
device
program
as
it
is
in
phase
one
where
it
requests
explicitly
the
extended
resources,
if
we're
also
to
request
integral
CP
use,
the
the
Numa
manager
would
coordinate
so
that
they
do
end
up
in
the
the
same
socket
without
any
changes
to
any
of
the
components.
That's
there.
A
C
So
that's
kind
of
a
main
open
we
have
is
the
the
Numa
alignment,
because
one
of
the
major
use
cases
we
have
is
that
the
the
pod
spec
writer
would
only
have
to
request
one
thing
in
their
pods
back.
So
in
our
current
phase,
one
you
have
to
request
both
the
network,
CRD
annotation
and
the
extended
resource
request.
So
I
want
to
kind
of
limit
the
error
there
to
only
have
one
either
the
annotation
or
the
extended
resource
request.
But
to
do
new,
my
lineman
tweet.
C
E
E
B
E
A
D
I
was
outside
actually
I.
Couldn't
able
to
talk,
you
guys,
I
found
a
new
place.
So
previously
there
was
a
III
didn't
listen
problem,
maybe
so
the
device
I
listened
to
the
conversation
of
what
the
device
plug-in
can
invoke.
The
CNA,
so
I
just
want
to
get
the
community
aspect
like
whether
the
the
combinative
ones,
looking
like
the
net.
Multiple
networking
should
be
done
as
a
device
plug-in
model
or
it
should
be
as
a
CNA
model.
D
A
D
E
See
it
actually
wasn't
our
intention
to
really
power
the
network
resource,
as
its
name
suggests,
it's
a
really
intended
to
just
a
manager
devise
a
resource
and
I
also
feel
like
it's
probably
better
to
solve
this
problem
insuk
network,
because
the
folks
there
have
knowledge
on
networking
and,
as
we
have
seen
like
a
trend
to
to
make
network
resource
a
symbol
that
he
was
clocking
in
API.
There
are
some
something
not
really
much
like
a
network,
a
third,
how
the
resource,
it's
not
the
continual
resource,
so
I
actually
hope
with
the
problem
can
be
solved.
F
Just
a
small
notes
and
I
think
one
of
the
objectives
at
the
beginning
was
to
support
network
resource
and
this
put
off
because
I
think
one
of
the
things
you
are
right
is
that
Signet
work.
It
has
probably
a
lot
more
knowledge,
but
one
of
the
goals
of
this
resource
management
group
was
also
to
have
people
from
multiple
SIG's
meet
and
take
decisions
that
are
cross.
Things
and
network
devices
seems
like
something
that
does
cross
Sun
sex.
E
A
That's
a
good
point
should
make
sure-
maybe
maybe
as
part
of
agenda
like
Korres,
adding
any
Network
topics
inside
and
I
should
also
probably
notify
Signet
work
and
try
to
ensure
that
please,
like
one
or
two
representatives-
and
this
also
seems
like
a
really
big
problem
like
from
talking
with
them.
How
can
sort
of
picture
he
paints?
Is
that
there's
so
many
different
problems
that
are
getting
interconnected?
A
A
Rav
is
a
classic
example
where
you
have
to
pass,
and
you
have
to
handle
not
just
this
logical
resource
allocation,
but
you
also
have
to
deal
with
deal
and
and
a
whole
bunch
of
other
networking
configuration
so
that
space
is
the
the
number
of
permutations,
then
that
space
is
quite
vast
and
I
suspect.
Only
a
few
people
in
the
community
are
actually
grasping
all
the
different
set
of
problems
that
are
sort
of
related
to
the
same
area.
A
So
again,
like
in
a
roundabout
way,
I'm
saying
folks
in
Signet,
work
are
probably
thinking
about.
This
is
a
little
bit
harder
than
here
think
this
community
would
probably
have
much
more
opinions
stronger
opinions
on
like
how
to
deal
with
like
the
actual
resource
allocations,
comes
to
interactions
with
CNI
and
when
it
comes
to
interactions
with
networks.
C
B
A
Yeah
I
mean
someone
who
really
cares
about
this
problem
and
has
users
and
proudly
are
building
products.
Out
of
this
would
be
the
ideal
ones
for
championing
this,
because
I
say
everyone
else
is
like
pretty
much
busy,
so
you
would
have
to
figure
out
a
way
to
get
the
right
set
of
decision
makers
together
on
this
topic
and.
B
B
C
C
E
Currently,
starting
that,
but
I
think
the
general
asked
to
make
this
information
available
to
other
components
and
I
think
we
are
also
discussing
this
in
different
count:
tags
like
a
for
monitoring
and
maybe
also
for
other
purpose
and
the.
Hopefully
we
can
come
up
with
a
solution
that
can
allow
other
components
to
discover
this
information
easily.
It.
A
D
E
F
C
A
G
Practically
it's
my
question
which
I
wanted
to
bring
to
his
group
is
because
I
started
to
notice
what
Mike
robot
starts
to
comment
on
many
of
related
issues.
What
we're
in
roarton
state,
so
we
had
proposal
from
I.
Think
beginning
of
April
were
comments
like
oh
people
will
comment
in
it
during
April,
but
I
think
since
April
nothing
happens.
So
on
course
anyone
works
on
with
what
is
the
current
state
I.
E
We
are
still
trying
to
finalize
the
design,
so
that's
why
he
hasn't
been
updating
the
POC,
mostly
because,
like
before
the
design
was
paralyzed
I,
don't
think
we
should
spend
too
much
time
to
update
the
POC
because
of
that
may
change,
depending
on
the
background.
I
know,
that's
a
design,
so
we
are
hoping
to
get.
The
keys
are
finalized.
Hopefully
this
culture
and
then
a
single
a
lot
o
parts
in
his
POC
can
be
reused
by
the
way.
I
think
we
can
definitely
use
that
as
a
basis
going
forward.
G
I
G
I
G
I
G
E
A
A
A
G
J
Hello,
so
it's
it's
christian
from
christian
it
K
from
interest,
so
yeah
I
was
at
doing
that.
It's
not
really
urgent,
but
if
you
think
so
that
we
have
so
what
we
could
do
is
that
I
could
give
you
a
sort
of
high-level
introduction
what
we
are
trying
to
achieve
with
that
and
when
we
run
out
of
time
we
can
continue
during
the
next
one
or,
if
you
prefer,
then
we
can.
We
can
do
the
whole
thing
in
the
next
one
I'm.
What
boss
is
fine
with
me,
yeah.