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

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

(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/

(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.

(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.

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.

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

I am confused now, are you saying that the current documentation for OSP11 and ovs2.6 is not working?

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.

(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.