Suggestion: refer to label-schema.org for examples of label usage

[lizrice]

Over at label-schema.org we've been reaching a consensus about some common keys for container labels which could be referred to by different tools.

I'm opening this issue to start a discussion about whether the OCI image spec could in some way reference label-schema - perhaps as an example of label key usage? If this is something folks are willing to see added to the spec, I'm more than happy to make a PR.

To be clear: we're not trying to suggest that a container has to have any of these labels! We're envisaging a future where tools extract metadata from a container, so having common keys could save users from having to add duplicate labels with the same information. A reference from the OCI image spec could really help establish the conventions.

Here's a list of public container images published on Docker Hub that are using label-schema labels today.

[vbatts]

This SGTM. The conventions laid out in label-schema.org are completely compatible with both the labels in the OCI Image config.md, as well as annotations et al, and to my knowledge do not conflict anywhere.

[jonboulle]

+1. Honestly I'd like to see this in the spec itself (of course always as optional guidelines, never mandatory), but I suspect not all might agree with that sentiment.

…

On 8 December 2016 at 11:38, Vincent Batts ***@***.***> wrote: This SGTM. The conventions laid out in label-schema.org are completely compatible with both the labels in the OCI Image config.md, as well as annotations et al, and to my knowledge do not conflict anywhere. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#485 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACewN1mvvmzup5sKF4MWnP_2_JU1Wf8lks5rGFyjgaJpZM4LIIjQ> .

[wking]

On Thu, Dec 08, 2016 at 11:57:08AM -0800, Jonathan Boulle wrote: Honestly I'd like to see this in the spec itself (of course always as optional guidelines, never mandatory), but I suspect not all might agree with that sentiment.

The spec already has a stub like this [1], and we may need to keep critical keys in-spec (e.g. if we use one for naming [2]). But I think it's good to push as much as possible (including the ones we define now [1]) to a separately versioned entity. Then you can drop an ill-conceived label (and major bump the label spec) without having to major bump the core image spec. I'm agnostic about whether those external label specs live under the OCI umbrella or not. [1]: https://github.com/opencontainers/image-spec/blob/656fb2f82121e8bd611b5aae4a6a3471e1bfe078/manifest.md#pre-defined-annotation-keys [2]: #438 (comment)

[stevvooe]

I'm not sure that OCI should prefer one labeling schema over another. The image format is not a packaging system and I don't think we should continue to push this idea. As it stands now, labels/annotations have been haphazardly added to the manifest with no thought to how they propagate, what they mean, provenance. Even worse, these get added to containers at runtime with no thought or care to the effect they may have (k8s load balancing?). The idea that one can mine and trust the metadata on hub images eschews any concept of provenance or security (Do I need to demonstrate this or shall I inject some bad data into microscaling.com for you?).

The main issue, as I have explained to @lizrice on many occasions, is that multiple things that are the same will be different because of arbitrary metadata.

The right approach is to have a metadata system that can collect naming, signing and other metadata at a higher-level, referring to the hash directly. This system sits above the existing objects. The provenance is clearer and we don't get the arbitrary mess that comes along with image labels. Such systems could operate independently without stepping on each others toes and without creating massive label bloat. Also, they will actually be secure.

[wking]

On Tue, Dec 20, 2016 at 01:31:56PM -0800, Stephen Day wrote: The main issue, as I have explained to @lizrice on many occasions, is that multiple things that are the same will be different because of arbitrary metadata.

The mass is in the layers, which are below this metadata in all proposals. If a manifest changes because someone's annotated their layer descriptors, it creates a new manifest blob, but that's not a lot of CAS-backend bloat.

The right approach is to have a metadata system that can collect naming, signing and other metadata at a higher-level, referring to the hash directly. This system sits _above_ the existing objects. The provenance is clearer and we don't get the arbitrary mess that comes along with image labels.

You certainly could put all of this in a CAS blob that pointed at the manifest (or the manifest-list? Or either?). That gives you an extra blob to walk, but allows you to preserve the manifest(-list) blob in the face of changing metadata. I doubt the manifest(-list) blobs are big enough for that preservation to be worth the extra blob, but it doesn't really matter either way. However, I do not see how adding a higher-level blob provides any increased provenance, increased security, or decreased “arbitrary mess” ;).

[lizrice]

There are two independent things here that shouldn't be conflated: one, the security of distribution of metadata, and two, the semantics of the metadata itself. Label-schema doesn’t make any attempt to address the first of those.

There is a logically consistent position that says metadata has no place within the image, or that it should not be defined by the image spec. But as it stands today the image spec already refers to labels and annotations as key-value pairs, so appears to take the position that there are reasons to have metadata included in the image.

In practice people are already using build-time labels today to store various metadata, and label-schema simply comes up with some semantic consistency for it. Those semantics would still be meaningful and useful whatever metadata distribution systems come to pass, and whether the metadata is built into the image or stored independently.

[RobDolinMS]

@lizrice (et. al.) Would it make sense to reference the @label-schema work hosted at http://label-schema.org/ as an informative reference in the spec?

[duglin]

OH@OCI F2F: use "title" instead of "name" as a label

[sudo-bmitch]

Doing a bit of house keeping. I believe this was resolved by #676. If that's not the case, feel free to follow up and this can be reopened.