config: add annotations

[vbatts]

there are annotations in the manifest, but having the same path
available for configuration specifc annotations seems logical as well.

Relates to #371

Signed-off-by: Vincent Batts [email protected]

[runcom]

+1

[jonboulle]

LGTM but I wonder more and more about the purpose/sanity of this config
object - does it still reflect what's in a modern docker image?does it make
any sense to define it here without a process to convert between it and the
runtime spec? (I think this conversation has already started on another
issue but imo the topic is quite unresolved)

Antonio Murdaca [email protected] schrieb am Do., 6. Okt. 2016,
10:25:

+1

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#372 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACewNz2me-RI1ybzXXi-czNFslvY4uFMks5qxLBvgaJpZM4KPq8d
.

[vbatts]

this particular piece is overlapped with #371, as the .config.Labels field is existing in the Docker config, even though is unspecified.
Does this annotations accomplish something separate from Labels? no, not really.
Is this annotations more consistent with the runtime and image manifests? yes.

I'm two ways about it.

[wking]

On Thu, Oct 06, 2016 at 01:40:03AM -0700, Jonathan Boulle wrote:

LGTM but I wonder more and more about the purpose/sanity of this
config object - does it still reflect what's in a modern docker
image?does it make any sense to define it here without a process to
convert between it and the runtime spec?

There is discussion on the conversion process and sanity thereof in
#87, which was moved to opencontainers/image-tools#25 although I think
whether we want an image-spec-specific config and how it gets
translated are still image-spec issues 1. And my personal
preference is to just ship a runtime-spec config.json and sanitize it
on unpacking (opencontainers/runtime-tools#219).

But as long as we have an image-spec-specific config based on Docker's
implementation, I think it makes sense to have something that supports
lossless translation (so either this PR or #371). I don't think
translating between field names will be a big deal, but there has been
push-back against translating in the past 2.

[philips]

Can we hold on this until post v1.0.0? Is there urgency here?

[vbatts]

@philips well, this is discovered as I'm working with folks to have OCI image support, and where to stash their arbitrary data. Can they just make the field themselves and do this? sure.
But this would keep the wording consistent across all the OCI annotations usage.

[philips]

@vbatts why does it need to be in the config and not the manifest?

[vbatts]

only urgency is that it makes more sense in the config, than the manifest.
but also consistency with the runtime-spec config.

On Mon, Oct 24, 2016 at 3:07 PM, Brandon Philips [email protected]
wrote:

@vbatts https://github.com/vbatts why does it need to be in the config
and not the manifest?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#372 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEF6ZJ6xzFpfWd58CCqZnqE-EjoFSXRks5q3QILgaJpZM4KPq8d
.

[vbatts]

even though I want to see this consistency, I'm tagging this for post-v1.0.0.
LABELS (#371) needs to be in for v1 for compatibility though.

[vbatts]

closing this for now. The config has labels, which is effectively equivalent and is consistent with current docker implementation.