►
Description
CNCF SIG Runtime Container Orchestrated Device Working Group Meeting 2020-06-23
A
A
B
B
B
B
A
B
B
B
B
Talking
with
Ricardo,
it
would
be
nice
to
have
the
part
of
the
group
just
finished
by
Friday.
So
having
just
people
go
over
it
and
post
a
comment
or
a
sign-off
would
be
really
nice
if
I
think
the
bigger
question
here
is
really.
Is
there
a
section?
That's
needed,
like
Adrian
mentioned
it
in
the
previous
meeting,
which
is
like?
Should
we
have
a
full
section
on.
B
B
B
A
B
B
That's
definitely
a
reasonable
position
to
be
in
so
maybe
maybe
use
cases
need
to
be
specific
to
lead.
The
effort
that
were
solving
so,
for
example,
use
kinases,
4c
I
need
to
be
specific
to
CDI
the
there
can
be
examples,
specific
use
cases
that
we're
hoping
to
solve
immediately,
but
really
is
really
what
you're
saying
that
we
need
to
be
careful
to
not
prescribe
to
a
very
specific
area.
B
D
So,
according
account,
according
to
what
we
currently
see
in
the
court
of
contain
your
DN
cryo,
it's
just
simply
coping
exactly
what
is
present
on
the
host.
So
if
your
hosts
are
different,
these
throws
when
it
means
like
a
group,
video
group
or
accelerator
or
something
they'll,
have
different
numeric
IDs.
A
Right,
so,
if
you
want
them
to
be
set,
we
need
a
way
to
set
them
right.
If
you
don't
want
to
use,
be
the
host
path,
IDs,
then
we're
gonna
need
us
some
kind
of
way
to
set
them
for
each
host,
apply
separately,
I.
Think
I,
don't
think
we
can
just
copy
the
you
know:
the
user
ID
of
the
process
for
the
container
to
the
user,
ID
of
the
host
device
right
or
the
device
that
you
want
to
mount
in
the
container.
A
In
why
why
is
saying,
or
why
do
we
presume
that
all
host
devices
should
have
the
same
user
ID
as
the
process
of
the
container
I
mean
it's
certainly
a
pattern
that
we
could
support?
I'm,
just
saying:
that's
not
the
way
the
specification
is
drawn
out
in
not
in
the
runtime
spec
or
in
the
in
the
Chryse
back
coming
from
kubernetes.
A
D
A
The
reason,
in
the
reason,
by
the
way
that
it's
missing
is
because
the
initial
design
was
to
pull
that
from
the
path
that
they
pass
us.
So
if
they
wanted
to
create
a
déplacement
set
of
permissions,
they
would
create
that
device
and
then
pass
it
to
us
from
coop
from
couplet.
That's
that's
the
current
design
pattern
that
we're
using,
but
they
may
not
be
doing
that
right.
They
may
not
be
doing
anything
extra
yet,
but
that's
why
we
did
what
we
did.
Okay,
just
providing.
G
Two
different
cases
here
right,
like
one,
is
the
regular
devices
created
by
the
container,
like
your
PT,
MX
and
all
those
things.
So
those
are
those
I
think
we
should
just
retain
what
the
host
permissions
are,
because
some
of
these
have
special
groups
and
users
but
I.
If
I
understand
the
proposal
correctly,
we
are
only
talking
about
changing
the
UID
and
GID
of
the
devices
injected,
so
it
will
change
it
for
your
GPU
device,
for
example
right
and
not
for
everything,
because
the
defaults
will
still
be
befall.
D
D
D
What
our
container
can
come
to
to
runtime,
saying
like
Rana,
does
user
like
95
and
group
33,
and
we
end
up
in
which
situation?
Would
these
numbers
of
user
ID
and
group
ID
is
random?
Like
user
cannot
predict
what
kind
of
ownership
is
on
the
host
and
our
first
thought
was
like
okay,
if
user
is
requesting
with
this
user
ID
and
group
ID
when
and
user
should
give
access
to
two
to
a
device?
So
let's
use
with
group
ID
and
user
ideas
as
ownership
information
for
this
particular
device.
E
G
That
makes
my
my
only
buddy
is:
do
we
have
any
edge
cases
where
we
wouldn't
want
to
do
that
like
this
definitely
makes
sense
for
GPU
and
those
kind
of
devices,
but
will
it
break
any
legacy?
Workloads
say
where
you
have
a
bunch
of
different
processors,
running
as
different
you
IDs,
and
then
we
just
change
it
to
the
UID
and
GID
of
the
primary
process.
Is
it
going
to
break
such
workloads?
So
what
I'm
really
getting
at
is?
G
A
D
We're
a
few
things
here,
so
the
trying
to
answer
questions
like
one
by
one.
So
first
question:
do
we
have
scenario
where
we
don't
have
matching
process
ID
and
permissions
I
tried
to
think
about
it
and
I
haven't
found
any
reason
for
it
so
practically
like.
If
user
wants
to
use
with
the
why's,
he
need
some
way
to
use
it.
The
only
option,
or
only
potential
scenario,
is
what
like,
if
you
have
some
devices
which
is
like
read-only.
D
So
if,
if
a
permission
is
said
by
only
reading
from
device,
but
not
calling
in
any
like
ioctl
and
so
on,
wet
might
be
limiting
factor,
but
on
wet
hand.
We
are
getting
information
from
CRI,
which
says
like
what
mode
of
iteration
for
devices
we
have
so
like
read,
write
create,
so
we
can
do
chmod,
accordion
Plato
to
get
information
regarding
multiple
user
IDs.
What
you
brought
up
my
understanding.
So
if
you
have
we,
actually
we
have
two
scenarios.
One
scenario
is
what
we
have
right
now
is
what
device
each
individual
device
is
assigned
into.
D
One
container
like
we
don't
have
right
now
over
shared
devices
between
multiple
containers
and
if
we
container
is
started
with
specific
user
ID,
which
is
known
route,
where
is
practically
quite
small
chance.
What
we
will
have
inside
what
container
processes
which
will
be
running
was
different
user
ID,
all
right,
yeah.
G
But
just
last
week
I
was
talking
to
some
customer
and
they
were
trying
to
move
legacy
work
loaded.
They
are
running
a
bunch
of
different
processes.
So
in
such
cases,
if
we
just
change
it
to
the
primary
container
user
and
other
other
processors
running
as
different
users,
and
then
the
container
try
to
access
the
device
yeah.
A
Well,
that's
the
type
of
scenario,
I'm
thinking
we're
running,
multiple
hosts
within
one
container
right
services,
micro
services,
that
sort
of
thing-
and
you
may
not
want
to
provide
a
any
any
old
micro
service.
That's
running
you
know,
access
to
devices
at
least
not.
You
know,
through
some
interaction
between
the
processes
that
are
running
in
the
container,
but.
D
G
But
how
will
the
container
runtime
know
that
container
and
time
will
only
get
it
through
the
CRI
right?
Yes,
so
it
can.
You
assume
that
anything
sent
to
it
over
a
CRI
is
always
a
GPU
device
kind
of
a
device
like
no
one
is
preventing
someone
to
take
a
TTY
like
device
and
do
a
mount
through
the
cube
later
it'll.
It
will
also
still
show
up
through
the
CRI.
That's
that's
the
problem
in.
D
G
B
There's
ways
we
can
mitigate
this
I,
don't
know
how
that
would
translate
to
container
to
your
apartment,
but
in
in
communities
we
could
go
through
the
feature,
gate
path,
I,
don't
know
if
that
translates
very
well
for
upon
net
or
container
D,
but
we
would
enable
this
feature
by
default
and
better
wait
for
a
year
or
two
and
then
figure
out.
If
we've
had
feedback
from
customers
are
concerned,
that
we
broke
their
workloads.
That
might
be
one
way
we
could
go
forward.
B
D
Problem
is
were
two
things
like.
One
thing
is:
if
we
are
talking
about
outcome
of
this
group,
where
we
don't
have
this
CDI
interface
of
injecting
with
devices,
so
once
we
get
word,
the
problem
will
go
away
because
we
will
have
ability
to
specify
Bleich,
runtime
spec
part,
which
can
include
those
over
the
ship.
D
So
words
like
long
term
solution,
midterm
solution
or
short-term
solution.
We
we
have
two
options
like
one
is
like
option
a
so
we
will
just
clarify
the
assumption
of
what
like
what
will
be
permission.
Software
devices
like
from
Sierra
to
Aussie,
I
level
and
option
two.
Is
we
start
changing
winter,
for
interfaces
between
device
plug
into
couplet
and
from
couplet
to
runtime
to
include
also
well,
that's
practically
we'll
the
two
options.
What
we
have
like
it
with
device
security
context.
D
G
A
D
G
G
D
G
C
G
G
D
G
D
G
G
D
D
D
A
Don't
think
we
needed
them
to
standardize
the
annotation,
because
those
would
be
more
on
the
OCI
side,
but
but
I
think
we
do
need
to
talk
to
them
about
whether
or
not
they
would
want
to
cap.
So
they
could
own
extending
their
current
device,
API
right
and
then
enhancing
the
COI
API
to
pass
correct
security
content.
I.
G
G
D
H
B
B
And
the
next
item
is
like
there's:
no
specific
action.
I
wanted
to
mention
the
fact
that
some,
the
device
monitoring
in
communities
are
currently
working
towards
GA
we're
looking
into
disabling
some
device,
metrics
that
were
collected
by
cubelets
and
I
mean
before
we
go
to
TA.
The
general
question
is
to
this
group:
if
there's
been
any
concern
around
device
matching,
if
there's
been
any
issues
and
just
getting
some
feedback
on
the
existing
mechanism,
if
there
are
other
people
they're
using
the
pod
resources,
API
would
be
nice.
B
B
We
have
the
metrics
as
and
GPA
utilization
its.
Then
we
have
DP
as
a
tag
and
then
maybe
it's
a
counter,
and
then
we
have
a
spit
like
a
number
100
right,
but
right
now
the
problem
is
with
this
specific
metric.
You
don't
know
at
the
end
of
the
day,
you
want
to
be
able
to
do
a
graph
that
says
for
pod
and
container
X.
The
GP
utilization
is
100,
but
right
now
you
only
have
a
node
view
of
update
utilization.
B
B
I
We
don't
have
that
level
of
details,
unfortunately,
which
is
being
described
right
by
Ray,
not,
but
we
would
like
to
have
it
so
as
to
couplet
level.
Metrics,
no
I
haven't
really
been
using.
Those
I've
been
using
the
device
information
from
the
gr
PC,
which
basically
tells
you
what
devices
are
used
in
containers
I
tried
that.
I
B
B
B
D
D
Well,
that's
one
thing
reason
why
I'm
thinking
about
this
in
PR
mode
is
because
for
the
spec
I
was
thinking
like
wait.
When
we
first
time
discussed
it,
I
was
saying
what
like
in
containing
respect.
We
should
be
able
to
put
like
majority
of
information
what
we
can
put
in
from
from
OCI
runtime,
spec
and
I
think
well.
My
comment
is
still
true.
I
think
we
should
have
a
list
of
items
which
is
actually
allowed
to
be
say
it
explicitly.
So
we
know
what
we
have
this
permission
mechanism
for
device
we're
like.
Where
is
fields.
D
B
Then
understand
what
they
are
saying
is
the
CGI
spec
should
not.
Basically
when,
when
it
describes
devices
it
describes
the
operations
that
need
to
be
to
happen
for
that
device
to
be
available
to
the
container
rights,
and
these
operations
could
be
mount.
These
operations
could
be
hope.
So
if
we
look
at
CDI,
do
we've
we've
described
a
few
examples
here
where
it
could
be
a
host
path
here,
right
so
I
mean
I
think,
but
they
also
have.
B
D
B
G
G
The
CDI
should
define
what
fields
are
supported
and
only
those
fields
like
the
runtime
should
not
blindly
just
process
all
the
items
there
and
match
them
with
other
existing
OCIO
fields
and
add
them
and
I
guess.
We
may
also
need
some
ordering
thing:
yeah
right,
like
append
inject
in
the
beginning,
or
something
like
that
for
at
least
mounts.
B
G
G
G
Mean
it
may
be
possible
that,
after
all
of
our
examples
we
think
Oh
in
all
cases
we
just
do
an
append.
So
we
don't
need
an
odd
ordering,
but
till
we
know
that
for
sure
how
we
inject
them,
we
will
need
some
guidance
of
the
render
on
Tyneside
it,
but
we
append
or
add
to
the
beginning
or
inject
somewhere
else
soy
or
something
like
that.
My.
D
G
D
Yeah
ii
thought
what
I
actually
had
is.
It
was
from
from
more
from
the
practical
step,
so
I
don't
know
like
some
kind
of
library
or
budget
version
of
some
component,
where
we
can
practice
like
we
have
OCR
ice
container
spec
as
an
input
and
also
a
spec
like
as
output
after
we
do
all
this
transformation.
B
We
were
discussing
last
time
to
you:
is
there
in
terms
of
deliverables,
that
we
had
that
list?
That
was
interesting,
which
is
like
a
specification
and
a
goal
in
API
and
I.
Think
what
that's?
What
you're,
describing
you
go
along?
The
library
for
merging
POC
I
expect
with
the
city
I
expect
for
transforming.
D
G
D
H
B
B
Anyone
gonna
going
to
review
this
whole
thing.
Alright,
there
is
I'll.
Do
that,
make
up
all
requests
I'll
be
happy
to
do
that
and
then
from
there
on
I
think,
definitely
making
sure
that
this
specification
is
so
I
think
we
mentioned
here
that
we
need
more,
probably
to
specify
the
ordering
we'll
probably
need
to
specify
the
list
of
allowed
transformations.
B
Everything
from
their
own
once
were
okay
with
the
specification,
the
biggest
question
that
I've
was
I,
think
like
we
needed
to
figure
out
last
time
was
what
is
the
life
cycle
of
this
project?
When
is
it
okay
to
say
we're
done
with
the
specification?
Let's
now
proceed
to
integrate
it
and
something
in
a
runtime.
Is
there
a?
Is
there
a
phase
where
we
going
to
be
doing
some
parks?
Is
there
a
phase
where
how
do
we
want
to
organize
the
lifecycle
here?
I.
A
D
D
D
B
That
seems
pretty
reasonable
to
me,
making
sure
there
were
were
passed.
The
draft
stages
is
definitely
something
that
I
mean
seems
like
a
pre
huge
wall
before
we
actually
go
and
talk
or
go
and
make
the
full
requests.
Toxin
validation
is
going
to
be
very
nice,
just
accelerating
odds,
yeah
I
think
like
the
different
requests
is
there
is
there
is
a?
Are
there
things
that
might
or
Bruno
you
think
would
be
really
important
to
have
before
we
start
engaging
with
or
not
engaging
with
them
before
in
that
project,
lifecycle.
A
A
A
You
know,
okd
groups
that
are
gonna
be
out
there.
That
will
want
to
start
using
this.
You
know
and
then,
when
we
get
rid
of
the
annotations
with
via
caps
right
well,
will
want
to
have
that
cycle.
Go
one
more
time
around
right.
Getting
the
feedback
from
the
primary
users
of
the
this
whole,
like
that,.