Bug 1514574

Summary:	Adding GRE Support To Existing Deployment Fails
Product:	Red Hat OpenStack	Reporter:	Dan Sneddon <dsneddon>
Component:	rhosp-director	Assignee:	Brent Eagles <beagles>
Status:	CLOSED WONTFIX	QA Contact:	Amit Ugol <augol>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	10.0 (Newton)	CC:	amuller, aschultz, bfournie, dbecker, jlibosva, mburns, morazi, rhel-osp-director-maint
Target Milestone:	zstream	Keywords:	Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-07-17 14:26:11 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 Dan Sneddon 2017-11-17 19:21:59 UTC

Description of problem:
In OSP 10, when an operator adds GRE to the Neutron network/tunnel types and performs a stack update, the Compute nodes do not work for GRE networks.

Version-Release number of selected component (if applicable):
OSP 10, possibly newer versions

How reproducible:


Steps to Reproduce:
1. Deploy RHOSP with VLAN and VXLAN networking
2. Modify NeutronNetworkType and NeutronTunnelTypes to include 'gre'
3. Perform stack update

Actual results:
After stack update, operator can create GRE networks, but when trying to deploy VMs on GRE networks, no compute nodes are found that can support GRE.

Expected results:
The operator should be able to launch instances on GRE networks after updating the stack to include GRE network types.

Additional info:

Comment 3 Brent Eagles 2017-12-04 14:04:13 UTC

By the wording of the bug report, this looks like the openvswitch agents on the compute nodes aren't being restarted on the compute nodes to accept the new configuration. Investigating...

Comment 4 Assaf Muller 2018-07-17 14:26:11 UTC

After talking to Brent, we understand that this does work for 13. Since a workaround exists for 10 (restarting OVS agents on all nodes post stack-update), I think that investing time in a fix specific to OSP 10 fails prioritization considerations.