Docker not configured to pull from undercloud registry by default

Bug #1691524 reported by Steven Hardy on 2017-05-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Steven Hardy

Bug Description

I enabled logging requests from the undercloud registry like this:

[root@undercloud /]# cat /etc/docker-distribution/registry/config.yml
version: 0.1
    disabled: false
    service: registry
        layerinfo: inmemory
        rootdirectory: /var/lib/registry

Then I did docker pull from the undercloud, and some deployed overcloud nodes - they hit dockerhub without trying the local registry AFAICT. I assume we're passing the registry location explicitly in the heat hook (are we?! I've yet to re deploy with logging enabled), but it'd be good if we made manual operations also use the local registry where possible.

The option to do this seems to be:

--add-registry= which can be appended to OPTIONS in /etc/sysconfig/docker (puppet-tripleo will need updating to do this I think).

I also wonder if, at least optionally, we should block dockerhub so we can be sure all the images are actually pulled to the local registry e.g in CI, otherwise we may be taking a performance hit without realizing? There's a --block-registry option that does this I think.

Steven Hardy (shardy) on 2017-05-17
Changed in tripleo:
status: New → Triaged
milestone: none → pike-2
tags: added: containers
Steven Hardy (shardy) wrote :

Actually in my environment during an overcloud there's no access to the undercloud registry recorded at all AFAICS.

Steve Baker (steve-stevebaker) wrote :

Have you set the DockerNamespace param in the environment?

  DockerNamespace: # or tripleo, whatever
  DockerNamespaceIsRegistry: true

Dan Prince (dan-prince) wrote :

Exactly like stevebaker said. I use a local registry (not on my undercloud though). To activate it you just need to add heat parameters to your overcloud environment like:

  DockerNamespaceIsRegistry: true

Steven Hardy (shardy) wrote :

I'm using /home/stack/containers-default-parameters.yaml which gets created by quickstart, it looks like:

$ cat /home/stack/containers-default-parameters.yaml
  # NovaImage: atomic-image # FYI the team is using overcloud-full currently
  # Defaults to 'tripleoupstream'. Specify a local docker registry
  # Example:
  # Enable local Docker registry
  DockerNamespaceIsRegistry: true

So it does appear to be configured correctly, and the service is listening on the right IP:
$ netstat -taupen | grep 8787
(No info could be read for "-p": geteuid()=1000 but you should be root.)
tcp 0 0* LISTEN 0 1352248 -

Also the environment file doesn't solve the case where an operator interacts with docker directly on the CLI (I know we probably don't want to encourage that, but it's useful for developers at least).

Steven Hardy (shardy) wrote :

Ok so the root cause of this (thanks to mandre for helping work through this) is we set DockerNamespaceIsRegistry to false in this environment (which is the default in the templates anyway), which if (like me) you specify the environments in an unfortunate order, the quickstart generated environment setting gets overwritten by the docker.yaml.

Since this is just duplicating the template defaults, we should probably remove them from docker.yaml I think.

Fix proposed to branch: master

Changed in tripleo:
assignee: nobody → Steven Hardy (shardy)
status: Triaged → In Progress
Changed in tripleo:
importance: Undecided → Medium

Submitter: Jenkins
Branch: master

commit 47dfa57f5cc8a96cf0682eec226d68908819cc75
Author: Steven Hardy <email address hidden>
Date: Thu May 18 10:53:10 2017 +0100

    Comment parameters for registry in docker.yaml

    These duplicate the defaults in puppet/services/docker.yaml and
    break things if you include an environment file (e.g that generated
    by quickstart containers-default-parameters.yaml) before the

    Instead it's probably more helpful to include the commented lines
    showing how to enable use of a local docker registry.

    Change-Id: I3896fa2ea7caa603186f0af04f6d8382d50dd97a
    Closes-Bug: #1691524

Changed in tripleo:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers