Sorry, I meant "Tuesday".
On 19 August 2015 at 10:51, Jaume Devesa <devv...@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 <sha...@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-requ...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
