Bug 1024242 - interactive install sets wrong IP for CONFIG_NOVA_NETWORK_HOST
Summary: interactive install sets wrong IP for CONFIG_NOVA_NETWORK_HOST
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: beta
: 4.0
Assignee: Ivan Chavero
QA Contact: Udi Kalifon
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-29 08:08 UTC by ben-redhat
Modified: 2013-12-20 00:33 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-20 00:33:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2013:1859 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement Advisory 2013-12-21 00:01:48 UTC

Description ben-redhat 2013-10-29 08:08:13 UTC
Description of problem:

When doing an interactive install of Red Hat OpenStack Grizzly with packstack, the install fails with:

ERROR : Error during puppet run : Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install openstack-quantum' returned 1:
Please check log file /var/tmp/packstack/20131022-131634-8x3p1o/openstack-setup.log for more information

The systems have lost network activity.

I tracked it down when I did a non-interactive install and compared the answer file, CONFIG_NOVA_NETWORK_HOST when doing the interactive install does not get set to the correct IP address.  It sets it to the default IP that packstack offers to assign each question, which for me was the wrong IP address.  During the interactive install, it never asks for the network host, and when it asks to verify the configuration it is not listed either.

Fixing the IP address for CONFIG_NOVA_NETWORK_HOST in the answer file and running packstack --answer-file completes successfully.

Version-Release number of selected component (if applicable):

# rpm -q -a | grep "packstack"
openstack-packstack-2013.1.1-0.31.dev677.el6ost.noarch

How reproducible:

Every time packstack is run in interactive mode.  If the default IP address works, then it isn't an issue, but for me the default IP does not work.  I ran packstack from a system not part of the OpenStack cloud. I was assuming it would want a dedicated Puppet server, but it doesn't look like it needs one.

When run in non-interactive mode, packstack sets the IP address correctly for my setup.

Steps to Reproduce:
1. Run packstack in interactive mode from a machine that isn't in the OpenStack cloud.
2. The default IP address offered by packstack will be assigned to CONFIG_NOVA_NETWORK_HOST in the answer file instead of the controller node IP.
3.

Actual results:
CONFIG_NOVA_NETWORK_HOST=One of the IPs from the system running packstack

Expected results:
CONFIG_NOVA_NETWORK_HOST=Internal IP of network node

Additional info:

Comment 2 Ivan Chavero 2013-11-15 00:41:03 UTC
Did you enable quantum while installing in interactive way??

If quantum is enabled packstack is not going configure nova network so it wont ask for CONFIG_NOVA_NETWORK_HOST

have you tried a new packstack version?? openstack-packstack-2013.1.1-0.31.dev696.el6

Comment 3 ben-redhat 2013-11-15 03:09:01 UTC
Yes, I was using Quantum.  I was not using nova-network, but the installation failed when the IP address of that variable did not match the network controller node.  Just changing that variable was the difference between a working install and a non-working install.

I have not tried reproducing it with a newer packstack.  I have a working install after manually fixing that variable. I was just trying to report the issue I had so that hopefully others wouldn't have the same issue.

Comment 4 Ivan Chavero 2013-11-15 18:06:18 UTC
We appreciate your help!

After some tests i found that the current packstack version does not have this problem.

Comment 6 Scott Lewis 2013-11-19 16:54:29 UTC
Auto adding >= MODIFIED bugs to beta

Comment 9 Bruce Reeler 2013-12-16 04:48:27 UTC
NEEDINFO Ivan Chavero

Hi Ivan, your prev needinfo was reset, but this bug is in the list of bugs in advisory and still requires doc text (comment 8) , or needs flag set to - if no doc text required. 
Thanks.

Comment 10 Udi Kalifon 2013-12-18 11:38:00 UTC
With version: openstack-packstack-2013.2.1-0.20.dev936.el6ost.noarch

I ran an interactive install, and for all nova-related and neutron-related questions I entered a non-default IP address. Still, in the answers file, the field CONFIG_NOVA_NETWORK_HOSTS got the default IP (my IP).

Comment 11 Ivan Chavero 2013-12-18 14:46:59 UTC
Did you set CONFIG_NEUTRON_INSTALL=n??

If you don't, the interactive install won't ask for the CONFIG_NOVA_NETWORK_HOSTS param.

extract of the interactive install using openstack-packstack-2013.2.1-0.20.dev936.el6ost.noarch:

...
Should Packstack install OpenStack Networking (Neutron) service [y|n]  [y] : n
...

Enter list of IP addresses on which to install the Nova Network service  [192.168.100.221] : 192.168.100.100
Parameter CONFIG_NOVA_NETWORK_HOSTS failed validation: Given host does not listen on port 22: 192.168.100.100
User input failed validation, do you still wish to use it? (yes|no): yes



grep CONFIG_NOVA_NETWORK_HOSTS packstack-answers-20131218-074153.txt 
CONFIG_NOVA_NETWORK_HOSTS=192.168.100.100

confirmed it works

Comment 12 Udi Kalifon 2013-12-19 09:51:38 UTC
I checked again with OpenStack Networking (Neutron) service turned off, and confirmed that CONFIG_NOVA_NETWORK_HOSTS gets set. 

Checked in: openstack-packstack-2013.2.1-0.20.dev936.el6ost.noarch

I suggest documenting the fact that Nova networking will not be configured if Neutron is installed.

Comment 14 errata-xmlrpc 2013-12-20 00:33:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2013-1859.html


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