Add registry v2 to Bay nodes

Registered by Steven Dake

Add the registry v2 to each node of a Bay to allow OpenStack cloud operators to reduce or eliminate the dependency on the Docker public image registry in order to produce working containers in Magnum.

Discussion on Vancouver design summit: (section 1.1)

Blueprint information

Not started
Steven Dake
Steven Dake
Hua Wang
Series goal:
Milestone target:

Related branches



Our plan is to include Docker Distribution [1] (registry v2) on each Bay node that uses Docker:

The Swift backend for Docker [2] should be used so the storage features of the cloud are leveraged without creating a storage hotspot on the Bay's master node. Once this code has been merged, we can proceed with this feature. This approach allows each node to access registry on localhost, removing the need to secure this service using tls / ssl.

[1] Docker Distribution
[2] Swift Backend for Distribution


In addition to the above, we should check to verify that Docker Distribution can be configured to use the Docker Public Registry as an upstream resource and create local cached copies of the upstream images in its local (swift) image storage. Note that some cloud operators will want this capability turned on, and others will want it turned off, and use a batch process to fetch, test, and import upstream images only after they have been tested to meet acceptance criteria (security, license, etc.).

(hongbin) The swift backend pull request is unlikely to be merged and released at l1, so I push the target to l2.

Gerrit topic:,topic:bp/registryv2-in-master,n,z

Addressed by:
    Add registry to api and db

Addressed by:
    Add registry to template

(devkulkarni): I was wondering how would one push custom docker images to the docker registry on each node of a bay? Or, that is not necessary as the custom image can be stored in swift and Docker Distribution magic will make it appear in the docker registry on each node?

(adrian_otto): Devdatta, the Distribution (registryv2) service does not hold any local state. It persists everything to the backing store (swift). This means that anywhere you run the service on a common backing store, you have access to the same data. It relies on the backing store's features for scale-out of the data storage tier. So, if you are running one on every bay node on the same port, then your registry address can always be on the same localhost:port throughout the bay. In fact, the Distribution service should bind to, rather than *. This will narrow the attack surface, and simplify the protection of it.

Addressed by:
    Add registry_address to db and api

Addressed by:
    Add registry_trust_id to bay

Addressed by:
    Create trust_id for bay

Addressed by:
    Hide user credentials

Addressed by:
    Add docker registry support in template definition

Addressed by:
    Enable swift services

Addressed by:
    Configure docker registry in devstack

Addressed by:
    Add docs for docker registry

Addressed by:
    Add support for docker registry

Addressed by:
    Config docker registry in devstack

Addressed by:

Addressed by:
    Add docker registry support for swarm

Addressed by:
    Heat params are different in swarm master and swarm node


Work Items

This blueprint contains Public information 
Everyone can see this information.