Bug 1177033 - rubygem-staypuft: neutron deployment doesn't advance, the IPs used to register the computes in foreman, moved to the controller during deployment.
Summary: rubygem-staypuft: neutron deployment doesn't advance, the IPs used to registe...
Keywords:
Status: CLOSED DUPLICATE of bug 1176423
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rubygem-staypuft
Version: unspecified
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: ga
: Installer
Assignee: Mike Burns
QA Contact: Omri Hochman
URL:
Whiteboard:
Depends On:
Blocks: 1177026
TreeView+ depends on / blocked
 
Reported: 2014-12-23 21:49 UTC by Alexander Chuzhoy
Modified: 2015-01-05 16:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-05 16:39:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.