Description of problem: Describing this issue with just a two containers but seems to impact all pacemaker containers. All non-pacemaker containers are correctly forced to the version defined in images.yaml. Registry contains the following containers: openstack-ovn-northd:16.2.4-17 openstack-ovn-northd:16.2.4-17.1679573635 openstack-ovn-controller:16.2.4-17 openstack-ovn-controller:16.2.4-17.1679573638 However, the goal is to force to version: 16.2.4-17 with the following images.yaml in deployment. parameter_defaults: [...] ContainerOvnDbsImage: registry.local:443/rhosp-rhel8/openstack-ovn-northd:16.2.4-17 ContainerOvnControllerImage: registry.local:443/rhosp-rhel8/openstack-ovn-controller:16.2.4-17 With this config ovn-controller (not managed by pacemaker) will be deployed with the desired 16.2.4-17 version; however, openstack-ovn-northd (tagged as: cluster.common.tag/openstack-ovn-northd:pcmklatest) will be updated to the more current version: 16.2.4-17.1679573635 This seem to be related to how the container is tagged and setup for pacemaker; perhaps the tripleo-container-tag ansible playbook used for this. Version-Release number of selected component (if applicable): rhosp 16.2.4 How reproducible: See above
Pretty sure this is intentional to ensure stability. Those containers will only be changed during a minor update: https://github.com/openstack/tripleo-heat-templates/blob/1393d39be367db3acb02508e0e858395a4e4fefa/deployment/ovn/ovn-dbs-pacemaker-puppet.yaml#L17-L24 They are tagged during update_tasks here: https://github.com/openstack/tripleo-heat-templates/blob/1393d39be367db3acb02508e0e858395a4e4fefa/deployment/ovn/ovn-dbs-pacemaker-puppet.yaml#L315-L320 This wont happen outside of a update, so the only way you could achieve this without updating would be to manually pull the images, tag them and restart the pacemaker services. Whether pidone would support such a thing is another question. Adding pidone to review.
Hey Matt, from our discussion on slack I thought we were going to use the minor update workflow? Brendan is correct, I don't think you can change bundle images during a stack update nowadays if you use the cluster common tag (https://github.com/openstack/tripleo-heat-templates/commit/8b8f103906843ab25e5b97a76253b6120aea1de3). I would +1 the manual tagging of the images in case of emergency (production down, fix it quickly and run the minor update later). Cheers, Luca
probably a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2215283
(In reply to Luca Miccini from comment #2) > Hey Matt, from our discussion on slack I thought we were going to use the > minor update workflow? > Brendan is correct, I don't think you can change bundle images during a > stack update nowadays if you use the cluster common tag > (https://github.com/openstack/tripleo-heat-templates/commit/ > 8b8f103906843ab25e5b97a76253b6120aea1de3). > I would +1 the manual tagging of the images in case of emergency (production > down, fix it quickly and run the minor update later). > > Cheers, > Luca Thanks for the clarification, I guess I didn't understand the full situation during the slack discussion and that minor update workflow was necessary (or manually tagging the images). Sorry for being slow to understand, I'll close this one.