subject:"\[openstack\-dev\] \[tripleo\] \[puppet\] move puppet\-pacemaker"

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-04-06 Thread Michele Baldessari

On Wed, Mar 23, 2016 at 09:58:17AM +0100, Sofer Athlan-Guyot wrote:
> > Can I change the interface of pcmk_resource?
> >
> > You have pcmk_constraint but I have pcmk_location/colocation/order
> > separately. I can merge then into a single resource like you did
> > or I can keep them separated. Or I can make both. Actually they are
> > different enough to be separated.
> 
> Yes, I think that you've got it right, and separating the resource seems
> to be cleaner.

Agreed. The resources have fairly different semantics that keeping them
separate makes more sense. E.g. the following pattern cannot be
expressed cleanly today with the openstack puppet-pacemaker module (at least a
couple of months ago, haven't looked recently):
pcs constraint location foores rule resource-discovery=exclusive score=0 
nodetag eq foonode

Not sure if the above would work with the fuel module.

> > Will I have to develop 'pcs' style provider for every resource? Do we
> > really need them?
> 
> 'pcs' command is the way to go on rhel platform.  It's the interface of
> choice to the pacemaker interface.  So, I would say yes.  I can help
> here.

Also note that pcs did make it to debian unstable a few months ago, so
in the mid-long term, this interface will be relevant for Debian-derived
distros as well.

cheers,
Michele
-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
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

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-23 Thread Sofer Athlan-Guyot

Dmitry Ilyin  writes:

> I've started my merging effort here
> https://github.com/dmitryilyin/openstack-puppet-pacemaker

Great, thanks.

>
> Can I change the interface of pcmk_resource?
>
> You have pcmk_constraint but I have pcmk_location/colocation/order
> separately. I can merge then into a single resource like you did
> or I can keep them separated. Or I can make both. Actually they are
> different enough to be separated.

Yes, I think that you've got it right, and separating the resource seems
to be cleaner.

>
> Will I have to develop 'pcs' style provider for every resource? Do we
> really need them?

'pcs' command is the way to go on rhel platform.  It's the interface of
choice to the pacemaker interface.  So, I would say yes.  I can help
here.

By the way, a lot of refactoring has been done to the module[1].  The
most noticeable change for a merging effort has been the inclusion of a
beaker acceptance test.  It's basic for now, but it stress a good chunk
of the code.

I suggest that we do this on gerrit on top of this patch[1] to have
access to the openstack CI ? Using depends-on we could test fuel and
tripleo as well.

WDYT ?

[1] https://review.openstack.org/#/c/294182/
-- 
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

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-22 Thread Dmitry Ilyin

I've started my merging effort here
https://github.com/dmitryilyin/openstack-puppet-pacemaker

Can I change the interface of pcmk_resource?

You have pcmk_constraint but I have pcmk_location/colocation/order
separately. I can merge then into a single resource like you did
or I can keep them separated. Or I can make both. Actually they are
different enough to be separated.

Will I have to develop 'pcs' style provider for every resource? Do we
really need them?
__
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

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-21 Thread Sofer Athlan-Guyot

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  writes:

> On Fri, Mar 18, 2016 at 10:55 AM, Dmitry Ilyin  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 :
>>>
>>> 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 
>>> wrote:

 On Thu, Mar 17, 2016 at 2:22 PM, Sergii Golovatiuk
  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
 > 
 > wrote:
 >>
 >>
 >> On Feb 12, 2016 11:06 PM, "Spencer Krum"  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

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-19 Thread Sergii Golovatiuk

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

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Sat, Feb 13, 2016 at 6:20 AM, Emilien Macchi 
wrote:

>
> On Feb 12, 2016 11:06 PM, "Spencer Krum"  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  > > > > 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 
> > > >
> > > >
> > > >
> > > >
> __
> > > > 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:

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-19 Thread Dmitry Ilyin

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 :

> 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 
> wrote:
>
>> On Thu, Mar 17, 2016 at 2:22 PM, Sergii Golovatiuk
>>  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"  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
>> >> > > > > 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.
>> >> > > > >
>>

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-19 Thread Andrew Woodward

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  wrote:

> On Thu, Mar 17, 2016 at 2:22 PM, Sergii Golovatiuk
>  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"  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
> >> > > > > 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
> >> > > >

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-18 Thread Emilien Macchi

On Thu, Mar 17, 2016 at 2:22 PM, Sergii Golovatiuk
 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 
> wrote:
>>
>>
>> On Feb 12, 2016 11:06 PM, "Spencer Krum"  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 > > > > > 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > > >
>> > >

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-18 Thread Emilien Macchi

On Fri, Mar 18, 2016 at 10:55 AM, Dmitry Ilyin  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 :
>>
>> 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 
>> wrote:
>>>
>>> On Thu, Mar 17, 2016 at 2:22 PM, Sergii Golovatiuk
>>>  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
>>> > 
>>> > wrote:
>>> >>
>>> >>
>>> >> On Feb 12, 2016 11:06 PM, "Spencer Krum"  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
>>> >> > > > >> >> > > > > wrote:
>>> >> > > >
>>> >> > >

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-02-12 Thread Emilien Macchi

On Feb 12, 2016 11:06 PM, "Spencer Krum"  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  > > > 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 
> > >
> > >
> > >
> > >
__
> > > 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

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-02-12 Thread Spencer Krum

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.


[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  > > 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > 
> > 
> > 
> > -- 
> > Juan Antonio Osorio R.
> > e-mail: 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

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-02-10 Thread Juan Antonio Osorio

I like the idea of moving it to use the OpenStack infrastructure.

On Wed, Feb 10, 2016 at 12:13 AM, Ben Nemec  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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: 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

[openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-02-09 Thread Emilien Macchi

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

Any feedback is welcome,

[1] https://github.com/redhat-openstack/puppet-pacemaker
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-02-09 Thread Ben Nemec

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
> 
> 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.




signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

[openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

14 matches

Site Navigation

Mail list logo

Footer information