RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1601795 - ovn-controller CLI request - remove chassis from the ovn south database
Summary: ovn-controller CLI request - remove chassis from the ovn south database
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openvswitch
Version: 7.5
Hardware: All
OS: All
low
low
Target Milestone: rc
: ---
Assignee: Mark Michelson
QA Contact: haidong li
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-17 09:12 UTC by Miguel Duarte Barroso
Modified: 2020-01-14 22:41 UTC (History)
11 users (show)

Fixed In Version: openvswitch-2.9.0-75.el7fdn
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-02 17:54:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0014 0 None None None 2019-01-02 17:54:52 UTC

Description Miguel Duarte Barroso 2018-07-17 09:12:50 UTC 
Description of problem:
When the ovn-controller is stopped, the chassis entry is removed from the ovn-sb database, which results in the ovn-tunnel being removed, leading to ovn traffic interruption.

The "stop" command should not cause the tunnel to be removed, since that leads to traffic interruption during ovn-controller restarts.

Another command (CLI would do) should be provided to remove the chassis entry from the sb table, since that is useful for a set of use cases.


Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. stop the ovn controller


Actual results:
The chassis is removed from the ovn-sb database when the ovn-controller is stopped.


Expected results:
The chassis is *not* removed from the ovn-sb database. An alternative for the ovn-controller to easily remove itself from the ovn-sb database should be provided (ovn-controller CLI command, for example).

Additional info:
Comment 2 Mark Michelson 2018-07-17 13:49:05 UTC 
I think the best way to do this is to add some new flag when exiting the ovn-controller process that allows for the chassis to remain in the southbound database instead of being removed. This way, you can pass this flag in when restarting ovn-controller and not pass this flag in when shutting down ovn-controller. Does this sound like a reasonable approach to you?
Comment 3 Miguel Duarte Barroso 2018-07-18 08:16:46 UTC 
It does. Thanks for the prompt response.
Comment 4 Mark Michelson 2018-07-25 12:13:34 UTC 
I've posted a patch for review.

The first patch allows for you to call `ovs-appctl -t ovn-controller exit --restart` in order to have the exit not clean up databases.

The second patch alters ovn-ctl so that if you call `ovn-ctl restart_controller`, then '--restart' is passed to the command to exit ovn-controller.

I will update this issue as reviews come in.
Comment 5 Mark Michelson 2018-07-25 12:14:01 UTC 
Apologies, I left the link out of my previous comment: https://patchwork.ozlabs.org/project/openvswitch/list/?series=57394
Comment 6 Mark Michelson 2018-08-03 17:00:07 UTC 
This patch has been merged upstream in OVS master and 2.10
Comment 7 Mark Michelson 2018-08-13 12:28:37 UTC 
Dan has asked me to clarify what was added for QE's benefit.

The change added makes it so that you can optionally stop ovn-controller without tearing down tunnels. You can do this in one of two ways:

`ovs-appctl -t ovn-controller exit --restart`

This will exit ovn-controller and not tear down its tunnels. When you start ovn-controller back up again, it will start back up smoothly and re-use what it had already created.

The other thing you can do is to issue:

`ovn-ctl restart_controller`

This will issue the previous ovs-appctl command and then start ovn-controller again. It is a shortcut method for issuing the stop and start manually.

Any other methods used to stop the ovn-controller (e.g. initd or systemctl) will not pass the --restart flag and will still tear down tunnels.
Comment 12 haidong li 2018-11-22 09:58:37 UTC 
Hi Mark,I met some issue when I test the command "ovn-ctl restart_controller",the ovn-controller can't be up after it.Is there any configuration I missed?

[root@dell-per730-19 scripts]# ./ovn-ctl restart_controller
Exiting ovn-controller (113959) [  OK  ]
Starting ovn-controller [  OK  ]
[root@dell-per730-19 ~]# systemctl status ovn-controller
● ovn-controller.service - OVN controller daemon
   Loaded: loaded (/usr/lib/systemd/system/ovn-controller.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

Nov 22 04:07:13 dell-per730-19.rhts.eng.pek2.redhat.com systemd[1]: Starting ...
Nov 22 04:07:13 dell-per730-19.rhts.eng.pek2.redhat.com ovn-ctl[22868]: Start...
Nov 22 04:07:13 dell-per730-19.rhts.eng.pek2.redhat.com systemd[1]: Started O...
Nov 22 04:28:08 dell-per730-19.rhts.eng.pek2.redhat.com systemd[1]: Stopping ...
Nov 22 04:28:08 dell-per730-19.rhts.eng.pek2.redhat.com ovn-ctl[100063]: Exit...
Nov 22 04:28:08 dell-per730-19.rhts.eng.pek2.redhat.com systemd[1]: Stopped O...
Nov 22 04:30:39 dell-per730-19.rhts.eng.pek2.redhat.com systemd[1]: Starting ...
Nov 22 04:30:39 dell-per730-19.rhts.eng.pek2.redhat.com ovn-ctl[113947]: Star...
Nov 22 04:30:39 dell-per730-19.rhts.eng.pek2.redhat.com systemd[1]: Started O...
Nov 22 04:54:56 dell-per730-19.rhts.eng.pek2.redhat.com ovn-ctl[43269]: ovn-c...
Hint: Some lines were ellipsized, use -l to show in full.

[root@dell-per730-19 scripts]# systemctl start ovn-controller
Job for ovn-controller.service failed because the control process exited with error code. See "systemctl status ovn-controller.service" and "journalctl -xe" for details.
Comment 13 Mark Michelson 2018-12-05 18:01:29 UTC 
I think there is probably a mismatch in state between the actual state of ovn-controller and systemd.

If you started ovn-controller using systemd, and then you run ovn-ctl restart_controller, then systemd is probably unaware that ovn-controller was restarted.

systemd does not make it easy to specify a custom method for restarting a service. You can specify how to stop a service and how to start a service. When you issue a `systemctl restart`, it stops the service and starts the service again.
Comment 14 haidong li 2018-12-06 05:32:02 UTC 
set the status to verified according to comment12 and comment13.
Comment 18 errata-xmlrpc 2019-01-02 17:54:40 UTC 
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://access.redhat.com/errata/RHBA-2019:0014
Note You need to log in before you can comment on or make changes to this bug.