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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev