Open Stack

Thanks Steven.

I've registered the blueprint:

https://blueprints.launchpad.net/tripleo/+spec/midonet-deployment-support

We'll start preparing the pseudo-thirdparty job, develop the feature and
bother you guys in the IRC
channel as soon as you approve the blueprint.

Can we discuss it next Thursday on the IRC meeting?

On 18 August 2015 at 18:14, Steven Hardy <shardy at redhat.com> wrote:

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



-- 
Jaume Devesa
Software Engineer at Midokura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150819/4a8ca9c1/attachment.html>