Bug 1117276 - Test Foreman/RHEL OSP on RHEL 7 nodes where Network Manager is NOT disabled
Summary: Test Foreman/RHEL OSP on RHEL 7 nodes where Network Manager is NOT disabled
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhel-osp-installer
Version: 5.0 (RHEL 7)
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: Installer
Assignee: Mike Burns
QA Contact: Omri Hochman
URL:
Whiteboard:
Depends On: 1117539 1119052
Blocks: 1117277
TreeView+ depends on / blocked
 
Reported: 2014-07-08 12:38 UTC by Perry Myers
Modified: 2018-12-06 17:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1117277 (view as bug list)
Environment:
Last Closed: 2016-04-19 01:29:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Perry Myers 2014-07-08 12:38:17 UTC
Description of problem:
RHEL OSP 5 on RHEL 6 and RHEL 7 require that Network Manager be disabled.  This was primarily due to lack of resources to determine what issues would arise with NM enabled.

We should reenable NM and uncover any issues that arise.  This bug serves as an overall Tracker for issues encountered relating to NM usage when Foreman is deploying nodes or when Foreman is deploying onto nodes where NM is present.

Comment 1 Perry Myers 2014-07-08 12:39:10 UTC
Note: The concrete code change for this specific bugzilla is to change the kickstarts that come with Foreman to include NM in the definition.

Comment 2 Perry Myers 2014-07-09 17:07:05 UTC
Notes from mangelajo about possible sources of problems w/ OVS:

"Services that work with neutron-openvswitch-agent dynamically create ports in OVS, and wire those to bridges which are handled by that agent.

An important requisite with Network Manager is that it won't interfere with the setup, creation and handling of those dynamically created ports. Also, it's important that NM wont't generate excessive load while those ports are discovered and/or inspected.

We have seen problems where the network service was restarted: (something) was tearing down/up the ovs-bridges ripping out the ports connected to it, and making a big mess for neutron-l3-agent and neutron-openvswitch-agent."

Comment 3 Lars Kellogg-Stedman 2014-08-06 22:58:29 UTC
A problem we encountered was that NetworkManager would kill the running puppet agent if a puppet class made changes to the interface over which puppet was connected to the puppet master.

Specfically, if one was attempting to use eth0 as the "external" interface and this was *also* the provisioning interface, NetworkManager would kill puppet when it detected link loss on this interface caused by the process of moving it into the br-ex OVS bridge.

The end result was that (a) the puppet run would be cancelled and (b) the system would be left without network connectivity, because Puppet died before completing the interface configuration.


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