►
From YouTube: Kubernetes SIG Node 20230627
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20230627-170501_Recording_1374x1020.mp4
A
A
B
B
Actually
never
mind
video
here,
yes,
hi,
so
I'm
gonna
place
here,
I
opened
the
pull
request.
So
by
the
way,
this
is
my
my
first
meeting,
I'm
I
work
with
Microsoft
and
I'm.
You
know
working
on
this
confidential
pods
on
on
Azure
kubernetes,
basically
and
I
I
I
opened
this
PR
as
as
an
example
right.
Of
course,
we
don't
need
this
to
be
the
solution,
just
proposal,
so
so
the
problem.
B
The
problem
we
were
running
in
nature
is
that
we'd
like
to
to
be
able
to
run
different
runtime
classes
on
the
same
on
the
same,
coordinates
cluster
and
we've
run
into
into
a
a
problem.
We
have
different
snapshots,
so
we
use
potato
now
allows
different
subjects
to
be
used
for
a
runtime
class,
and
then
we
run
into
this
problem
where,
when
we
run
a
confidential
pod
first
using
an
image
and
then
you
try
to
run
another
non-confidential
part
later
using
the
same
image.
B
Let's
cancel
the
cubelet,
it's
automatic,
it
doesn't
require
users
to
to
annotate
the
their
their
podiums
yeah.
So
so
we
can.
We
can
go
into
into
more
details
of
the
problems
we're
running
into
and
I
try
to
describe
them
in
the
in
the
in
the
pull
request,
but
but
the
request
to
cumulates,
basically
to
add
an
annotation,
and
this
is
sort
of
what
the
the
pull
request
does.
So
what
I'd
like
to
hear
from
you
is
how
do
you
feel
about
this?
C
No,
this
is
this
is
fine.
Using
an
annotation
would
be
a
good
way,
I
believe
to
you
know,
to
align
for
a
particular
runtime
Handler,
but
but
yeah.
What
we'd
like
to
do
is
is
eventually
pass
the
you
know
the
policy
for
doing
the
insurer
down
to
the
container
runtime
as
opposed
to
having
Google
it.
Do
the
insurer
first
and
then
run
the
Pod
by
the
way.
C
Well,
I,
don't
know
if
you
notice,
but
the
the
Pod
itself
also
for
each
container
will
ensure
that
image
is
local
and
you
know,
depending
on
whether
you've
got
isolation
across
the
the
various
runtime.
You
know,
engines
and
snapshots.
We
may
or
may
not
be
able
to
share
some
information
since
it's
they're,
both
from
the
k8s
name
namespace.
C
You
know
tell
us
what
what
runtime
Handler
you're
going
to
use
so
we'll
so
we'll
pull
to
that
space
and
ensure
that
space
when
the
requesting
status
on
the
images,
yeah
yeah,
you
can't
just
say
cool.
You
know,
please
go
pull
this
to
that!
Runtime
Handler!
You
also
have
to
say
you
know
when
you're
getting
the
list
of
images
and
the
status
for
all
of
them.
C
Well,
yeah,
it's
a
long!
It's
a
long-term!
You
know
plan
is
to
move
to
policy,
to
policy
handling
on
that
kind
of
thing
because
yeah,
it's
just
it's
not
working
very
well
to
have
Google
it
managing
that
policy
without
our
understanding
of
it,
and
then
we
do.
We
have
two
types
of
garbage
collection,
one
for
the
image
reference
and
and
the
other
for
the
snapshots.
B
C
Also
gonna,
it's
also
gonna,
be
you
know,
cross-related
to
a
a
cap,
we've
got
called,
ensure,
pool
policy
or
insure
full,
always
kind
of.
If
you
know
the
image
policies
where
it's
pull
always
or
pull
is
not
present,
there's
a
you
got
the
same
kind
of
problem
there
it
if
it's
there
for
one
is
it
there
for
both
we've
already
got
some
code
going
in
for
that
so
and
it
won't
understand
your
annotations.
A
C
Do
we
want
Google
to
aggregate
across
all
of
the
runtime
Handler
name
spaces
within
the
kas.io
namespace?
Maybe
maybe
not
I,
don't
know
when
when
you're
asking
for
insurer,
you
know
do
we,
you
know
that's
a
tricky
question.
We
could
just
reply
back
to
your
surgery,
which
snapshot
are
we
using,
but
again
that's
only
for
container
D,
it's
not
for
cryo,
yet
they're
they're,
still
using
the
grass
fiber
they're,
not
using
this
kind
of
this
kind
of
concept.
Yet.
B
Yeah
so
so
in
terms
of
the
pr
I'm
not
touching
anything
related
to
to
garbage
collection
of
images,
I'm,
just
adding
the
annotations
in
the
ensure
image
access
and
then
so.
This
gets
translated
into
a
denotation
into
a
pool
and
and
then
the
check
for
the
presence
right.
That's
really
all
I
do
and
that
it's
a
this
annotation
for
the
for
the
runtime
Handler
right,
so
so,
without
actually
mention
the
concept
of
snapshot
which
this
gets
used
in
the
equality
case,
based
on
the
what
I
handled.
C
But
then,
when
you
actually
run
the
container,
we
also
insured
again
one
last
time
because
it
could
have
been
collected
right
between
asking
the
question
and
happening
we
check
one
more
time
and
which
isn't
a
big
deal.
If
it's
you
know
cash
local,
it
would
only
be
a
big
deal
in
the
case
of
welding
certain
you
know
case
here
where
they
needed
it
to
be
in
another
snapshot.
A
C
D
D
Hey
something
to
think
about
also
a
strategy
that
could
be
used
is
in
situations
where
the
the
image
is
stored
in
a
different
run
for
a
different
runtime
Handler
than
the
default.
We
could
use
the
CRI
pinned
field
and
then
have
the
runtime
handle
the
garbage
collection
of
those
images
instead
of
having
Cuba.
Do
it
so
just
be
basically
considered
a
totally
separate
like
the
qubit,
wouldn't
consider
it
for
eviction.
D
Yeah,
it's
the
only
way
for
the
CRI
to
tell
the
Cuba
to
like
tune
it's
it's
eviction.
The
other
thing
is,
you
know
we
brought
this
up
a
couple
weeks
ago,
but
in
129
we're
going
to
be
collecting
use
cases
for
like
a
more
clever
image,
eviction
schemes
so
like
this
is
a
good
thing
to
bring
up
now.
So
we
can
consider
that
in
you
know,
as
we
go
forward
with
kind
of
figuring
out
different
ways
to
yeah
tune
that.
A
D
D
Cryo
is
trying
to
add
support
for
using
six
store
signatures
and
verifying
with
those
and
we're
trying
to
add,
make
it
namespace
aware,
but
because
the
cubelet
only
pulls
image
once
you
know
for
the
whole
node,
it's
not
aware
of
like
whether
or
not
it
can
like.
If
a
container
a
did
have
the
signature
or
it
was
in
the
namespace.
D
With
the
signatures
policy
correct,
then
it
would
be
able
to
pull
the
image,
but
then
it's
container
B
wasn't
in
that,
then
it
would,
it
should
not
be
able
to,
but
it
is
currently
able
to
rely
on
the
fact
that
container
a
had
already
pulled
it.
So
it
is
really
related
in
that,
like
currently
the
Cuba
doesn't
try
to
verify
a
container
should
be
pulled
for
each
container.
D
An
image
should
be
pulled
for
each
container
that
it's
running,
for
it
just
says
it
once
for
the
node
then
verifies
that
it's
still
present
for
the
node.
So
it
is
relevant
to
the
degree
that
currently
the
cubelet
doesn't
know
enough
or
isn't.
B
is
inexpressive
enough
for
all
of
the
different,
like
image,
storing
or
pulling
mechanisms
that
the
Cris
are
trying
to
work
through
right
now,.
D
You
know
providers
for
signatures
and
right,
but
right
now
it's
only
defined
per
node,
so
the
cube
is
only
able
to
like
well.
The
CRI
is
only
going
to
pull
an
image
once
and
at
that
point
we'll
verify
the
signature
for
whatever
you
know
container
it's
being
pulled
for,
but
it
won't
actually
do
it
for
each
future
container.
C
It
really,
it
really
depends
what
the
signature
is
pointing
to
right
on.
Who
should
be
doing
that
if
it's
yeah,
that
we
don't
have
a
way
to
reply
back
Sergey
to
you
know
to
couplet
right
now,
a
list
of
signatures
on
all
of
various
blobs
manifests
that
we
pulled
from
this
image
that
you've
requested
it's
not
in
the
status.
Yet
right.
C
But
I
guess
that's
sort
of
that's
the
question
Peter.
What
should
should
we
be
doing
this
kind
of
policy
management
to
make
sure
these
things
are
signed
down
in
the
container
run
times,
I?
Think
so,
or
do
we
keep
letting
kubl
it
or
keep
requiring
Kublai
to
do
the
management
of
those
types
of
things
and
artifacts
making
sure
it's
got
an
s-bomb
that
sort
of
thing
right.
C
D
A
So,
specifically,
for
this
PR
I
think
you
may
need
to
get
more
information
of
like
what
alternative
we
have.
Maybe
we
can
introduce
some
new
CRI
fields
and
it
will
solve
this
and
plus
trying
to
address
a
problem
with
garbage
collection
so
introducing
new
problem
while
solving
as
a
problem.
It's
not
ideal,
so
we
need
to
medicine.
Is
it?
Do
you
have
enough
action
items
from
this
discussion.
B
I'm
trying
to
understand
the
the
better
understand
the
the
the
image
lifetime
issues
from
from
as
far
as
I
understand.
What
like
sort
of
the
implication
of
this
is
that,
if,
if
you
have,
let's
say
some
image
that
was
downloaded
for
two
different
runtime
headlets
right
that
might
understand,
and
then
only
only
one
is
being
used
and
the
other
one's
not
being
used
anymore,
then
the
neither
would
be
collected,
but
then
once
they're
both
gone
then
then
both
would
be
eventually
it
would
be
garbage
collected.
C
Requires
when
you
do
a
poll
or
an
Ensure
process
that
you
at
least
pass
in
the
runtime
Handler,
just
specify
it
for
the
Pod
and
then
internally,
when
we
reply
back
to
a
list,
we
need
to
return
the
handle
that
was
used.
If
we
decide
that's
the
right
place
to
handle
insure
with
this
kind
of
thing
and
for
signatures
and
other
stuff.
B
Yes,
but
then,
but
what
I'm
trying
to
say
is
that
when
we
report
the
list,
for
example,
we
don't
do
filtering.
So
if,
if
on
the
list,
we
actually
get
the
list,
regardless
of
which
runtime
Handler
has
it
right,
then
then
I
think
garbage
collection
still
works,
but
that
has
this
Quirk,
where
you
would
only
garbage
collected
the
thing
once
all
of
them
are
gone
right.
So
when
you're
trying.
D
Well,
you,
you
can
I
I,
guess
it
comes
to
like
how
long
you
want
the
duplicated
images
to
be
stored,
because,
like
you,
can
you
can
pretty
much
consider
it
like
two
containers
on
the
same
node
using
the
same
runtime
class
like
you
know,
that's
what
the
qubit
will
consider
it.
As
the
problem
is
the
underlying
storage
layer.
The
image
will
be
duplicated
between
the
two
spots.
So
it's
like.
Do
we
find
that
duplication
acceptable?
D
You
know
for
the
number
of
images
that
would
be
used
between
both
like
coming
to
think
of
it.
I
I
think
that
at
this
point
that
is
acceptable
versus
needing
to
teach
the
cubelet
how
to
be
aware
of
these
two
things,
because
this
is
kind
of
like
it's
a
niche
use
case.
I
mean
it's
not
super
Niche,
but
it's
like
it's
a
pretty
fine-tuned
use
case.
I,
don't
imagine
that
there
are
that
many
pods
or
nodes.
Even
that
will
be
running
both
confidential
computer.
A
Do
we
know
Mike,
do
you
know
if
you
delete
image
from
container
G,
we'll
delete
from
both
handers
or
it
will
just
delete
it
from
a
default
because
I
I?
My
comment
was
in
assumptions
that
containers
you
may
have
this
behavior
when
it
will
try
to
delete
only
one
and
you
will
get
stuck
in
a
situation.
When
can
energy
always
returns,
the
image
Google
tries
to
delete
it
and
it
always
tries
to
delete
it
from
default
and
it
never
got
deleted.
B
Oh,
so
just
just
an
introduction
that
I
just
just
briefly
so
sorry
for
for
speaking
over
people,
but
this
is
actually
a
point
of
discussion
and
something
that
I
sort
of
mentioned
on
the
pr
right.
We
have
a
choice
on
what
to
do
when
The
annotation
is
not
present
right.
So
when
the
notation
is
not
present
and
we
can
list
everything
regardless.
B
B
If
annotation
is
not
present,
we
go
to
the
default
one
time
Handler
instead
of
using
any
Handler,
and
in
that
case
we
run
into
into
this
problem
of
of
like
getting
images
stuck
because
we
never
specifying
the
the
right
runtime
Handler
for
that
image.
So
so
I
think
it's
like
the
default
action
when
navigation
is
not
present.
Sort
of
like
helps
addressing
this.
This
concern.
A
D
Yeah
I
I,
think
that
makes
sense,
I
think
that,
like
yeah
establishing
in
the
CRI
that,
if
your,
if
your
image
is
duplicated
between
multiple
handlers,
then
like
the
cubelet
asking
to
remove
it,
that
should
apply
everywhere,
because
the
cube
is
keeping
track
of
which
containers
are
using.
What
until.
B
C
D
I
I
actually
think
this.
This
might
be
a
hotter
take,
but
I
actually
think
we
don't
need
your
PR
as
a
stand.
So
as
long
as
containerdy
or
you
know,
the
CRI
is
doing
the
correct
thing
with
the
removals,
because,
if
because
it
was
mentioned
earlier
that,
like
at
container
run
time,
if
the
image
is
not
present,
at
least
like
crowd,
doesn't
really
have
doesn't
have
this
Behavior
yet
so
I
mean.
D
D
C
C
Like
to
at
least
add,
you
know
which
runtime
handle,
even
if
we're
not
going
to
use
it,
I'd
like
to
be
able
to
see
when
they
request
an
image
Peter,
for
you
know
for
pulling
what
the
runtime
Handler
is
going
to
be
for
the
pod,
that's
being
run
against,
we
we've
already
added
a
couple
of
other.
You
know
annotations
for
the
pods
pod
information
that
we're
passing
down
I.
Think
that's
going
to
be
a
part
of
this
policy
thing
anyway,
going
forward
we're
gonna,
we're
gonna
need
to
know.
D
C
B
D
D
So
the
situation
that
this
all
right,
there's
just
the
situation
that
your
PR
would
be
optimizing
for
is
for
if,
if
the
Cuba
didn't
know
like,
if
they
didn't
know
that
the
Pod
sandbox
was
going
to
be
run
in
a
separate
runtime
Handler
pulled
the
image,
but
then
it
actually
was
which
I
don't
think
so.
I
think
the
risk
is
like
only
for
the
duplicated
case,
where
the
Pod
is
first
run
in
the
default
runtime
Handler.
D
D
B
D
C
D
F
C
B
Now,
what
we're
getting
is
not
cortex
timeouts,
it's
actually
you're
trying
to
create
a
snapshot.
You're
trying
to
prepare
a
Snapchat
snapshots
and
the
parent
is
something
that
doesn't
exist
right
so,
like
you,
you
believe
that
the
image
is
this
present
and
then
you're
trying
to
prepare
a
snapshot
to
be
able
to
use
that
right.
That's
it's
a
different
error.
It's
not
a
thing
on.
D
C
C
B
B
C
D
All
right,
no
I,
don't
I,
think
I,
think
you're
right,
I,
think
I.
It
wouldn't
be
passed
down
because
the
Cuba's,
the
one
triggering
it
based
on
that
field,
so
I,
actually
I've
flipped
again
back
to
your
PR,
sounds
useful.
For
that
reason.
Yes,
so
thanks
for
workshopping,
this
I
agree
because
yeah
continue
or
you
know,
the
CRI
doesn't
isn't
aware
of
pole
policy,
and
so
the
keyboard
has
to
be
able
to
tell
it
when
to
pull
and
when
not
so
like.
D
A
C
No
and
I
I
agree
with
you,
Alexander
I
think
down
the
road
we
need.
We
definitely
need
to
get
this.
This
pole
policy
to
be
passed
in
the
runtime
Handler
in
a
more
formal
way
with
under
the
expectation
that
the
container
runs
on
is
going
to
be
managing
the
images
collecting
them
and
such
which
would
require
kiblet
to
also
pass
down
the
percentage
of
resource
use
policy.
So
they
can
do
that
collection
right,
remove
those
images
as
well
right.
D
A
G
G
There
is
an
opportunity
to
take
another
look
at
how
we
do
signal
E3
tests
for
nodes
in
particular
initially,
given
that
we
have
a
fun
requirement
where
we
need
to
run
a
test
scenario
against
many
operating
systems,
and
now
multiple
architectures
and
I
see
that
the
cops
project
has
a
neat
way
of
generating
what's
effectively
a
test
grid
of
various
permutations.
So
I
had
a
look
at
how
they've
done
it.
G
So
they've
got
this
little
python
script
in
in
the
same
folders
as
next
as
the
Power
jobs
and
they
basically
Define
a
test
scenario
running
against.
Let's
say
tedos's
with
this
many
with
multiple
options
and
then
they
would
generate
a
power
job,
so
they
probably
got
like
hundreds
of
jobs
generated
like
that.
Instead
of
a
human
right
and
all
those
drops
out
so
I
have
a
PR
in
there
has
implements
that
so
it'd
be
great.
If
you
could
get
that
approved,
I
also
want
to
take
this
opportunity
to
finish
that
cap.
G
A
A
G
A
E
A
A
H
Hello,
so,
okay,
it's
about
one
issue
which
is
was
open
a
few
weeks
ago
and
it's
fixed
so
I'm
trying
to
get
basically
design
review
and
code
review
and
just
trying
to
bring
attention
because
it's
a
regression.
So
a
bit
of
context
for
about
this,
while
a
while
ago
we
had
the
bug
on
which
we
noticed
that
the
device
were
improperly
handled
on
node
reboot.
H
Basically,
what
happened?
It
was
another
Boot
and
the
Pod
were
admitted
and
because
of
code
worked,
the
workload
was
started
without
the
device
actually
allocated,
which
in
some
cases
is
very
bad,
and
we
fixed
that,
unfortunately,
for
reasons
that
are
explained
in
the
PR
but
basically
boils
down
to
a
few
issues
in
the
tests
we
may
we
introduced.
H
So
this
is
it
and
basically
I'm
I
think
I
found
a
fixed
tank
to
a
conversation
with
Clayton
and
others.
Others
in
this
group
already
commented
on
slack.
Thank
you
for
that
and
I
think
I
found
a
way
forward,
which
should
make
your
own
app
in
should
address
all
the
questions
I'm
aware
of,
but
I
will
like
really
love
to
have
more
comments
and
and
review
and
Confirmation,
or
not
that
this
is
indeed
a
good
way
or
any
missing
items,
and
so
this
is
me
trying
asking
for
that.
E
E
H
I
Yeah
I
just
want
to
mention
I
was
I'll,
spend
a
little
bit
of
time
looking
at
this
and
have
a
few
comments,
I'll
send
them
out
on
the
PR,
but
big
thanks
for
for
working
on
this
I
think
overall,
definitely
right
fix
and
looks
good
to
me
overall
there's
a
few
kind
of
small
comments.
I'll
leave
on
the
pier
that's.
A
Yeah
it's
yet
another
situation
on
kubility
Stars
shouldn't
be
that
dramatic,
I
think
another
problem
we
have
is
these
probes
right
when
probe
when
Kubota
starts,
it
makes
everything
come
ready
and
then
we
need
to
reprob
everything.
It's
much
smaller
problems,
though,
but
still
a
similar
aspect
of
it.
H
A
D
Yeah,
so
this
one,
you
know,
I
I,
just
wanted
to
bring
up
a
slight
some
light
complications
that
have
come
up
about
the
secret
driver
thing
that
are
not
insurmountable,
but
I
just
wanted
to
bring
it
to
the
group's
attention
and
gather
feedback.
Basically
that
you
know
currently,
the
idea
is
for
the
C
group
driver
field
to
be
static
in
that
the
cubelet
requested
once
and
then
assumes
it
to
be
the
case.
But
technically
speaking,
the
CRI
implementation
can
reboot
underneath
the
cubelet
and
change
that
value.
D
So
I
just
wanted
to
make
people
aware
of
or
discuss
like
what
I'm
imagining
for.
It
is
adding
a
caveat
in
the
CRI
spec
that
says,
if
the.
If,
if
a
c
group
driver
is
changed,
then
either
the
CRI
should
ensure
that
there
are
no
containers
running
currently
like
it
hasn't
restored
into
containers
that
were
previously
running
on
the
last
run
or
the
node
like
has
rebooted
but
speak.
D
But
that
is
something
that
has
to
be
enforced
on
the
CRI
side,
because
the
qubit
is
not
going
to
be
continually
asking
for
this
field,
so
it
won't
be
able
to
learn
that
it's
changed
and
react
to
it.
So
so
you
know
we
definitely
have
precedent
of
asking
to
see
right
nicely
to
do
things,
but
I
just
wanted
to
double
check
that
that
approach
makes
sense
to
people
and
they
don't
have
any
concerns
or
anything.
A
D
Cubelet,
so
this
is
the
the
problematic
Behavior
will
be
that
the
cubelet.
So
if,
if
the
CRI
changes,
the
C
group
driver
underneath
the
qubit
Cubit
will
not
be
aware
and
will
continue
to
create
the
old
whatever
the
original
hierarchy
is
so
like,
if
it's
originally
just
a
v,
cubelet
will
continue
to
create
slices
for
a
container
that
will
now
like
not
be
managed
by
System
B,
so
the
I
I
assume
I
haven't
tested
it,
but
I
would
be
surprised
if
that
worked.
D
I
know
cryo,
like
manually
checks
the
paths
of
the
the
Pod
C
group
to
check
that
it
conforms
to
what
it
expects
to
be.
The
C
group
driver,
I,
don't
know
if
containerdy
does
the
same,
but
I
assume
that
the
pot,
the
container
Creations
or
pod
Creations
would
start
failing,
because
the
pause
C
group
and
the
container
c
groups
are
like
different
drivers.
D
So
the
expectation
that
it's
being
declared
at
the
the
CRI
spec
level
is
that
this
is
the
responsibility
of
the
CRI
implementation
to
handle
gracefully
and
a
couple
of
ways
that
that
could
happen
is
either.
It
ensures
a
reap,
or
basically
it
needs
to
ensure
that
there
are
no
running
containers
when
the
C
group
driver
switches,
because
the
cube,
because
the
Cuba
would
have
already
created
the
C
group
hierarchy.
D
If
there
are
already
containers-
and
so
we
basically
need
to
make
sure
that
there,
the
switch
doesn't
happen,
mid
run
of
a
node.
The
easiest
way
to
ensure
it
is
just
node
reboot.
It
like
it
needs
to
go
along
with
the
node
reboot,
which
would
be
possible
to
check,
but
might
be
a
little
bit
more
complicated
than
just
checking.
If
there
are
any
running
containers.
D
E
D
So
if
it
re,
if
the
CRI
implementation
restarts
and
the
node
hasn't
rebooted
or
the
containers
have
been
removed,
then,
and
the
C
group
driver
has
switched,
then
the
CRI
should
like
error
or
like
return
response
to
the
cubelet
or
something
like
it,
should
that's
that's
a
error
condition
that
should
be
handled
as
abnormal,
because
it'll
make
it
would
otherwise
make
like
some
nefarious
errors
happen
during
container
creation.
That
might
be
confusing.
Thank.
C
D
D
D
C
F
I
One
question
about
about
the
proposal
as
well:
I'm,
not
sure
if
it
was
if
it
was
covered
somewhere
else,
but
like
I,
don't
know
how
big
of
an
issue
it
is,
but
four
different
runtime
classes.
Is
there
a
difference
to
group
driver
potentially
per
runtime
class,
or
are
you
making
assumptions?
Classes
will
have
the
same
secret
driver
we're.
D
Not
supporting
that
in
kubernetes
like
oh,
that
the
the
I
think
we
previously
briefly
talked
about
it,
but
basically
because
the
cubelet
is
managing
the
hierarchy
itself
and
is
managing
qos
classes
like
you
know,
for
that
like
it
would
make
it
really
complicated
to
try
to
manage
it
between
different
ones.
So
so
far,
we've
just
not
even
tried
to
support
that,
even
though
containerdy
supports
it
and
I
think
that
we
should
continue
doing
that.
D
Yeah,
it's
it
would,
it
would
create
a
it,
would
make
the
cubic
code
a
lot
more
complicated.
You
know
if
we
move
to
a
world
where
the
CRI
is
fully
in
control
of
the
CEO
of
hierarchy
then,
like
maybe
but
like
at
that
point,
it
would
be
an
implementation
detail
of
the
CRI,
but
I
don't
think
we
should
teach
the
cubelet
how
to
Multiplex
the
Sierra
the
C
group
driver.
It.
I
Makes
sense
makes
sense,
I
I
think
that's
fine.
My
only
concern
is,
if
there's
someone
already
doing
some
crazy
stuff
like
that,
like
I,
don't
know
if
they're,
maybe,
if
someone's
using
I,
don't
know,
say,
system,
DC
grip
driver
on
the
kublet
Pod
levels
to
groups
and
for
the
container
ones,
maybe
they're
running
inside
some
VM
or
something
using
secret.
I,
don't
know
if
this
is
like
something
anyone
does
I
just
want
to
make
sure
we
don't
yeah
the
factory
reset
like
personally
I'm,
not
aware
for
basic.
I
D
Well,
and
admittedly,
there
are
some
hacky
situation
said
some
cryo
code
has
where,
like
systemd,
doesn't
manage
certain
C
group
Fields,
so
cryo
will
manage
it
on
its
own.
But
that
said
like
we're,
not
teaching
the
qubit
about
that
so
like.
If,
if
that
creates
any
weird
situations,
that's
the
CRI
implementation's
fault,
and
it's
not
something
that
we
should
make
they
keep
it
aware
of.
It
makes
sense.