container image prepare incorrectly excludes not completely secure registries for DockerInsecureRegistryAddress

Bug #1833751 reported by Alex Schultz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Fix Released
High
Alex Schultz

Bug Description

If you are using the container image prepare, we generate a list of insecure registries to put into DockerInsecureRegistryAddress. Currently if the host is not https, it will get added to the list automatically. If the host answers on https but has an invalid certificate it does not get added to the default generated DockerInsecureRegistryAddress which leads to container pull failures during the deploy. It is however added to an internal list generated in the python image uploader code so it will work when loading containers from the source to the undercloud registry so there is a mis-match in how the insecure registries are handled.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to tripleo-common (master)

Fix proposed to branch: master
Review: https://review.opendev.org/666913

Changed in tripleo:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tripleo-common (master)

Reviewed: https://review.opendev.org/666913
Committed: https://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=51d723a9ff0d7af47d1974a8e77fe7187e57357b
Submitter: Zuul
Branch: master

commit 51d723a9ff0d7af47d1974a8e77fe7187e57357b
Author: Alex Schultz <email address hidden>
Date: Fri Jun 21 14:07:34 2019 -0600

    Handle registries with incorrect certs correctly

    We actually end up allowing registries with incorrect certificates in
    the upload code so they get treated the same as inscure registries.
    This change updates the return code of the is_insecure_registry to match
    how we handle these registries in the image uploader. Additionally, this
    means that when the container image prepare code runs, we will correctly
    include these registries that have ssl enabled but incorrect
    certificates will correctly be included in the
    DockerInsecureRegistryAddress setting.

    Change-Id: I7fba881645ec2ea167c064be07ed6d4281b7ed3d
    Closes-Bug: #1833751

Changed in tripleo:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to tripleo-common (stable/stein)

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/669761

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tripleo-common (stable/stein)

Reviewed: https://review.opendev.org/669761
Committed: https://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=c053ac5eb0415689a5cfa50adcd1aa66cc027f10
Submitter: Zuul
Branch: stable/stein

commit c053ac5eb0415689a5cfa50adcd1aa66cc027f10
Author: Alex Schultz <email address hidden>
Date: Fri Jun 21 14:07:34 2019 -0600

    Handle registries with incorrect certs correctly

    We actually end up allowing registries with incorrect certificates in
    the upload code so they get treated the same as inscure registries.
    This change updates the return code of the is_insecure_registry to match
    how we handle these registries in the image uploader. Additionally, this
    means that when the container image prepare code runs, we will correctly
    include these registries that have ssl enabled but incorrect
    certificates will correctly be included in the
    DockerInsecureRegistryAddress setting.

    Change-Id: I7fba881645ec2ea167c064be07ed6d4281b7ed3d
    Closes-Bug: #1833751
    (cherry picked from commit 51d723a9ff0d7af47d1974a8e77fe7187e57357b)

tags: added: in-stable-stein
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/tripleo-common 11.1.0

This issue was fixed in the openstack/tripleo-common 11.1.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/tripleo-common 10.8.1

This issue was fixed in the openstack/tripleo-common 10.8.1 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.