►
Description
CNCF SIG Runtime Container Device Interface COD Working Group 2021-02-09
B
C
E
D
Noticed
that
like
for
the
second
one,
the
request
is
coming
with
the
parameters
from
the
first
pvc-
I
I
didn't
get
it
so
I
I
just
gave
up,
but
it's
I
don't
know
why,
because
it's
like
the
pod
is
definitely
referring.
The
each
port
refers
its
own
pvc
and
there
are
like
different
parameters
for
this
af
uid
fpga
in
pvcs,
but
when
volume
is
created
like
the
same
parameters
like
come
like
every
time,
I
don't
know
why.
That's.
D
B
F
C
A
G
F
G
Like
use
deployments
created
by
some
third
parties
and
fire
them
without
looking
that,
much
or
without
merging,
like
configuration
manual
or
anything
like
that,
so
yeah
but
yeah,
let's
see
it's
not
ideal,
I
would
say
probably
we
should
going
forward,
find
a
way
to
like
drop
in
this
like
or
multiple
multiple,
multiple
configurations
more
easily
through
crds
or
some
other
way.
At
least.
A
G
Basically
from
the
energy
side,
the
search
manager
itself
requires
very
little
work,
so
I
mean
the
problem:
is
that
nfd
doesn't
support
this
kind
of
certificate
rotation,
so
it
doesn't
at
the
moment,
understand
it.
The
certificates
might
change,
that's
the
problem,
so
that
needs
to
be
solved.
But
after
after
that's
solved,
then
dropping
in
third
monitor.
Is
this
really
a
piece
of
cake?
So
I
yeah
I
like
that
solution.
E
E
F
A
E
E
E
All
right
so
for
full
context.
These
logos
were
designed
by
the
nvidia
creative
department.
We
did
have
a
big
meeting
with
them
in
terms
of
making
sure
that
the
different
logos
that
they
come
up
with
do
not
include
nvidia
visual
elements.
I
mean
the
main
one
being
we
did
not
want
them
to
kind
of
use
the
nvidia
colors.
E
We
we
spent
a
lot
of
time
with
them,
making
sure
that
they
understood
that
it's
a
process
that
it
is
with
the
community
and
the
goal
is
to
kind
of
like
present
you
with
options
and
the
community
is
kind
of
the
final
decider
on
this,
not
nvidia.
So
we're
really
just
here
to
kind
of
at
least
the
nba
creative
department
is
here
to
kind
of
help
us
come
up
with
the
logo
and
we
are
the
decider
there's
in
no
way
kind
of
like
nvidia
involvement.
E
Here,
we're
trying
to
be
neutral.
Some
of
the
kind
of
keywords
that
we
brainstormed
a
bit
with
them
to
come
up
with
different
options
are
like
the
her
device
container
node.
I
think,
like
I,
don't
have
the
notes
with
from
that
meeting
with
me,
but
we
spent
different
time
just
like
discussing
a
bit.
What
are
kind
of
visual
elements
that
we
would
like
to
see.
One
of
them
that
came
up
with
funnel
the
other
one
being
container
being
the
two
main
thing.
E
G
E
E
I
don't
have
my
notes
from
the
previous
meeting,
but
one
of
the
kind
of
framework
that
creative
have
gave
me
to
evaluate
and
give
some
feedback
on
logo
is
the
first
thing
that
they
kind
of
were
interested
is
like
outside
of
the
cars.
Do
we
like
these?
The
the
the
the
concept
that
these
logos
represent?
E
Are
we?
Are
we
attracted
by
the
idea
of
a
funnel
or
the
idea
of
a
container
that
is
layered
on
top
or
maybe
kind
of
this
id
of
option
c
kind
of
feels
like
it's
a
box
that
has
more
boxes,
so
it's
a
box.
Augmented
also
are
these
kind
of
visual
elements
that
we
think
make
sense,
or
do
we
care
more
about
a
specific
visual.
E
D
E
F
F
E
Okay,
I
think
one
other
thing
that
I
kind
of
noticed
is
that
the
appeal
of
the
black
and
white
option
c
kind
of
gets
lost
with
the
colors.
For
some
reason,
it
seems
like
this.
This
kind
of
like
visual,
intriguing
element
in
option
c
kind
of
gets,
gets
tossed
a
bit
with
the
cars.
You
know
what
I'm
saying.
G
E
E
F
All
right,
so
I
don't
have
any
slides
for
that,
but
just
to
just
couple
of
words
a
couple
of
words
so
now
remember
when
we
started
talking
about
how
to
cdi
would
look
like
we
had
the
idea
of
using
a
custom
resource
definitions
to
actually
describe
the
kind
of
request
for
device
attributes,
so
something
what
we
can.
We
put
as
many
of
the
device
properties
as
we
want
like,
like
gpu
memory,
gpu
time.
If
we
want,
when
fpga
bit
stream
names
and
yeah,
they
are
there.
F
But
the
problem
is
what
to
introduce
such
big
change
to
the
kubernetes.
It's
it's
problematic,
so
we
wanted
to
show
or
to
have
some
of
like
proof
of
concept
where
we
can
demonstrate,
where
idea
and
when
starting
from
what
idea
evolved
to
something
what
can
be
written
as
a
cap
or
other
like
a
real
proposal.
F
So
what
we
took
as
as
we
agreed
earlier,
so
we
took
with
cgi
as
a
bottom
layer,
so
the
way
how
it
works.
What
we
have
run
c,
which
reads
with
cdi
specification
and
when
exposed
to
a
container,
we
have
a
bit
customized
version
of
ranzi,
because
we
have
also
gpu
related
properties
and
like
false
something
which
is
it's
discussed
at
upstream
kernel,
but
not
yet
in
web
stream
kernel.
Yet
so
we
can.
F
So
you
have
a
port
stack,
you
have
the
port
spec,
referring
to
device
as
a
volume.
For
now
right,
you
have
similar
to
a
storage
request
where
you
can
specify.
I
want
particular
class
of
device.
I
want
particular
properties
of
this
claim,
and
I
want
to
use
this
claim
between
like
in
either
in
one
container
or
between
multiple
ports
or
between
multiple
containers
in
this
port
and
so
on.
F
F
F
F
D
Okay,
so
let's
let's
go
so
the
the
idea
is
to
basically
use
cdi
kind
of
objects
to
to
show
the
like
resource
allocation
and
management
approach
like
without
actually
creating
crds
and
referencing
them,
because
that
that
would
require
a
lot
of
a
lot
more
work.
So
it's
it's
a,
and
this
is
what
I'm
going
to
demonstrate.
D
Yeah
and
these
two
services,
the
first
one,
is
the
controller.
So
it's
basically
it's
just
one
instance
usually
for
the
cluster.
It
collects
the
information
about
the
devices
from
the
node
agents
and,
as
we
have
only
master
and
one
node,
we
have
also
this
node
agent
port
running
that
that
basically
runs
on
the
node
scans,
the
available
devices
and
provides
them
to
the
controller.
D
And
on
this
node
we
have
two
fpga
nodes,
so
I
will
demonstrate
the
fpga
device
allocation,
so
we
have
two
devices
here.
So
this
like
port,
zero
device
and
port
one
device,
and
then
this
device
knows
is
actually
consumable
resources
from
the
user
workflow
point
of
view
and
what
differs
between
those.
So
there
are
two
parameters
here
like
to
pay
attention
to
like.
First
one
is
interface.
D
Uid
is
it's
the
same.
It's
basically
id
of
the
device
like
in
simplified
terms,
so
we
have
two
like
devices
of
the
same
kind.
So,
and
this
second
parameter
is
accelerator
uuid
and
that's
that
differs
here
and
that
is
id
of
the
function,
which
is
a
flash
at
integer
device.
So
fpga
fpga
is
a
programmable
device.
So
it's
currently
like
two
devices:
they
are
programmed
with
two
different
functions
and
that
function
is
basically
will
be
used
as
a
as
a
parameter
so
like.
D
Let's,
let's
see
how
exactly
so
like.
First,
first
of
all,
we
create
a
storage
class.
So
let's
look
at
how
it's
organized,
so
we
have
like
storage
class
parameters
so
with
device
type
fpga
vendor
intel
and
the
interface
id,
which
is
basically
what
I
showed
so
it
specifies
the
device,
so
the
like
device
class,
if
you
will
and
then
so
we
created
and
that's
that
is
usually-
should
be
done
by
cluster
admin
next
piece
by
the
way
you
know
you
can
interrupt
me
like
any
time.
D
D
I'm
back
again
sorry
for
that,
so
this
fu
id
is
that
parameter
so
user
workflow
wants
some
particular
accelerator
function
to
utilize
and
that's,
but
the
software
is
basically
organized
the
way
that
those
parameters
can
be
like
arbitrary
so
and
it's
just
up
to
the
node
controller
to
understand
those
parameters
so
the
rest
of
the
software
like
central
controller
for
for
it.
It's
just
like
a
list
of
like
key
value,
keys
and
values,
and
that's
it
so
for
next
thing.
D
D
D
F
D
E
F
E
D
E
C
E
D
D
But
it's
it's
more
complex.
I
would
say
so.
If,
if
you
have
some
kind
of
like
simple,
like
conceptual
questions
I
can
answer
now,
if
not,
then
we
can
switch
to
ukri
and
ukri
will
will
demo
this
gpu
case.
But
this
is
like,
like
very
simple
case,
so
one
parameter
the
function
id
and
and
practically
that's
it.
So.
D
F
Okay,
the
biggest
concept
is
what
like
we
are
splitting,
where
two
pieces,
like
one
piece,
is
well
actually
three
pieces.
One
piece
is,
we
have
devices
with
the
classes
and
we
can
have
multiple
of
them
and
we
have
a
provisioner
like
vendor-specific
provisioner,
which
handles
those
second
thing.
We
split
out
the
allocation
phase,
so
user
declares.
I
want
with
kind
of
devices
with
this
set
of
parameters,
and
the
third
piece
is
in
report
spec.
We
are
saying:
okay,
now,
I'm
going
to
use
with
allocation.
What
I
created
with
my
neither
parent.
E
D
We
actually
don't
need
to
do
it,
so
it
can
be
done
like
in
or
granularity
so
that
it
doesn't
depend
on
device
plug-in
in
in
any
way.
So
you
can
either
use
those
like
for
simple
cases,
but
as
soon
as
you
have
like
more
parameters,
you
want
to
use
them.
Then
then
that's
that's
the
way
to
go
from
our
point
of
view.
D
F
D
E
A
A
Yeah,
like
it
said
this
is
a
more
complex
setup,
so
this
is
for
gpus
and
also
we
have
a
little
bit
more
of
a
more
of
a
cluster
here,
since
it's
just
not
just
one
node,
plus
plus
the
controller.
This
is
three
nodes
that
we
have
here
and
I,
by
the
way
I
don't
have
anything
recorded,
so
it
either
works
or
it
doesn't.
We
may
have
demo
effects
so
three
nodes
identified
by
labeling
them
with
storage
equals
cdi.
A
A
A
A
A
Now
what
you're
probably
interested
in
is
like
you
know
what
what
are
these
so
we've
defined
here,
that
each
port
gets
1.5,
gigs
of
ram
and
300
millicourse?
If
we
do
the
math,
the
cluster
had
16
gigs.
So
basically,
you
know
it's
more
than
you
know
asking
10
of
these,
but
since
these
each
of
these
gpus
only
have
has
four
gigs
of
ram.
A
A
A
I
have
a
little
script
which
doesn't
seem
to
be
working
today
so
that
part
of
we
got
the
demo
effect
over
there.
Let's
see
that
was
just
the
user
error,
it
needs
the
deployment
name.
Okay.
So
the
expectation
in
in
this
printout
is
that
we
should
have
two
lines
for
the
card
one.
Basically,
only
the
cmls
one
machine
had
two
gpus,
as
you
can
see
from
here,
and
both
of
these
cards
should
have
two
ports.
A
A
A
As
long
as
we
use
the
storage
paradigm
and
the
same
happens
if
we
have
two
containers
inside
the
port
which
use
the
gpu
separatedly
same
issue,
because
the
volumes
are
created
one
by
one
and
you
basically
need
a
scheduler
extender
to
help
reason
being
that
when
you're
considering
them
one
by
one,
you
don't
necessarily
understand
that
you
cannot
allocate
the
second
one
anymore,
so
it
gets
complicated
there.
Storage
as
such
is
not
the
best
for
this
kind
of
thing,
even
though
it
does
work
nicely.
When
you
have
just
you
know,
one
gpu
being
allocated.
A
E
A
F
So,
as
I
mentioned,
we
found
several
well
corner
cases
where
our
storage
doesn't
work
properly.
So,
for
example,
like
one
volume
can
be
easily
shared
between
multiple
ports
on
the
same
node
and
for
our
devices
allocation.
We
should
prevent
with
this
kind
of
scenario
and
then
like
read
once
or
involve
multiple
times
overall
sharing
between
the
ports.
F
E
A
You
know
the
means
so
there's
no
no
device
plugins
here
and
you
know
I
can
take
this
a
little
further.
I
applied
another
deployment
over
there.
Obviously
it
ended
up
pending
it's
these
two
over
here
this
one,
and
if
I
now
delete
the
first
one,
then
if
everything
works
eventually
it
should
get
deployed.
A
E
E
There's
from
a
user
perspective,
it's
it's
going
to
be
transformative,
especially
as
we
have
more
and
more
devices
that
are
being
able
to
be
shareable
from
an
engineering
perspective,
an
architecture
perspective.
I
I
think
the
the
battle
is
going
to
be
interesting
to
kind
of
enable
this
in
kubernetes,
given
that
it
touches
scheduler
and,
at
the
same
time,.
A
A
E
F
E
F
E
Ken
should
probably
also
kind
of
start
joining,
so
I'll
definitely
make
sure
that
he's
invited
and
has
is
aware
of
everything
makes
sense.
So
we
have
10
minutes.
I
did
want
to
kind
of
talk
through
a
bit
department,
implementation
that
I
have,
which
is
like
this
demo
that
I
came
up
in
september,
and
I
wanted
to
kind
of
discuss
a
little
bit
about
things
that
we
can
probably
improve
and
how
we're
going
to
kind
of
structure.
Everything
so
kind
of
the
first
thing
that
I
want
to
talk
about
is
more
of
the
api.
E
E
E
So
if
it
refers
to
a
name
that
we
find
in
the
cdi
specification,
then
we
know
that
it's
a
cdi
device,
and
so
we
add
that
name
to
this
list
of
devices
and
from
there
we
kind
of
have
this
function
that
is
provided,
but
with
with
cdi.
Basically
that
allows
us
to
kind
of
I'm
sorry
having
a
hard
time
that.
F
E
Every
time
we
call
has
device,
I'm
going
to
parse
all
the
files,
so
there's
probably
a
little
device
basically
just
reads:
through
all
the
files
reads:
the
devices
there's
a
few
questions
we
might
want
to
ask
ourselves.
That's
just
like.
Should
we
be
providing
context
so
that
the
the
map
that
we
build
out
of
these
files
is
kept?
We
don't
rebuild
it
every
time
and
the
other
one
being
I
mean
the
other
one
being
like.
Of
course
we
could
just
like
has
device
with
an
aria
street.
F
E
I
think
the
last
one
that
I
want
to
talk
about
is
the
specification
right
now.
I
re-implemented
the
kind
of
the
ocs
structures,
but
we
might
want
to
discuss
if
we
want
to
have
the
cdi.
Basically
just
have
the
oci
structures
imported,
so
refer
to
kind
of
ocid
devices
in
the
container
edits,
so
devices
oci,
dot
linux
devices.
E
E
So
my
thought
process
is
to
kind
of
move
this
cdi
folder
inside
the
cdia
repository,
so
that
includes
these
like
kind
of
devices
and
what
you're
going
to
see
in
podman
is
kind
of
these
small
edits.
So
the
container
struct
now
kind
of
comes
around
with
the
cdi
device
in
the
cia
device.
If
field
is
here,
we
update
the
spec
and
here
in
the
cli
we
kind
of
go
over
the
different
devices.
E
E
To
me,
that's
kind
of
up
to
michael
crosby
and
what
he
wants
to
do
he's.
Ultimately,
the
person
that
kind
of
decides
the
architecture
if
he
wants
us
to
go
to
win
or
island,
we'll
go
through
an
r
if
he
wants.
If
he's
okay
with
us,
going
through
a
container
directly,
then
we'll
go
through
container
d
and
then
maybe
an
hour
later.
F
E
F
E
F
I
wanted
to
bring
this
non-root
devices
patches
what
we
had
discussed
a
few
months
back
so
mikhail
implemented
the
purchase
as
we
agreed,
but
we
were
lucky
enough,
reviewers,
so
renault
at
least
from
your
site.
If
you
have
time,
please
help
with
saying
your
words
like
yes
or
no
okay,
and
I
will
try
to
ping
our
people
as
well.