Bug 1469686 - OVS 2.7.1 always fails to start
OVS 2.7.1 always fails to start
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openvswitch (Show other bugs)
11.0 (Ocata)
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Vijay Chundury
Ofer Blaut
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-11 11:51 EDT by fiezzi
Modified: 2017-07-13 04:57 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-13 04:57:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description fiezzi 2017-07-11 11:51:30 EDT
Description of problem:
OVS 2.7.1 in BREW lacks some error checking
file /usr/share/openvswitch/scripts/ovs-ctl at line 246

The following is the current code
umask 0002 && start_daemon "$OVS_VSWITCHD_PRIORITY" "$OVS_VSWITCHD_WRAPPER" "$@"
    return 1

Clearly, OVS cannot start, it always returns 1, no meter the real exit code.

The following is the correct code
umask 0002 && start_daemon "$OVS_VSWITCHD_PRIORITY" "$OVS_VSWITCHD_WRAPPER" "$@" ||
    return 1

The following is the upstream code
https://github.com/openvswitch/ovs/blob/branch-2.7/utilities/ovs-ctl.in

Version-Release number of selected component (if applicable):
At this morning openvswitch-2.7.1-1.git20170710.el7fdb.x86_64

How reproducible:
Perform a clean OVS 2.7.1 installation and try to start it. Somehow upgrading from 2.6 to 2.7 there is no issue. It looks like the ovs-ctl is not upgraded.

Actual results:
ovs always fails to start

Expected results:
ovs should start without any issue
Comment 1 fiezzi 2017-07-11 11:58:38 EDT
Ops, my bad. I just realized this is a documentation bug.

This happens because 

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html-single/network_functions_virtualization_configuration_guide/#ap-ovsdpdk-vxlan-first-boot

in the function set_ovs_config

the last sed lacks the double ||

 sed -i 's/start_daemon \"\$OVS_VSWITCHD_PRIORITY.*/umask 0002 \&\& start_daemon \"$OVS_VSWITCHD_PRIORITY\" \"$OVS_VSWITCHD_WRAPPER\" \"$@\"/' $ovs_ctl_path

it should be

 sed -i 's/start_daemon \"\$OVS_VSWITCHD_PRIORITY.*/umask 0002 \&\& start_daemon \"$OVS_VSWITCHD_PRIORITY\" \"$OVS_VSWITCHD_WRAPPER\" \"$@\" ||/' $ovs_ctl_path
Comment 2 Flavio Leitner 2017-07-11 21:04:06 EDT
Hi,

First of all, it is bad practice to modify files shipped by another package. The files will show as ``modified´´ which is unexpected and the changes will get lost when the package is updated or re-installed.

If it's possible to improve that at this point, OVS team would be glad to help.
Feel free to start a discussion on Red Hat's OVS devel mailing list.

I am reassigning to Vijay since this is not a bug in OVS package.

Thanks,
fbl
Comment 3 Saravanan KR 2017-07-12 06:20:01 EDT
(In reply to Flavio Leitner from comment #2)
> Hi,
> 
> First of all, it is bad practice to modify files shipped by another package.
> The files will show as ``modified´´ which is unexpected and the changes will
> get lost when the package is updated or re-installed.
> 
> If it's possible to improve that at this point, OVS team would be glad to
> help.
> Feel free to start a discussion on Red Hat's OVS devel mailing list.
> 
This workaround has already been raised with Aaron and he has proposed a patch to fix it - https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/333423.html

https://bugzilla.redhat.com/show_bug.cgi?id=1459436

For now, there no other way possible other than modifying the service file. We are hoping that we will get a better solution to remove this workaround.


This BZ has been raised against OSP11. As per our understanding, OvS2.7 will be used from OSP12 onwards. Correct me if I am wrong. 

For OSP12, we are fixing this issue via templates, no need of documentation and first-boot scripts - https://review.openstack.org/#/c/478163/
Comment 4 Flavio Leitner 2017-07-12 08:37:10 EDT
(In reply to Saravanan KR from comment #3)
> For now, there no other way possible other than modifying the service file.
> We are hoping that we will get a better solution to remove this workaround.

systemd gives a priority to the services in /etc, so you can create a host-specific services in there: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html
"9.6.2. Creating Custom Unit Files"

That leaves OVS services intact, you can do the necessary changes, and it survives upgrades/re-installs.
Comment 5 fiezzi 2017-07-12 09:28:54 EDT
(In reply to Saravanan KR from comment #3)
> (In reply to Flavio Leitner from comment #2)
> > Hi,
> > 
> > First of all, it is bad practice to modify files shipped by another package.
> > The files will show as ``modified´´ which is unexpected and the changes will
> > get lost when the package is updated or re-installed.
> > 
> > If it's possible to improve that at this point, OVS team would be glad to
> > help.
> > Feel free to start a discussion on Red Hat's OVS devel mailing list.
> > 
> This workaround has already been raised with Aaron and he has proposed a
> patch to fix it -
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/333423.html
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1459436
> 
> For now, there no other way possible other than modifying the service file.
> We are hoping that we will get a better solution to remove this workaround.
> 
> 
> This BZ has been raised against OSP11. As per our understanding, OvS2.7 will
> be used from OSP12 onwards. Correct me if I am wrong. 
> 
> For OSP12, we are fixing this issue via templates, no need of documentation
> and first-boot scripts - https://review.openstack.org/#/c/478163/

I believe that from a pure documentation standpoint we should fix the issue in the OSP11 downstream docs.
OSP12 will be another story but the fact that the current docs is buggy makes a lot of confusion.
Comment 6 Saravanan KR 2017-07-13 03:31:34 EDT
OSP11 with OvS2.7? That is something which will not work as it requires lot of other changes for DPDK, as we need to add devargs to the os-net-config, which we are working upstream.
Comment 7 fiezzi 2017-07-13 03:34:41 EDT
The downstream public documentation would make fail whatever OVS version.
It doesn't matter 2.7 or 2.6.

Please look at the first comment.
https://bugzilla.redhat.com/show_bug.cgi?id=1469686#c1
Comment 8 Saravanan KR 2017-07-13 03:37:40 EDT
I am confused now, are you saying that the current documentation for OSP11 and ovs2.6 is not working?
Comment 9 fiezzi 2017-07-13 04:05:16 EDT
I apologize, that's my bad at all.
Please ignore this BZ, anyways this will be somehow managed upstream either in the tripleo templates or with an RHEL specific OVS patch.

Sorry again for the mistake.
Comment 10 Saravanan KR 2017-07-13 04:56:55 EDT
(In reply to Flavio Leitner from comment #4)
> (In reply to Saravanan KR from comment #3)
> > For now, there no other way possible other than modifying the service file.
> > We are hoping that we will get a better solution to remove this workaround.
> 
> systemd gives a priority to the services in /etc, so you can create a
> host-specific services in there: 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/
> html/System_Administrators_Guide/sect-Managing_Services_with_systemd-
> Unit_Files.html
> "9.6.2. Creating Custom Unit Files"
> 
> That leaves OVS services intact, you can do the necessary changes, and it
> survives upgrades/re-installs.

It is applicable for service files, but there is as change for the ovs-vsctl script file too. I am not sure if that can also be absorbed here. But we will look in to it. Thanks.

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