Vendor description #32
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 5 commits
June 15, 2015 18:02
Change the labels to lowercase-underscore format (e.g. 'build-date') to enable cleaner formating by tools displaying this information. Follow-up on #8
Propsing two new fields to support Red Hat, ISV, and customer use cases:
* authoritative_source - The authoritative registry for an image.
- In combination with the 'name' label, this tells a user where to go and look for official updates and current versions of the image, regardless of the local tags.
* distribution_scope - The intended scope of distribution for the image.
- Allows a user to define the intended scope of distribution. 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 - which is different from the license(s) of the image content.
- In combination with the 'authoritative_source' and 'name' labels allows automatic redirect to the authoritative source.
The name should be relative to the authoritative_source so that combination of the authoritative_source, name, version and release labels should resolve to the actual image (depending on the implementation details of the protocls used).
For Docker images created by Red Hat as well as for certified images, we standardized 'name' to be the relative path for the image (e.g. 'rhel7/rhel-tools'). An actual Red Hat image can be retrieved by:
# docker pull authoritative_source+'/'+name+':'+version+'-'+release
Still refered to 'registry' rather than a neutral term.
| | vcs_type | The type of version control used by the container source. Generally one of git, hg, svn, bzr, cvs| | ||
| | vcs_url | URL of the version control repository| | ||
| | vcs_ref | A 'reference' within the version control repository; e.g. a git commit, or a subversion branch| | ||
| | authoritative_source | The authoritative location at which the image is published (image location is 'authoritative_source/name')| |
There was a problem hiding this comment.
image location is
authoritative_source/name
why are you prescribing this? It's back to tying against specific implementations like a Docker registry. What if an authoritative source is a yum repository? Better to just say (if anything) that the image name is namespaced against this source.
There was a problem hiding this comment.
I am open to generalize the language, but this is not Docker-specific at all. Please submit a PR on top of this.
|
Breaking this apart to multiple pulls would make it a lot easier to deal with. Please reopen as multiple pulls. git branch -b NEWNAME Should help you separate them out. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To address #14