►
From YouTube: GMT 2018-05-17 Containerization WG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
A
A
A
A
A
A
A
A
A
A
C
C
C
So
originally
I
thought
that
we
could
do
this
just
by
modifying
their
cgroups
devices.
Isolator-
and
I
went
pretty
far
down
that
path
and
had
working
code.
But
it
was
really
ugly
mainly
because
there's
a
lot
of
conceptual
mismatches
around
how
they're
cgroups
subsystems
expect
things
to
work.
They
expect
things
to
work
on
a
base
at
the
root
of
the
content
or
e,
but
really
for
this
application.
We
only
want
them
to.
We
want
it
to
be
per
container.
C
C
The
easiest
thing
to
do
here
is
to
mount
dev
temper
vests
that
totally
works,
but
you
want
to
get
one
day
of
temper
first
instance
across
the
whole
system,
which
makes
it
kind
of
unattractive
in
in
production,
really
infeasible.
You
can't
you
see
what
happens.
It
is
if
you
modify
the
dev
temper
vests
in
any
container.
That
modification
is
going
to
show
up
in
all
so
that
kind
of
rules
it
out
for
for
any
kind
of
container
Orchestrator.
C
Theoretically,
you
can
make
theoretically
I
think
it
makes
sense,
but
in
in
practice
the
implementation
is
just
too
gnarly
and
the
the
mismatched
assumptions
in
the
systems
make
it
make
it
a
very
a
pretty
awkward
approach.
So
what
I've
got
now
is
a
patch
series
which
is
out
for
review,
which
implements
a
Linux
devices
isolator,
and
it
actually
is
really
simple:
it
consumes
the
same
allowed
devices
that
the
cgroups
devices
isolator
consumes
and
it
constructs
it
stages.
C
The
device
nodes
in
a
per
container
run
directory,
and
it
by
amounts
those
in
when
you
actually
launch
the
container
staging
the
staging.
The
devices
into
their
container
run
directory
allows
like
Garant,
make
that's
necessary,
because
that's
the
only
way
to
guarantee
that
you
have
the
correct
privileges
to
be
able
to
create
the
devices
and
that
you're
able
to
create
the
devices
with
the
right
access
control
policy.
C
So
whether
it's
read,
write
or
read
only
for
the
container
their
codes
fairly,
simple
it
it's
fairly
well
confined
so
I
think
it's
a
much
better
approach
than
them.
Other
two
for
my
pip
for
my
immediate
purpose,
simply
making
the
allowed
devices
available
in
containers
is
enough,
but
I
think
we
can
extend
this
approach
to
to
allow
schedulers
to
have
per
container
control
over
which
devices
are
allowed
and
available.
B
C
B
This
is
because
I
think
for
some
of
the
devices
like
TV
now
TV
random
DV
those
standard
on
devices
that
are
every
contingent
is
to
to
to
use
on
and
right
now
we
do
that
in
like
launched
our
CPP,
which
is
not
the
right
place.
If
we
move
to
those
line
into
the
linux
device
isolator.
That
means
we
have
to
turn
on
this
isolator
by
default.
Yeah.
C
I
think
that's
a
good
direction,
so
I
think
I
think
a
next
step
for
the
Lumix
to
bus
I
said
it
might
be
to
construct
/div
as
a
whole
as
a
No.
So
currently
the
way
it
works
is
it's
going
to
do.
Abide
amount
per
device,
but
if
Frank,
if
we
take
their
complete
control
of
/dev
into
the
Linux
devices,
then
weaker
instead
of
having
multiple
PI
mounts,
we
would
just
do
one
and
we
will
instruct
the
whole
thing
so
I
think.
B
I
think
that
that's
always
do
that
incrementally,
okay,
so
another
question
is
like
so
the
separation
between
this
one
and
the
secret
device
isolator
is
so
the
single
device
isolator
is
going
to
be
responsible
only
for
allowing
those
device
number
to
show
up
to
be
able
to
be
accessed
from
the
container.
That's
it
has
nothing
to
do
with
the
device.
No
creation,
exactly
okay,
yeah
I
think
that's
pretty
clear
like
that.
So.
C
In
this
first
in
this
first
patch
series,
if
you
have
them
both
they'll
work
together
automatically
because
they're
both
looking
at
the
same
agent
flags
in
the
future.
If
we,
when
we
extend
that
those
devices
will
need
to
add
some
code
to
have
it
like
explicit
cooperation,
I
think
just
in
in
a
similar
way
to
how
the
NVIDIA
GPU
isolator
works.
D
C
B
C
C
Yeah
actually,
since
I
wrote
this
store,
originally,
my
I
had
a
container
launch
info,
but
the
current
patch
doesn't
user
doesn't
have
them
at
all
they
tip.
So
what
happens
now
in
the
patch
series
is
that
the
container
launcher
just
looks
in
their
devices
directory
and
it
mounts
things
that
are
finds
and
it
by
amounts
things
that
it's
finds.
They're
so
turned
out
that,
although
my
original
series,
I
added
a
device
info
to
container
launch,
unify
I,
threw
that
away
as
well
as
I
went.
C
B
B
B
A
B
C
They've
got
a
cooperation
with
mounting
things.
Also.
Might
we
I
think
some
of
Jason's
patches
will
help
us
there,
because
right
now
we
don't
have
a
have
really
good
ways
to
make
sure
that
we're
Mount
they're
doing
container
mounts
in
the
correct
in
the
correct
order.
I
think
Jason,
spatulas,
yeah,
so
she'll.
B
E
C
E
A
A
That
sounds
great
yeah,
so
another
another
thing
for
James.
So
once
you
have
the
idea
on
the
agent
correct
change
and
all
the
framework
API
change
as
well
as
the
internal
code
of
change,
could
you
add
it
to
the
top
and
shared
it
with
the
with
the
mailing
list
for
and
the
API
potential
change?
And
people
could
comment
on
that
in
in
their
email
thread?
A
C
A
C
Not
in
this
patch
series,
so
I
think
that
we
want
to
do
that
eventually,
because,
like
OCI,
spec
has
a
way
to
specify
devices
so
doing
it
per
container
with
API
is
kind
of
probably
a
median
term
direction
we
want
to.
We
want
to
follow,
I,
don't
know,
I,
don't
know
that
I'm
going
to
get
scheduled
to
work
on
that
and
I
don't
have
like
immediate
plans
to
do
it.
Yeah.
B
C
C
B
I
mean
if
the
name
e
is
standard,
then
it's
okay,
but
if
for
the
name
is
like
not
standard,
then
I
don't
know
your
firm
weeks.
Gonna
use
that
like
so
that
I
think
that's
really
Mike
Ramirez
ap
I.
Don't
have
that
form
that
that's
one
of
the
reason
they
don't
have
dancing
their
IEP
I
for
containers
see
out
bubbling
to
think
more
on
those.
A
C
C
No,
the
trap,
the
pet.
The
review
is
kind
of
proof
of
concept
stage.
So,
okay,
if
I
agree
that
we
want
to
do
this,
and
we
agree
that
this
is
the
right
direction
and
all
those
things
then
I
can
add.
You
know
flags
I,
think
we
wouldn't
need
a
flag.
We
should
definitely
have
a
flag.
Just
with
the
right
approach
is
like
Oh
turn
on
the
flat
like
it
had
the
flag
off
by
default
and
then
go
through
we'll
have
to
go
through
a
whole
deprecation.
B
Cycle
them
right
right,
so
we
student
to
keep
the
OCO
path,
but
you
have
to
flag
is
turned
on.
Then
the
module
tests
we'll
go
through
the
defy
executor,
yeah
yeah
I'm,
pretty
sure
to
do
that.
All
the
work
is
making
sure
the
tests
work.
You
know,
look
in
both
cases.
I
see,
okay,
I,
see,
damn
that
make
sense
like
having
all
the
tests
working
is.
A
Yeah,
okay,
I
still
regard
that
application.
Gonna
be
hurt,
I
yeah,
the
one
thing
I'm,
not
sure
it
is
like
we're
done.
Oh,
we
could
eventually
deprecated
it
because,
because
why
even
we
have
a
long
deprecation
cycle,
the
change,
the
deprecation
of
the
command
is
cuter.
It
gonna
break
a
lot
of
users.
Is
that
especially
for
the
user
who
build
the
tooling
on
top
of
whom
a
suspicion,
for
example,
like
some
tooling
some
news
that
they
feel
like
the
squid,
which
which
go
to
always
with
this
and
standard
out
standard
errors
from
the
same
box?
A
Okay,
then
box,
are
your
sony
logging,
logging,
stuff
yeah?
I
mean
some
tooling
like
any
tooling,
which
gonna
read
on
from
the
from
the
sandbox.
They
need
to
change
it.
So
as
far
as
I
know
many
mazes
user,
they
build
their
own
tooling.
To
like
do
some
parsing
from
the
from
the
continual
log
so
yeah,
but.
B
But
that's
the
purpose
of
deprecation
cycle
right,
you,
you
ask
people
say
hey,
this
is
bad.
We
know
it's
bad
and
we'll
move
away
from
that,
but
we're
gonna
be
backwards
compatible.
So
that's
the
that's
the
reason
for
the
deprecation
cycle
and
we
have
this
new
support.
Please
try
that
if
that
makes
just
satisfy
your
need,
Princeton,
library
or
tuning-
and
we
didn't
have
a
long
application
cycle,
but
eventually
are
going
to
abrogate
that
and
you
remove
that
thing.
Yeah.
A
B
A
So
I
my
my
concern.
It
is
like
it
the
typical
firstly,
initially
the
defecation
defecation
strike.
Are
you
gonna
be
long?
The
second
thing
it
is
deacon,
it's
very
likely
it
can
all
the
automated
use
that
they
have
to
change
something,
and
the
third
thing
it
is
like
this
is
a
big
change
for
user
in
behavior.
So
maybe
we
should
like
considered
was
anyone
of
any
of
us
have
cycle?
B
B
We
should
get
rid
of
that
and
just
some
legacy
stuff
and
people
depends
on
those
legacy
behavior
and
if
we
don't
do
anything
with
an
ever
move
away
from
those
things,
so
should
start
doing
that
and
and
have
a
long
left
application
cycle
to
allow
people
to
to
migrate
from
that
I.
Don't
them,
although
and
move
to
the
new
one.
A
B
Guess
who
has
cycle
to
review
those
chain?
It's
it's!
It's
just
touching
the
container
Iser
parts
also
touching
some
the
agent
part
I,
think
yeah
I.
Think
that
took
the
question.
I
think
that
the
problem
here
would
you
find
some
Shepherd
for
this
work.
We
all
know
this
is
important,
but
but
sounds
like
it's
not
a
priority
for
any
of
us.
B
B
C
Yeah,
exactly
so
I
mean
I
think
it's
at
a
point
where
we
can
see
where
it's
going.
So
if
everyone
agrees
that
this
is
something
we
want
to
do,
then
I
can
try
to
work
on
that,
but
yeah
and
also
like
James,
my
god,
I
want
to
go
and
polish
it
off
and
finish
it
and
only
find
that
we
didn't
want
it.
We
didn't
really
all
agree.
Yeah
the
first
place,
yeah.
B
C
B
B
B
And
use
the
same
lunch
helper
to
actually
launch
the
container
for
the
command
executor.
The
task,
but
that
that
creational
container
does
not
go
through,
does
not
go
through
the
the
agent
code.
Basically,
it
directly
go
to
the
launch
helper
so
that
what
that
essentially
means
is
from
isolators
perspective.
Each
isolator
needs
to
be
aware
of
this
special
case.
If
this
is
a
command
executor,
I
have
dual
isolations
specifically
if
I
know
this
is
a
command
executor.
Sorry,
this
is
a
command
task.
C
D
B
That
would
be
pretty
hard,
especially
like
Danny
I
mean
it
defeat.
The
purpose
of
doing
this
change,
because
the
whole
purpose
of
this
change
trying
to
do
something
do
things.
You
know
in
a
unified
way
into
the
agent
into
the
isolator.
But
what
you're
saying
is
we
still
do
special
case
for
command
tasks
dense
extent
and
then,
what's
the
point
of
doing
that,
every
factory
can
remove
the
command
executor.
So
so
the
whole
purpose
of
tires
trying
to
make
nice
I
mean
in
a
unified
way.
B
B
C
B
Objection
I
know
like
some
people
might
object
to
that.
I
know.
I
do
have
a
little
tuning,
but
maybe
they're
not
aware
of
that
I
mean
that
might
break
their
tuning.
I
guess
I
need
to
be
more
explicit,
yeah
I
think
the
killer.
Your
idea
is
great,
so
let's
be
more
explicit
about
the
things
that
will
change
and
listening
the
talk
and
then
send
that
to
the
user
and
warn
them
that
this
is
happening
so.
B
A
B
D
I
agree
with
the
transition.
The
thing
is
like
when,
when
we
list
the
difference
or
change
some
in
exchange,
we
are
making
we're
making
I'm
just
wrong
to
think
I.
Just
wish
that
we
could
think
about
what
are
the
specialization.
It's
only
happened
locally
and
doesn't
hurt
a
lot
when
we
mean
in
a
site
when,
in
the
yeah.
B
So
yeah
I
think
we
can
definitely
do
that.
We
were
saying
it's
like
if
we
can
just
very
simple
that
it's
very
localized
you
know
a
single
isolator
or
something
like
that.
It's
not
very
like
a
a
big
change.
Then
maybe
you
can
maintain
some
backwards.
Compatibility
regarding
the
behavior,
yeah
I
agree.
If
we
can
do
that,
but
my
my
opinion
is,
it's
very
mean
I
think
to
mail.
It
many
two
things
that
people
will
see
different.
This
one
is
a
sandbox
layout.
B
That's
one
thing!
The
other
thing
is
the
Seagram
layout
for
freezer.
I
think
only
freezer,
because
for
the
rest,
see
group
Restless,
eager
assistant
will
be
the
same
on
just
a
freezer.
You
have
this
nesting
structure.
These
are
the
only
two
that
I
can
remember,
and
also
there
are
some
some
house
check
differences.
Yeah,
that's
yeah.
A
B
Yeah
environment
variable
is
I,
mean
it's
attacked
at
annually
we
were
fixing
the
issue,
it's
more
like
a
bug
that
we
even
hire
some
of
the
and
secure
environment
to
the
task,
which
is
a
bug,
but
the
easier
it
is
like
some
uses.
They
might
I
know
they
rely
on
this
behavior
I
know
so,
but
yeah
I
think
we
should
not
I
mean
it's
like
people
rely
on
some
buggy
behavior
mesos,
which
we
should
move
them
away
from
this.
C
B
E
B
A
B
Think
we
just
start
this
discussion
in
protic
I
mean
Gilbert.
If
you
do
have
some
small
cycle
on
that.
Take
a
look
at
those
patch
gives
some
high-level
comments
like,
for
example,
you
know
a
joke
slide
for
sure
yeah
and
just
some
Gibson
Potter
or
comments
to
unblocking
and
James
see.
If
we
can
find
someone
internally
back
and
review
the
patch.
That
would
be
great
too.
B
A
B
Okay,
see
my
screen,
you
guys
see
my
screen
yeah,
yes,
okay,
so
I
did
some
change
to
the
to
the
logger
interface.
It's
mainly
dispatch
that
changed
the
logger
interface,
so
the
main
challenge
is
actually
so.
If
we
look
at
the
logger
interface
right
now,
so
it
used
to
be
taking
these
three
parameters
and
secured
in
flow
sandbox
directing
the
user.
At
the
time
when
logger
was
written,
it
was
specifically
for
the
executor
and
it's
not
for
like.
Can
you
know
it's
tasks?
B
Part
of
the
reason
is
this
command
command
task
issue,
where
the
tasks
log
is
actually
part
of
the
executors
log,
they
go
to
the
same
STD
out
in
this
in
the
air,
and
so
that's
home,
detect
going
to
fix
part
of
that
work.
So
so
so
yeah
yeah
yeah,
it's
very
executor
specific.
B
If
you
look
at
the
module
implementation
inside
the
repo
on
the
entry
modules
that
it
looks
into
some
specific
environment,
variable
choot
to
tweak
the
logger
behavior,
but
as
I
said
it's
previously,
it's
only
possible
if
you're
dealing
with
an
executor
now
the
change
I'm
doing
right
now
is
make
it
general
so
that
all
the
containers
can
can
can
benefit
from
this.
This,
and
so
the
change
is
pretty
simple.
Just
changing
these
to
feel
to
be
the
container
config,
which
is
a
superset
of
all
these
informations.
B
So
the
changes
itself
is
very
simple:
I
might
want
to
add
another
field
here
called
container
ID,
but
I
haven't
done
that
and
to
do
that
right
away
next,
so
that
we
don't
have
two
changes
on
the
modern
interface,
because
some
some
there's
no
way
to
get
a
container
ID
no
longer,
but
something
longer
do
require
the
container
ID.
So
that's
the
the
interface
change
and
I
I
kind
of
changed
all
the
entry
modules
to
adapt
to
the
new
mod
to
the
module
interface.
B
So
the
change
is
pretty
simple,
because
this
has
all
the
information
that
we
have
previous
day.
So
so
the
change
is
pretty
straightforward:
just
find
the
right
field
and
do
the
change.
So
if
you
have
a
custom
logger
that
so
it
will
no
longer
work
which
the
new
version
may
so
so
you
have
to
change
your
logger
to
to
adapt
to
the
new
interface
yeah
the
rest
of
the
changes
per
day
from
a
formality.
There's
knows
nothing
interesting
and
also
I
updates.
The
challenge
talk
about
this
new
change.
A
Sergey,
you
have
I,
have
two
questions,
so
the
first
one
is
like
on
the
behavior
before
the
change,
so
the
log
of
modules
per
execute
here
so
for,
let's
say
for
fortify
security,
if
that's
the
continuous
we
have
two
nested
continuously.
So
how
do
we
handle
the
log
for
those
two
separate
container
inside
of
one
executed.
B
Know
previously,
logger
will
be
applied
to
each
container,
so
every
single
container
launch
will
go
through
loggers.
So
it's
already
the
case
that
the
logger
works
for
each
container,
including
as
to
container
or
standalone
container,
just
the
fact
that
to
control
the
behavior
for
that
log
logger
for
the
container,
it's
only
possible.
We
can
control
that
if
the
continuous
for
executor
it's
not
possible,
we
can
control
the
behavior
of
the
logger
if
the
container
is
nested
container
or
standalone
container
gotcha.
B
Okay,
so
this
patch
make
it
possible
to
actually
control
the
log
of
longer
behavior
per
container.
So
even
for
stand
on
container
or
nasty
container,
you
can
control
the
logger
behavior,
because
something
longer
that
like
this
us
build
is
like
you
can
eat
a
dump
to
journal
D
or
them
to
sandbox
or
both.
B
A
B
So
so
on
the
use
case,
for
that
is,
like
I,
know,
like
some
logger
dumb
to
journal
D,
and
when
you
write
to
journal
the
one
of
the
tree,
you
add
to
the
log,
a
one
that
feels
you
add
to
the
log
entries
I
container
ID,
so
that
I
can
do
general
control
filter
by
the
container
ID.
So
you
can
see
logs
for
particular
container
IDs
yeah.
B
Do
that
today
actually
I
need
something
a
new
field
called
container
ID.
Then
this
interface
will
be
exactly
the
same
as
the
interface
of
an
isolator
prepare.
So
it
will
be
exactly
the
same.
Well,
the
return
value
is
different,
but
oh,
the
parameter
will
be
the
same,
which
is
consistent
with
which
is
pretty
consistent
with
I/o.
We
can
add
the
company
ID
to
the
container
config.
No,
no
I
think
we
shouldn't
do
that.
That's
a
much
bigger
change!
You
know
just
had
a
container
ID
here:
okay,
yeah!
That's
it
any
questions.
B
Did
for
me,
okay,
yeah,
that's
pretty
much
why
I
want
to
share
just
wanna,
let
everyone
know
in
case
you
guys
have
a
logger
module,
they'll
custom
logger
by
mojo.
If
you're,
not,
then
it's
not
apply
to
you
all
right,
I'll!
Stop
sharing
my
screen!
That's
it
from
my
side.
A
B
Yeah
I
mean
just
just
in
general,
like
if
you
guys
have
any
like
I
know:
I
guess
have
a
kind
of
like
a
small
for
King
in
your
environment,
kind
of
the
patches.
That
I
mean
any
of
the
issues
you
saw.
It
agree
that
you
can
create
at
least
some
GF.
Let
us
know
like
what
the
issue
is,
so
that
we
can
yeah.
It
would
be
nice
to
upstream
all
those
bug
fixes,
at
the
very
least,
to
to
upstream.
E
So
also
like
I
think
we
can
leave
this
some
discussions
offline,
but
you
know
but
I
mean
just
a
brief
for
my
you
know
mention
about
like
the
needs
for
the
pre
exact,
and
you
know,
post
exact,
for
the
mountain
info.
I
think
last
time
I
proposed
this
and
Angie
asked
me
a
while
that's
necessary
but
like
by
looking
at
the
secrets
and
I
I
do
think
my
you
know
we
can.
We
can
definitely
think
about
that
as
a
model.
So,
okay.
E
B
E
E
That's
around
the
mounts
for
some
some
of
the
liked
about
the
mount
you
probably
want
to
you
know
apply
a
bunch
of
on
our
show
squirts
about
just
in
the
context
of
those
mounts
and
that
previously
I
was
there,
like
my
so
like
container
D
or
like
lib
container,
has
this
model
and
each
of
the
mountain
info
and
they
would
have
like
to
pre
and
post
them.
Exact
and
I
proposed
this.
The
MA.
You
know
to
populate
this
over
to
the
container,
to
like
a
container
mount
info
and
yeah.
B
I
think
that
the
I
think
one
the
use
case
for
that
yeah
I
know
what
I
continually
has
this
at
the
time.
I
I
don't
have
a
use
case
for
that
as
soon
as
anything
introduce
that
one
but
yeah
I
think
there's
one
use
case
where
I
think
about
the
secrets.
Right
so
ma
you
find
you
you
you
you
you
in
the
mount
info.
You
do
a
amount
of
the
Rama
fest,
because
you
want
the
secrets
to
being
memory
after
you
mount
the
Rama
fast.
B
You
want
to
copy
the
secrets
to
that
FS
and
best
that
has
to
be.
You
cannot
do
in
the
hut
like
in
the
prepare
stage
of
the
isolator,
because
it's
not
being
mounted
yet
so
so
that
might
be
you
wanna
use
case
that
we
want
to
support.
It
will
be
much
nice,
so
we
have
this
because
right
now,
if
you
look
at
a
secret
isolator,
it's
pretty
happy
I
think
it
just
use
like
a
move.
Somehow
right.
C
B
E
E
We
do
have
from
you
know,
teams
them
are
proposing
to
use
them
this
isolator,
and
currently
it's
not
in
the
ideal
state.
So
for
us
them
you
know,
would
be
better
to
start.
Looking
at
that
and
I've
been
like
refactoring
the
code
around
those
Isolators
yeah.
C
E
Discretion
in
in
in
adult
ask
so.
C
E
That
really
depends
on
the
context
timeline
here
and
like
after
that,
I
I
would
say
it's
yes
and
no,
some
of
the
some
of
those
them
you
know
secrets
are
things
that
my
definitely
has
to
be
better
done
right
after
that
yeah.
B
E
I
know
what
James
means,
but
like
ma
I
would
say
appropri
and
after,
and
so
that's
really
happening
in
between.
Like
me,
know
the
pre
like
in
between
the
the
mount
the
mount
called
system
call
and
then
right
after
that
I
prior
to
like
to
route.
But
if
you
are
for
all
of
those
posts,
even
when
you
do
intrude
and
you
don't
really
have
the
context
anymore,.
E
B
B
So
they
basically
define
a
shell
script
for
individual
mount
like
you
can
do
something
before
the
mountain
do
something
after
the
Mount.
So
what
I
think
what
James
is
saying
like
things
we
already
have
this
think
globally,
like
like
you
can
do.
You
can
already
read
some
script
right
after
I.
Don't
know
if
it's
after
or
before,
but
we
can
do
both
I
think.
C
E
B
I
think
so
I
think
there
are
see
two
options.
One
is
doing
that
for
each
mount
like
for
each
mount
info.
You
can
define
some
pre
and
after,
like
post,
exact
commands
the
other
approach.
Is
you
do
that
globally?
Basically,
using
like
before
you
prepare
all
the
mounts,
you
can
run
some
script
and
actually
prepare
all
the
mounts.
You
can
read
some
scripts
and
each
isolator
can
set
each
individual
set.
Those
commands
so.
C
E
B
I
say
that
make
sense,
yeah,
yeah,
I
think
we
do.
We
see
to
approach
this
I
think
either
those
works
I
mean
we
can
decide
what
to
do
because
I
think
this
is
internal
I
think
you
can
decide
what
to
do.
It's
not
like
super
controversial
right,
just
just
like.
Where
do
we
put
this
command
is
seeing
the
mount
info
or
the
container
knowledge
info?
That's
it
right.
It's.