search

label-schema / label-schema.org

Static content for Label Schema Spec
139 stars 16 forks source link

Suggestions for new label #7

Open timgriffiths opened 7 years ago

timgriffiths commented 7 years ago

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

sublimino commented 7 years ago

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

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

lpalgarvio commented 7 years ago

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

example

lpalgarvio commented 7 years ago

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,

amouat commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

pull request #22

lpalgarvio commented 7 years ago

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

pull request #24

lpalgarvio commented 7 years ago

Submitted authors issue #23 and pull request #25:

lpalgarvio commented 7 years ago

@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 commented 7 years ago

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

For regular distributions:

For base images (with no parent image):

lpalgarvio commented 7 years ago

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

lpalgarvio commented 6 years ago

36 added for vendor

lpalgarvio commented 6 years ago

@amouat @lizrice @chamilad

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

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

Could be interesting, yes. It's purpose is very different than the one i suggested, both could complement each other.

~~I'm changing my PR given that "architecture" is returned on docker inspect:~

    "Architecture": "amd64",
    "Os": "linux",

But OS information is not returned the way i was suggesting.

Would you prefer these OS-* labels be called distribution instead? I was thinking more broadly, to consider things that aren't distributions and also different operating systems.

https://github.com/label-schema/label-schema.org/pull/26

lpalgarvio commented 6 years ago

EDIT:

however,

While using grep works:

docker image inspect debian:jessie | grep "Architecture"
        "Architecture": "amd64",

Using docker image ls --filter does not.

docker image ls --filter "Architecture=amd64"
Error response from daemon: Invalid filter 'architecture'

So i still suggest keeping it.

chamilad commented 6 years ago

@lpalgarvio AFAIU distribution-scope has a different meaning than the OS-* labels you have suggested. Specifically, 

 This addresses the end-user case of internal builds vs. public content and the use case of a vendor like Red Hat that provides content streams under subscription agreements

This addresses a more business-oriented, open-ended case than the OS details. One example would be to selectively provide Images to different tiers of clients.

WDYT?