Re: Docker image naming scheme


Ed Warnicke (eaw) <eaw@...>
 

Daniel,
Thank you for taking a swag at this :)
Overall I like your structure very much, but do have a question about the use of the ‘:’
Is such a ‘:’ use the convention in docker-land? Does it convert to filenames on a filesystem?
(I ask, because while ‘:’ is a perfectly valid character in a posix path segment… I know its effectively
used a a special character by lots of tools… and so am curious :) )

Ed

On Nov 18, 2014, at 10:03 AM, Daniel Farrell <dfarrell@...> wrote:

Hello TSC!

The Integration team has been working to develop a naming scheme for OpenDaylight Docker images. We're under the impression that we should get your approval, as you oversee naming-related things. This email describes our proposal.

Note that I'll use these terms when describing a name: ${org}/${repo}:${tag}. A particular ${org}/${repo}:${tag} is an image.

Also note that I'm assuming we're going to convert the OpenDaylight DockerHub account[1] from a user to an org.

Proposed naming scheme:

The org name would be opendaylight, of course.

In keeping with Docker conventions, the repo part of the namespace would encourage layering. For example, we would build on an OS image (Debian, Fedora...) to create an empty Karaf image. Other ODL folks would then build on that Karaf image to create images that are suitable for various use cases (DLUX-ready, WCBench-ready, <your-feature-here ready>...). Projects might be best served by choosing a repo name that matches their existing "user-facing" feature name, like L2switch + UI = l2switch-ui. Generally, we suggest that projects use their judgment to create names that are a balance between descriptive and short. Users will actually have to type these names fairly regularly.

Tags would be used to show versions. For the empty Karaf repo, they would follow the existing version tags of the Karaf distributions:

opendaylight/karaf:0.2.0-helium
opendaylight/karaf:0.2.1-helium
opendaylight/karaf:0.2.2-helium
opendaylight/karaf:0.2.1-snapshot
opendaylight/karaf:0.2.2-snapshot
opendaylight/karaf:0.3.0-snapshot

Other repos, like one that's configured to work with WCBench, would likely use more Docker-standard tags like :latest, :stable and :dev.

Examples:

# Stored on DockerHub
debian:7 <- opendaylight/karaf:0.2.1-helium <- opendaylight/wcbench:stable
debian:7 <- opendaylight/karaf:0.3.0-snapshot <- opendaylight/wcbench:latest

# Built on my local system for testing
debian:7 <- opendaylight/karaf:0.3.0-snapshot <- opendaylight/wcbench:dev

Dockerfiles would live in directories under integration/packaging/docker[2]. A future directory structure might look like this:

integration/packaging/docker/
- README
- karaf/
-- README
-- 0.2.0-helium/
--- Dockerfile
--- README
-- 0.2.1-helium/
--- Dockerfile
--- README
-- 0.2.2-helium/
--- Dockerfile
--- README
-- 0.2.1-snapshot/
--- Dockerfile
--- README
-- 0.2.2-snapshot/
--- Dockerfile
--- README
-- 0.3.0-snapshot/
--- Dockerfile
--- README
- wcbench/
-- README
-- stable/
--- Dockerfile
--- README
-- latest/
--- Dockerfile
--- README
- <some feature here>/
# This feature doesn't need more than one auto-built image
-- Dockerfile
-- README

The OpenDaylight DockerHub org would have a set of Automatic Builds. Each build would track a repo branch, and for every change on that branch the appropriate Dockerfiles would be executed to create up-to-date images.

If you have any feedback, please let me know. :)

[1]: https://hub.docker.com/u/opendaylight/
[2]: https://github.com/opendaylight/integration/tree/master/packaging/docker

Daniel Farrell
Software Engineer, Red Hat SDN Team
https://twitter.com/dfarrell07
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Join {TSC@lists.opendaylight.org to automatically receive all group messages.