Hide Forgot
Description of problem: After a successful run, all future puppet runs on the networker fail with: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Local ip for ovs agent must be set when tunneling is enabled at /etc/puppet/environments/production/modules/neutron/manifests/agents/ovs.pp:32 on node mac52540074c85b.example.org This is because puppet has (correctly) moved the IP address off of the physical interface and onto the bridge, so the ipaddress_eth1 fact becomes empty: [root@mac52540074c85b ~]# ip a s eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP qlen 1000 link/ether 52:54:00:4c:53:68 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe4c:5368/64 scope link valid_lft forever preferred_lft forever [root@mac52540074c85b ~]# ip a s br-ex 7: br-ex: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 52:54:00:4c:53:68 brd ff:ff:ff:ff:ff:ff inet 192.168.201.148/24 brd 192.168.201.255 scope global dynamic br-ex valid_lft 2532sec preferred_lft 2532sec inet6 fe80::5815:46ff:fe8b:aada/64 scope link valid_lft forever preferred_lft forever [root@mac52540074c85b ~]# facter ipaddress_eth1 [root@mac52540074c85b ~]# facter ipaddress_br_ex 192.168.201.148 Version-Release number of selected component (if applicable): openstack-foreman-installer-2.0.16-1.el6ost.noarch openstack-puppet-modules-2014.1-19.8.el6ost.noarch
So really what we want is logic like: if (eth0 is a member of a bridge) local_ip = ipaddress_BRIDGENAME else local_ip = ipaddress_eth0 endif
I just took a look at the facts on a configured node, and saw no references to ipaddress_<BRIDGE>, only the actual NICs and lo. Marek, does any of the recent network enhancements on the foreman side add facts for bridges? If not, we may need to create our own custom fact here.
We don't add any bridge facts, on the other hand, bridge facts are standard part of facter output. Recent changes in foreman create bridge devices in Foreman so they could be used for puppet parameters. But if the bridge is created after initial run, I'm not sure we are able to modify these parameters afterwards, since the network interfaces are assigned to subnets before deploy is triggered. Maybe we could do it during the deployment process, Scott Seago would probably know better.
Patch posted: https://github.com/redhat-openstack/astapor/pull/383
merged
Hi, I am trying to verify this bug. There were several changes since this bug opened. When I try to put External and Tenant networks under the same subnet, I get an error message: "Tenant: Subnet cannot be shared with other traffic types in this deployment." I suggest to close this bug, since this configuration blocked in the Staypuft GUI.
@summer - The patch actually fixes the behavior, so once the ip gets moved to the bridge (which only happens when you are not using a provider network, which I believe is the default in Staypuft now), subsequent puppet runs _do_ now work. The puppet code will now check for the ip on both the bridge and the nic-to-be-bridged, returning an ip from whichever one it finds the IP on. @toni - I am not sure if you still need info here, as I see you marked it verfied after the request? The way to test this is in staypuft via advanced parameters, set the external_network_bridge to 'br-ex' (or any other name you want to call the bridge). Previously, this would work fine on the first pass, but subsequent runs would fail. This should no longer be the case. In my opinion, this was a valid bug which is now corrected.
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://rhn.redhat.com/errata/RHBA-2014-1800.html