Bug 1109894

Miguel, do you have a puppet manifest that i can check directly. I'm testing with packstack and can't reproduce it.

Ivan, I'm deploying from foreman,

Where should I get the manifests from?

Thanks.

Miguel,

I'm not very familiar with foreman so i don't know where the manifests go. 
I'll ask in #rhos-dev for help with that

Currently checking the environment in which this problem happened, it seems that the problem does not appear anymore.
I recommend try a fresh install and check if the problem appears again.

it seems to be a mismatch in the execution order of the manifest that creates br-ex and the one that uses it, checking the neutron puppet module

i'm testing some code in the neutron puppet module in order to control this but i haven't been able to control this properly.

So this is interesting.  On ajo's system, the following manifest will reproduce the problem:

    vs_bridge { 'br-ex': 
            ensure => present,
    }
    vs_port { 'eth1':
            ensure => present,
            bridge => 'br-ex',
    }

Like this:

    # puppet apply this_fails.pp
    Notice: Compiled catalog for networknode.rhel6-staypuft.com in environment production in 0.07 seconds
    Notice: /Stage[main]/Main/Vs_bridge[br-ex]/ensure: created
    Error: Could not set 'present' on ensure: undefined method `[]' for nil:NilClass at 7:/root/this_fails.pp
    Error: Could not set 'present' on ensure: undefined method `[]' for nil:NilClass at 7:/root/this_fails.pp
    Wrapped exception:
    undefined method `[]' for nil:NilClass
    Error: /Stage[main]/Main/Vs_port[eth1]/ensure: change from absent to present failed: Could not set 'present' on ensure: undefined method `[]' for nil:NilClass at 7:/root/this_fails.pp
    Notice: Finished catalog run in 0.13 seconds


But, if you first add an ip address to eth1:

    # ip addr add 10.12.13.14/24 dev eth1

And then run the manifest:

    # puppet apply this_fails.pp 
    Notice: Compiled catalog for networknode.rhel6-staypuft.com in environment production in 0.07 seconds
    Notice: /Stage[main]/Main/Vs_bridge[br-ex]/ensure: created
    Notice: /Stage[main]/Main/Vs_port[eth1]/ensure: created
    Notice: Finished catalog run in 4.15 seconds

It completes without errors.

I've confirmed this behavior on my own system...if the interface you are trying to add does not have an ip address, this fails reliably.

The problem is in lib/puppet/provider/ovs_port/ovs_redhat.rb, which does this:

        device = ip('addr', 'show', @resource[:interface])
        cidr = device.to_s.match(/inet (\d*\.\d*\.\d*\.\d*\/\d*)/)[1]
        IFCFG::BridgeStatic.new(@resource[:bridge], cidr).save

If the device has no ip adDress, "cidr" will be nil and the attempt to use "[1]" on it raises an exception.

nice catch Lars!!

This leaves us with this options to solve this problem:


- make <put your installer here> ask the user to set the ip address or set it to get it via dhcp and then add it to the respective manifest (this is my preference since gives the user explicit choices)

- make the puppet module try to get a ip address via dhcp if the interface does not have one.

- make the puppet module show an error if the interface does not have an ip address and ask the user to configure it.

I don't think there is any reason to require an address on this interface.  It is perfectly valid for there to be no ip address on the bridge and for the external network gateway to be elsewhere on the network.

I have submitted a simple change upstream to permit this module to work when the interface has no address:

  https://review.openstack.org/#/c/94504/

Testing patch on Miguel's environment

Tested patch in Miguel's environment and it works

Ivan confirms that this change fixes the behavior.

Note that my patch is a very small change to an existing review, which stems from https://bugzilla.redhat.com/show_bug.cgi?id=1095279.  Comments on that bz indicate that they are waiting for the upstream maintainer to return from PTO in order to merge these changes.

Verified : openstack-puppet-modules-2014.1-18.el6ost.noarch

Unable to reproduce the bug. I had successful neutron deployment with : 
   ovs_bridge_mappings = ["inter-vlan:br-eth3","ext-vlan:br-ex"]
   ovs_bridge_uplinks = ["br-eth3:eth3","br-ex:eth3.195"]


Checked also that the fix is in the Code :
 /var/lib/puppet/lib/puppet/provider/vs_port/ovs_redhat.rb
-------------------------------------
        device = ip('addr', 'show', @resource[:interface])
        cidr = device.to_s.match(/inet (\d*\.\d*\.\d*\.\d*\/\d*)/)
        cidr = cidr ? cidr[1] : ""
        IFCFG::BridgeStatic.new(@resource[:bridge], cidr).save



  def dynamic?
    device = ''
    device = ip('addr', 'show', @resource[:interface])
    return device =~ /dynamic/ ? true : false
  end

Current patch is also creating ifcfg files for bridge/port when not using physical interfaces, that breaking neutron

Latest upstream patch set https://review.openstack.org/#/c/94504/7/ addresses it.

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.

http://rhn.redhat.com/errata/RHEA-2014-0846.html

closed, no need for needinfo.