Red Hat Bugzilla – Bug 1500507
Support DockerInsecureRegistryAddress in image prepare command
Last modified: 2018-02-05 14:15:23 EST
Currently we have to manually add the respective DockerInsecureRegistryAddress (when required). It would be nice if we could use the --set argument of image prepare to configure the parameter appropriately.
This is now implemented in at least 3 different tripleo deployment helpers repos for CI https://review.openstack.org/#/c/509232/9/roles/overcloud-prep-containers/templates/overcloud-prep-containers.sh.j2@15 https://github.com/openstack/tripleo-quickstart-extras/search?utf8=%E2%9C%93&q=insecure&type= https://github.com/redhat-openstack/tripleo-upgrade/search?utf8=%E2%9C%93&q=INSECURE&type= https://github.com/redhat-openstack/infrared/search?utf8=%E2%9C%93&q=insecure&type= Getting this functionality rolled into tripleo which can be re-used by these other projects would be helpful to reduce amount of code duplication as well as feature richness of the functionality.
Rather than adding another option to the prepare command, it should just detect whether the registry is insecure by making https and http calls, then set the DockerInsecureRegistryAddress if it is not https.
(In reply to Steve Baker from comment #2) > Rather than adding another option to the prepare command, it should just > detect whether the registry is insecure by making https and http calls, then > set the DockerInsecureRegistryAddress if it is not https. Having it magically enable "DockerInsecureRegistryAddress" might be perceived as security problem by some users though too. I sort of like the idea of letting insecure registry address configuration as being explicitly something you need to enable.
The backport is merged in stable/pike
Verified: Environment: python-tripleoclient-7.3.3-3.el7ost.noarch An https connection is made to the registry and if it returns an ssl error, then the DockerInsecureRegistryAddress line is appended automatically. Example of how it looks in the file: DockerInsecureRegistryAddress: - 192.168.24.1:8787
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3462