This bug has been partially fixed in RHOS 4 0-day RC.  The service is not started but it is still chkconfig on.  This means it will start on reboot and that openstack-status shows it as dead. This should not be started AND chkconfig off.

So this patch to controller.pp will disable openvswitch on the controller node only. It is not the test solution because the service is originally added as a resource in vswitch::ovs. However, that file exists in stackforge/packstack.  If we want a quick and dirty local solution this will work:

[jliberma@se-users neutron]$ cat controller.pp.p0 
--- controller.pp.orig	2014-03-13 12:20:44.814509341 -0400
+++ controller.pp	2014-03-13 12:21:23.152511758 -0400
@@ -206,4 +206,9 @@
     dport    => ['9696'],
     action   => 'accept',
   }
+
+  service { 'openvswitch':
+    enable => false,
+  }
+  
 }

The drawback to doing it this way is that any class that calls neutron/controller.pp will have this service disabled. Right now there are no hosts that do this. However, we may see a problem with an all-in-one configuration that uses Neutron or perhaps a Cisco plugin that requires openvswitch.

You can test by patching the manifest, adding a host to the "neutron controller" host group, and then running "puppet resource service openstack" with the following expected output:

service { 'openvswitch':
  ensure => 'stopped',
  enable => 'false',
}

If this is acceptable I will submit a merge request for astapor. I will describe the better solution that involves stackforge/packstack in a subsequent comment.

So this solution requires a patch to /usr/share/packstack/modules/vswitch/manifests/ovs.pp as well as /usr/share/openstack-foreman-installer/puppet/modules/quickstack/manifests/neutron/controller.pp.

We add a parameter to the class vswitch::ovs called ovs_enable which we can use to conditionally disable/enable openvswitch.

This is helpful in the case of the neutron controller where openvswitch should be installed but not running.

The advantage of this parameterized approach is that openvswitch can be conditionally enabled or disabled. This would be useful for an all-in-one deployment or if there are networking plugins (such as Cisco) where openvswitch should be installed but disabled.

ovs.pp.p0:
--- ovs.pp.orig	2014-03-13 12:32:23.884917627 -0500
+++ /pub/projects/rhos/havana/scripts/jliberma/bz1041970/ovs.pp	2014-03-13 12:13:20.844779350 -0500
@@ -1,7 +1,9 @@
+# /usr/share/packstack/modules/vswitch/manifests/ovs.pp
 # vswitch: open-vswitch
 #
 class vswitch::ovs(
-  $package_ensure = 'present'
+  $package_ensure = 'present',
+  $ovs_enable = true
 ) {
 
   include 'vswitch::params'
@@ -14,8 +16,8 @@
         package { $kernelheaders_pkg: ensure => $package_ensure }
       }
       service {'openvswitch':
-        ensure      => true,
-        enable      => true,
+        ensure      => $ovs_enable, 
+        enable      => $ovs_enable,
         name        => $::vswitch::params::ovs_service_name,
         hasstatus   => false, # the supplied command returns true even if it's not running
         # Not perfect - should spot if either service is not running - but it'll do
@@ -31,8 +33,8 @@
     }
     'Redhat': {
       service {'openvswitch':
-        ensure      => true,
-        enable      => true,
+        ensure      => $ovs_enable,
+        enable      => $ovs_enable,
         name        => $::vswitch::params::ovs_service_name,
       }
     }

Patch controller.pp.p1:
--- controller.pp.orig	2014-03-13 12:20:44.814509341 -0400
+++ controller.pp	2014-03-13 13:15:46.166674587 -0400
@@ -206,4 +206,8 @@
     dport    => ['9696'],
     action   => 'accept',
   }
+
+  class { '::vswitch::ovs':
+    ovs_enable => false
+  }
 }

The drawback of this approach is that this parameter should be used everywhere in packstack and openstack-foreman where openvswitch is enabled or started. However, by default both are enabled, so it is likely that this patch will have no effect on any servers that have openvswitch installed and should be running it.

Also, calling this case from controller.pp executes all of the logic in this case, which is primarily a conditional expression to determine if you're installing openvswitch on a Debian or RedHat-based system.

"
This bug was closed as part of a backlog clean up.
If you see value in tracking this bug please re-open it.
"