Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1440273

Summary:	[RFE][RelNotes] default plan "overcloud" is replaced in UI when deploying via CLI
Product:	Red Hat OpenStack	Reporter:	Dan Macpherson <dmacpher>
Component:	documentation	Assignee:	RHOS Documentation Team <rhos-docs>
Status:	CLOSED WONTFIX	QA Contact:	RHOS Documentation Team <rhos-docs>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	10.0 (Newton)	CC:	jjoyce, jschluet, opavlenk, rhos-maint, slinaber, srevivo, tvignaud, ukalifon
Target Milestone:	beta	Keywords:	FutureFeature
Target Release:	11.0 (Ocata)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	Running the 'openstack overcloud deploy' command replaces the default 'overcloud' plan. If a user creates an overcloud with the CLI, deletes it, then creates a new overcloud with the web UI, the web UI uses the 'overcloud' plan from the CLI deployment. This can cause the web UI to include unwanted parameters from the previous overcloud deployment. As a workaround: 1. Ensure the 'user-environment.yaml' environment file is disabled when deploying a new overcloud. 2. Upload a new version of the plan (from the '/usr/share/openstack-tripleo-heat-template').	Story Points:	---
Clone Of:	1427198	Environment:
Last Closed:	2017-04-07 17:59:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1427198
Bug Blocks:

Description Dan Macpherson 2017-04-07 17:48:18 UTC

+++ 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.

Comment 1 Dan Macpherson 2017-04-07 17:59:40 UTC

This bug is a tracker for a known issue for the OSP11 Beta release notes. Closing