Open Stack

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