Bug 1177033

Summary:	rubygem-staypuft: neutron deployment doesn't advance, the IPs used to register the computes in foreman, moved to the controller during deployment.
Product:	Red Hat OpenStack	Reporter:	Alexander Chuzhoy <sasha>
Component:	rubygem-staypuft	Assignee:	Mike Burns <mburns>
Status:	CLOSED DUPLICATE	QA Contact:	Omri Hochman <ohochman>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	unspecified	CC:	mburns, yeylon
Target Milestone:	ga
Target Release:	Installer
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-01-05 16:39:32 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:
Bug Blocks:	1177026

Description Alexander Chuzhoy 2014-12-23 21:49:44 UTC

rubygem-staypuft: neutron deployment doesn't advance, the IPs used to register the computes in foreman, moved to the controller during deployment.

Environment:
openstack-puppet-modules-2014.2.8-1.el7ost.noarch
ruby193-rubygem-foreman_openstack_simplify-0.0.6-8.el7ost.noarch
openstack-foreman-installer-3.0.8-1.el7ost.noarch
rhel-osp-installer-0.5.4-1.el7ost.noarch
ruby193-rubygem-staypuft-0.5.9-1.el7ost.noarch
rhel-osp-installer-client-0.5.4-1.el7ost.noarch


Steps to reproduce:
1. Install rhel-osp-installer
2. Configure/run Neutron deployment (one controller+2 computes)

Result:
The deployment doesn't complete.
Checking the systems, I realized that the IP used by computes are in use by the controller.
I verified the IPs resided on computes right after they were provisioned with OS. 

Expected result:
The IP registered in foreman should stay on the respective compute host.

Comment 2 Alexander Chuzhoy 2014-12-23 21:54:15 UTC

Reproduced the bug on the same (bare metal) environment.

Comment 3 Alexander Chuzhoy 2014-12-23 22:08:59 UTC

After assigning hosts to deployment and assigning the networks, I click on "Access all details" button.

I see that "ceilometer_admin_vip" will use the IP that was assigned to first compute, and "heat_admin_vip" will use the IP assigned to the second compute.

Comment 5 Alexander Chuzhoy 2014-12-23 22:35:09 UTC

Moving the admin_api and management traffic types to a separate subnet (away from the default subnet) should resolve it. 
I see no collisioning IPs in the list of IPs under "Access all details" after moving the mentioned types.

Comment 6 Alexander Chuzhoy 2014-12-24 16:10:31 UTC

The workaround suggested in comment #5 worked for me. Have a successful deployment.

Comment 7 Mike Burns 2015-01-05 16:39:32 UTC

same issue as bug 1176423

*** This bug has been marked as a duplicate of bug 1176423 ***