Description of problem:
When enabling octavia in the overcloud the cinder-volume container can't be created in step 5 thus deployments are failing.


Version-Release number of selected component (if applicable):
RHOSP 16.1


How reproducible: N/A


Steps to Reproduce:
1.
2.
3.

Actual results:
Deployment fails during step 5 of deployment. Error they are seeing

fatal: [vlo-undercloud-s01]: FAILED! => {\"changed\": true, \"cmd\": \"openstack image create --disk-format qcow2  --container-format bare --tag amphora-image  --file /usr/share/openstack-octavia-amphora-images/octavia-amphora.qcow2  --property hw_architecture=x86_64  --private octavia-amphora-16.1-20200722.1.x86_64\\n\", \"delta\": \"0:00:14.203100\", \"end\": \"2020-10-13 19:22:38.230420\", \"msg\": \"non-zero return code\", \"rc\": 1, \"start\": \"2020-10-13 19:22:24.027320\", \"stderr\": \"HTTP 500 Internal Server Error: The server has either erred or is incapable of performing the requested operation.\", \"stderr_lines\": [\"HTTP 500 Internal Server Error: The server has either erred or is incapable of performing the requested operation.\"], \"stdout\": \"\", \"stdout_lines\": []}


Expected results:
Deployment will finish successfully.



Additional info:
The customer is using glance for cinder backend.  When octavia is removed from templates from the deployment; then cinder-volume container starts at step 5 and deploy is fine.

From what we can see when enabling octavia; none of the controller nodes have cinder-volume-role node attribute set and so pacemaker is not starting the container in step 5 and for this property to be set there has to be a container that's created in step 2 cinder_volume_init_bundle which is also not created on any of the controller nodes so that explains why the cinder-volume service isn't started.

However looking into the plan we can see that the CinderVolume Service is mapping to the cinder-volume-pacemaker-puppet.yaml so this should be fine. At this point I am not sure what is going wrong when enabling octavia so as the deployments are failing.


We also asked the customer to set explicit mapping for OS::TripleO::Services::CinderVolume service and run a stack update and see if that mitigates this issue.