Bug 1124484
Summary: | Puppet fails on networker after br-ex is configured | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | John Eckersberg <jeckersb> |
Component: | openstack-foreman-installer | Assignee: | Jason Guiditta <jguiditt> |
Status: | CLOSED ERRATA | QA Contact: | Toni Freger <tfreger> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | Foreman (RHEL 6) | CC: | aberezin, jguiditt, lars, mburns, mhulan, morazi, rhos-maint, slong, yeylon |
Target Milestone: | z2 | Keywords: | Triaged |
Target Release: | Installer | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | openstack-foreman-installer-2.0.29-1.el6ost | Doc Type: | Known Issue |
Doc Text: |
If you attempt to use the same interface as your tunnel endpoint for GRE or VXLAN tenant networks AND as your external network interface, your initial deployment will succeed but subsequent puppet runs will generate the following error:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Local ip for ovs agent must be set when tunneling is enabled
This error occurs because when the interface is assigned to the bridge, the IP address configuration is moved to the bridge, but the puppet configuration is still trying to use the IP address of the interface.
Workaround: Do not use the same interface as your tunnel endpoint and as your external network interface.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2014-11-04 17:01:36 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
John Eckersberg
2014-07-29 15:19:41 UTC
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 |