Remove clarify rootfs item from the ROADMAP

[mrunalp]

We discussed this in the face to face meeting and agreed
that it makes sense to keep the rootfs as is for flexibility.

Signed-off-by: Mrunal Patel mrunalp@gmail.com

[vishh]

@mrunalp: Why does the rootfs have to be part of the Spec?

[mrunalp]

@vishh We are taking this item out of the roadmap as we don't think that we need any modifications.

[vishh]

What is the rationale to keep the rootfs path configurable?

On Wed, Jan 13, 2016 at 12:07 PM, Mrunal Patel notifications@github.com
wrote:

@vishh https://github.com/vishh We are taking this item out of the
roadmap as we don't think that we need any modifications.

—
Reply to this email directly or view it on GitHub
#304 (comment).

[wking]

On Wed, Jan 13, 2016 at 11:58:15AM -0800, Mrunal Patel wrote:

We discussed this in the face to face meeting and agreed that it
makes sense to keep the rootfs as is for flexibility.

Looking over 1, the only references I see to ‘rootfs’ are in the
archive-format discussion, the layering discussion, and the “Split b/w
runtime.json” discussion (which seems to be about unifying the
config?). Are you saying “we want to keep the current ‘root.path’
setting so folks can use other names” (which sounds fine to me)? Or
are you saying “we want to keep the current spec and charter that
require bundles to contain a rootfs”. I was pushing back on the
latter in 2, and having an optional rootfs certainly seems more
flexible to me.

 Subject: Dropping the rootfs requirement and restoring arbitrary bundle content
 Date: Wed, 26 Aug 2015 12:54:47 -0700
 Message-ID: <20150826195447.GX21585@odin.tremily.us>

[mrunalp]

This was discussed yesterday and the conclusion was that bundle authors should be able to name their rootfs whatever they want to.

[vishh]

Ok. Thanks for the clarity.

On Wed, Jan 13, 2016 at 12:10 PM, Mrunal Patel notifications@github.com
wrote:

This was discussed yesterday and the conclusion was that bundle authors
should be able to name their rootfs whatever they want to.

—
Reply to this email directly or view it on GitHub
#304 (comment).

[jonboulle]

Eh, somehow I missed this point yesterday, but I agree with Vish, this
seems totally unnecessary in the spec until we have a good use
case/rationale for why it should be configurable.

On Wed, Jan 13, 2016 at 9:12 PM, Vish Kannan notifications@github.com
wrote:

Ok. Thanks for the clarity.

On Wed, Jan 13, 2016 at 12:10 PM, Mrunal Patel notifications@github.com
wrote:

This was discussed yesterday and the conclusion was that bundle authors
should be able to name their rootfs whatever they want to.

—
Reply to this email directly or view it on GitHub
<#304 (comment)
.

—
Reply to this email directly or view it on GitHub
#304 (comment).

[mrunalp]

Allowing changing the rootfs allows flexibility in the config. For e.g. one can have two configs point to the same rootfs and invoke the runtime to start readonly containers.

We discussed that the bundle verification is separate from what the runtime sees. So, after the bundle is verified, there could be a prepare tool to merge the layers and prepare a rootfs. Next step might be to have two different configs point to the same prepared rootfs. If we don't allow modifying the path to the runtime then we lose this flexibility.

[vishh]

@mrunalp: My understanding is that the current bundle format will contain a json configration along with a directory named rootfs that will contain the application's rootfs.
If the rootfs were to be re-used, there can be multiple configs with different top level directories.
If the configs have to be re-used, again multiple top level directories can be used with a combination of bind-mounts to avoid copying the rootfs.

I agree that we need to provide an ability to mark the rootfs as readOnly, but I'm having trouble understanding why the directory path rootfs needs to be configurable?

[wking]

On Wed, Jan 13, 2016 at 12:25:54PM -0800, Vish Kannan wrote:

My understanding is that the current bundle format will contain a
json configration along with a directory named rootfs that will
contain the application's rootfs.

The current bundle format does not require that name [1](fine with
me), but it does require a rootfs directory (which seems like it's out
of scope for this issue).

If the configs have to be re-used, again multiple top level
directories can be used with a combination of bind-mounts to avoid
copying the rootfs.

It's true that you don't need configurable paths (because you can just
bind-mount anything). But allowing a configurable path makes this
sort of thing easier. For example, my editor lets me specify a path
on the command line, so I don't have to bind-mount the file to
‘./edit.txt’ before invoking the editor ;).

[crosbymichael]

Discussing this more the general idea is that it is better for the config to be explicit from the user and not infer anything were we don't have to even if by convention it will most likely be rootfs.

LGTM

[vbatts]

LGTM