image-layout: remove support for nested index #718
Conversation
Signed-off-by: Akihiro Suda <[email protected]>
AkihiroSuda
force-pushed
the
remove-nested-index
branch
from
19fb6ce
to
c11e3ef
Compare
|
This is from when the "index" was a separate entity from the manifest-list.
Now that they're combined, perhaps it does not make sense, but it is not
disallowed. One might have a "fat manifest" to group various manifests, and
this would be displayed in the `index.json` as an index itself. A bit
recursive, sure, but not an invalid use-case.
…On Wed, Aug 2, 2017 at 5:00 AM Jonathan Boulle ***@***.***> wrote:
***@***.**** approved this pull request.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#718 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEF6U_Cl7tht7zhslxN4OyCR--GsW-5ks5sUDqcgaJpZM4Oqo9l>
.
|
|
This is a completely valid configuration. As @vbatts said, imagine packing an image with a multi-platform image. Remember that refs on indexes are only valid when present in @AkihiroSuda If there is a use case I'm misunderstanding here, let me know, but I'm going to close this PR. |
|
@stevvooe but how does that use case involve an index referring to another index? e.g. in the example here it refers to two manifests directly
not sure what this means, can you link me to some part of the spec that illustrates this? |
|
On Wed, Aug 02, 2017 at 09:16:48AM -0700, Jonathan Boulle wrote:
… but how does that use case involve an index referring to another
index?
Before #546, what we now call “an index” was known as “a manifest
list”. That schema applies to index.json, but it can also apply to
blobs in CAS. And content using the
application/vnd.oci.image.index.v1+json media type can reference other
blobs using that same media type. For example, you might have [1] in
CAS (as sha256:f808ffe92ab277b20078353645cf0cc3c82c28e3), and then an
entry in index.json like:
{
"mediaType": "application/vnd.oci.image.index.v1+json",
"size": 683,
"digest": "sha256:f808ffe92ab277b20078353645cf0cc3c82c28e3",
"annotations": {
"org.opencontainers.image.ref.name": "1.0.0",
}
}
> Remember that refs on indexes are only valid when present in
> index.json.
not sure what this means, can you link me to some part of the spec
that illustrates this?
I think he's referring to [2]:
[org.opencontainers.image.ref.name] SHOULD only be considered valid
when on descriptors on `index.json` within image layout.
In my example above, that means there's probably no point to setting
org.opencontainers.image.ref.name in
sha256:f808ffe92ab277b20078353645cf0cc3c82c28e3, which is stored in
CAS.
[1]: https://github.com/opencontainers/image-spec/blob/v1.0.0/image-index.md#example-image-index
[2]: https://github.com/opencontainers/image-spec/blame/v1.0.0/annotations.md#L32
|
I'm not sure I understand the distinction. What does problem does this PR address? Could you elaborate?
|
The example you gave is "packing an image with a multi-platform image.". That example is illustrated in (the example I linked to](https://github.com/opencontainers/image-spec/blame/710038243d857231f17df1c3f4c10850154bd1f7/image-index.md#L93) which is an image index pointing to two image manifests (i.e. both of In contrast, the image index example in the image layout document points to one image manifest and one image index (i.e. one of It is unclear to me and apparently others what the use case of the latter is. Furthermore, it is "soft contradicted" by the guidance in the image index documentation itself which suggests that implementations should be prepared to have indices point to image manifests - https://github.com/opencontainers/image-spec/blame/710038243d857231f17df1c3f4c10850154bd1f7/image-index.md#L35 I don't think refs are relevant to this specific discussion. |
|
On Fri, Aug 04, 2017 at 12:31:59PM +0000, Jonathan Boulle wrote:
It is unclear to me and apparently others what the use case of the
_latter_ is.
Say you want to provide an image-layout providing a Foo 1.0.0 image
for both amd64 and ppc64. One option is to use per-platform names
(e.g. 1.0.0-amd64 and 1.0.0-ppc64). That is going to be the most
portable approach, but it's a bit of a pain for the consumer, since
they need to figure out which name to use.
Another option is to use two
application/vnd.oci.image.manifest.v1+json entries in index.json, both
of which have org.opencontainers.image.ref.name set to 1.0.0 but which
have different platform information. That would work, except that
some implementations may decide to error out [1,2] or pick the first
entry regardless of platform [3] because they can't decide between the
two names.
Another option is to use a single
application/vnd.oci.image.index.v1+json in index.json which has
org.opencontainers.image.ref.name set to 1.0.0. Then the
implementation can retrieve that index from CAS, and select the
appropriate manifest based on the platform metadata in its manifests
array. This is the nested-index use case.
Furthermore, it is "soft contradicted" by the guidance in the image
index documentation itself which suggests that implementations
should be prepared to have indices point to _image manifests_…
Right. This is the potential portability issue with the nested-index
approach. Folks who wanted a single name across multiple platforms
will have to pick *something* that image-spec does not require support
for, and it's up to them whether they want to prefer implementations
that support duplicate names in index.json or implementations that
support nested indexes.
[1]: #581 (comment)
[2]: #588 (comment)
[3]: opencontainers/image-tools#164 (comment)
|
Signed-off-by: Akihiro Suda [email protected]
discussed in #716