Hi Steven/Emilien, Thanks for the quick responses.
On Tue, 18 Aug 2015 16:10, Steven Hardy wrote: > On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote: > > 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. Yes, we would like to be fully upstream on this. MidoNet plugin support for Puppet Neutron is already done since Kilo (and backported to Juno). We do have in mind Emilien's request. So I think that won't be a problem. > 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. The links and the steps to follow are so helpful! Thanks again. Couple of questions here: * There is no need of `tripleo-puppet-elements`? * Since the integration seems feasible, does it make sense to start opening a blueprint and start working on it? > > 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. Even if there is not an official Third Party methodology, it wouldn't be so hard to add a Jenkins job on our infrastructure to listen upstream gerrit events and make comments instead of voting, right? (maybe I am speaking so quickly, I can not image right now how a TripleO Jenkins job look like...) > > Let us know if you need any further help - you can drop in to #tripleo on > Freenode to discuss :) I'm already there :) > > 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 Regards! -- Jaume Devesa Software Engineer at Midokura __________________________________________________________________________ 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
