Multi-platform support

[sladage]

Allowing for a single container to contain multiple platform-specific configurations.

[wking]

Ah, I see you didn't indent it to be recursive ;). I think this
explicit-child approach makes it too hard to handle per-combination
tweaks (see 1), but I don't have a better idea that doesn't make
all-combination tweaks difficult. I'm fine waiting until someone does
have a better idea (to avoid putting work into a likely dead end), and
until then think we should just walk a config directory looking for
the best platform match (so change the bundle spec) without altering
the config spec itself (see 1).

But if we do land this approach, I'd suggest at least making the
"platforms" behavior recursive. Special-casing the top-level config
will just make life harder on implementors and container authors (and
I don't see an upside to the special case).

[sladage]

I had not thought about making it recursive, that could actually work. Or if we don't make it recursive, it could load all matching configs. (each platform section being more specific)

As for the walking trough a config dir solution, although simple, it could get messy having to update all configs which mostly contain the same info anyway. (not very efficient either)

But yeah, let's see if someone has a better idea.

[wking]

On Fri, Jul 24, 2015 at 02:28:27PM -0700, Stefan Ladage wrote:

As for the walking trough a config dir solution, although simple, it
could get messy having to update all configs which mostly contain
the same info anyway. (not very efficient either)

Yeah, but Dockerfile has had reasonable success with the KISS
approach, and folks can always add external tooling like 1 if they
want to build those repetitive configs from a DRYer template.

[sladage]

True, the simple approach is generally the better approach,just less flexible in this case. Even if we don't need the flexibility at this moment, we might in the future. Having said that, I actually like the config dir idea. We just have to be careful that we don't, in an attempt to keep things simple, end up with a specification that is too inflexible. Not that I think it is an issue here, just something to keep in mind.

[wking]

On Fri, Jul 24, 2015 at 03:18:41PM -0700, Stefan Ladage wrote:

… I actually like the config dir idea…

I'll write up a PR.

[sladage]

Looks good, although, I'm not entirely sure where you were going with the version check. Also, the naming convention should be made more clear I think. Like:

[platform]_[arch]_[???].json

linux_x64.json
linux_arm64.json

Looking at both solutions I can't really say one is more simple than the other though. :) It just moves the problem from the config file spec to the directory layout spec.

[wking]

On Sun, Jul 26, 2015 at 04:23:22AM -0700, Stefan Ladage wrote:

Looks good, although, I'm not entirely sure where you were going
with the version check.

In #76? I'm not sure if I can add much to clarify my commit-message
comments (repeated in the initial PR post), but the version ranking
lets you write a bundle compatible with both 1.x and 2.x of this spec
(by supplying both a v1.0 and a v2.0 config for a given platform in
your config/ directory). Does that help?

Also, the naming convention should be made more clear I think. Like:

[platform]_[arch]_[???].json

linux_x64.json
linux_arm64.json

Again, I think you're talking about #76. With that approach, the
filenames (under config/) don't matter at all. Use whatever you like
best. If folks want to pick a convention, that's fine with me, but I
don't see a need to suggest something in the spec. If we do want to
suggest something, I'll happily merge a PR against my config-directory
branch ;).

Looking at both solutions I can't really say one is more simple than
the other though. :) It just moves the problem from the config file
spec to the directory layout spec.

The approach in #76 makes it possible to support multiple,
incompatible versions (e.g. 1.x and 2.x) at the same time. It also
doesn't require any config-file merging, so the existing runC can
already launch containers from such a bundle (you just have to do
the config-choosing work by hand until we get the proposed mpm tool
1). And the only problem we need to solve for mpm is matching
platforms (we don't need to worry about combining the parent spec with
the child specs). Of course, “combining the parent spec with child
specs” (or handling $ref replacement) can be useful for reducing
duplication, but as I tried to show earlier 2, I'm not convinced
that either is sufficiently powerful to be worth the complication. I
do think automatic platform matching is sufficiently powerful to be
worth the complication though, and that's the only thing #76 adds.

And as I tried to say in [3], I doubt we'll be able to leap
immediately to consensus solutions for all the issues facing container
authoring and management. I think we need an ecosystem of tools that
each address a single facet of the problem (runC for launching a
container from a given config, mpm for finding the config that best
matches the current platform and runC implementation, …), and we need
a clearer framework to flexibly combine those tools. Then I can try
my way, and if you're not convinced, you can try your way, bundle
authors can choose whichever works for them, bundle consumers can push
back if installing the required tools is too troublesome, etc., etc.
And we'll eventually consolidate around a smaller set of great tools.
If we end up with something like the Mercurial / Git divide while a
particular pair of tools takes a few years to sort out the popularity
contest, that's fine.

[wking]

On Mon, Jul 27, 2015 at 03:19:43PM -0700, W. Trevor King wrote:

And as I tried to say in [3], …
…
[1]: #76 (comment)

Oops, should have been [1].

[philips]

Can someone write-out a use case for this? What is an example use case for a bundle that supports multiple archs? Why is having two bundles too complicated?

[philips]

I am going to close this out and repeat my questions on #73 until we decide whether this is desirable or not.