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 1511449 - [RFE] Add the ability to migrate manually NAPT switch to another node [NEEDINFO]
Summary: [RFE] Add the ability to migrate manually NAPT switch to another node
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: opendaylight
Version: 12.0 (Pike)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: lpeer
QA Contact: Noam Manos
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-09 11:53 UTC by Itzik Brown
Modified: 2019-03-06 16:17 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-06 16:16:20 UTC
itbrown: needinfo? (nyechiel)


Attachments (Terms of Use)

Description Itzik Brown 2017-11-09 11:53:37 UTC
Description of problem:
There should be an option to move a NAPT switch from one node to another.
For example when there is a need to bring a node down for maintenance.

Version-Release number of selected component (if applicable):
opendaylight-6.1.0-2.el7ost.noarch

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Aswin Suryanarayanan 2018-01-29 13:42:01 UTC
Itzik,

Would like to understand more about this. 

Do you want this to migrated when the switch enters maintenance mode. I assume the ovs change its state to maintenance and odl is notified. Nat service responds to the event and reschedules the NAPT switch.

Or do you want to make it a manual process? Where the switch will be rescheduled based on an API call? Where we remove this switch from the pool of switches from which we select  NAPT switch? or we have different expectation?

Comment 3 Itzik Brown 2018-01-29 14:32:48 UTC
My expectation is that we can disable a switch and then either the routers will be migrated automatically (preferred) or manually.

Comment 4 Aswin Suryanarayanan 2018-01-30 14:24:26 UTC
Disable switch is kind of bringing down the switch?

One other option would be reuse the parameter in [1], "odl_base_weight".
This will be configured in "external_ids" parameter of "Open_vSwitch" table. 

We can think of adding support to change this weight dynamically. At a given point of time switches with the lowest weight will be selected as a NAPT switch. Weight will be incremented by a factor of 1 for each NAPT switch scheduled.


To change the existing NAPT switch, this weight can be made high before maintenance.


Does this proposal looks acceptable?

[1]https://github.com/opendaylight/netvirt/blob/master/docs/specs/weighted-napt-selection.rst

Comment 5 Itzik Brown 2018-01-31 08:37:38 UTC
Using the weight parameter will only be used for new routers , right?

Comment 6 Aswin Suryanarayanan 2018-01-31 10:22:48 UTC
(In reply to Itzik Brown from comment #5)
> Using the weight parameter will only be used for new routers , right?

If the question is will netvirt listen for changes in the weight after router g/w is set?  currently it will not. We have to need add support for dynamic weight updation.

Comment 8 Franck Baudin 2019-03-06 16:16:20 UTC
As per depreciation notice [1], closing this bug. Please reopen if relevant for RHOSP13, as this is the only version shipping ODL.

[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/release_notes/index#deprecated_functionality

Comment 9 Franck Baudin 2019-03-06 16:17:40 UTC
As per depreciation notice [1], closing this bug. Please reopen if relevant for RHOSP13, as this is the only version shipping ODL.

[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/release_notes/index#deprecated_functionality


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