Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Regards!

-- 
Jaume Devesa
Software Engineer at Midokura