Pass a path to `config.json`?

[dpc]

I'd like to issue runc run without relying on CWD, and be able to name config.json something completely else.

Something like runc run --spec /some/path/mycontainer.json . It seems right now I can do runc run -b /mycontainer/ but the spec file will have to be /mycontainer/config.json.

Am I missing anything?

[williammartin]

Hi @dpc,

I think this would break compatibility with the runtime-spec, in particular:

config.json: contains configuration data. This REQUIRED file MUST reside in the root of the bundle directory and MUST be named config.json. See config.json for more details.

[dpc]

Seem to me that by using it, I am opting into something, so it's technically OK. It's not like runc suddenly stops accepting well formed runtime-spec bundle.

I don't really get that "bundle" thing BTW. It seems it contains only one file: config.json, and in that file, rootfs directory is configured (it can be any absolute path). So what's the point of having that bundle directory in the first place? If I want everything in one directory, I can just put everything in one directory. There is no reason to mandate the name of the spec file and referring to it through it's parent directory, as far as I can see.

[wking]

On Mon, Jun 12, 2017 at 09:54:13AM -0700, Dawid Ciężarkiewicz wrote: I don't really get that "bundle" thing BTW.

Previous discussion in opencontainers/runtime-spec#423, in case you want to weigh in there (although I'm not sure how likely it is for the runtime-spec maintainers to reopen that PR).

[dpc]

@wking Thanks. I have recursively followed the discussion through that link, and it convinced me, that the "bundle" is a higher level (image management) concept unnecessarily pulled into the lower level concept (running a container). Anyway, it's not a big deal for me, I was just wondering if I can avoid the inconvenience.

[cyphar]

I've talked to a few people who have found the bundle concept frustrating. In particular, it makes creating a library around an OCI runtime more difficult (because the API is no longer just an OCI configuration, it requires having on-disk state).

However I don't see any reason why future versions of the spec might remove that restriction, and allow for bare configurations that aren't inside a bundle. I'm actually not entirely sure why bundles are necessary. In particular, if you look at LXC, their configurations don't have such a restriction.

Personally, the utility of a bundle has been useful (umoci creates bundles and stores extra data inside the bundle specific to umoci's operation) so I can see why people might like it, but it feels quite odd to mandate that particular choice of organisation inside the spec.

The main argument that I can see is the whole "relative root" case. In particular, one case I would be concerned about if we removed bundles is what should the spec say about a path like ../blah for the rootfs (noting that due to mountpoints and symlinks that the results may not be predictable for a user).

[wking]

On Wed, Jun 14, 2017 at 01:07:56AM -0700, Aleksa Sarai wrote: The main argument that I can see is the whole "relative root" case. In particular, one case I would be concerned about if we removed bundles is what should the spec say about a path like `../blah` for the rootfs (noting that due to mountpoints and symlinks that the results may not be predictable for a user).

This may be a discussion better suited to runtime-spec, but I think the obvious choices for anchoring relative paths are: a. The parent directory of the config.json, which gives you exactly the same behavior as the current “bundle” anchor. b. The current working directory when ‘create’ (or ‘run’, etc.) is invoked. This is a bigger change from the current situation, but allows you to pass the config in via a pipe (e.g. #202). I think all of these methods are going to be ambiguous if there are symlinks involved in the path to the bundle / config.json / working-directory unless the spec covers how they should be handled. Folks concerned about that can always use absolute paths.

[AkihiroSuda]

Closing as this is not likely to happen.