Open Stack

Sorry, I meant "Tuesday".


On 19 August 2015 at 10:51, Jaume Devesa <devvesa at gmail.com> wrote:

> 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
>



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