►
Description
CNCF SIG Runtime Container Orchestrated Device Meeting 2020-09-15
A
C
A
B
B
All
right,
it's
a
meeting
recording
it
is
recording.
I
think
we
can
probably
start
this
is
september
15th
meeting.
I
think
we
have
three
topics
on
the
agenda.
If
I
recall
correctly,
the
first
one,
I
think,
is
from
sasha
it's
about
sorry,
I'm
opening
the
agenda.
At
the
same
time,
on
my
side,
it's
about
improvement
in
cri,
apis
to
report,
resources
up
and
down
between
keyboard
and
runtimes.
B
Second,
one
is
more
or
less
just
administrative
strife
stuff
just
a
question
to
use
sigmund
times
distribution
list
rather
than
we're
mailing
us,
rather
than
the
cod
mailings
that
we
have.
I
think,
it'll
improve
a
bit
some
of
the
communication
between
sig
run
time
just
and
then
overall.
The
last
point
is
just
discussing
next
step
for
cdi
with
respect
to
converging
with
nri,
and
I
think
just
generally
questions
on
that
front
or
more
about.
Should
we
just
merge
the
repositories?
B
B
A
A
A
How
we
organize
it
so
in
in
relation
to
this
particular
working
group?
I
think
this
is
the
way
how
we
can
communicate
about
information,
what
kind
of
devices
we
discovered
from
cdi,
but
anyway.
So
with
repository,
what
what
I
created
it
has
initial
list
of
ideas
and
to
do
items.
What
we
had
in
our
mind,
what
we
think
it
would
be
good
to
implement
on
cri
site,
or
sometimes
some
things
and
on
runtime
side,
what
are
a
couple
of
to-do
items
for
our
project,
cri
resource
manager.
A
C
A
Nri
is
not
enough
stuff,
because
practically
nri
in
the
current
implement
in
a
current
design
is
just
a
set
of
life
cycle
hooks
for
the
containers,
and
we
want
to
have
well
based
on
what
we
did
in
the
cri
resource
manager
is,
is
complete,
state
machine?
So
you
don't.
You
are
not
only
reacting
to
a
single
container
or
single
port.
You
need
to
have
some
component,
which
will
be
able
to
understand
the
whole
state
of
the
system,
especially
for
scenarios
like
even
use
trying
to
rebalance
the
resources.
C
C
A
C
C
A
B
A
B
I
agree
with
what
you're
saying
I
agree
that
there's
definitely
a
component
that
is
container
runtime.
That
kind
of
is
super
interesting
with
this
group
of
people
and
it's
super
helpful
and
I
think
it
kind
of
makes
sense.
I
mean
when
we
as
a
group
try
to
collaborate
on
a
pull
request
if
we
open
up
a
request
against
the
cap
repositories,
it's
kind
of
complicated-
and
I
agree
that
having
staging
ground
is
is,
is
a
really
nice
place
to
have
we're
just
staging
ground
where
we
can
just
discuss
things
is
nice.
C
E
E
Yeah
yeah,
and
the
second
thing
I
wanted
to
just
give
a
heads
up
here-
is
like
derrick
and
I
are
gonna
in
today's
signal.
We
are
going
to
propose
taking
cri
out
of
alpha
so
now.
I
think
I
want
to
raise
it
here
yeah,
so
I
want
to
raise
it
here
like
like
we
don't
you
don't
get
fractured
across
too
many
groups
and
like
we
don't
want
to
slow
that
down
too,
because
there's
some
deadline.
We
have
upstream
to
get
that
moving
right.
E
A
A
What
we
had
in
mind
that
was
more
about
like
provide
more
information
in
existing
messages,
so,
for
example,
like
creates
and
blocks
will
have
not
only
were
just
like
empty
message.
Saying
like
this
is
the
name
of
the
sandbox
and
visas
annotations.
It
will
also
have
the
list
of
like
unit
containers,
normal
containers
and
the
list
of
resources.
What
is
going
to
be
used
in
this
container
like
and
when,
like
that,
like
create
container,
it
will
have
resources
a
bit
more
update.
Container
resources
will
have
a
full
list
of
resources
like
that.
E
C
A
E
About
it
yeah,
I
I
feel
like
it's
still,
okay,
to
move
it
to
beta
and
then
add
these
things.
It's
not
the
final
version
right.
We
don't
want
to
block.
What's
already
there
and
stable
in
a
way,
that'll
help
deprecate,
docker,
ship
and
move
forward,
and
then
we
keep
discussing
these
new
items
and
keep
them
moving.
C
A
Mike,
but
actually
like
adding
some
fields
which
is
optional
for
runtime
to
react
on,
I
think
it's
a
compatible
change,
yeah
it
it
is
so
it
it's
not.
So
my
understanding
only
changing
reversion
number
like
from
let's
say
like
alpha
one
to
alpha
two
or
or
something
it
means
only
if
those
versions
are
completely
incompatible
and
they
need
to
transformation
between
investment.
C
Well,
it
also
means
that
we
need
to
look
at
the
news,
the
new
additional
services.
The
capabilities
are
added,
you
know,
and
there's
going
to
have
to
be
some.
You
know
effort
on
it.
They
they
have
a
different
qualification
for
when
an
api
goes.
You
know
ga,
but
they're
they're,
pretty
good
with
it's.
Okay,
if
you've
got
two
versions,
but
since
we
haven't
even
got
to
version
one
yet
because
we
keep
wanting
to
add
more
stuff,
it's
it's
been
slowing
it
down
right.
C
Just
just
a
minor
heads
up
if
it'd
be
it'd,
be
better
if
we
could
have
a
point
release
or
we've
been
using
annotations
with.
You
know,
without
modifications
for
a
long
time.
But
I
I
agree
with
you.
It
would
be
nice
if
we
could
just
quickly
go
to
ga
and
and
then
modify
the
the
sarah
api
to
have
additional
extensions
right.
A
E
A
See
it
parallel
because
you
might
have
like
different
profiles
for
for
different
type
of
resources.
So,
for
example,
like
block
io
is
one
profile,
but
memory
and
cpu
our
profile.
So
the
current
problem
with
qris
classes
is
what
we
are
calculated
based
on
only
cpu
and
memory,
and
I
I
think
all
this
thing
will
again
will
be
more
complicated
as
soon
as
we
will
get
fully
functional
vertical
part
after
scale.
E
That
sounds
like
an
idea
worth
exploring,
but
now
I
think,
like
I
feel
like
we
should
take
a
pause
and
define
a
road
map,
because
when,
like
renault
started
cdi,
it
was
very,
the
scope
was
well
defined,
but
now
it
isn't
clear
to
me
like
we
are
taking
on
a
lot
of
ideas,
lot
of
those
ideas
sound
like
they
need
to
be
tackled.
But
what
is
the
order
in
which
we
are
tackling
them
and
what
is
the
scope
of
each
one
like
some
are
more
well
defined
than
others
like?
E
I
think
resource
classes
have
been
discussed
upstream
for
a
while,
like
it
just
jogged
my
memory
that
yes,
I've
heard
this
before
so
some
are
more
controversial
versus
some
are
not
where
okay
cdi
the
is
just
go
to
the
run
time
we
kind
of
reached
agreement.
We
can
take
it
to
the
next
step,
but
some
of
the
other
ideas
that
you
talked
about
now
will
probably
need
more
discussion
and
coordination
with
other
groups.
A
B
Sorry,
I
think,
like
lots
of
great
ideas
with
earn
out-
and
I
agree
with
renault-
that
having
some
kind
of
roadmap
would
be
super
helpful
for
these
ids.
Here's.
What
I
would
suggest
is
just
write
down
some
blurb
for
each
of
these
ids
and
what
you
kind
of
expect
in
terms
of
effort
in
terms
of
talking
to
different
people
and
maybe
like
give
your
idea
of
priorities,
send
an
email.
And
then
we
can
probably
like
discuss
that
on
the
on
the
mailing
list
from
there
right.
B
I
think
I'll
take
a
stab
at
it.
Then
I
think
most
people
are
not
subscribed
to
the
prs
and
maybe
the
commits
that
are
already
present.
That's
why
maybe
we
haven't,
we
hadn't
noticed,
but
I'll
definitely
take
a
stab.
I
think
email
is
probably
the
easiest
way
to
reach
out
everyone
here
and
then
the
next
one
is
going
to
be
github
issues
and
tagging
them.
A
Probably
not
just
just
one
more
comment,
so
you
mentioned
what
like
initial
scope
of
cdi
so
the
last
year
when
we
were
talking
with
renault
about
the
idea
of
improving
with
cdi
devices,
we
we
talked
about
like
two
steps
like
one
step
is
about
how
we
solve
it
on
the
runtime
level
and
second
step
how
it
will
be
exposed
to
like
upper
levels
like
kubernetes
and
so
on.
We
had
some
ideas,
so
I
think
it's
it's
not
really
expanding
too
much
scope,
but
it
will
be
linked
at
some
point.
E
So
I
think,
like
bill
till
the
last
two
three
meetings,
we
were
very
focused
on
the
low
level
runtime
one
where
we
kind
of
reached
agreement,
so
I
think
maybe
like
we
should
start
discussing
the
next
one
that
comes
on
top
and
then
the
plan
for
actually
implementing
the
lower
level
one
in
the
runtimes,
and
I
think
I
was
more
commenting
about
the
additional
things
that
we've
been
discussing,
not
cdi
itself.
It
seems
smaller
than
let's
go.
C
A
A
True,
well,
that's
why
I'm
trying
to
combine
everyone
saying
like
okay:
this
is
where
list
of
things
what
we
want
to
work
on
like
I
know
what
not
all
of
them
are
resulted
to
particular
cash.
So
once
we
have
a
caps
to
to
one
project
to
another,
we
can
put
a
link
saying
like
okay.
This
item
is
done.
Link.
It
recap
is
over
here
or
located
over
here,
contribute.
C
B
It
just
coming
back
to
what
I
think
you,
you
did
touch
an
interesting
point,
that's
kind
of
ill-defined
which
is
how
how
cdi
will
change
the
interactions
between
kubernetes
and
the
runtimes
and
that's
definitely
something
that's
kind
of
blurry
right
now
and
which
will
probably
need
us
to
involve.
Maybe
a
few
other
people
on
the
signal.
B
A
E
So
I
I
think,
though
I
think
what's
like
the
way
it's
worked
so
far
is
like
runtime
is
dumb,
cubelet
has
the
overall
picture
and
it
tells
the
runtime
to
do
these
things,
and
now
we
are
finding
gaps
that
hey.
This
is
not
enough.
If
I
want
to
do
an
image
pool
in
the
pod
sandbox,
I
need
to
know
the
pod
sandbox
slice
name
in
the
image
pool
and
somehow
change
that
interaction.
That's
one
example
so,
like.
E
Up
with,
like
exact
scenarios,
where
we
feel
that
we
may
benefit
from
the
runtime
getting
more
information
running,
the
slice
doesn't
sound
like
a
good
example
running
in
the
slice
doesn't
sound
like
a
very
specific
bad
example
to
me,
because,
like
yeah,
the
containers
have
to
run
inside
the
pod
slice
right.
So
that's
a
basic
kubernetes
assumption.
E
A
I
mean
I
mean,
I
mean
the
hierarchy
of
things,
so
I
know
what,
for
example,
a
t
for
weight
deployment
way
way,
installing
the
kubernetes
in
a
way
what
we
have
only
subset
of
cpu
cores
available
for
kubernetes
and
varesta
infrastructure,
cpus
for
like
high-end
speed,
network
stuff,
and
we
had
the
problem
of
isolating
kubernetes.
What
like
do
not
take
those
ones,
but
it's
one
example.
But
what
I'm
more
talking
about
is
what
we
we
have.
A
We
have
a
problem
between
linux
and
windows,
so
the
kubelet
knows
a
lot
about
the
linux
and
does
the
assumptions
on
the
linux
side,
but
for
windows.
It
says
like
oh
well,
cri,
please
run
it
somehow.
I
don't
know,
but
you
run
it
and
the
same
thing
was
the
idea
of
virtual
kublet,
where,
like
where
implementation
of
a
container
execution
is
just
saying
like.
I
know
this
set
of
resources,
give
me
the
container
and
I
will
figure
out
how
to
run
so.
A
E
Yeah,
I
I
think,
like
even
the
example
you
just
gave
to
me
right,
like
the
atnt
case,
I
would
imagine
immediately
that
yeah
there'll
be
some
flag
to
cubelet,
telling
it
okay.
These
are
the
only
cpus
that
are
available
to
kubernetes
and
you
are
only
available
to
you're
only
allowed
to
pass
those
down
to
the
cri
for
the
for
the
workloads.
So
for
that
example,
can
you
like
give
more
details
on
how
you
think
the
runtime
would
solve
it
as
opposed
to
solving
it
in
the
cubelet?
E
A
The
problem
is
that
kublet
was
written
during
several
years
and
by
different
people
with
different
subsets
of
the
minds.
So,
like
everything,
what
is
topology
related?
It
doesn't
care
about
those
c
groups
hierarchies
what
it
does
it
just
calls
c
advisor.
Give
me
machining
for
c
advisor
says
well.
This
is
what
all
the
cpu
is,
what
I
detected
from
the
system
and
when
cpu
manager
says.
Oh,
I
have
this
amount
of
cpus
and
the
same
goes
to.
A
This
allocatable
and
available
resources,
which
is
submitted
to
node
status,
part
of
of
a
node
object.
So
it
also
does
exactly
the
same
so
it
says:
oh
okay,
I
detected
from
c
advisor
with
amount
of
cpu
total
in
the
system.
This
amount
of
memory
total
in
the
system.
I
have
kublet
flux,
says
what
system
reserve.
It
is
x,
amount
of
memory
and
x
amount
of
cpus,
so
it
just
cuts
it
and
that's
it.
So
it
doesn't
really
calculate
what
is
actually
said
in
the
like.
Currency
group
object
if
it's
specified
and
so
on
so.
A
B
B
All
right,
so
I
think,
like
I
mean
I
think
you
brought
a
few
very
interesting
points
just
just
to
close
on
this
and
and
just
a
lot
of
food
for
thoughts,
and
I
think,
like
at
least
I'm
I'm
very
interested
in
contributing
and
to
any
just
effort
that
you
want
to
start
on
this
I'll.
Take
a
look
at
the
representative
link
to
it
in
the
chat
feel
free
to
link
to
any
issues
that
you
think
are
worth
looking
at
too.
B
B
B
I
I
think
like
for,
for
now,
we
we
have
probably
10
emails
and
it's
mostly
just
agendas
and
notes.
So
it
kind
of
makes
sense
to
me
that
if
this
is
what
we're
going
to
use
a
distribution
list,
we
might
as
well
include
sig
runtime
or
even
just
send
our
emails
to
sync
runtime.
I
know.
If
ever
is
everyone
subscribed
to
see
runtime?
B
B
B
B
My
question
is
more
tactically:
how
does
that
look
like
we
had
this
idea
of
contributing
the
cr
repository
to
the
nri
repository?
It's
still
like,
I
I'm
okay,
with
doing
that.
It's
just
I'm
having
a
hard
time
figuring
out.
What
does
it
look
like?
Does
it
look
like
just
a
directory
where
we
have
the
spec
kind
of
a
conversation
we
should
also
have
with
michael
crosby,
but
how
do
we?
How
do
we
do
the
next
steps?
Do
we
start
a
an
email
thread?
Do
we
start
a
discussion
on
slack?
A
Michael
crosby
is
what
the
nri
scope
what
he
initially
proposed.
It
was
not
well
not
enough
for
at
least
what
things
what
we
are
trying
to
solve,
so
one
of
the
outputs
of
this
list
of
items.
What
I
created
we
we
need
to
do
is
it
will
be
what
we,
what
will
be
the
next
steps
of
ideas,
what
we
have
and
what
michael
have
so.
B
All
right,
so
I
think
I
think
you
weren't
here
in
the
last
meeting.
So
let
me
summarize
it
up
to
you,
I
think,
a
bit
with
michael.
We
thought
that
it
kind
of
makes
sense,
at
least
like
we
had
a
lot
of
similarities
between
the
nri
and
the
cdi
ids,
and
I
think
just
talking
a
bit
through
and
presenting
a
bit
cdi
to
michael.
It
sounded
like
a
reasonable
idea
to
try
and
kind
of
have
the
ibs
convert
and
have
instead
of
having
the
nri
spec
and
the
cdi
spec.
A
C
No,
I
just
say
the
the
very
first
code
drop.
Yes,
it
was.
It
was
limited
in
this
capability,
but
that's
it's
not
just
for
containers.
It's
also
for
pods
right
and
it's
not
just
for
between
the
create
in
the
run
step
it.
It's
also
going
to
be
expanded
to
support
pre-create
post-stop.
All
those
sorts
of
you
know
capabilities,
and
it's
not
just
hooks
because
it
sits.
You
know
it
sits
at
the
integration
point
for
cri.
A
So
that's
what
I
was
saying
like
we.
We
wanted
with
michael
to
merge
those
two
ideas
into
one
library
which
can
be
got
it.
Okay.
Now
I
understand
okay,
so
for
him
like
ours,
here,
irm
is
implemented
as
a
proxy
between
the
kubrick
and
cri.
So
like
well
right,
so
circuit
injection
practically
for
michael
for
his
setup.
It
was
not
possible.
That's
why
he
tried
to
do
implemented
in
inside
campaign
only,
and
I
was
saying
to
him
like
okay.
Well,
we
have
that
code.
B
A
Start
well,
my
my
question
was
about
like
merging
cri
and
cd
or
cgi
and
the
mri.
I
think
what
the
question
about
how
to
nourish
it.
It
should
wait
until
this
discussion
about
what
like
how
much
of
an
existing
code,
we
can
reuse
between
sierra
ram
and
nri.
What
michael
has
wanted
and
red
might
reshape
how
the
with
convergence
between
those
two
projects
might
help.
B
E
B
B
B
All
right,
I
think,
that's
a
yes
for
everyone
and
I'll
also
ask
you
guys
for
everyone
and
sorry
everyone
in
the
room
to
try
to
take
us
another
stab
at
the
specs
or
the
pr's
that
are
standing.
Let
me
know
if
there's
some
work.
I
need
to
do
again
on
these
pr
so
that
we
can
have
some
something
that
can
be
built
on
or
imported
a
go
module
to
be
imported
right.
C
A
C
Yeah
that
that
that
last
time
I
checked
that's
what
he
was
he
was
looking
for
more
you
know,
scenarios
and
that's
probably
where
we
can
help
most
is-
is
to
you
know,
pull
in
these
additional
scenarios
on
what
needs
to
happen
at
the
nri
cri
level,
so
that
we
can.
We
can
make
those
modifications
what
they
need
to
be
done
right
and
hopefully,
in
the
common
ways
that
all
the
container
runtimes
can
can
implement
it.
The
exact
same
way
that
would
be
nice.
B
All
right,
I
think,
that's
pretty
much
it
and
was
there
anything
anyone
wanted
to
discuss
is
there.
Maybe
this
is
something
that
I
I
wanted
to
ask
like.
Some
of
the
people
in
the
meeting
here
are
kind
of
new,
and
some
of
the
people
in
the
meeting
might
just
are
just
interested
it'd
be
interesting
to
have
your
opinion.
If
there's
some
context,
we
need
to
build
from
time
time.