label-schema / label-schema.org Goto Github PK

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

As I think about this, I was considering adding a new label that would be great to see on images globally. Every time FROM is called, I would like to append to a genesis value.
For example:
FROM alpine:latest
...
COMMIT alpine.altered:latest
FROM alpine.altered:latest
...
COMMIT alpine-with-netconf:latest

ENV image-genesis="alpine:latest;alpine.altered:latest;alpine-with-netconf:latest"

May or may not be useful for this standard, but I thought I'd chime in.

I really like the idea of providing a standard for this, so top marks team 👍

Should information on the position of LABEL tags in the Dockerfile be explicitly defined in the spec?

This would remove any confusion / speculation. Perhaps adding a blanket rule of "Build time LABEL tags should always be the last thing in the Dockerfile" would probably suffice, but then there are more "permanent" LABEL tags that would be safe at the start, such as LABEL org.label-schema.name

It is difficult to modify docker.cmd by the consumer of the label, which meant I didn't use it for Whalebrew. See here for more details: whalebrew/whalebrew#6

Instead, I opted for specific labels for each thing I wanted to configure. Eg. the location to mount each volume, the port to expose each port as, and so on. See here: https://github.com/bfirsh/whalebrew#configuration-1

This means I can construct and add Docker options at runtime, and is much safer because it doesn't allow arbitrary options to be passed. Also, it could potentially work with rkt too.

Hello,

Accordingly to docker, the label notation has this guideline:

Authors of third-party tools should prefix each label key with the reverse DNS notation of a domain they own, such as com.example.some-label.

How do you view this for cases that would have additional levels of keys, ie, org.label-schema.mykey.mysubkey?

Example:
org.label-schema.authors.author.name

The subdomain authors doesn't necessarily exist...

What would be your official statement / decision so i can adjust accordingly the PRs that I've been proposing? Would they be allowed or disallowed?

https://docs.docker.com/engine/userguide/labels-custom-metadata/

I was just thinking we should a label with the version of Docker that was used to build the image.

As per
https://docs.docker.com/compose/compose-file/

Example:

--
version: '2'
services:
  test:
    labels:
      - "org.label-schema.schema-version=1.0"
      - "org.label-schema.name=e.g. Example project name"
      - "org.label-schema.description=Example project description in 300 chars or less"
      - "org.label-schema.vendor=e.g. ACME Inc"
      - "org.label-schema.url=e.g. https://www.example.com/"
      - "org.label-schema.vcs-ref=$VCS_REF"
      - "org.label-schema.vcs-url=e.g. https://github.com/microscaling/microscaling"
      - "org.label-schema.version=$VERSION"
      - "org.label-schema.build-date=$BUILD_DATE"

Is this project abandoned?

We need to indicate that this spec is now superceded by the annotations section of the OCI image spec.

Hi

Since the MAINTAINER instruction has been deprecated, what are your thoughts on adding a author/maintainer label into label schema?

org.label-schema.maintainer="John Doe [email protected]"

Thanks

Under the table "Build-time labels" there are a number of differences between the column "Label" and the column "Example":

1. Label "docker.cmd.debug", Example "docker.debug-shell"
2. Label "docker.params", Example "docker.param"
3. Label "rkt.cmd.debug", Example "rkt.debug-shell"
4. Label "rkt.params", Example "rkt.param"

And finally, a random typo under the heading "Label semantics", paragraph 2:
"From the absence of the label one can not infere there is no such source."
.. should be:
"From the absence of the label one can not infer there is no such source."

Great idea, love the project. Thanks!

Just wanted to put here some thoughts for labels supporting the reproducible research efforts that many people use Docker for. Feedback welcome! If there is some support/consensus, I'd be happy to create a PR to discuss concrete details.

• repository-url could point to a repository or archive, where the image is preserved (long term), e.g. Zenodo, OSF, figshare, ..., e.g. org.label-schema.repository-url = "https://zenodo.org/record/45983"
• repository-doi as above, but with a DOI, e.g. org.label-schema.repository-doi = "10.5281/zenodo.45983"
• publication-doi is the DOI of a scientific publication, e.g. org.label-schema.publication-doi = "10.1145/2851581.2892483"

The docker.cmd.test label requires you to pass an absolute image name. The image being tested might be under a different name or tag.

A much more useful label for me would be a path to an executable inside the container to run. This would be portable across runtimes, and allow the consumer of the label to easily pass their own options, etc.

One thing that differs between containerized apps is the host kernel. Would you consider it worthwhile to track this by adding a label org.label-schema.kernel.vendor-version?
It would include information about the kernel version which the vendor used when creating/testing the image, for informative reason. This might only be relevant in the long run, naturally, as breaking changes in kernels are rare.

A potential content would be the output of cat /proc/version such as Linux version 4.4.0-75-generic (buildd@lgw01-21) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017, or uname -r which on my system gives 4.4.0-75-generic.

Hello

We have Vendor, but Authors and/or Maintainers is missing in the specification.
Can we take a look at what's done in PHP Composer?

https://getcomposer.org/doc/04-schema.md#authors
`authors#

The authors of the package. This is an array of objects.

Each author object can have following properties:

name: The author's name. Usually their real name.
email: The author's email address.
homepage: An URL to the author's website.
role: The author's role in the project (e.g. developer or translator)

An example:

{
"authors": [
{
"name": "Nils Adermann",
"email": "[email protected]",
"homepage": "http://www.naderman.de",
"role": "Developer"
},
{
"name": "Jordi Boggiano",
"email": "[email protected]",
"homepage": "http://seld.be",
"role": "Developer"
}
]
}`

Hey, first of all, I like the idea of labels and like even more on a "common" way of specifying them but how would your schema respond to this use case ?
Image these repos:

• application/pikachu (vX.X.X)
• docker/pikachu (vY.Y.Y)

Where application/pikachu contains the source for the pikachu app and docker/pikachu contains the Dockerfile for the pikachu container. Imagine now that the pikachu app has a dependency to ca-certificates in version vZ.Z.Z
So this would be some of the labels:

{
  "build-date" = "xxxxxxx",
  "name": "pikachu",
  "description": "foo bar stuff",
  "vcs-url": "[git_url]/docker/pikachu",
  "vcs-ref": "279FA63",
  "version": "vY.Y.Y"
  "vendor": "Pokemon"
}

Now in this case, I don't know which version of ca-certificates is installed nor do I know which version of pikachu app is installed.
So wouldn't it be better to add something like this:

{
  "build-date" = "xxxxxxx",
  "name": "pikachu",
  "description": "foo bar stuff",
  "vcs-url": "[git_url]/docker/pikachu",
  "vcs-ref": "279FA63",
  "version": "vY.Y.Y"
  "vendor": "Pokemon"
  "applications": {
    "pikachu" : {
      "vcs_url": "[git_url]/application/pikachu",
      "vcs_ref": "[commit_id]",
      "version": "vX.X.X"
    },
    "ca-certificates": {
      "version": "vZ.Z.Z"
    }
  }
}

This would allow to know what's actually in the image. It might also be great to have more info in the labels of the image it is based on since that could also be a changing factor if you reference for example: ubuntu:latest. Having the base image ID in there would garantee that you'll be able to rebuild that image exactly how it is

Like I said this is just an example of wht I'd like to see if there is some standardization of labels that would be done :)

What about a label that provides the "main" or "normative" source for an image, e.g. a link to Docker Hub or Quay?

org.label-schema.registry-url = "https://hub.docker.com/_/nginx/"

how is the static content licenced?

An example might be a scientific pipeline with multiple tools inside a pipeline. Could org.label-schema.version be set to be a list of tuples? Here is an example Dockerfile for genome assembly software in bioinformatics:

https://github.com/bioboxes/shovill/blob/release/0.4/Dockerfile

hey label-schema team! I'm one of the developers for Singularity (http://singularity.lbl.gov) which is a container that is primarily for HPC and science (doesn't have security risks of Docker). I've seen your schema used for some Docker containers, and would be interested to follow suit for Singularity. Right now our default metadata labels are rather general:

singularity inspect --json centos-7.img
{
    "data": {
        "attributes": {
            "labels": {
                "build-date": "20170605",
                "vendor": "CentOS",
                "name": "CentOS Base Image",
                "license": "GPLv2"
            }
        },
        "type": "container"
    }
}

the above outputs the JSON API spec, but the labels itself is just a flat dictionary:

singularity inspect centos-7.img
 {
    "build-date": "20170605",
    "vendor": "CentOS",
    "name": "CentOS Base Image",
    "license": "GPLv2"
}

We are adding modular application support for inside the images, and in addition to a structural format, since we will have labels for each internal module (and the container) it would be really great to have standard labels! This might also help issue #31. What are your thoughts? What is the process we could go about this? What I would propose to do is make a first pass at a set of singularity labels here --> https://docs.google.com/document/d/1k0I1M1BIR1aqGxVVJrow_Gj3T8BXHco-oqnreYKuxL8/edit?usp=sharing (this is the document we are working on the internal structure) and then if you like, I can PR something here? Do you have a spec / definitions outside of this repo?

Generally, scientists need more information about container metrics that are important for reproducibility. This would mean things like software versioning and hardware intended for, some metadata about the authors possibly, and labels specific to the modules inside (and this is a hard territory to venture into, but also workflow type things like inputs and outputs). The goal would be to find a container, know how it was made, what it is intended for and how to run it,and then be able to do so.

Looking forward to chatting with you!

The text for docker.cmd.text says:

How to run the bundled test-suite for the image under the Docker runtime. MUST execute tests then exit, returning output on stdout and exit with a non-zero exit code on failure

It it conceivable that a test suite might only print errors on stderr, and nothing on stdout.

Also is the intent that all these are MUSTs?

• execute tests then exit
• returning output on stdout
• exit with a non-zero exit code on failure

(I think so, but the wording could perhaps be clarified.)

As referenced from your introduction, the Project Atomic folks have a similar project in ContainerApplicationGenericLabels. I'm curious if you've interacted with them at all and discussed collaborating or merging? It would be great to have it consolidated in a single effort.

SE4 is a convention for standard API endpoints for retrieving status and healthcheck info.

I think a label-schema label saying this image follows the SE4 convention could be very useful. It probably needs to be an "experimental" label since the SE4 convention is new and won't apply to all images.

The http://label-schema.org/rc1/ page doesn't specify when it was published or that is superceded by the OCI spec.

It might be useful to add a similar snippet that is currently in the README to webpage

This project is no longer actively maintained. Visit http://label-schema.org for more information about the legacy label-schema project, and go to the OCI Image Spec for future label definitions.