Message ID | 1454094161-27707-1-git-send-email-guru@ovn.org |
---|---|
State | Rejected |
Headers | show |
On 29.01.2016 22:02, Guru Shetty wrote: > This reverts commit 9b5422a98f817b9f2a1f8224cab7e1a8d0bbba1f. > > Reason: > Calling 'ovs-appctl exit' on ovs-vswitchd will cause ovs-vswitchd > to destroy all the ports from the datapath. This is an unacceptable > behavior while restarting the daemons. Killing is more unacceptable here, because ovs with vhost-user port will not be able to open this port anymore. > Couple of reasons that come > to mind are: > > 1. Any configured ip addresses will be lost Why this can't be solved using network-scripts or something else? > 2. Traffic will stop flowing. I think, this was just a side effect. IMHO, stop of traffic flowing is an expected behaviour while you restarting the switch. Best regards, Ilya Maximets.
On 31 January 2016 at 23:24, Ilya Maximets <i.maximets@samsung.com> wrote: > On 29.01.2016 22:02, Guru Shetty wrote: > > This reverts commit 9b5422a98f817b9f2a1f8224cab7e1a8d0bbba1f. > > > > Reason: > > Calling 'ovs-appctl exit' on ovs-vswitchd will cause ovs-vswitchd > > to destroy all the ports from the datapath. This is an unacceptable > > behavior while restarting the daemons. > > Killing is more unacceptable here, because ovs with vhost-user port will > not be able to open this port anymore. > If 'ovs-appctl exit' solves the above problem, can one could argue that killing the daemon via SIGTERM should do the same? i.e you should register the cleanup functions that is so important for proper functioning after restart (irrespective of how this particular problem is solved). > > > Couple of reasons that come > > to mind are: > > > > 1. Any configured ip addresses will be lost > > Why this can't be solved using network-scripts or something else? > This is very hard since OVS runs on multiple hypervisors each with different way of configuring interfaces. > > > 2. Traffic will stop flowing. > > I think, this was just a side effect. IMHO, stop of traffic flowing > is an expected behaviour while you restarting the switch. > When OVS daemons are restarted, the flows in the kernel remain making old traffic continue to flow. There has been quite a bit of effort done to prevent traffic disruption during upgrades so you cannot introduce a regression here. I think it is probably easier to prevent 'ovs-appctl exit' from deleting the bridges in the first place. > > Best regards, Ilya Maximets. >
On Mon, Feb 01, 2016 at 08:05:33AM -0800, Guru Shetty wrote: > On 31 January 2016 at 23:24, Ilya Maximets <i.maximets@samsung.com> wrote: > > > On 29.01.2016 22:02, Guru Shetty wrote: > > > This reverts commit 9b5422a98f817b9f2a1f8224cab7e1a8d0bbba1f. > > > > > > Reason: > > > Calling 'ovs-appctl exit' on ovs-vswitchd will cause ovs-vswitchd > > > to destroy all the ports from the datapath. This is an unacceptable > > > behavior while restarting the daemons. > > > > Killing is more unacceptable here, because ovs with vhost-user port will > > not be able to open this port anymore. > > > If 'ovs-appctl exit' solves the above problem, can one could argue that > killing the daemon via SIGTERM should do the same? i.e you should register > the cleanup functions that is so important for proper functioning after > restart (irrespective of how this particular problem is solved). > > > > > > > Couple of reasons that come > > > to mind are: > > > > > > 1. Any configured ip addresses will be lost > > > > Why this can't be solved using network-scripts or something else? > > > This is very hard since OVS runs on multiple hypervisors each with > different way of configuring interfaces. > > > > > > > 2. Traffic will stop flowing. > > > > I think, this was just a side effect. IMHO, stop of traffic flowing > > is an expected behaviour while you restarting the switch. > > > When OVS daemons are restarted, the flows in the kernel remain making old > traffic continue to flow. There has been quite a bit of effort done to > prevent traffic disruption during upgrades so you cannot introduce a > regression here. > > > I think it is probably easier to prevent 'ovs-appctl exit' from deleting > the bridges in the first place. I'm going to try for that first.
On Fri, Jan 29, 2016 at 11:02:41AM -0800, Gurucharan Shetty wrote: > This reverts commit 9b5422a98f817b9f2a1f8224cab7e1a8d0bbba1f. > > Reason: > Calling 'ovs-appctl exit' on ovs-vswitchd will cause ovs-vswitchd > to destroy all the ports from the datapath. This is an unacceptable > behavior while restarting the daemons. Couple of reasons that come > to mind are: > > 1. Any configured ip addresses will be lost > 2. Traffic will stop flowing. > > Reported-by: Edgar Cantu <eocantu@us.ibm.com> > Signed-off-by: Gurucharan Shetty <guru@ovn.org> I prefer the following patch: https://patchwork.ozlabs.org/patch/579068/ I see I forgot to credit Edgar for reporting the problem. I'll fix that.
diff --git a/AUTHORS b/AUTHORS index 7ae64d3..a92b94f 100644 --- a/AUTHORS +++ b/AUTHORS @@ -277,6 +277,7 @@ David Palma palma@onesource.pt Derek Cormier derek.cormier@lab.ntt.co.jp Dhaval Badiani dbadiani@vmware.com DK Moon dkmoon@nicira.com +Edgar Cantu eocantu@us.ibm.com Edwin Chiu echiu@vmware.com Eivind Bulie Haanaes Eric Lopez elopez@nicira.com diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in index 773efb3..dd8a1e9 100644 --- a/utilities/ovs-lib.in +++ b/utilities/ovs-lib.in @@ -202,18 +202,11 @@ start_daemon () { stop_daemon () { if test -e "$rundir/$1.pid"; then if pid=`cat "$rundir/$1.pid"`; then - for action in EXIT .1 .25 .65 1 \ - TERM .1 .25 .65 1 1 1 1 \ - KILL 1 1 1 2 10 15 30 \ - FAIL; do + for action in TERM .1 .25 .65 1 1 1 1 KILL 1 1 1 2 10 15 30 FAIL; do if pid_exists "$pid" >/dev/null 2>&1; then :; else return 0 fi case $action in - EXIT) - action "Exiting $1 ($pid)" \ - ${bindir}/ovs-appctl -T 1 -t $rundir/$1.$pid.ctl exit - ;; TERM) action "Killing $1 ($pid)" kill $pid ;;
This reverts commit 9b5422a98f817b9f2a1f8224cab7e1a8d0bbba1f. Reason: Calling 'ovs-appctl exit' on ovs-vswitchd will cause ovs-vswitchd to destroy all the ports from the datapath. This is an unacceptable behavior while restarting the daemons. Couple of reasons that come to mind are: 1. Any configured ip addresses will be lost 2. Traffic will stop flowing. Reported-by: Edgar Cantu <eocantu@us.ibm.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org> --- AUTHORS | 1 + utilities/ovs-lib.in | 9 +-------- 2 files changed, 2 insertions(+), 8 deletions(-)