Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1514574 - Adding GRE Support To Existing Deployment Fails
Summary: Adding GRE Support To Existing Deployment Fails
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: zstream
: 10.0 (Newton)
Assignee: Brent Eagles
QA Contact: Amit Ugol
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-17 19:21 UTC by Dan Sneddon
Modified: 2018-07-17 14:26 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-17 14:26:11 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.