container image prepare assumes default tag of 16.0 always exists even when it doesn't in a filtered content view

[James Slagle]

If you don't specify a tag key in ContainerImagePrepare, it will automatically be added to the rendered overcloud_containers.yaml.j2 and read as the default value 16.0 from container_image_prepare_defaults.yaml.

image_uploader.py will then attempt to load the manifest for the 16.0 tagged image so that tag_from_label can then be used to set the actual tag for the image.

However, when using a filtered content view in Satellite, an image with tag 16.0 may not exist. In that case, you get a not found error similar to:

tripleo_common.image.exception.ImageNotFoundException: Not found image: docker://satellite.bm-mec01-rh.mec.ouroath.com:5000/vce-production-latest-osp16_containers-neutron-server:16.0

Adding the 16.0 tag to the content view doesn't work either, then image_uploader.py just looks for the latest tag it read from the label, which likely doesn't exist in the content view either.

The proposed behavior should be something like:
- save somehow if the default value of tag was used
- when _inspect runs in image_uploader.py, if the image is not found, check if the default tag was added and used.
- if it was, then query for the list of tags (this is already done anyway), pick one (sort with vercmp perhaps), and read the manifest from that one.
- use that manifest to read all the labels/etc.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/739594
Committed: https://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=0c4de9c771fad75ebabe2d18f5aef4b76613d52a
Submitter: Zuul
Branch: master

commit 0c4de9c771fad75ebabe2d18f5aef4b76613d52a
Author: James Slagle <email address hidden>
Date: Mon Jul 6 15:16:02 2020 -0400

    Don't assume default tag exists in container repo

    When no tag is set for an entry in ContainerImagePrepare, the default
    tag from container-images/container_image_prepare_defaults.yaml will be
    assumed, which is typically current-tripleo, or a release version such
    as 16.0.

    In most cases, this tag will exist. However, when using a satellite with
    a content view that has been filtered on tags, it likely won't exist
    since content views are often used with container image versions that
    are not the latest.

    In the case where no tag is set in the entry in ContainerImagePrepare,
    and the default tag does not exist in the container repo, the latest tag
    from the repo will be assumed instead.

    Change-Id: I985ef22c340c4071866c8c51bf303a6f4ee7713c
    Closes-Bug: #1886547
    Signed-off-by: James Slagle <email address hidden>

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/741621

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/741622

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/741621
Committed: https://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=ec65b686c38f696ac2aefc9d7dc9376f5637aa1d
Submitter: Zuul
Branch: stable/ussuri

commit ec65b686c38f696ac2aefc9d7dc9376f5637aa1d
Author: James Slagle <email address hidden>
Date: Mon Jul 6 15:16:02 2020 -0400

    Don't assume default tag exists in container repo

    When no tag is set for an entry in ContainerImagePrepare, the default
    tag from container-images/container_image_prepare_defaults.yaml will be
    assumed, which is typically current-tripleo, or a release version such
    as 16.0.

    In most cases, this tag will exist. However, when using a satellite with
    a content view that has been filtered on tags, it likely won't exist
    since content views are often used with container image versions that
    are not the latest.

    In the case where no tag is set in the entry in ContainerImagePrepare,
    and the default tag does not exist in the container repo, the latest tag
    from the repo will be assumed instead.

    Change-Id: I985ef22c340c4071866c8c51bf303a6f4ee7713c
    Closes-Bug: #1886547
    Signed-off-by: James Slagle <email address hidden>
    (cherry picked from commit 0c4de9c771fad75ebabe2d18f5aef4b76613d52a)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/741622
Committed: https://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=589ac8ac0d5a14ce4aa831892d3b0a4a31e29674
Submitter: Zuul
Branch: stable/train

commit 589ac8ac0d5a14ce4aa831892d3b0a4a31e29674
Author: James Slagle <email address hidden>
Date: Mon Jul 6 15:16:02 2020 -0400

    Don't assume default tag exists in container repo

    When no tag is set for an entry in ContainerImagePrepare, the default
    tag from container-images/container_image_prepare_defaults.yaml will be
    assumed, which is typically current-tripleo, or a release version such
    as 16.0.

    In most cases, this tag will exist. However, when using a satellite with
    a content view that has been filtered on tags, it likely won't exist
    since content views are often used with container image versions that
    are not the latest.

    In the case where no tag is set in the entry in ContainerImagePrepare,
    and the default tag does not exist in the container repo, the latest tag
    from the repo will be assumed instead.

    Change-Id: I985ef22c340c4071866c8c51bf303a6f4ee7713c
    Closes-Bug: #1886547
    Signed-off-by: James Slagle <email address hidden>
    (cherry picked from commit 0c4de9c771fad75ebabe2d18f5aef4b76613d52a)
    (cherry picked from commit ec65b686c38f696ac2aefc9d7dc9376f5637aa1d)

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/750060

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/750109

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/750060
Committed: https://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=66cdee5a0fd350eaef805eed664a7f71cf5046a2
Submitter: Zuul
Branch: stable/ussuri

commit 66cdee5a0fd350eaef805eed664a7f71cf5046a2
Author: James Slagle <email address hidden>
Date: Fri Sep 4 16:45:51 2020 -0400

    Fix handling of default_tag

    The previous fix, 589ac8ac0d5a14ce4aa831892d3b0a4a31e29674 was not fully
    working as intended because during the templating of the container image
    prepare entry, the setting for default_tag was being lost.

    This fix simplifies the handling by just checking the initial
    mapping_args for the presence of a tag key to determine if the
    default_tag flag should be set.

    Change-Id: Idfebf62e0e10b709367cfcb6977cf18550a4a4b0
    Partial-Bug: #1886547
    Signed-off-by: James Slagle <email address hidden>
    (cherry picked from commit b744db900f51416da25ccf923b2105f43f528720)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/750109
Committed: https://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=e53f6f73e308899a2a79ca11b4d3c4a9849c1ac2
Submitter: Zuul
Branch: stable/train

commit e53f6f73e308899a2a79ca11b4d3c4a9849c1ac2
Author: James Slagle <email address hidden>
Date: Fri Sep 4 16:45:51 2020 -0400

    Fix handling of default_tag

    The previous fix, 589ac8ac0d5a14ce4aa831892d3b0a4a31e29674 was not fully
    working as intended because during the templating of the container image
    prepare entry, the setting for default_tag was being lost.

    This fix simplifies the handling by just checking the initial
    mapping_args for the presence of a tag key to determine if the
    default_tag flag should be set.

    Change-Id: Idfebf62e0e10b709367cfcb6977cf18550a4a4b0
    Partial-Bug: #1886547
    Signed-off-by: James Slagle <email address hidden>
    (cherry picked from commit b744db900f51416da25ccf923b2105f43f528720)
    (cherry picked from commit 66cdee5a0fd350eaef805eed664a7f71cf5046a2)

[OpenStack Infra (hudson-openstack)]

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