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 <emil...@redhat.com> writes:
> 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
>>
--
Sofer Athlan-Guyot
__________________________________________________________________________
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
