Bug 1816126

The problem here is that some customer always specify "latest" tag for containers. Because Satellite server keeping synchronizing with CDN every day or week, and we cannot freeze containers as we can do with RPM packages using content view, the "latest" tag is going to be a newer version when deploying in production. I know we have z11 code now and that is what we are testing, but when we deploy in another region, "latest" will be something else, maybe Z12 or higher.

Maybe a proper workflow here would be to freeze the RPMs along the specific {version}-{release} ... rather than having other processes to keep track of which versions are within which z-release.

yeah we should probably tag with zX imho.

(In reply to David Hill from comment #3)
> Maybe a proper workflow here would be to freeze the RPMs along the specific
> {version}-{release} ... rather than having other processes to keep track of
> which versions are within which z-release.

Slightly off-topic:
Regarding overcloud containers, even if an operator has no understanding/knowledge of z-releases they can "take a snapshot of the container" deployed in a certain env, at any given point of time.
That can be done by using `openstack object save overcloud environments/containers-default-parameters.yaml --file overcloud_images.yaml` using undercloud credentials, and then use the output file in future deployments (in a `pip freeze` fashion).

Is any of you aware of a similar workaround for the undercloud container images?

The use case is for operators managing multiple environments having the hard requirement to be 1:1 (down to container 16.X-Y tag) with the original one even if deployed later in time.
IIUC, in those cases using "tag: 16.1.2" for `container image prepare` would not be enough, as 16.1.X tag might later point to containers included with async releases, etc. and diverge from the original env.

(In reply to Michele Valsecchi from comment #12)
> (In reply to David Hill from comment #3)
> > Maybe a proper workflow here would be to freeze the RPMs along the specific
> > {version}-{release} ... rather than having other processes to keep track of
> > which versions are within which z-release.
> 
> Slightly off-topic:
> Regarding overcloud containers, even if an operator has no
> understanding/knowledge of z-releases they can "take a snapshot of the
> container" deployed in a certain env, at any given point of time.
> That can be done by using `openstack object save overcloud
> environments/containers-default-parameters.yaml --file
> overcloud_images.yaml` using undercloud credentials, and then use the output
> file in future deployments (in a `pip freeze` fashion).
> 
> Is any of you aware of a similar workaround for the undercloud container
> images?
> 
> The use case is for operators managing multiple environments having the hard
> requirement to be 1:1 (down to container 16.X-Y tag) with the original one
> even if deployed later in time.
> IIUC, in those cases using "tag: 16.1.2" for `container image prepare` would
> not be enough, as 16.1.X tag might later point to containers included with
> async releases, etc. and diverge from the original env.



Our customer wants to do this, however we can add the overcloud_images.yaml to the deployment, but the images wan't be pulled down to the director if it's not in the container_images_prepare.yaml right? How can we do this and ensure the images are pulled to the director before deployment?

OSP13 support officially ended on 27 June 2023