+++ This bug was initially created as a clone of Bug #1427198 +++

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.

--- Additional comment from Udi on 2017-03-02 21:03:48 EST ---

After reinstalling the undercloud this bug doesn't recreate any more, so there might be something missing in the scenario.

--- Additional comment from Udi on 2017-03-16 02:29:08 EST ---

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.