[Rdo-list] Query regarding RDO Juno-1 install on CentOS7

[Perry Myers]

On 12/29/2014 09:39 AM, Deepak Shetty wrote:
> 
> On Dec 29, 2014 8:00 PM, "Patrick Laimbock" <patrick at laimbock.com
> <mailto:patrick at laimbock.com>> wrote:
>>
>> On 29-12-14 14:06, Deepak Shetty wrote:
>>>
>>> Hi,
>>>    I was able to install 3-node RDO juno-1 (rdo-release-juno-1.noarch)
>>> over CentOS7, but at the end of install it gave me this ...
>>> Questions prefixed with Q: inline below:
>>>
>>> Additional information:
>>> * Time synchronization installation was skipped. Please note that
>>> unsynchronized time on server instances might be problem for some
>>> OpenStack components.
>>>
>>> *Q: Do i need to sue ntpd to ensure all my systems are in sync, whats
>>>
>>> the recommended way here ?*
>>
>>
>> All your nodes need to have the correct time. You can specify an NTP
> server in the Packstack answer file or as a CLI option and then
> Packstack will configure your nodes to use that NTP server. If you don't
> specify an NTP server then Packstack doesn't handle NTP so you will have
> to do it yourself. Either way, make sure that all nodes always have the
> correct time.
> 
> Thanks, will try this.
> 
>>
>>> * Warning: NetworkManager is active on <IP1>, <IP2> and <IP3>. OpenStack
>>> networking currently does not work on systems that have the Network
>>> Manager service enabled.
>>>
>>> *Q: Do i need to disable NetworkManager.service on all or is it safe to
>>>
>>> ignore this? What exactly doesn't work with NetworkManager ?
>>
>>
>> You need to disable NetworkManager and enable network service. Before
>> you run Packstack you will also need to setup the ifcfg-XXXX network
>> interfaces on all nodes and activate them.
> 
> Why can't packstack handle this itself if it doesn't support NM? I m
> concerned about the manual steps involved and losing on my n/w
> connections in case i do anything wrong.  Is there any reference on how
> to do this, i couldn't find anything specific on the quickstart page.

Packstack uses SSH to remotely configure hosts. Trying to disable NM and
enable standard ifcfg networking while using an ssh session is very
tricky and often results in hosts that have completely lost networking.
So, we don't attempt to do this. Instead, we recommend using a kickstart
to deploy your machines that disables NM at host install time

As for why NM needs to be disabled, there are a bunch of open bugs
against NM targeted at RHEL 7.1 (or maybe later) where NM and Neutron
networking conflict with each other. I think for Nova networking NM
might be fine, but for Neutron there are known issues.

Livnat might have a list of NM bugs handy that would need to be resolved
before we can begin looking at testing NM + Neutron together again to
determine if there are more issues lying in wait, or if we can
green-light that combination

Perry