Bug 1167329

AFAIK network configuration has to be only on network nodes.

(In reply to Martin Magr from comment #5)
> AFAIK network configuration has to be only on network nodes.

Please check the configuration example in comment 0 more closely.

I've now tested using RHEL 7 + RHEL OSP 7 with all available updates as of 2015-10-27 installed. On a KVM test setup this seemed to work ok but on HP BL460c G8 blades the compute nodes' network configuration was only partially updated meaning that packstack run never finished and the affected compute nodes became completely unreachable.

After recovering from this and using:

CONFIG_NEUTRON_OVS_BRIDGE_IFACES=
#br-eth0:eth0

packstack completes ok, then manually dropping the needed network configuration files in place and rebooting gives a working environment.

I'll attach unsanitized logs from a customer environment captured after the failed packstack run.

Actually, I think I know where the error comes from. Packstack should not try to configure br-ex in compute nodes, as this is not needed there.

The issue comes from https://github.com/openstack/packstack/blob/64170f16096bd6b9c487bd2a21de7bba6749c930/packstack/puppet/templates/neutron_ovs_agent.pp#L16-L24 , where bridge_uplinks and bridge_mappings are passed to class { '::neutron::agents::ml2::ovs':} regardless of whether this is a network node or a compute node.

I'm going to work on this, expect having a patch soon.

Proposed https://review.openstack.org/241753 with a fix.

We do not have ifcfg-br-eth0 on the compute

Marko, What is the exact desired behavior please? 

[CONTROLLER ~]# ll /etc/sysconfig/network-scripts/ifcfg-*
-rw-r--r--. 1 root root 222 Jun 14 08:40 /etc/sysconfig/network-scripts/ifcfg-br-eth0
-rw-r--r--. 1 root root  85 Jun 14 08:40 /etc/sysconfig/network-scripts/ifcfg-eth0
-rw-r--r--. 1 root root 254 Jan 15  2015 /etc/sysconfig/network-scripts/ifcfg-lo
[CONTROLLER ~]# rpm -qa | grep packst
openstack-packstack-puppet-2014.2-0.27.dev1474.gd85ee76.el7ost.noarch
openstack-packstack-2014.2-0.27.dev1474.gd85ee76.el7ost.noarch


[COMPUTE ~]# ll /etc/sysconfig/network-scripts/ifcfg-*
-rw-r--r--. 1 root root 126 Feb 24  2015 /etc/sysconfig/network-scripts/ifcfg-eth0
-rw-r--r--. 1 root root 254 Jan 15  2015 /etc/sysconfig/network-scripts/ifcfg-lo

(In reply to Alexander Stafeyev from comment #18)
> We do not have ifcfg-br-eth0 on the compute
> 
> Marko, What is the exact desired behavior please? 

I think Javier would be the best person to provide the definitive answer but please note that the version we now have in QA is missing the upstream patch which landed a bit earlier due to the change we did in this BZ earlier:

https://bugs.launchpad.net/packstack/+bug/1569360

So upstream added an additional option around this, should we perhaps backport it?

Thanks.

If we want to have the most complete behaviour, i.e. having ifcfg files created in all cases where a bridge is needed, plus having the bridges properly created for compute nodes only when required, then it gets a bit complicated.

It would require https://review.openstack.org/304052 and https://review.openstack.org/307403 backported all the way back to Juno (or Kilo?), and some documentation update to include the new CONFIG_NEUTRON_OVS_BRIDGE_COMPUTE answer-file option from the second patch.

Is this what's expected, or should we settle with fixing on a later release?

(In reply to Javier Peña from comment #20)
> 
> It would require https://review.openstack.org/304052 and
> https://review.openstack.org/307403 backported all the way back to Juno (or
> Kilo?), and some documentation update to include the new
> CONFIG_NEUTRON_OVS_BRIDGE_COMPUTE answer-file option from the second patch.
> 
> Is this what's expected, or should we settle with fixing on a later release?

I can't speak for others but considering how essential it is to configure networking properly (esp. for PackStack users of whom many are not intimately familiar with all the low level details) it would certainly be nice to have this fixed. OTOH, Juno/Kilo users are probably ok with what they've had all along so perhaps no point to backport so far.

IOW, I trust on your judgement on this.

Thanks.

(In reply to Marko Myllynen from comment #21)
> (In reply to Javier Peña from comment #20)
> > 
> > It would require https://review.openstack.org/304052 and
> > https://review.openstack.org/307403 backported all the way back to Juno (or
> > Kilo?), and some documentation update to include the new
> > CONFIG_NEUTRON_OVS_BRIDGE_COMPUTE answer-file option from the second patch.
> > 
> > Is this what's expected, or should we settle with fixing on a later release?
> 
> I can't speak for others but considering how essential it is to configure
> networking properly (esp. for PackStack users of whom many are not
> intimately familiar with all the low level details) it would certainly be
> nice to have this fixed. OTOH, Juno/Kilo users are probably ok with what
> they've had all along so perhaps no point to backport so far.
> 
> IOW, I trust on your judgement on this.
> 
> Thanks.

I would take the complete fix to Liberty and later, unless anyone is against that.

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.

https://access.redhat.com/errata/RHBA-2016:1260