Hi, I've been working on it lately, mainly adding idempotency and beaker jobs to the openstack/puppet-pacemaker version. Such a merge would be great. I'm in for such project.
Emilien Macchi <[email protected]> writes: > On Fri, Mar 18, 2016 at 10:55 AM, Dmitry Ilyin <[email protected]> wrote: >> Hello. >> >> I'm the author of fuel-infra/puppet-pacemaker and I guess I would be able to >> merge the code from "fuel-infra/puppet-pacemaker" to >> "openstack/puppet-pacemaker" >> We will be having a single set of pcmk_* types and two providers for the >> each type: "pcs" and "xml", there is also a "noop" provider. >> >> It would be possible to choose the implementation by specifying: >> >> pcmk_resource { 'my-resource' : >> provider => 'pcs', >> } >> >> or >> >> pcmk_resource { 'my-resource' : >> provider => 'xml', >> } > > I think that's our major differences indeed. > If you are interested, we can start to work together on > openstack/puppet-pacemaker, and add some experimental CI jobs for Fuel > (we already have TripleO jobs) gating the puppet-pacemaker module. > So together we could iterate by adding the pieces without breaking both > modules. > > If you want, we can chat about it on IRC, during a meeting or not, so > we can make progress on it during Newton cycle. > > Thanks a lot for your collaboration, > >> >> 2016-03-18 2:50 GMT+03:00 Andrew Woodward <[email protected]>: >>> >>> I'd be happy to see more collaboration here as well, I'd like to hear from >>> the maintainers on both sides identify some of what isn't implemented on >>> each so we can better decide which one to continue from, develop feature >>> parity and then switch to. >>> >>> On Thu, Mar 17, 2016 at 12:03 PM Emilien Macchi <[email protected]> >>> wrote: >>>> >>>> On Thu, Mar 17, 2016 at 2:22 PM, Sergii Golovatiuk >>>> <[email protected]> wrote: >>>> > Guys, >>>> > >>>> > Fuel has own implementation of pacemaker [1]. It's functionality may be >>>> > useful in other projects. >>>> > >>>> > [1] https://github.com/fuel-infra/puppet-pacemaker >>>> >>>> I'm afraid to see 3 duplicated efforts to deploy Pacemaker: >>>> >>>> * puppetlabs/corosync, not much maintained and not suitable for Red >>>> Hat for some reasons related to the way to use pcs. >>>> * openstack/puppet-pacemaker, only working on Red Hat systems, >>>> suitable for TripleO and previous Red Hat installers. >>>> * fuel-infra/puppet-pacemaker, which looks like a more robust >>>> implementation of puppetlabs/corosync. >>>> >>>> It's pretty clear Mirantis and Red hat, both OpenStack major >>>> contributors who deploy Pacemaker do not use puppetlabs/corosync but >>>> have their own implementations. >>>> Maybe it would be time to converge at some point. I see a lot of >>>> potential in fuel-infra/puppet-pacemaker to be honest. After reading >>>> the code, I think it's still missing some features we might need to >>>> make it work on TripleO but we could work together at establishing the >>>> list of missing pieces and discuss about implementing them, so our >>>> modules would converge. >>>> >>>> I don't mind using X or Y tool, I want the best one and it seems both >>>> of our groups have some expertise that could help to maybe one day >>>> replace puppetlabs/corosync code by Fuel & Red Hat's module. >>>> What do you think? >>>> >>>> > >>>> > -- >>>> > Best regards, >>>> > Sergii Golovatiuk, >>>> > Skype #golserge >>>> > IRC #holser >>>> > >>>> > On Sat, Feb 13, 2016 at 6:20 AM, Emilien Macchi >>>> > <[email protected]> >>>> > wrote: >>>> >> >>>> >> >>>> >> On Feb 12, 2016 11:06 PM, "Spencer Krum" <[email protected]> wrote: >>>> >> > >>>> >> > The module would also be welcome under the voxpupuli[0] namespace on >>>> >> > github. We currently have a puppet-corosync[1] module, and there is >>>> >> > some >>>> >> > overlap there, but a pure pacemaker module would be a welcome >>>> >> > addition. >>>> >> > >>>> >> > I'm not sure which I would prefer, just that VP is an option. For >>>> >> > greater openstack integration, gerrit is the way to go. For greater >>>> >> > participation from the wider puppet community, github is the way to >>>> >> > go. >>>> >> > Voxpupuli provides testing and releasing infrastructure. >>>> >> >>>> >> The thing is, we might want to gate it on tripleo since it's the first >>>> >> consumer right now. Though I agree VP would be a good place too, to >>>> >> attract >>>> >> more puppet users. >>>> >> >>>> >> Dilemma! >>>> >> Maybe we could start using VP, with good testing and see how it works. >>>> >> >>>> >> Iterate later if needed. Thoughts? >>>> >> >>>> >> > >>>> >> > [0] https://voxpupuli.org/ >>>> >> > [1] https://github.com/voxpupuli/puppet-corosync >>>> >> > >>>> >> > -- >>>> >> > Spencer Krum >>>> >> > [email protected] >>>> >> > >>>> >> > On Fri, Feb 12, 2016, at 09:44 AM, Emilien Macchi wrote: >>>> >> > > Please look and vote: >>>> >> > > https://review.openstack.org/279698 >>>> >> > > >>>> >> > > >>>> >> > > Thanks for your feedback! >>>> >> > > >>>> >> > > On 02/10/2016 04:04 AM, Juan Antonio Osorio wrote: >>>> >> > > > I like the idea of moving it to use the OpenStack >>>> >> > > > infrastructure. >>>> >> > > > >>>> >> > > > On Wed, Feb 10, 2016 at 12:13 AM, Ben Nemec >>>> >> > > > <[email protected] >>>> >> > > > <mailto:[email protected]>> wrote: >>>> >> > > > >>>> >> > > > On 02/09/2016 08:05 AM, Emilien Macchi wrote: >>>> >> > > > > Hi, >>>> >> > > > > >>>> >> > > > > TripleO is currently using puppet-pacemaker [1] which is a >>>> >> > > > module >>>> >> > > > hosted >>>> >> > > > > & managed by Github. >>>> >> > > > > The module was created and mainly maintained by Redhat. It >>>> >> > > > tends to >>>> >> > > > > break TripleO quite often since we don't have any gate. >>>> >> > > > > >>>> >> > > > > I propose to move the module to OpenStack so we'll use >>>> >> > > > OpenStack Infra >>>> >> > > > > benefits (Gerrit, Releases, Gating, etc). Another idea >>>> >> > > > would >>>> >> > > > be to >>>> >> > > > gate >>>> >> > > > > the module with TripleO HA jobs. >>>> >> > > > > >>>> >> > > > > The question is, under which umbrella put the module? >>>> >> > > > Puppet ? >>>> >> > > > TripleO ? >>>> >> > > > > >>>> >> > > > > Or no umbrella, like puppet-ceph. <-- I like this idea >>>> >> > > > >>>> >> > > > >>>> >> > > > I think the module not being under an umbrella makes sense. >>>> >> > > > >>>> >> > > > >>>> >> > > > > >>>> >> > > > > Any feedback is welcome, >>>> >> > > > > >>>> >> > > > > [1] https://github.com/redhat-openstack/puppet-pacemaker >>>> >> > > > >>>> >> > > > Seems like a module that would be useful outside of TripleO, >>>> >> > > > so >>>> >> > > > it >>>> >> > > > doesn't seem like it should live under that. Other than >>>> >> > > > that I >>>> >> > > > don't >>>> >> > > > have enough knowledge of the organization of the puppet >>>> >> > > > modules >>>> >> > > > to >>>> >> > > > comment. >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > __________________________________________________________________________ >>>> >> > > > OpenStack Development Mailing List (not for usage questions) >>>> >> > > > Unsubscribe: >>>> >> > > > >>>> >> > > > [email protected]?subject:unsubscribe >>>> >> > > > >>>> >> > > > >>>> >> > > > <http://[email protected]?subject:unsubscribe> >>>> >> > > > >>>> >> > > > >>>> >> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > -- >>>> >> > > > Juan Antonio Osorio R. >>>> >> > > > e-mail: [email protected] <mailto:[email protected]> >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > __________________________________________________________________________ >>>> >> > > > OpenStack Development Mailing List (not for usage questions) >>>> >> > > > Unsubscribe: >>>> >> > > > [email protected]?subject:unsubscribe >>>> >> > > > >>>> >> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >> > > > >>>> >> > > >>>> >> > > -- >>>> >> > > Emilien Macchi >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > __________________________________________________________________________ >>>> >> > > OpenStack Development Mailing List (not for usage questions) >>>> >> > > Unsubscribe: >>>> >> > > [email protected]?subject:unsubscribe >>>> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >> > > Email had 1 attachment: >>>> >> > > + signature.asc >>>> >> > > 1k (application/pgp-signature) >>>> >> > >>>> >> > >>>> >> > >>>> >> > __________________________________________________________________________ >>>> >> > OpenStack Development Mailing List (not for usage questions) >>>> >> > Unsubscribe: >>>> >> > [email protected]?subject:unsubscribe >>>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >> >>>> >> >>>> >> >>>> >> __________________________________________________________________________ >>>> >> OpenStack Development Mailing List (not for usage questions) >>>> >> Unsubscribe: >>>> >> [email protected]?subject:unsubscribe >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >> >>>> > >>>> > >>>> > >>>> > __________________________________________________________________________ >>>> > OpenStack Development Mailing List (not for usage questions) >>>> > Unsubscribe: >>>> > [email protected]?subject:unsubscribe >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> >>>> >>>> >>>> -- >>>> Emilien Macchi >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> -- >>> >>> -- >>> >>> Andrew Woodward >>> >>> Mirantis >>> >>> Fuel Community Ambassador >>> >>> Ceph Community >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> -- Sofer Athlan-Guyot __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
