[openstack-dev] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

Steven Hardy shardy at redhat.com
Tue Aug 18 15:10:19 UTC 2015


On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote:
> Hi all,
> 
> We in Midokura are considering to collaborate on TripleO to provide MidoNet as a
> backend technology for Neutron in the overcloud.
> 
> We haven't found any vendor plugin image defined on the
> `tripleo-puppet-elements` nor heat template in the `tripleo-heat-templates`...
> So my first question is: Is there willingness from the TripleO folks to accept
> code to deploy third-party vendors?  Alternatively (although not desirable): is
> there any plugin system to work out of the tree?
> 
> I'm a noob on TripleO, so I would need some guidance for next steps to follow to
> achieve our goal. I understand that work should be done on these three projects:
> 
>  * `tripleo-puppet-elements`: we do have a puppet module to configure MidoNet, I
>     understand an image to install the packages will be needed.
>  * `tripleo-heat-templates`: MidoNet and Neutron specific templates.

I think the pattern for the templates will be similar to the Cisco ML2
plugins which are currently being integrated:

https://review.openstack.org/#/c/198754/

The plug-points for third-party configuration is still undergoing some
refinement, but the basic steps are:

1. Ensure you have support in the upstream puppet modules (as mentioned by
Emilien), and figure out the hieradata required to drive puppet as
required.

2. Create a heat template which creates the hieradata, and defines
parameters for all configurable values, e.g like:

https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml

3. Define a heat environment file, which wires in the template from (2) via
the OS::TripleO::ControllerExtraConfigPre interface:

https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml

4. Add the hieradata file deployed via (2) to the controller hierarchy:

https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml

5. Add conditional logic to the manifiests so the appropriate modules from
(1) are included when your backend is enabled:

https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp
https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp

Basically the way this works is the hieradata is deployed via (2) before
puppet runs, and the manifiest changes in (5) consumes that data when we
apply it during deployment.

>  * `tuskar`?: will we need tuskar as well?

No, we're moving away from tuskar and it's not required for third-party
integration such as described above (it's also not covered in CI).

Speaking of CI, it'd be good to discuss how you plan to ensure your stuff
stays working, as clearly we don't have the resources in upstream CI to
test it, having third-party CI jobs vote on TripleO changes would be one
way to solve this, but AFAIK we don't yet have a process in place to enable
this.

Let us know if you need any further help - you can drop in to #tripleo on
Freenode to discuss :)

Steve



More information about the OpenStack-dev mailing list