<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks Steven.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I've registered the blueprint:<br><br><a href="https://blueprints.launchpad.net/tripleo/+spec/midonet-deployment-support">https://blueprints.launchpad.net/tripleo/+spec/midonet-deployment-support</a><br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">We'll start preparing the pseudo-thirdparty job, develop the feature and bother you guys in the IRC<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">channel as soon as you approve the blueprint.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Can we discuss it next Thursday on the IRC meeting?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 August 2015 at 18:14, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Aug 18, 2015 at 05:59:44PM +0200, Jaume Devesa wrote:<br>
> Hi Steven/Emilien,<br>
><br>
> Thanks for the quick responses.<br>
><br>
> On Tue, 18 Aug 2015 16:10, Steven Hardy wrote:<br>
> > On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote:<br>
> ><br>
> > I think the pattern for the templates will be similar to the Cisco ML2<br>
> > plugins which are currently being integrated:<br>
> ><br>
> > <a href="https://review.openstack.org/#/c/198754/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/198754/</a><br>
> ><br>
> > The plug-points for third-party configuration is still undergoing some<br>
> > refinement, but the basic steps are:<br>
> ><br>
> > 1. Ensure you have support in the upstream puppet modules (as mentioned by<br>
> > Emilien), and figure out the hieradata required to drive puppet as<br>
> > required.<br>
><br>
> Yes, we would like to be fully upstream on this.  MidoNet plugin support for<br>
> Puppet Neutron is already done since Kilo (and backported to Juno). We do have<br>
> in mind Emilien's request. So I think that won't be a problem.<br>
><br>
> > 2. Create a heat template which creates the hieradata, and defines<br>
> > parameters for all configurable values, e.g like:<br>
> ><br>
> > <a href="https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml</a><br>
> ><br>
> > 3. Define a heat environment file, which wires in the template from (2) via<br>
> > the OS::TripleO::ControllerExtraConfigPre interface:<br>
> ><br>
> > <a href="https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml</a><br>
> ><br>
> > 4. Add the hieradata file deployed via (2) to the controller hierarchy:<br>
> ><br>
> > <a href="https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml</a><br>
> ><br>
> > 5. Add conditional logic to the manifiests so the appropriate modules from<br>
> > (1) are included when your backend is enabled:<br>
> ><br>
> > <a href="https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp</a><br>
> > <a href="https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp</a><br>
> ><br>
> > Basically the way this works is the hieradata is deployed via (2) before<br>
> > puppet runs, and the manifiest changes in (5) consumes that data when we<br>
> > apply it during deployment.<br>
><br>
> The links and the steps to follow are so helpful! Thanks again. Couple of<br>
> questions here:<br>
><br>
> * There is no need of `tripleo-puppet-elements`?<br>
<br>
</div></div>It depends, if your additions require additional packages to be installed,<br>
then you may need to either add them to an existing element, or create a<br>
new element which may be specified by those building images with<br>
diskimage-builder, e.g so their images contain what you require.<br>
<br>
<a href="https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller</a><br>
<br>
If your integration purely requires configuration changes (and the puppet<br>
module already exists in the image), you may not need to do anything.<br>
<span class=""><br>
> * Since the integration seems feasible, does it make sense to start opening a<br>
>   blueprint and start working on it?<br>
<br>
</span>Absolutely, a blueprint is probably a good idea (although tbh these haven't<br>
been strictly required lately..) summarising the required changes, then you<br>
can use the examples I linked to work on the template changes.<br>
<span class=""><br>
> > No, we're moving away from tuskar and it's not required for third-party<br>
> > integration such as described above (it's also not covered in CI).<br>
> ><br>
> > Speaking of CI, it'd be good to discuss how you plan to ensure your stuff<br>
> > stays working, as clearly we don't have the resources in upstream CI to<br>
> > test it, having third-party CI jobs vote on TripleO changes would be one<br>
> > way to solve this, but AFAIK we don't yet have a process in place to enable<br>
> > this.<br>
><br>
> Even if there is not an official Third Party methodology, it wouldn't be so hard<br>
> to add a Jenkins job on our infrastructure to listen upstream gerrit events and<br>
> make comments instead of voting, right? (maybe I am speaking so quickly, I can<br>
> not image right now how a TripleO Jenkins job look like...)<br>
<br>
</span>Yes, this was exactly what I had in mind - it'd be great if we could get<br>
some sort of non-voting comments from those contributing third-party<br>
additions - I know this pattern works well for other projects, so I guess<br>
the same approach for TripleO may be reasonable as well.<br>
<div class="HOEnZb"><div class="h5"><br>
Steve<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><font face="tahoma, sans-serif">Jaume Devesa</font><div><font face="tahoma, sans-serif">Software Engineer at Midokura</font></div></div></div>
</div>