projectatomic / containerapplicationgenericlabels Goto Github PK

Hi, I wonder if there is any interest in labelling images with metadata relating to the source code repository from which it was built. Since with docker images the Dockerfile is only one piece of the puzzle (and other scripts or artifacts might be ADDed in, RUN, etc.) and typically these are collected together in a version control repository, to find out precisely what was used to build an image, one may need to refer to the repository and to a specific commit within.

So it might be useful to label with at least the commit-id, but probably also a repository URL, and if it can't be inferred from the URL, a repository type.

What is the reason to have the name label if it matches with the image name? Both OS and Kubernetes have display-name label which provides more information in human-readable form about the image content. For example: https://github.com/openshift/sti-ruby/blob/master/2.2/Dockerfile#L13

Can the image have a license? I feel like this is pretty problematic when most images are composed of multiple pieces of various software with different licenses.

The help label is used by atomic, but is not documented in this repository. IMO it also caused the issue tracked in https://pagure.io/atomic-wg/issue/267, which was also reported to projectatomic/atomic#967.
Once the dilemma is resolved, we should document this label properly here.

What about having a label for syscall (system call) tables. Imagine that I want to verify that the user space packaged up in the container image can run on a given container host?

For example, what about verifying that a Fedora 22 container image can or can't run on a Fedora 18 container host?

Describing environment variables shouldn't be exclusive to the nulecule spec https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/projectatomic/labels.md

https://github.com/opencontainers/image-spec/blob/master/annotations.md

We should introduce a substitution for MAINTAINER instruction:

moby/moby#25466

What would it be? maintainer, contact, upstream?

In each section the label capitalization is different, between all caps, CamelCase and lower case. I would suggest that we just standardize on lowercase as it is common for things like urls, programming language variable names, etc.

I've totally missed the /vendor folder. Links should be included in the main readme.

I havent seen it on the list...

I'm thinking what authoritative-source label should be for images that are located on Docker Hub at https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/labels.md.

If authoritative-source is only meant to be able to reconstruct the docker pull ... command, if authoritative-source is empty, then it results in correct docker pull ... command in case of docker hub hosted images. So, for those images the label authoritative-source shouldn't be required.

I would like to propose a Build label that contains a hint how to build the docker image. This label will carry some free text.

Example:

# Dockerfile
LABEL Build docker build --rm --tag myimage .

and a bash alias docker-build='$(grep LABEL Dockerfile | grep Build | cut -d " " -f 3- )'

The "usage" label has recently turned up in rhel75 images:

            "usage": "This image is very generic and does not serve a single use case. Use it as a base to build your own images.",

This caught us by surprise because we hadn't heard of this label before. I wonder whether, if it's going to be used across a bunch of RH images, it ought to be described in this spec.

Docker images have a "maintainer" field, and this spec introduces a "Vendor" label. What's the difference? Is one an individual while one is an organization? Should it be an email address, a URL, or is the format unspecified?

Is it authoritative-source or authoritative-source-url?

Are there any reasons why the labels are authoritative_source and not authoritative-source ? Kubernetes and OpenShift labels seems to both follow the foo-bar case. Also the Docker upstream promote the "dash" case: https://docs.docker.com/userguide/labels-custom-metadata/

Having a set of labels be available to support intents as described in moby/moby#11187.

Do we have to worry about datatypes for labels? - string vs json blob?

The red hat vendor page does not list labels in tabular format, as the top-level page does, and as a consequence is far harder to read. It would be good to normalise on either consistently using tables or not, with my preference being the former.

The purpose of the TEST label is for the image authors to be able to specify a self-contained check to figure out whether the image can run correctly on the given host.

Use case:

FROM fedora:22
LABEL TEST='sh -c "([ -c /dev/kvm ] && [ \"$(stat -c \"%a\" /dev/kvm)\" -eq "666\" ]) || (echo \"Bad KVM device\"; exit 1)"'

$ atomic test my-kvm-image
ERROR: Bad KVM device

I would like to propose a License label that contains license information about the image. It will carry string containing license information. Could be simply the name of the license (GPLv2.1), or a comma separated list of several different licenses (GPLv2.1, Apache-2.0). License Names should be the short name from the osi.

All images should contain a License Label to easy use of containers for compliance and governance sensitive organizations.

Hi,
I'm now working on a way how to put changelog information to OpenShift Xpaas JBoss MW images and I'd like to see some more standard way to attach some release notes/changelog to an image even for regular container application.

Ideally it should be two labels like:

In practice there are different kinds of container images:

• Basic bootstrap such as a base image and runtimes such JBoss EAP, Python, etc. These images are meant for building upon.
• There are individual service components such as e.g. a mariadb image delivered by an ISV, or a db-cluster atomic-app image. These are meant to be aggregated into applications, but by themselves usually would not be modified beyond parameterization.
• We have top-level applications, that just will be parameterized and the run - e.g. a containerized delivery of Kolab. Could be a single, multi-service container for an existing enterprise app or a full atomic-app. These ususally will just be installed, parameterized and run.
• There sometimes are containers that are simply 'hidden' components of something else - e.g. a component of an atomic-app or something like the openshift pod container, that is not useful on it's own and would only be used when pulled in by something else.

It would be a good thing to capture this classification in the meta-data to e.g. be able to filter search on it.

Please drop the authoritative-source-url label from the specification:

• It is easy for this to become stale over time as organizations rename their public-facing registries.
• This label cannot support multiple registries.
• It has never been authoritative from the point of view of trust. It's easy for anyone to forge the value, and we should encourage container users to authenticate their images with cryptographic means instead.

There are two examples of using these labels for container configuration? I sort of get the use case for the min memory label but max memory doesn't seem like a realistic concern.

Can whoever wrote the container configuration section explain a few more use cases of what this might be used for?

Also, why are the container that it is formatted as a reverse DNS oid even though these labels are presumably scoped to a single image?

Based on some of the discussions on this proposal and subsequent pull requests, there appear to be some use cases for labels that are too specific to try to standardize (e.g. this came up in the authoritative_source and distribution_scope context).

We should define a standard for naming vendor-specific labels.

The document states that these two labels are required:

• io.k8s.display-name (Name of the container displayed in Kubernetes)
• io.openshift.tags (tags used by searching engine, e.g. "builder,php,php56,rh-php56")

Is that true? Why are those being enforced?

When I open this document I am confused with what labels will Red Hat images have. There are two sets, Naming and versioning related and Other labels: some of the labels are required, some are optional, some does not specify anything.

What labels should users of Red Hat images expect?

@riekrh @aweiteka @rhatdan

Are those the same thing? Or is one an url (of registry's fronted) and the other registry URI to use with pull?

May want to denote LABEL semantics on layered images.

e.g. - latest label overrides..? etc.

I am rather concerned about the current format of the install/uninstall commands as described in the atomic command. As implemented currently it relies on the host OS having a particular runtime available and then gives a script in the container access to the full host root and says "good luck".

Make script runtime/host agnostic

To fix this first concern perhaps have this label spec that there be a defined API on what sort of environment the "install executable" can expect to be operating in, for example having a /media/host-root mount point, etc. Then the container doesn't need to expect any details about the host and instead the relies on the host to create the correct environment.

Re-evaluate using a script

That said, I think that this whole install/uninstall thing is going to get us into a rather crazy place where containers are going to have to know what type of Linux it is installing to. Instead we could say what are the sorts of things we will need to configure and make them explicit.

For example in the install script in the blog post the command only does a handful of things:

• Puts down some configuration files via templates
• Enables the systemd unit file

Perhaps instead the container should describe those configuration files as metadata and the installer command should pick/choose the files that are appropriate for the host? So there would be a freedesktop.org/systemd/unit-template="[Service]... label or perhaps a label that is template-linux-host-configuration-dir=/usr/share/app-host-template.

I propose this because I am a bit skeptical that the API should be defined as a executable running over the root. That seems likely to take us back to a place where every upstream needs to worry about the finicky details of the host OS.

Hi, I'd like to have a way of describing that an image is not a docker image, but e.g. rkt. My use case is [1], where I want to be able to express that a Nulecule application doesn't necessarily consist exclusively of Docker images.

[1] https://github.com/bkabrda/nulecule-images/

Many products we want to put into images - as well as images as an entity themselves usually go through a pre-production lifecycle from experimental over beta, tech-preview, to production ready. Some are development-only or community editions vs fully supported. It would be helpful to have the ability to describe this in metadata.

The spec includes the following example:

I am not sure if this is a bad example or if I don't understand the idea behind it. If I were building a webserver image, I would not apply a label called "something.webserver.memory.max". I would just apply a "memory.max" label, and it would be for the webserver because that is the image to which it is applied. There wouldn't be any need to encode this fact in the name of the label.

If the idea here is that an organization might want to namespace labels because they want to avoid conflicts with labels used at other organizations that makes sense, but using com.example.memory.max and com.example.memory.min might better illustrate the idea (because here namespacing is used exclusively as an organizational differentiator).

See:

projectatomic/atomic#43

We should likely move that issue here.

I feel like having whitespace in the name might cause troubles.

Current keys in metadata use camelcase. I would prefer being consistent.

There are some nice existing OpenShift labels which are missing: https://docs.openshift.com/enterprise/3.0/creating_images/metadata.html

Per vendor/redhat/names.md we accept '--' in the build image name. This causes a failure in docker v1.8+.

$ rpm -q docker
docker-1.8.1-3.git32b8b25.fc22.x86_64
$ cat /etc/redhat-release 
Fedora release 22 (Twenty Two)
$ sudo docker build -t test/atomicapp--name .
repository name component must match "[a-z0-9]+(?:[._-][a-z0-9]+)*"
$ sudo docker build -t test/atomicapp-name .
Sending build context to Docker daemon  2.08 MB
Step 0 : FROM centos:centos7
...