This is the overcloud deploy command used for upgrade:

(undercloud) [stack@undercloud-0 ~]$ cat composable_docker_upgrade.sh 
#!/bin/bash

openstack overcloud deploy \
--templates /usr/share/openstack-tripleo-heat-templates \
--libvirt-type kvm \
--ntp-server clock.redhat.com \
--environment-file /usr/share/openstack-tripleo-heat-templates/environments/services/sahara.yaml \
--environment-file /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml \
-e /home/stack/virt/network/network-environment.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /home/stack/virt/hostnames.yml \
-e /home/stack/virt/debug.yaml \
-e /home/stack/virt/nodes_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-composable-steps-docker.yaml \
-e /home/stack/docker-osp12.yaml \

Note that in OSP11 we used /usr/share/openstack-tripleo-heat-templates/environments/services/sahara.yaml but for the Docker services we need switch it to /usr/share/openstack-tripleo-heat-templates/environments/services-docker/sahara.yaml

I am changing the title to make this report more generic. When upgrading to OSP12 and moving to containers we need to manually replace the environment file(in OSP11 they are located in environments/services/) which activate the extra feature with its correspondent in environments/services-docker. This is an error prone operation which can lead to unexpected upgrade results in case switching the environment files gets missed by the user. The transition to containerized services should be as much as possible transparent for the user.

This ties into a greater problem of dockerized deployment not being the default. E.g. we also have to use docker.yaml, docker-ha.yaml, major-upgrade-composable-steps-docker.yaml. (We had to go this way to allow for Puppet variant to keep working, and build the Docker variant in parallel.)

Technically it should be possible to change all the defaults to Docker and make Puppet be the special case instead, but the cost of this could be fairly high as the change is an inherent chicken-and-egg issue with regards to CI and people's expectations.

We'd have to first copy all the defaults to Puppet-specific files, then make CI/people use those new files when they want to deploy Puppet variant, then we can switch the defaults to Docker, then make CI/people use the defaults when they want to deploy Docker variant (instead of Docker-specific files), and then get rid of the (now deprecated) Docker-specific files from repos.

So it's a multi-step change and we should weigh the costs/benefits here to assess feasibility.

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