Bug 1119443 - Packstack is 'hard-coded' on eth1 (fails on a CentOs7 vanilla installation
Summary: Packstack is 'hard-coded' on eth1 (fails on a CentOs7 vanilla installation
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: RDO
Classification: Community
Component: openstack-packstack
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Martin Magr
QA Contact: Ami Jeain
URL:
Whiteboard:
Depends On:
Blocks: lars-starred
TreeView+ depends on / blocked
 
Reported: 2014-07-14 19:32 UTC by Yaniv Kaul
Modified: 2015-04-03 13:56 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-03 13:56:49 UTC


Attachments (Terms of Use)

Description Yaniv Kaul 2014-07-14 19:32:09 UTC
Description of problem:
Packstack with Nova does not change the private interface to anything realistic on the host. Therefore, it fails in an ugly manner on CentOS 7 (host completed installation fine on CentOS 6.5, same packstack):
ERROR : Failed to run remote script, stdout: Device eth1 does not exist

stderr: Warning: Permanently added '10.102.34.175' (ECDSA) to the list of known hosts.
+ trap t ERR
+ ip addr show dev eth1
Device "eth1" does not exist.
+ echo Device eth1 does not exist
+ exit 1
++ t
++ exit 1

[root@lgdrm920 Mgmt-OpenStack installation]# grep eth1 answers.txt 
CONFIG_NOVA_COMPUTE_PRIVIF=eth1
CONFIG_NOVA_NETWORK_PRIVIF=eth1


Version-Release number of selected component (if applicable):
openstack-packstack-2014.1.1-0.25.dev1208.el7.noarch

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
[root@lgdrm920 Mgmt-OpenStack installation]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1e:67:9f:35:92 brd ff:ff:ff:ff:ff:ff
3: enp4s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1e:67:9f:35:93 brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1e:67:69:77:74 brd ff:ff:ff:ff:ff:ff
    inet 10.102.34.175/20 brd 10.102.47.255 scope global dynamic eth0
       valid_lft 157111sec preferred_lft 157111sec
5: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:1e:67:69:77:75 brd ff:ff:ff:ff:ff:ff

Comment 1 Yaniv Kaul 2014-07-14 19:35:06 UTC
I'm not sure what would be a good interface to choose from. In my case, either enp4s0f0 or enp4s0f1 would have been good.

Comment 2 Rich Bowen 2014-09-12 14:15:13 UTC
For whatever it's worth, I'm getting the same error, and ... :

[rbowen@localhost ~]$ sudo ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether f0:de:f1:dc:2a:08 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 10:0b:a9:c7:05:60 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.176/24 brd 192.168.0.255 scope global dynamic wlp3s0
       valid_lft 85484sec preferred_lft 85484sec
    inet6 fe80::120b:a9ff:fec7:560/64 scope link 
       valid_lft forever preferred_lft forever


So it looks like, in this case, I'd want wlp3s0. This is a fresh CentOS7 install. Perhaps packstack needs to be a little smarter than just having default interface names?

Looks possibly related to the discussion at https://openstack.redhat.com/forum/discussion/500/rdo-install-issues-on-f19-eth1-django14/p1

Comment 3 Lars Kellogg-Stedman 2015-03-27 01:58:20 UTC
If "packstack --allinone" is failing, that is an actual problem and we should try to correct it.  But if you are encountering this error on a multi-node install, I'm not sure that there's any sane way for packstack to select among multiple interfaces.

The solution in this latter case is to run "packstack --gen-answer-file answers.txt" and then edit the answers file appropriately before running packstack.

Can you confirm whether or not this was a --allinone install?

Comment 4 Yaniv Kaul 2015-03-27 17:33:41 UTC
I was not using an allinone.
But I think a reasonable hidden assumption is that it should be the correct value of the node I'm running packstack on.

Comment 5 Lars Kellogg-Stedman 2015-04-03 13:56:49 UTC
If you're not performing an all-in-one install you are already explicitly setting a number of configuration options.  Furthermore, in a system with multiple interfaces -- as in your example, or in rbowen's example -- there is *no way* for Packstack to intelligently select which of the available interfaces should be used for this option.

I think it makes sense that we require CONFIG_NOVA_NETWORK_PRIVIF to be set explicitly.


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