opencontainers
*: support manifest lists
Currently all of the tooling only really supports tags that reference manifests (not manifest lists). The main reason for this is that I'm not really sure how to implement manifest list handling. Should we just take the current OS and architecture (and should that be taken from runtime.GOOS which is not entirely accurate, or from some other source?). Or we could just mandate that --os and --arch be specified with every call (this is annoying).
Not to mention how should we handle repacking? Should we not allow repacking over a different manifest than the one that was used to extract the damn thing (which is how the current implementation works)?
The main issue here is that we have to come up with a way of figuring out which manifest we are interested in. Exposing the checks for os and architecture (and variant and os.version) are easy. The problem is extracting the right manifest for os.features and features -- while we could just detect these we need to have a better idea which one we want.
Possibly the best way of handling this is to just implement umoci info (#11) and then just allow users to specify which index they want (we can pretty-print everything in the output). If nothing is specified we just extract the first one that matches the host.
So here's my current view:
-
Make
umoci statprovide information about each manifest in a manifest list (just saying what the description is). -
Add an extra field to the formatting of
--imageto allow you to specify which index of a manifest list you want to mess around with.
Do you have any interest in getting index functionality up and running? I might be able to lend a hand!
I was looking into using umoci to create test cases for http://github.com/atlaskerr/distribution-client and I'd like to test index logic.
So, since opening the issue the status has changed slightly. Right now, umoci supports recursively looking through indexes to find a manifest -- all the code is in place for that.
The main issue is that (in the CLI front-end) there's no way to say (in the case of ambiguity, like a multi-arch image) what manifest you'd prefer. I was thinking of just making it use the host, but given the fun CLI spaghetti that skopeo has turned into (in this regard) it'd be nicer if the CLI UX was more reasonable. Docker just uses the current host, but given the need for cross-compiling this is a bit of a pain.
In addition, umoci doesn't know how to create a new multi-arch image. It can modify one that already exists, but it doesn't know how to "upgrade" a single-arch image to a multi-arch one. This would be quite trivial to add, but without the first part (a CLI for extraction that makes sense) the CLI for the creation similarly wouldn't make sense.
I can work on this when I get back from LCA tomorrow.
The reason why I'm focusing so much on the CLI here is because we have a CLI compatibility guarantee (for KIWI) and thus I'm very cautious about making CLI UX decisions that might prove a bad idea in the future.
Yeah that does seem like a pickle lol. Let me know if I can be of any help.
FYI I don't need the index functionality immediately. Would you want hold off and get together next month to come up with a game plan?
Sorry, get together where? Or do you mean like a conf call? I wouldn't mind that no.
I guess it strongly depends on which features you really need versus the ones that would be useful. I've been playing with a patch to add the "upgrade" support but the real problem is it's really hard to come up with an interface that isn't interactive (and for the KIWI usecase, we need to be scriptable).
Call, email, this thread...whatever's easiest for you. I'd like some way to use umoci to work with creating indexes. I know you were saying that you wanted to have the hard stuff done before you implemented creation; and that's fine, but I don't want you to spend a lot of time working on this if it's just for me since my use-case is really small.