Description of problem:
When deploying the default plan (overcloud) from the GUI, the overcloud deployment fails because it tries to deploy the cloud as IPv6.
The selected environments were:
overcloud-resource-registry-puppet.yaml
environments/puppet-pacemaker.yaml
environments/storage-environment.yaml
This happened after deploying a custom plan with IPv6, then undeploying it and trying to deploy with the default plan again.
Version-Release number of selected component (if applicable):
openstack-tripleo-ui-1.1.0-1.el7ost.noarch
openstack-tripleo-heat-templates-5.2.0-3.el7ost.noarch
openstack-tripleo-common-5.4.1-1.el7ost.noarch
openstack-tripleo-0.0.8-0.2.4de13b3git.el7ost.noarch
How reproducible:
don't know
Steps to Reproduce:
1. Deploy a custom plan with IPv6
2. Undeploy
3. Deploy with the default plan (I deployed with 3 controllers, 2 computes and 3 internal ceph).
Actual results:
Deployment fails (it fails at the point where is tries to start pcs). If you look in the swift container of the overcloud plan, you find a file there called "user-environment.yaml". It maps all the resources to their IPv6 versions.
You can also see in the mistral environment that a lot of parameters which enable the IPv6 versions of the services are set to "true":
"RabbitIPv6": true,
"MemcachedIPv6": true,
"CephIPv6": true,
"NovaIPv6": true,
"MongoDbIPv6": true,
"CorosyncIPv6": true
Expected results:
When the user doesn't select any IPv6 environments, the default plan should result with an IPv4 deployment.
This was caused by deploying an IPv6 overcloud from the command line. When deploying from the command line, the default plan "overcloud" is replaced, and then a GUI user who tries to deploy the default plan will actually be deploying something else. The same happened when I deployed with custom roles from the CLI - I got the customized roles in the default plan in the GUI.
This is currently working as designed, we can decide whether we want to handle this differently.