Suggestions for new label

[timgriffiths]

vcs-branch -> In case we are not always building off master

[sublimino]

@timgriffiths I wonder if this is needed when one can always

git reset --hard <revision hash in org.label-schema.vcs-ref>?

[lpalgarvio]

license and archicture labels are also missing, along with many defined here:
https://github.com/projectatomic/ContainerApplicationGenericLabels

example
- "license=GPLv3"
- "architecture=amd64"

[lpalgarvio]

also something for the distribution, if used as base image.
LSB is the standard set of libraries and utils for discovering information about your linux distribution.

$ lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description: Linux Mint 17.3 Rosa
Release: 17.3
Codename: rosa

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

so,

• "os-name=Ubuntu"
• "os-version=14.04.5 LTS, Trusty Tahr"
• "os-id=ubuntu"
• "os-version-id=14.04"

[amouat]

Isn't architecture defined at a higher level? I'm sure it's in the image spec or something.

Licence should definitely be there. Surprised we missed that one. Also OS stuff LGTM.

[lizrice]

Yes I think you're right @amouat, architecture has its own field in the image

We left licence out for rc1 because there's some debate as to what it actually means (is it a license for the source code or the binary?) but it would be good to hammer that out, I'd be all for getting it into the document. FWIW a lot of existing images have a license label already (albeit the vast majority that have it are simply inheriting it from the Centos image).

On the OS things, maybe I am missing the point but I'm not sure we can usefully specify labels that are really only usable by the OS image maintainers - this wouldn't be something that the majority of (non-OS) maintainers could use, right? And I'm not sure what the use case is for a generic label for this info. If, say, the Ubuntu maintainers decide to label their image with "org.ubuntu.version=14.04.5 LTS, Trusty Tahr", the org.ubuntu.version key (which I just made up as an example) would be just as useful to a developer or operator. I think?

On a more pragmatic point, even if we document a convention that OS image maintainers should label using the key "org.label-schema.os-version" it's pretty meaningless unless they all buy into it.

[amouat]

Yes, I forgot about the licence debate. It's pretty serious, as child images will inherit the label and could be wrongly assumed to be issued under that licence. There would need to be a way of saying exactly what in the image falls under the licence.

We would need to work with the creators of base (or OS) images in order to get their buy-in, but it seems useful and plausible to me.

[chamilad]

Regarding license, can't we enable it and keep the conflicting cases to be resolved at the user end when that becomes significant? Enabling it, accepting the possible open-ended of it can allow images that use proper licensing to use the label.

Also IMO, distribution-scope [1] is also a good candidate to be introduced.

[1] - https://github.com/projectatomic/ContainerApplicationGenericLabels#distribution-scope

[lpalgarvio]

This format is becoming standard: SPDX
https://spdx.org/licenses/

It's being used by php composer, npm and bower:
https://getcomposer.org/doc/04-schema.md#license

[lpalgarvio]

org.label-schema.license=GPL-3.0

Can we get this in?
I think the responsibility of licenses is up to the people who create dockerfiles and docker-compose.yml files, not the scope of label-schema. It seems plausible that the license of the source code and the binary image should be the same, and that these should be conformant with the software that it uses, be it the OS or the programming language stack. But label-schema can't condone or force any behaviour. Regardless, most labels are about image generation or the image itself, so this can be assumed/stated in the specification.

I've submitted a pull request
#21

[lpalgarvio]

Added two more:
org.label-schema.vcs-branch=master
org.label-schema.vcs-tag=v1.0

pull request #22

[lpalgarvio]

Another easy one:
org.label-schema.keywords=abc,def,xyz

pull request #24

[lpalgarvio]

Submitted authors issue #23 and pull request #25:

• org.label-schema.authors.john.name = "John Doe"
• org.label-schema.authors.john.email = "john@example.com"
• org.label-schema.authors.john.homepage = "http://john.example.com"
• org.label-schema.authors.john.role = "DevOps"

[lpalgarvio]

@lizrice @amouat: architecture has its own field in the image

yes, but you can only see it on images that were already built.
you can't know this when reading only the dockerfile or the docker-compose.yml files.

OS labels are useful for people who want to contribute, reuse or use these images.
They need to be able to see both from source code (dockerfiles/docker-compose.yml) and binary perspective what the image will be using. As you know, Debian, CentOS and Alpine are all very different (ie, apt vs yum vs apk) and so are their software (ie, httpd 2.2 on Debian 7 vs 2.4 on Debian 8).

A custom image that is based on no distribution can state that as well.

[lpalgarvio]

Added pull request #26 for os-id, os-version-id and os-architecture.

For regular distributions:

• org.label-schema.os-id = "ubuntu"
• org.label-schema.os-version-id = "14.04"
• org.label-schema.os-architecture = "amd64"

For base images (with no parent image):

• org.label-schema.os-id = "custom"
• org.label-schema.os-version-id = "none"
• org.label-schema.os-architecture = "amd64"

[lpalgarvio]

You can view all these proposals added and combined here:
https://github.com/lpalgarvio/label-schema.org/blob/merges/rc1.md