On Tue, Aug 18, 2015 at 05:59:44PM +0200, Jaume Devesa wrote: > 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`?
It depends, if your additions require additional packages to be installed, then you may need to either add them to an existing element, or create a new element which may be specified by those building images with diskimage-builder, e.g so their images contain what you require. https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller If your integration purely requires configuration changes (and the puppet module already exists in the image), you may not need to do anything. > * Since the integration seems feasible, does it make sense to start opening a > blueprint and start working on it? Absolutely, a blueprint is probably a good idea (although tbh these haven't been strictly required lately..) summarising the required changes, then you can use the examples I linked to work on the template changes. > > 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...) Yes, this was exactly what I had in mind - it'd be great if we could get some sort of non-voting comments from those contributing third-party additions - I know this pattern works well for other projects, so I guess the same approach for TripleO may be reasonable as well. 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