label-schema / label-schema.org Goto Github PK
View Code? Open in Web Editor NEWStatic content for Label Schema Spec
Static content for Label Schema Spec
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/"
Under the table "Build-time labels" there are a number of differences between the column "Label" and the column "Example":
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!
Is this project abandoned?
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.
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 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.
I was just thinking we should a label with the version of Docker that was used to build the image.
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
.
vcs-branch -> In case we are not always building off master
We need to indicate that this spec is now superceded by the annotations section of the OCI image spec.
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
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"
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
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?
(I think so, but the wording could perhaps be clarified.)
how is the static content licenced?
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/
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:
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 :)
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.
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.
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
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
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 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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.