Open Stack

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',
}


2016-03-18 2:50 GMT+03:00 Andrew Woodward <xarses at 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 <emilien at redhat.com>
> wrote:
>
>> On Thu, Mar 17, 2016 at 2:22 PM, Sergii Golovatiuk
>> <sgolovatiuk at 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.macchi at gmail.com>
>> > wrote:
>> >>
>> >>
>> >> On Feb 12, 2016 11:06 PM, "Spencer Krum" <nibz at 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
>> >> >   nibz at 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 <
>> openstack at nemebean.com
>> >> > > > <mailto:openstack at 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-request at lists.openstack.org?subject:unsubscribe
>> >> > > >
>> >> > > > <
>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>> >> > > >
>> >> > > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > --
>> >> > > > Juan Antonio Osorio R.
>> >> > > > e-mail: jaosorior at gmail.com <mailto:jaosorior at gmail.com>
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> __________________________________________________________________________
>> >> > > > 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
>> >> > > >
>> >> > >
>> >> > > --
>> >> > > Emilien Macchi
>> >> > >
>> >> > >
>> >> > >
>> __________________________________________________________________________
>> >> > > 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
>> >> > > Email had 1 attachment:
>> >> > > + signature.asc
>> >> > >   1k (application/pgp-signature)
>> >> >
>> >> >
>> >> >
>> __________________________________________________________________________
>> >> > 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
>> >>
>> >>
>> >>
>> __________________________________________________________________________
>> >> 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
>> >>
>> >
>> >
>> >
>> __________________________________________________________________________
>> > 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
>> >
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> __________________________________________________________________________
>> 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
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160318/6a770097/attachment.html>