OpenStack Queens split control plane gotcha #3 – split OVN services

So here’s the third gotcha I’ve run into. For background, I’m trying to deploy a ‘split’ OpenStack control plane in OpenStack Queens using ML2+OVN – 3x nodes running all Pacemaker-managed services, and 3x nodes running the non-Pacemaker services (e.g. Keystone, Neutron Server, etc).

The problem is that the Neutron API service – which deploys the neutron-server-ovn image – requires the NeutronCorePlugin service. This in turn runs a puppet manifest that will fail because of a missing piece of hieradata – ovn::northbound::port.

neutron-server-ovn (the OS::TripleO::Services::NeutronAPI service) needs the northbound port in order to set up the logical flows in the northbound DB. When running in a monolithic controller model this is already available, thanks to the OS::TripleO::Services::OVNDBs service.

In a split model OVNDBs is split away from NeutronAPI, necessitating a change.

The simple fix is adjusting the /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-ovn.yaml like so:

--- a/neutron-plugin-ml2-ovn.yaml.old
+++ b/neutron-plugin-ml2-ovn.yaml
@@ -30,6 +30,10 @@ parameters:
     description: Mapping of service endpoint -> protocol. Typically set
                  via parameter_defaults in the resource registry.
     type: json
+  OVNNorthboundServerPort:
+    description: Port of the OVN Northbound DB server
+    type: number
+    default: 6641
     description: Port of the OVN Southbound DB server
     type: number
@@ -108,6 +112,7 @@ outputs:
           - get_attr: [NeutronMl2Base, role_data, config_settings]
           - ovn::southbound::port: {get_param: OVNSouthboundServerPort}
+            ovn::northbound::port: {get_param: OVNNorthboundServerPort}
             neutron::plugins::ml2::ovn::ovsdb_connection_timeout: {get_param: OVNDbConnectionTimeout}
             neutron::plugins::ml2::ovn::neutron_sync_mode: {get_param: OVNNeutronSyncMode}
             neutron::plugins::ml2::ovn::ovn_l3_mode: true

A simple adjustment, adding the missing piece of hieradata to the resource, and the required parameter.

Now the hieradata is deployed onto the non-Pacemaker nodes:

[root@os1-ospservices-0 hieradata]# pwd
[root@os1-ospservices-0 hieradata]# grep -r "ovn::northbound"
service_configs.json:    "ovn::northbound::port": 6641,

So while I did get a clean stack deploy from this, I’m yet to test what the overall results are. That’s the next job: actually verify that OVN in a split controller model is working as it should.

Tempest should come in handy here.

Leave a Reply

Your email address will not be published. Required fields are marked *