On Fri, Mar 18, 2016 at 10:55 AM, Dmitry Ilyin <dil...@mirantis.com> 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 <xar...@gmail.com>: >> >> 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 <emil...@redhat.com> >> wrote: >>> >>> On Thu, Mar 17, 2016 at 2:22 PM, Sergii Golovatiuk >>> <sgolovat...@mirantis.com> 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 >>> > <emilien.mac...@gmail.com> >>> > wrote: >>> >> >>> >> >>> >> On Feb 12, 2016 11:06 PM, "Spencer Krum" <n...@spencerkrum.com> 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 >>> >> > n...@spencerkrum.com >>> >> > >>> >> > 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 >>> >> > > > <openst...@nemebean.com >>> >> > > > <mailto:openst...@nemebean.com>> 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: >>> >> > > > >>> >> > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >> > > > >>> >> > > > >>> >> > > > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >>> >> > > > >>> >> > > > >>> >> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > -- >>> >> > > > Juan Antonio Osorio R. >>> >> > > > e-mail: jaosor...@gmail.com <mailto:jaosor...@gmail.com> >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > > __________________________________________________________________________ >>> >> > > > 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 >>> >> > > > >>> >> > > >>> >> > > -- >>> >> > > Emilien Macchi >>> >> > > >>> >> > > >>> >> > > >>> >> > > __________________________________________________________________________ >>> >> > > 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 >>> >> > > Email had 1 attachment: >>> >> > > + signature.asc >>> >> > > 1k (application/pgp-signature) >>> >> > >>> >> > >>> >> > >>> >> > __________________________________________________________________________ >>> >> > 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 >>> >> >>> >> >>> >> >>> >> __________________________________________________________________________ >>> >> 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 >>> >> >>> > >>> > >>> > >>> > __________________________________________________________________________ >>> > 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 >>> > >>> >>> >>> >>> -- >>> Emilien Macchi >>> >>> >>> __________________________________________________________________________ >>> 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 >> >> -- >> >> -- >> >> Andrew Woodward >> >> Mirantis >> >> Fuel Community Ambassador >> >> Ceph Community >> >> >> __________________________________________________________________________ >> 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 >> > > > __________________________________________________________________________ > 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 > -- Emilien Macchi __________________________________________________________________________ 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