Bug 981153 - Physical NIC should be added to br-ex by hand.
Physical NIC should be added to br-ex by hand.
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack (Show other bugs)
3.0
Unspecified Unspecified
low Severity low
: async
: 4.0
Assigned To: Martin Magr
Nir Magnezi
: ZStream
Depends On:
Blocks: 981470
  Show dependency treegraph
 
Reported: 2013-07-04 02:46 EDT by Etsuji Nakai
Modified: 2016-04-26 11:38 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 981470 (view as bug list)
Environment:
Last Closed: 2014-01-07 12:21:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Etsuji Nakai 2013-07-04 02:46:50 EDT
Document URL: 
https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/3/html-single/Getting_Started_Guide/index.html#sect-Quick_Start_Deployment_using_PackStack

Section Number and Name: 
4.1. Quick Start Deployment using PackStack


Describe the issue: 
After the single node deployment with "packstack --allinone", the following OVS bridges are created for ovs-plugin agent.

===========
# ovs-vsctl show
ac567f64-8a31-4297-88a7-46369d8662c4
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
    ovs_version: "1.9.0"
===========

But a physical NIC used for the public network connection should be added to the br-ex by hand so that VM instances can access the public network.

# ovs-vsctl add-port br-ex eth1


In addition, this NIC should be different from the one used for API/management. (If you add API/management NIC to the bridge, it becomes inaccessible.)


Suggestions for improvement: 

1) Describe the following as a pre-req of single node deployment:

- The node needs to have at least two physical NICs connected to the same public network. We suppose they are eth0 and eht1 here.

- Assign IP address to eth0. This IP is used for API/management access.

- Bring up eth1 without assigning IP. Typically, this can be done with the following config file.

/etc/sysconfig/network-scripts/ifcfg-eth1
=============
DEVICE=eth1
HWADDR=00:40:26:BC:9A:AC
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
=============

2) Add the following step after "packstack --allinone".

# ovs-vsctl add-port br-ex eth1

Additional information: 

# rpm -qa | grep packstack
openstack-packstack-2013.1.1-0.20.dev632.el6ost.noarch

# rpm -qa | grep quantum
openstack-quantum-openvswitch-2013.1.2-3.el6ost.noarch
python-quantum-2013.1.2-3.el6ost.noarch
openstack-quantum-2013.1.2-3.el6ost.noarch
python-quantumclient-2.2.1-1.el6ost.noarch
Comment 2 Stephen Gordon 2013-07-04 16:35:00 EDT
With the exception of confirming that we can no longer support all-in-one on a system with only 1 NIC this bug primarily seems to refer to tasks that PackStack should be performing.
Comment 3 Dave Neary 2013-07-11 09:14:21 EDT
I can confirm that when you add eth0 to br-ex, the host is then inaccessible.

Is Steve correct when he says that we no longer support a single NIC install of OpenStack with PackStack/RDO?

Cheers,
Dave.
Comment 4 Stephen Gordon 2013-07-11 09:21:08 EDT
(In reply to Dave Neary from comment #3)
> I can confirm that when you add eth0 to br-ex, the host is then inaccessible.
> 
> Is Steve correct when he says that we no longer support a single NIC install
> of OpenStack with PackStack/RDO?
> 
> Cheers,
> Dave.

From my point of view it's an open question, I really don't want that to be the case but if I can't get accurate information from SMEs (or packstack updated to handle it) then I can't leave the documentation out there saying it will work.
Comment 5 Alvaro Lopez Ortega 2013-11-13 14:07:17 EST
This might be fixed already. Terry, could you please clarify it?
Comment 6 Terry Wilson 2013-11-13 16:30:38 EST
--allinone is not currently meant to be used off of the host machine with neutron. It sets up a double NAT to provide outbound access through whatever default gateway exists on the host, but this does not allow anything off of the host to access this address range.

To successfully use --allinone to do this, several manual steps must be done. For more details, see: http://openstack.redhat.com/Neutron_with_existing_external_network

which also suggests some improvements where we could make this less labor-intensive in the future.
Comment 7 Alvaro Lopez Ortega 2014-01-07 12:21:49 EST
Based on Terry's comments, we're closing this bug.

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