*: Remove "bundle" and go straight to config.json #423
Conversation
|
... |
|
The bottom two commits from the original 42fbdb8 have landed (with
some other changes via #435. With b08f2f4, I've rebased this PR onto
master to build on the version that landed in #435.
I've also spun off the new root commit into it's own PR (#451), since
“split off the bottom chunk” approach worked well in #435. If this PR
is still to big to swallow, folks can review #451 instead.
|
|
And I've spun the config-linux commit off into #452.
|
|
We discussed this on the call and all said that there is benefits of keeping the bundle and we don't want to remove it. |
|
On Tue, May 24, 2016 at 03:01:14PM -0700, Michael Crosby wrote:
There were certainly folks who wanted to keep it (most people who Let me pull out the the schema commit into it's own PR, and we can And this is rebased again with b08f2f4 → 39c3618 now that #451 and |
The bundle contains 'config.json' and other things, but this schema is just for 'config.json'. This is mostly: $ sed -i 's|/bundle|/runtime/config|' schema/*.json for the 'id' fields, but I also tweaked 'root.description' and the schema.json 'description'. Signed-off-by: W. Trevor King <[email protected]>
Some history behind bundle requirements: * 77d44b1 (Update runtime.md, 2015-06-16) lands the initial reference to a root filesystem, requiring a relative path. It also lands the "bundle" construct, which at this point includes content directories, signatures, and the configuration file. The content directories "at least" include the root filesystem. * 5d2eb18 (*: re-org the spec, 2015-06-24) shifts the bundle docs to bundle.md and demotes signatures to "other related content". * 91f5ad7 (bundle.md: various updates to latest spec, 2015-07-02, opencontainers#55) finishes the signature demotion and strengthens the root-inclusion requirement with another "must include". * 7232e4b (specs: introduce the concept of a runtime.json, 2015-07-30, opencontainers#88) split out runtime.json, required the root directory to exist at `rootfs`, and dropped most references to "content directories". * 106ec2d (Cleanup bundle.md, 2015-10-02, opencontainers#210) kept the requirement for a rootfs directory in the bundle root, but relaxed the name requirement to allow other single-component names (e.g. `my-rootfs`). Dropped the last reference to "content directories". * cb2da54 (config: Single, unified config file, 2015-12-28, opencontainers#284) rolled runtime.json back into config.json. * b2e9154 (Remove requirement for rootfs path to be relative, 2016-04-22, opencontainers#394) allowed absolute paths for root.path and removed some "same directory" language while leaving other "same directory" language. I think the root filesystem should be optional [1], but even folks who disagree on that point have come to the conclusion that it doesn't need to be in the bundle [2]. opencontainers#394 seems partially unfinished, but I think the intention was clear. Once you relax the "bundle must contain the root filesystem" requirement, the only thing that the bundle must contain is config.json. It doesn't seem to be worth the trouble to name a "bundle" construct if its only meaning is "the directory that holds config.json", so this commit removes all remaining references to the term "bundle". [1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/6ZKMNWujDhU Subject: Dropping the rootfs requirement and restoring arbitrary bundle content Date: Wed, 26 Aug 2015 12:54:47 -0700 Message-ID: <[email protected]> [2]: opencontainers#389 (comment) Signed-off-by: W. Trevor King <[email protected]>
|
-1 |
|
Hi. So I am a random dev that is doing something using So, is there any technical reason for requiring rootfs to be in the same directory? If not (and clearly it's very useful to be able to get it from the outside), and it's officially supported, then the spec file is all that matters, and I don't see why I need to put the spec file in a directory and have its name hardcoded. I get that it might be useful during packaging, image managment and delivery, etc. to talk about a "bundle" of some kind, and have a standard format of it, but then again: that's another level of abstraction, above just "running a container". |
I think the root filesystem should be optional, but even folks who disagree on that point have come to the conclusion that it doesn't need to be in the bundle (#389, #394). #394 seems partially unfinished, with “MUST be included” and “single directory” wording still applying to the root filesystem, but I think the intention was clear (why allow absolute paths if the root filesystem must still be in the bundle directory?). Once you relax the “bundle must contain the root filesystem” requirement, the only thing that the bundle must contain is config.json. It doesn't seem to be worth the trouble to name a “bundle” construct if its only meaning is “the directory that holds config.json”, so this commit removes all remaining references to the term “bundle”.
We use the word “bundle” a lot, so this PR is split up into a few commits. The earlier commits stand alone (at least, to my eye), and I expect they, or something like them, should land regardless of how the bundle removal goes down. I'm happy to spin them off into separate PRs if that makes them easier to review. Once the early commits are out of the way, the final commit clears out any remaining “bundle” wording. More detailed motivation for each commit is in the commit message.