►
Description
SIG Runtime Container Orchestrated Device Working Group Meeting 2020-10-13
B
B
A
C
E
E
You
know,
go
nuclear
on
november
1st,
at
least
not
according
to
you
know
our
buddy,
mr
cormac
right,
but
but
they
that's
what
it
currently
says.
It
says
you
know
on
that
date.
If
you
pull
100
images
in
six
hours,
you're
out
right,
no,
more
images
that,
until
after
the
six
hours,
if
you're
doing
it
anonymously,
if,
if
you
log
in
on
a
free
account,
you
get
200
pulls
right,
yep
and
you
know
for
a
developer,
that's
fine,
but
for
people
who
do
installs
at
customer
sites.
B
E
There
there
is
mike
but
they're
not
making
it
public
yeah,
so
so
yeah
yeah
they
do
have
they've
got
two
white
listing
programs
one.
I
don't
have
the
details
on
on
the
client
side
and
the
other
is
on
the
on
the
source
side.
If
you
have
an
organization,
you
know
with
a
bunch
of
repos
you
can
you
can
you
can
pay
them
to
for
the
resource,
storage
and
and
downloads
they'll?
Do
some
estimate
on
the
amount
you've
got
and
give
you
a
number
we're
still
working
that
out?
E
E
B
E
Yeah,
that's
definitely
the
the
solution
mike.
It's
just
that
there
are
certain
scenarios
where,
where
they've
gotten
used
to
using
latest
tags
and
docker
only
counts
the
they're,
they
don't,
they
don't
care.
How
how
much,
how
big
the
image
is
on
the
client
side,
they're,
just
counting
the
number
of
manifests
right
and
saying:
okay,
that's
one
pole
for
one
image,
no
matter
how
many
manifest
you
want
and
then,
of
course
we're
just
using
that
for
verification,
validation
of
the
hash.
E
C
C
So
I
think
maybe
sasha
and
mentioned
that
he
had
talked
to
you,
michael
crosby.
Could
you
maybe
get
us
up
to
speed
on
what
is
the
plan
or
what
it?
What
are
the
ids
that
you
have
for
the
nri,
and
I
think
there
was
some
mentions
about
asia?
Libraries
between
multiple
projects
is
that
is
that
a
good
introduction,
or
could
you
maybe
help
us
just
get
us
up
to
speed.
E
B
Side
I
can
like
so
far.
The
initial
design
of
nri
was
around
resource
management,
specifically
a
need
that
I
had
for
cpu,
pneuma
and
then
expanding
out
to
things
like
huge
huge
paid
support,
l3
cache
things
like
that
kind
of
over
the
past
month,
or
so
we've
been
working
on
a
few
different
plugins
to
support
that,
and
so
far
the
life
cycle
hooks
of
where
we
have
now
for,
like
the
crate,
start,
delete
and
update,
calls
all
have
worked
out.
B
But
so
far
from
my
point
of
view,
I
think
it's
flexible
enough
in
terms
of
supporting
this,
but
we've
also
discussed
about
some
ways
where
we
can
share
some
underlying
code
for
the
plug-ins.
I
think
the
api
is
pretty
generic
and
and
straightforward.
It's
collaborating
a
lot
on
the
plug-ins
and
how
those
are
built.
C
A
C
The
devices
I
mean
we
have
a
longstanding
bug
where,
because
of
how
we
do
we,
because
of
the
fact
that
we
add
devices
in
a
container,
for
example,
with
the
cpu
manager,
cpu
manager,
goes
in
updates.
The
just
calls
the
updates
on
the
cpus
and
the
container
loses
all
c
groups
permissions
to
read
from
the
dev
nvidia
nodes.
C
So
at
least
I
mean
that's
one
of
the
reasoning
where
we
had
behind
with
changing
the
spec.
Is
that
once
the
once
the
spec
has,
or
once
the
changes
have
been
sent
to
the
container
runtime,
the
hook
is
no
longer,
or
at
least
the
the
plug-in
is
no
longer
on
the
hook
to
get
in
there
and
intercept
every
update
call
the
other
one.
Is
that
there's
in
a
way
a
simplifying
factor
to
just
having
a
json
file?
C
B
Yeah,
I
think
I
think
the
api
of
how
inner
eye
is
it's
very
flexible,
so
it
would
allow
you
to
do
a
lot
of
that.
It's
just
making
sure
we
have
the
correct
hooks
in
the
in
the
cris
but
yeah.
I
think
I
think
it's
totally
doable
when
I
started
looking
into
a
pre
pre-create
hook
where,
like
it,
would
be
more
of
the
contract
between
nri
and
cri,
because
we'd
have
to
like
accept
the
current
spec
on
standard
in.
B
C
Okay,
so
maybe
I
think
one
of
the
question
that
at
least
I
had
was,
if,
if
we
feel
like
dnri,
is
the
right
way
forward,
the
first
question
is:
is
the
nri,
something
that
we
think
we'll
be
able
to
see
in
not
just
continuity
but
other
runtimes,
and
the
second
question
is:
if,
if
it
is
the
case,
how
do
we?
How
do
we
take
advantage
of
that?
How
do
we
concretely?
C
B
Yeah,
I
think
renault
would
be
the
best
to
to
talk
about
if
cryo
would
be
interested
in
supporting
this.
The
way
I'm
building
it
like
I'm
hoping
it.
The
goal
is
support
to
be
generic.
Just
like
cni
is
and
a
lot
of
the
the
domain.
Specific
implementation
happens
in
the
plug-ins,
where
we're
just
providing
hooks
within
our
cri
implementation,
so
so
yeah.
G
I
think
it
does
make
sense,
but
I
think
I
need
to
understand
the
bigger
picture
like
with
in
case
of
cdi.
We
understand
that
we'll
look
at
something
of
that
sent
over
the
cri
and
decide
that
okay,
we
need
to
make
these
modifications
to
the
spec.
So
how
are
we
integrating
with
the
other
items
in
the
spec
like?
When?
Are
we
deciding
that
they're
calling
into
the
nri?
F
B
A
A
A
B
A
G
E
Yeah,
I
think
michael's
nri
sort
of
solves
all
that
right.
We
just
have
to
make
some
decisions.
You
know
alex
you,
you're
modifying
the
the
spec
before
the
container
runtime
receives
it
in
the
cri
space
we
like
to
store
what
we
receive
from
kublet
right
in
our
own
little
storage.
So
we
we'd,
like,
I
think,
to
store
it
first
before
you
make
your
modifications
if
we
need
to
store
it
again
after
you
make
the
modifications.
That's
that's
fine!
That's
fair!.
A
B
Okay,
yeah-
that
was
one
gap
that
that
we
noticed
is.
We
want
at
least
one
change
in
the
cubelet
to
provide
us
the
entire
pod
spec.
Instead
of
feeding
us
containers,
one
by
one
because,
like
the
information's
there,
it
just
doesn't
give
the
cri
the
whole
pod
spec,
where
we
can
make
better
more
efficient
decisions.
When
we
know
the
entire
workload.
A
Michael,
you
probably
missed
it.
Auntie
started
to
draft
a
cap
about
what
it's
linked
in
the
meeting
units
below,
so
we
will,
and
now
it's
partially
linked
to
our
discussion,
what
we
had
in
this
cri
going
to
ge
or
better
discussion
about
generalizing
with
how
we
communicate
with
resources
down
from
equipment.
A
E
Michael,
the
when
you
say
the
whole
pod
specification
there's
a
lot
of
good
stuff
there
and
it's
not
just
the
pod
spec.
It's
also
the
other
objects
that
are
related
to
the
pod
spec
that
google
uses
you
know
to
make
decisions
and
set
up
the
pod
information.
That's
passed
on
the
pod
run,
request,
there's
also
a
bunch
of
other
stuff
that
happens
before
they
do
a
pod
run.
You
know
insofar
as
doing
image,
caching
and
loading
you
know
querying
the
state
of
the
node
that
sort
of
stuff
right
kubelet
keeps
that
information.
E
You
know
pretty
pretty
tight
to
the
vest,
but
I
think
we
they
have
a
a
thing
in
in
kublet
called
a
you
know,
a
container
runtime
manager
and-
and
I
think
there
was
an
original
intent
in
kublet
for
that
to
be
the
cri
and
right
now
it's
it's
just
got
a
lot
of
stuff
that
we
need
access
to.
So
we
probably
need
to
ex
extend
the
pod
specification
and
other
objects
that
kubelet
uses
to
be
distributed
through
the
cri
v2
or
something
to
that
effect.
A
E
G
G
E
A
H
But
sasha
so
that
so
this
om
adjustment.
Yes,
that's
fine
that
the
kublat
is
deciding
that,
but
the
problem
is
that
the
cubelet
is
currently
hiding
from
the
runtime
and
everybody
who
is
behind
the
sierra
interface
that
how
much
it
has
promised
the
containers
that
it
can
use
memory.
So
basically
the
memory
yes.
F
A
A
So
when,
when
some
condition
on
the
node
trigger
it
and
kubelet
needs
to
start
the
leaking,
it
will
evict
first
or
start
killing
the
containers
for,
like
normal
workloads
and
system
workloads
will
be
like
in
in
the
last
priority,
so
that
part
stays
in
recovery,
but
how
it's
run,
how
it's
killed
in
our
run
times.
In
my.
A
C
C
So
one
other
thing,
at
least
this
is
what
alex
is
mentioning.
One
of
the
things
we're
really
hoping
is
ci
is
something
that
eventually
pops
up
to
the
dockers
ui.
Maybe
the
container
dci
at
the
end
of
the
day,
what
we're
really
looking
for
is,
first
and
foremost,
being
able
to
do
docker
or
podman,
run
dash
dash
device,
my
super
device
and
then
something
like
ubuntu
and
then
my
vendor
tool.
C
We
really
want
kubernetes
to
be
doing
something
like
this.
That's
that's
the
mental
model
that
we're
going
for
rather
than
the
current
mental
model,
which
is
this
and
so
for
us.
The
the
first
objectives
here
is
really
to
surface
this
through
the
ci
and
then,
with
this
surface,
this
back
to
kubernetes.
B
Because
of
the
way
you
get
information
in,
like
you
have
to
have
hooks
in
the
cri
and
like
docker,
docker
demon
part,
you
can't,
I
don't
think,
there's
a
way
to
get
the
best
of
both
worlds.
Where
you
get
all
of
the
pod
spec
for
cube,
specific
runs
and
be
able
to
do
advanced
like
resource
placement.
Topology
with
just
a
generic
kind
of
the
way,
docker
and
stuff
is
today
container
by
container
running.
B
So
so
the
cri
shim
stays
the
same
because
we
provide
the
additional
pod
information
in
the
inner
eye
invokes
before
adding
this
to
docker
or
another
client.
You'd
have
to
add
the
inner
eye
hooks
to
that
specifically,
because
there's
not
a
generic
way
to
shove.
This
inside
container
decor
and
to
know
a
pod
run
versus
a
specific
container
invoked
from
docker.
G
G
B
E
B
C
E
A
A
Yeah
for
us,
the
port
is
also
needed
to
get
with
information,
because
we
are
supporting
feature,
we're
containing
affinity
and
anti-affinity.
So,
for
example
like
if
you
have
like
database
and
consumer
or
within
one
port
and
needs
to
be
located
close
together,
we
need
to
have
information
about
this
container,
actually
part
of
one
pot
right.
E
I
A
E
A
A
A
Oh,
our
quote
will
be
quite
simple
to
to
do
like
the
whole
policy
engine
is
can
be
detached
into
separate
library.
The
only
thing
well
only
will
be
different
is
what,
instead
of
this
proxy
object,
we
will
be
getting
calls
from
some
hours,
grpc
service
or
whatever
else
we
will
come
up
with,
but
not
nothing.
Much
changes.
B
A
Well,
michael
generally,
cdi
in
long
terms
supposed
to
support
also
the
pod
level
devices
but
applicable,
especially
for
like
rdma
kind
of
devices
where,
like
you,
have
a
shared
memory
between
multiple
containers
within
one
port,
so
the
carbon
cgi.
It
will
just
inject
the
same
device
twice
into
multiple
containers.
Oh
well
as
many
containers
as
many
devices.
A
C
Definitely
do
you
want
to
talk
about
it
or
do
you
want
to
also
present
it
in
the
next
in
the
next
meeting,
so
that
we
have
some
kind
of
formal
review
and
people
will
actually
yeah
like?
We
can
look
good
for
for
for
that
meeting
so
that,
after
at
the
end
of
the
next
meeting,
we
actually
say
yes,
no,
that
makes
sense,
it
does
not
make
all
sense
for
more
review
next
week.
C
J
C
All
right-
and
I
think
that's
it
cubecon
panel
discussion,
so
it
at
least
what
some
I
mean.
Some
of
the
discussion
we
were
having
is
that
the
format
is
more
of
a
q,
a
for
since
it's
a
panel
and
we
might
present
some
slides,
but
it
really
should
be
reduced
to
maybe
a
small
charge
slide
a
small
roadmap
side
and
if,
if
there's
a
need
for
an
architecture
diagram
that
might
be
a
good
place,
but
it
should
be
at
most
3
4
slides,
not
that
much.
C
C
So
I
don't
know
my
general
idea
here
is
just
let's
list
some
of
the
questions
that
we
think
actually
makes
sense
in
a
q
a
let's
list,
some
of
the
answers
that
we
we
would
like
to
see
to
the
these
questions,
and
that's
it
also
keep
in
mind
that
we
do
have
45
minutes,
but
we
should
keep
10
15
minutes
at
the
end
for
online
questions.
Does
that
make
sense
all
right?
Let
me
write
down
some
of
the
questions
that
the
people
here
want
to
see.
A
C
A
We
need
to
introduce
what
people
just
like
saying
like
now,
you
introduce
yourself
now
you
introduced
myself
and
so
on
and
when
probably
like
short
saying
from
each
one
like,
I
am
from
x
y
z,
like
what
and
maybe
again
like
first
first,
two
questions
like
where
charter
and
architecture
is
these
first
things
which
needs
to
be
asked,
and
afterwards
we
can
shuffle
to
already
to
like
more
discussion
between
all
participants,
but
at
least
like
the
first
few
minutes
to
set
up
with
tom
for
discussion.
We
needed.
C
A
A
So,
like
I
know
you
are
device
manufacturer,
we
are
hardware
manufacturer
together,
like
both
device
and
like
resource
management,
things
mike
and
monalis
from
runtimes
worlds.
So
the
first
question
would
be:
what
is
this
cdi
for
you
for
your
area?
What
do
you
expect
and
what
problems
you
are
trying
to
solve
with.
A
I
E
Well,
I
mean
we,
what
do
you
expect
from
cdi
in
the,
but
it's
the
cod
working
group,
so
at
some
at
some
level
we
need
to
talk
about
the
you
know:
what
what
are?
What
are
the
various
projects
that
are
that
are
involved?
You
know
the
cod
working
group
is
trying
to
encompass
right
and
what
is
this
right.
E
C
That's
definitely
a
possibility
I
can
like
as
a
modder,
I
can
spin
up
like
one
or
two
slides.
I
mean
we
already
have
at
least
one
right
at
least
one,
so
that
the
audience
can
ask
questions
from
the
picture
right
yeah.
I
I
think
I
shared
that.
Let
me
give
me
a
quick
second,
and
I've
got
the
slides
actually,
in
my.
A
C
A
A
A
F
C
I
E
C
C
C
A
Yeah
by
the
way,
speaking
of
fluvium
based
runtime,
so
sooner
or
later,
we
will
need
to
figure
out
how
to
inject
in
red
devices
where,
because,
if
we
are
injecting
only
on
the
container
start
time,
it
might
be
already
too
late,
because
vmware's
already
created
and
you
can't
hold
plug
with
device.
So
it's
giving
back
to
a
discussion.
F
I
C
G
E
C
E
C
So
I
think,
and
and
to
me
we
need
to
make
sure
that
there's
a
bit
of
nuance
in
our
thoughts
and
answers
in
that
we
probably
need
to
be
on
the
side
of
here
are
some
of
the
ids
that
we
have.
They
might
not
fit
always
with
the
sigs
or
maybe
we
haven't
talked
with
all
the
runtimes
and
it's
possible
that
I
mean
you,
you
you
see
where
I'm
going,
isn't
it
prescribing
an
id
and
that
we're
just
here's
the
result
of
our
work
and
it's
possible
that
not
everything
is
done.
E
E
A
C
C
C
Important,
that's
right,
yeah!
So
so
it's
not
just
something
that
I
say
immediately
as
part
of
the
presentation.
It's
also
something
that
both
alex
and
I
talking
about
right
yeah
so
that
maybe
maybe
this
should
not
should
not
be
ci
specific
right.
It's
what
you
expect
from
and
then
maybe
one
of
the
answer
could
be
from
cdi
and
then
from
the
cod
word
group
right,
yep.
A
F
E
E
A
C
Yeah,
but
that's
that's
an
actual,
very
important
point,
because
that
was
actually
also
one
of
the
questions
we
were
asking
ourselves
in
not
the
previous
meeting
but
the
meeting
a
month
ago,
which
is
there's
a
lot
of
initiatives
here,
we're
trying
to
close
on
cdi
but
at
the
same
time
there's
a
lot
of
ids
that
we
want
to
be
talking
about.
So
maybe
that's
something
that
we
can
probably
or
we
need
a
slide
out
of,
and
maybe
that's
something
you
want
you
can
present
alex
because
you
you
have
all
these
problems.
C
E
C
A
So
we
have
set
of
ideas,
we
have
some
draft
of
implementations,
we
have
background
use
cases
why
it's
needed.
What
we
don't
have
is
we
don't
have
any
representatives
from
like
our
run
time,
so
we
covering
all
the
likely
major
ones,
we
cry
and
campaign.
We
need
people
from
hpc
world.
We
need
people
from
our
like
small
runtimes.
We
need
vm
based
runtimes
to
provide
information.
What
kind
of
challenges
with
devices
we
have.
A
A
C
This
is
what
I
was
saying
to
michael.
This
idea
of
docker
run
dash
dash
device
rather
than
docker
and
v.
I
think
to
me:
it's
really
important
that
we
talk
about
this
because
it
it
it
makes
sense
in
everyone's
head
this.
This
idea
of
saying
docker,
run
back
device
versus
docker
and
v
is,
is
something
that
really
should
be
hitting
people
and
hey.
That
seems
like
a
really
important
idea.
Actually.
A
C
C
All
right,
that's
that's
at
least
some
pretty
good
amount
of
work.
We
should
definitely
try
to
think
at
least
try
to
maybe
like
expand
on
these
offline
and
then
from
there.
We
probably
need
to
fix
the
recording
session
and
then
hopefully,
we'll
only
need
one
take,
but
we
all
know
we'll
probably
need
at
least
two.
E
E
C
A
C
E
A
Yeah,
but
another
question
is
well
well
cube.
Ctl
is
fine,
but
you
need
to
have
device
plugin,
which
actually
will
be
exposing
or
backing
up
what
device.
So
we
like,
even
we,
if
we
let's
imagine
today,
we
implemented
cdi.
We
are
great,
we
don't
have
a
part
and
recovery
which
will
pass
that
information
down.
C
C
The
audience
in
a
way
all
right,
so
let
me
see
I'll
try
to
set
up
the
doodle
asap
and
then
feel
free
to
all.
Come
back
to
this
document
rewrite
some
of
the
questions
we'll
probably
have
to
assign
some
of
these
questions.
If
we
only
have
six
questions
to
ask-
and
we
have
five
speakers-
that's
going
to
be
fun.
C
C
E
B
C
C
C
E
I
A
A
E
E
G
E
C
E
And
you
guys
can
do
the
same
thing
when
you,
when
you
guys
are
talking
about
your
you
know
when
you're
showing
the
initial
charts
you
can
say
you
know
what
is
what
is
the
scope
for
you
right
and
how
are
you
involved
right
and
then
alice
can
talk
about
that
as
well?
You
know
he
can
introduce
himself
and
then,
or
did
you
want
to
introduce
people
nope.
A
C
G
C
E
C
E
E
E
F
A
By
the
way,
if
you're
using
the
zoom
to
to
record-
and
if
you
feel
what
you
you
want
to
add
something
to
once
for
half
hour,
we
can
use
this
rice
hand
thing.
So
at
least
the
moderator
can
give
chance
to
answer.
Also,
definitely
actually
I
I
I
don't
know
like
this
rise
hand,
is
it
going
to
be
visible
in
recorded
or
not,
but.