Mailing List Archive

On 05/28/2014 04:05 PM, Jay G. Scott wrote:
>
> Greetings,
>
> I'm a noob. If this isn't the right place to ask this,
> let me know. I took "general configuration questions"
> to include compiling.
>
> OS = RHEL6 (I hope) x86_64

On centos there's heartbeat in EPEL and pacemaker in standard repo. Not
sure what RH is doing with their "channels" this week, so... presumably
"yum list \*pace\*" should work?

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

On 28/05/14 05:05 PM, Jay G. Scott wrote:
>
> Greetings,
>
> I'm a noob. If this isn't the right place to ask this,
> let me know. I took "general configuration questions"
> to include compiling.
>
> OS = RHEL6 (I hope) x86_64
>
> I downloaded:
> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
> Heartbeat-3-0-7e3a82377fa8.tar.bz2
> ClusterLabs-resource-agents-v3.9.2-0-ge261943.tar.gz
>
> Errr.... I just now noticed this. Is there a Pacemaker source tarball
> somewhere? 'Cause I guess I don't have it.
>
>
> I wrote a book on using autotools and making RPMs.
> Looks like the existing packages could use some work.
> Heartbeat can't find the libltdl.tar file to install
> a local version, but I have a feeling the packages
> I have installed already should make that a moot point.
>
>
> Back to my problem:
>
> I compiled and installed
> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>
> Then I pressed on to Heartbeat. According to what I read
> online that's the proper order.
>
> 1. I have a libltdl.so.7 library but the configure script
> claims it does not have lt_ldopen(). I decided to bluster
> my way past that, in the hopes that the routine wouldn't
> really be needed.
>
> 2. But now it can't find ltdl.h, and I can't readily find a
> way around that. Ie, I can't find a RH package that
> has that header file. libtool and libtool-ltdl are both
> installed.
>
> [root@w1dns ~]# rpm -q -a | grep libtool
> libtool-2.2.6-15.5.el6.x86_64
> libtool-ltdl-2.2.6-15.5.el6.x86_64
>
> Are there pre-built versions of these things somewhere?
> I'm not anxious to re-invent the wheel.
> Are there more parts to this than I have?
>
> j.

I think you might want to be sure you're using the right stack.

Trick is, there are two answers for this.

Under RHEL 6, the fully supported stack is corosync + cman + rgmanager.
This has been Red Hat's stack since it got into the HA game, and will be
supported until 2020 when RHEL 6 support ends.

The other answer is corosync + pacemaker (+cman). This support is nearly
complete, but not totally complete. It got out of "Tech Preview" at the
end of the 6.4 stream and is effectively fully supported on 6.5 an
onward. Further, this will be the only supported stack on RHEL 7 and
forward.

In either case, heartbeat is long deprecated (though still supported by
Linbit, whom Red Hat has a support deal with). It has not been actively
supported in years and there is no plan to restart development in the
future. So please, do not use it.

If you're curious about the reasons for all this, I have an
incomplete-but-still-hopefully-helpful history of HA coming together here:

https://alteeve.ca/w/History_of_HA_Clustering

So to best help you, can I ask what your near and long-term goals are?
Once you've identified which stack is best for your use-case, we can
better help you identify compilation issues (or if you need to be
compiling anything at all).

Cheers

--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 28/05/14 07:42 PM, Digimer wrote:
> On 28/05/14 05:05 PM, Jay G. Scott wrote:
>>
>> Greetings,
>>
>> I'm a noob. If this isn't the right place to ask this,
>> let me know. I took "general configuration questions"
>> to include compiling.
>>
>> OS = RHEL6 (I hope) x86_64
>>
>> I downloaded:
>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>> Heartbeat-3-0-7e3a82377fa8.tar.bz2
>> ClusterLabs-resource-agents-v3.9.2-0-ge261943.tar.gz
>>
>> Errr.... I just now noticed this. Is there a Pacemaker source tarball
>> somewhere? 'Cause I guess I don't have it.
>>
>>
>> I wrote a book on using autotools and making RPMs.
>> Looks like the existing packages could use some work.
>> Heartbeat can't find the libltdl.tar file to install
>> a local version, but I have a feeling the packages
>> I have installed already should make that a moot point.
>>
>>
>> Back to my problem:
>>
>> I compiled and installed
>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>>
>> Then I pressed on to Heartbeat. According to what I read
>> online that's the proper order.
>>
>> 1. I have a libltdl.so.7 library but the configure script
>> claims it does not have lt_ldopen(). I decided to bluster
>> my way past that, in the hopes that the routine wouldn't
>> really be needed.
>>
>> 2. But now it can't find ltdl.h, and I can't readily find a
>> way around that. Ie, I can't find a RH package that
>> has that header file. libtool and libtool-ltdl are both
>> installed.
>>
>> [root@w1dns ~]# rpm -q -a | grep libtool
>> libtool-2.2.6-15.5.el6.x86_64
>> libtool-ltdl-2.2.6-15.5.el6.x86_64
>>
>> Are there pre-built versions of these things somewhere?
>> I'm not anxious to re-invent the wheel.
>> Are there more parts to this than I have?
>>
>> j.
>
> I think you might want to be sure you're using the right stack.
>
> Trick is, there are two answers for this.
>
> Under RHEL 6, the fully supported stack is corosync + cman + rgmanager.
> This has been Red Hat's stack since it got into the HA game, and will be
> supported until 2020 when RHEL 6 support ends.
>
> The other answer is corosync + pacemaker (+cman). This support is nearly
> complete, but not totally complete. It got out of "Tech Preview" at the
> end of the 6.4 stream and is effectively fully supported on 6.5 an
> onward. Further, this will be the only supported stack on RHEL 7 and
> forward.
>
> In either case, heartbeat is long deprecated (though still supported by
> Linbit, whom Red Hat has a support deal with). It has not been actively
> supported in years and there is no plan to restart development in the
> future. So please, do not use it.
>
> If you're curious about the reasons for all this, I have an
> incomplete-but-still-hopefully-helpful history of HA coming together here:
>
> https://alteeve.ca/w/History_of_HA_Clustering
>
> So to best help you, can I ask what your near and long-term goals are?
> Once you've identified which stack is best for your use-case, we can
> better help you identify compilation issues (or if you need to be
> compiling anything at all).
>
> Cheers

Note: I was mistaken on the current support of Pacemaker. The caveat I
was referencing was true in 6.4. In RHEL 6.5 and onwards, pacemaker *is*
fully supported, no caveats.

--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On Wed, May 28, 2014 at 07:42:58PM -0400, Digimer wrote:
> On 28/05/14 05:05 PM, Jay G. Scott wrote:
>>
>> Greetings,
>>
>> I'm a noob. If this isn't the right place to ask this,
>> let me know. I took "general configuration questions"
>> to include compiling.
>>
>> OS = RHEL6 (I hope) x86_64
>>
>> I downloaded:
>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>> Heartbeat-3-0-7e3a82377fa8.tar.bz2
>> ClusterLabs-resource-agents-v3.9.2-0-ge261943.tar.gz
>>
>> Errr.... I just now noticed this. Is there a Pacemaker source tarball
>> somewhere? 'Cause I guess I don't have it.
>>
>>
>> I wrote a book on using autotools and making RPMs.
>> Looks like the existing packages could use some work.
>> Heartbeat can't find the libltdl.tar file to install
>> a local version, but I have a feeling the packages
>> I have installed already should make that a moot point.
>>
>>
>> Back to my problem:
>>
>> I compiled and installed
>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>>
>> Then I pressed on to Heartbeat. According to what I read
>> online that's the proper order.
>>
>> 1. I have a libltdl.so.7 library but the configure script
>> claims it does not have lt_ldopen(). I decided to bluster
>> my way past that, in the hopes that the routine wouldn't
>> really be needed.
>>
>> 2. But now it can't find ltdl.h, and I can't readily find a
>> way around that. Ie, I can't find a RH package that
>> has that header file. libtool and libtool-ltdl are both
>> installed.
>>
>> [root@w1dns ~]# rpm -q -a | grep libtool
>> libtool-2.2.6-15.5.el6.x86_64
>> libtool-ltdl-2.2.6-15.5.el6.x86_64
>>
>> Are there pre-built versions of these things somewhere?
>> I'm not anxious to re-invent the wheel.
>> Are there more parts to this than I have?
>>
>> j.
>
> I think you might want to be sure you're using the right stack.
>
> Trick is, there are two answers for this.
>
> Under RHEL 6, the fully supported stack is corosync + cman + rgmanager.
> This has been Red Hat's stack since it got into the HA game, and will be
> supported until 2020 when RHEL 6 support ends.
>
> The other answer is corosync + pacemaker (+cman). This support is nearly
> complete, but not totally complete. It got out of "Tech Preview" at the
> end of the 6.4 stream and is effectively fully supported on 6.5 an
> onward. Further, this will be the only supported stack on RHEL 7 and
> forward.
>
> In either case, heartbeat is long deprecated (though still supported by
> Linbit, whom Red Hat has a support deal with). It has not been actively
> supported in years and there is no plan to restart development in the
> future. So please, do not use it.
>
> If you're curious about the reasons for all this, I have an
> incomplete-but-still-hopefully-helpful history of HA coming together
> here:
>
> https://alteeve.ca/w/History_of_HA_Clustering

i made a note to go check this.


>
> So to best help you, can I ask what your near and long-term goals are?

joke's on me:

yeah, you can ask. and as of about 15 minutes ago they changed.

near term -- now, nothing.
longer term -- looks like i'd need to move to Centos or one of the
other cost-free OSes. sigh.

so, thanks -- sincerely -- for the RH answer.
what's the answer for ... Centos, I guess...? And it does
embarrass me to have to ask that.

j.


> Once you've identified which stack is best for your use-case, we can
> better help you identify compilation issues (or if you need to be
> compiling anything at all).
>
> Cheers
>
> --
> Digimer
> Papers and Projects: https://alteeve.ca/w/
> What if the cure for cancer is trapped in the mind of a person without
> access to education?
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

--
Jay Scott 512-835-3553 gl@arlut.utexas.edu
Head of Sun Support, Sr. System Administrator
Applied Research Labs, Computer Science Div. S224
University of Texas at Austin
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 05/29/2014 12:01 PM, Jay G. Scott wrote:

> what's the answer for ... Centos, I guess...? And it does
> embarrass me to have to ask that.

Pacemaker/corosync -- 2+-node clusters, active-active clusters, active
development. Support for free is 50% chance Lars will ask you if you're
a paying Suse customer.

Heartbeat 'R1' (i.e. as long as you don't use 'crm' mode) -- simple,
stupid, has been rock solid (and, consequently, untouched) for years.
2-node active/passive clusters only, DIY external resource monitoring
(mon), the level of support is: Digimer will tell you "upgrade to
pacemaker".

What do you intend to run in HA mode?
--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

On 29/05/14 01:01 PM, Jay G. Scott wrote:
> On Wed, May 28, 2014 at 07:42:58PM -0400, Digimer wrote:
>> On 28/05/14 05:05 PM, Jay G. Scott wrote:
>>>
>>> Greetings,
>>>
>>> I'm a noob. If this isn't the right place to ask this,
>>> let me know. I took "general configuration questions"
>>> to include compiling.
>>>
>>> OS = RHEL6 (I hope) x86_64
>>>
>>> I downloaded:
>>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>>> Heartbeat-3-0-7e3a82377fa8.tar.bz2
>>> ClusterLabs-resource-agents-v3.9.2-0-ge261943.tar.gz
>>>
>>> Errr.... I just now noticed this. Is there a Pacemaker source tarball
>>> somewhere? 'Cause I guess I don't have it.
>>>
>>>
>>> I wrote a book on using autotools and making RPMs.
>>> Looks like the existing packages could use some work.
>>> Heartbeat can't find the libltdl.tar file to install
>>> a local version, but I have a feeling the packages
>>> I have installed already should make that a moot point.
>>>
>>>
>>> Back to my problem:
>>>
>>> I compiled and installed
>>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>>>
>>> Then I pressed on to Heartbeat. According to what I read
>>> online that's the proper order.
>>>
>>> 1. I have a libltdl.so.7 library but the configure script
>>> claims it does not have lt_ldopen(). I decided to bluster
>>> my way past that, in the hopes that the routine wouldn't
>>> really be needed.
>>>
>>> 2. But now it can't find ltdl.h, and I can't readily find a
>>> way around that. Ie, I can't find a RH package that
>>> has that header file. libtool and libtool-ltdl are both
>>> installed.
>>>
>>> [root@w1dns ~]# rpm -q -a | grep libtool
>>> libtool-2.2.6-15.5.el6.x86_64
>>> libtool-ltdl-2.2.6-15.5.el6.x86_64
>>>
>>> Are there pre-built versions of these things somewhere?
>>> I'm not anxious to re-invent the wheel.
>>> Are there more parts to this than I have?
>>>
>>> j.
>>
>> I think you might want to be sure you're using the right stack.
>>
>> Trick is, there are two answers for this.
>>
>> Under RHEL 6, the fully supported stack is corosync + cman + rgmanager.
>> This has been Red Hat's stack since it got into the HA game, and will be
>> supported until 2020 when RHEL 6 support ends.
>>
>> The other answer is corosync + pacemaker (+cman). This support is nearly
>> complete, but not totally complete. It got out of "Tech Preview" at the
>> end of the 6.4 stream and is effectively fully supported on 6.5 an
>> onward. Further, this will be the only supported stack on RHEL 7 and
>> forward.
>>
>> In either case, heartbeat is long deprecated (though still supported by
>> Linbit, whom Red Hat has a support deal with). It has not been actively
>> supported in years and there is no plan to restart development in the
>> future. So please, do not use it.
>>
>> If you're curious about the reasons for all this, I have an
>> incomplete-but-still-hopefully-helpful history of HA coming together
>> here:
>>
>> https://alteeve.ca/w/History_of_HA_Clustering
>
> i made a note to go check this.
>
>
>>
>> So to best help you, can I ask what your near and long-term goals are?
>
> joke's on me:
>
> yeah, you can ask. and as of about 15 minutes ago they changed.
>
> near term -- now, nothing.
> longer term -- looks like i'd need to move to Centos or one of the
> other cost-free OSes. sigh.
>
> so, thanks -- sincerely -- for the RH answer.
> what's the answer for ... Centos, I guess...? And it does
> embarrass me to have to ask that.
>
> j.

CentOS is a direct drop-in for RHEL, it's binary compatible (warts and
all, as they say). So using CentOS is no problem at all. I've used
CentOS and RHEL based clusters since 2009 without issue. You just need
to take the time to get it right; HA clustering is not inherently hard,
but there are a lot of moving parts that need to work just so.

Feel free to stop by #linux-cluster or #linux-ha on freenode. I and
others are frequently there (and when not, we'll read scroll-back and
answer older questions when we return).

Welcome to HA!

--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 29/05/14 01:43 PM, Dimitri Maziuk wrote:
> On 05/29/2014 12:01 PM, Jay G. Scott wrote:
>
>> what's the answer for ... Centos, I guess...? And it does
>> embarrass me to have to ask that.
>
> Pacemaker/corosync -- 2+-node clusters, active-active clusters, active
> development. Support for free is 50% chance Lars will ask you if you're
> a paying Suse customer.

Jay was asking about RHEL, but even then, I've seen Lars offer lots of
help in #linux-ha without asking that. The HA community helped me learn
everything I know about HA (the quality of that education I will leave
to others to determine) and not once was I asked by any RH or SUSE
employee if I was a paying customer. It's honestly been one of the best
communities I've seen in the OSS world.

> Heartbeat 'R1' (i.e. as long as you don't use 'crm' mode) -- simple,
> stupid, has been rock solid (and, consequently, untouched) for years.
> 2-node active/passive clusters only, DIY external resource monitoring
> (mon), the level of support is: Digimer will tell you "upgrade to
> pacemaker".

Or cman+rgmanager, either one. The argument for pacemaker is, as I said
in the first reply, that it is the only stack with long-term plans.
Heartbeat has been deprecated for some time already, and RH stopped
development of cman+rgmanager a year or two ago with the release of 3.2,
though it will be actively supported until at least 2020.

Cheers

--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 30 May 2014, at 3:01 am, Jay G. Scott <gl@arlut.utexas.edu> wrote:

> On Wed, May 28, 2014 at 07:42:58PM -0400, Digimer wrote:
>> On 28/05/14 05:05 PM, Jay G. Scott wrote:
>>>
>>> Greetings,
>>>
>>> I'm a noob. If this isn't the right place to ask this,
>>> let me know. I took "general configuration questions"
>>> to include compiling.
>>>
>>> OS = RHEL6 (I hope) x86_64
>>>
>>> I downloaded:
>>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>>> Heartbeat-3-0-7e3a82377fa8.tar.bz2
>>> ClusterLabs-resource-agents-v3.9.2-0-ge261943.tar.gz
>>>
>>> Errr.... I just now noticed this. Is there a Pacemaker source tarball
>>> somewhere? 'Cause I guess I don't have it.
>>>
>>>
>>> I wrote a book on using autotools and making RPMs.
>>> Looks like the existing packages could use some work.
>>> Heartbeat can't find the libltdl.tar file to install
>>> a local version, but I have a feeling the packages
>>> I have installed already should make that a moot point.
>>>
>>>
>>> Back to my problem:
>>>
>>> I compiled and installed
>>> Reusable-Cluster-Components-glue--glue-1.0.9.tar.bz2
>>>
>>> Then I pressed on to Heartbeat. According to what I read
>>> online that's the proper order.
>>>
>>> 1. I have a libltdl.so.7 library but the configure script
>>> claims it does not have lt_ldopen(). I decided to bluster
>>> my way past that, in the hopes that the routine wouldn't
>>> really be needed.
>>>
>>> 2. But now it can't find ltdl.h, and I can't readily find a
>>> way around that. Ie, I can't find a RH package that
>>> has that header file. libtool and libtool-ltdl are both
>>> installed.
>>>
>>> [root@w1dns ~]# rpm -q -a | grep libtool
>>> libtool-2.2.6-15.5.el6.x86_64
>>> libtool-ltdl-2.2.6-15.5.el6.x86_64
>>>
>>> Are there pre-built versions of these things somewhere?
>>> I'm not anxious to re-invent the wheel.
>>> Are there more parts to this than I have?
>>>
>>> j.
>>
>> I think you might want to be sure you're using the right stack.
>>
>> Trick is, there are two answers for this.
>>
>> Under RHEL 6, the fully supported stack is corosync + cman + rgmanager.
>> This has been Red Hat's stack since it got into the HA game, and will be
>> supported until 2020 when RHEL 6 support ends.
>>
>> The other answer is corosync + pacemaker (+cman). This support is nearly
>> complete, but not totally complete. It got out of "Tech Preview" at the
>> end of the 6.4 stream and is effectively fully supported on 6.5 an
>> onward. Further, this will be the only supported stack on RHEL 7 and
>> forward.
>>
>> In either case, heartbeat is long deprecated (though still supported by
>> Linbit, whom Red Hat has a support deal with). It has not been actively
>> supported in years and there is no plan to restart development in the
>> future. So please, do not use it.
>>
>> If you're curious about the reasons for all this, I have an
>> incomplete-but-still-hopefully-helpful history of HA coming together
>> here:
>>
>> https://alteeve.ca/w/History_of_HA_Clustering
>
> i made a note to go check this.
>
>
>>
>> So to best help you, can I ask what your near and long-term goals are?
>
> joke's on me:
>
> yeah, you can ask. and as of about 15 minutes ago they changed.
>
> near term -- now, nothing.
> longer term -- looks like i'd need to move to Centos or one of the
> other cost-free OSes. sigh.
>
> so, thanks -- sincerely -- for the RH answer.
> what's the answer for ... Centos, I guess...? And it does
> embarrass me to have to ask that.

For paid "fix this right now!" support, then SLES and RHEL (6.5+) are good options (both pay people to work on pacemaker).
There is also the option of talking to a cross-distro vendor like Linbit.

CentOS is a good free option as you get something enterprise ready and can piggy back off the fixes that go into RHEL.
The downside is that your problems need to be likely to affect paying customers before they can be prioritised and there can be a decent delay between a fix being available and shipped.

In some ways though, you can be better off running your favourite distro plus the latest from upstream.
Thats what the developers are using every day and all fixes are available immediately.
The project's regression tests get performed on every commit and are expansive enough that pretty much anything that makes it into the public source tree is quite usable.

The source trees for most things are at: http://github.com/ClusterLabs

>
> j.
>
>
>> Once you've identified which stack is best for your use-case, we can
>> better help you identify compilation issues (or if you need to be
>> compiling anything at all).
>>
>> Cheers
>>
>> --
>> Digimer
>> Papers and Projects: https://alteeve.ca/w/
>> What if the cure for cancer is trapped in the mind of a person without
>> access to education?
>> _______________________________________________
>> Linux-HA mailing list
>> Linux-HA@lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>> See also: http://linux-ha.org/ReportingProblems
>
> --
> Jay Scott 512-835-3553 gl@arlut.utexas.edu
> Head of Sun Support, Sr. System Administrator
> Applied Research Labs, Computer Science Div. S224
> University of Texas at Austin
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

On 30 May 2014, at 7:20 am, Digimer <lists@alteeve.ca> wrote:

> On 29/05/14 01:43 PM, Dimitri Maziuk wrote:
>> On 05/29/2014 12:01 PM, Jay G. Scott wrote:
>>
>>> what's the answer for ... Centos, I guess...? And it does
>>> embarrass me to have to ask that.
>>
>> Pacemaker/corosync -- 2+-node clusters, active-active clusters, active
>> development. Support for free is 50% chance Lars will ask you if you're
>> a paying Suse customer.
>
> Jay was asking about RHEL, but even then, I've seen Lars offer lots of help in #linux-ha without asking that. The HA community helped me learn everything I know about HA (the quality of that education I will leave to others to determine) and not once was I asked by any RH or SUSE employee if I was a paying customer.

The only context in which I've asked this question, or seen other do so, is to know how to get a fix to them efficiently.
Customers of enterprise distros sometimes need to go via specific processes in order to fast track the creation of packages that include the fix from upstream.

> It's honestly been one of the best communities I've seen in the OSS world.
>
>> Heartbeat 'R1' (i.e. as long as you don't use 'crm' mode) -- simple,
>> stupid, has been rock solid (and, consequently, untouched) for years.
>> 2-node active/passive clusters only, DIY external resource monitoring
>> (mon), the level of support is: Digimer will tell you "upgrade to
>> pacemaker".
>
> Or cman+rgmanager, either one. The argument for pacemaker is, as I said in the first reply, that it is the only stack with long-term plans. Heartbeat has been deprecated for some time already, and RH stopped development of cman+rgmanager a year or two ago with the release of 3.2, though it will be actively supported until at least 2020.
>
> Cheers
>
> --
> Digimer
> Papers and Projects: https://alteeve.ca/w/
> What if the cure for cancer is trapped in the mind of a person without access to education?
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

On 5/29/2014 4:20 PM, Digimer wrote:
> On 29/05/14 01:43 PM, Dimitri Maziuk wrote:

>> Support for free is 50% chance Lars will ask you if you're
>> a paying Suse customer.
>
> Jay was asking about RHEL, but even then, I've seen Lars offer lots of
> help in #linux-ha without asking that.

Yes he asked about centos and yes, I said 50% chance, not 100%.

...
>> the level of support is: Digimer will tell you "upgrade to
>> pacemaker".
>
> Heartbeat has been deprecated for some time already,

Nevertheless, when someone asks you how to get to the library,
"everyone's using kindle these days" is rarely the best answer.

Dima

_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 31 May 2014, at 12:56 am, Dmitri Maziuk <dmaziuk@bmrb.wisc.edu> wrote:

> On 5/29/2014 4:20 PM, Digimer wrote:
>> On 29/05/14 01:43 PM, Dimitri Maziuk wrote:
>
>>> Support for free is 50% chance Lars will ask you if you're
>>> a paying Suse customer.
>>
>> Jay was asking about RHEL, but even then, I've seen Lars offer lots of
>> help in #linux-ha without asking that.
>
> Yes he asked about centos and yes, I said 50% chance, not 100%.

50% is still grossly unfair.
Not once have I seen Lars (or anyone here) refuse to help someone based on their being or not being a paying customer.

Is there a reason you keep spouting nonsense?

>
> ...
>>> the level of support is: Digimer will tell you "upgrade to
>>> pacemaker".
>>
>> Heartbeat has been deprecated for some time already,
>
> Nevertheless, when someone asks you how to get to the library, "everyone's using kindle these days" is rarely the best answer.
>
> Dima
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

On 5/30/2014 6:20 PM, Andrew Beekhof wrote:

> Is there a reason you keep spouting nonsense?

Yes: I have a memory and it remembers. For example, this:
http://www.gossamer-threads.com/lists/linuxha/users/81573?do=post_view_threaded#81573
I don't remember that being an isolated incident either.

HTH,HAND
Dima

_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 1 Jun 2014, at 2:15 am, Dmitri Maziuk <dmaziuk@bmrb.wisc.edu> wrote:

> On 5/30/2014 6:20 PM, Andrew Beekhof wrote:
>
>> Is there a reason you keep spouting nonsense?
>
> Yes: I have a memory and it remembers. For example, this:
> http://www.gossamer-threads.com/lists/linuxha/users/81573?do=post_view_threaded#81573
> I don't remember that being an isolated incident either.

There is a very large distinction between:

- you don't pay for ${X} so I won't help diagnose your issue and get it fixed upstream, and
- you don't pay for ${X} so you don't get to make demands about what goes into packages for ${X}.

That you can't or won't see the difference says more about you than Lars.

[snip]

>> Heartbeat has been deprecated for some time already,
>
> Nevertheless, when someone asks you how to get to the library, "everyone's using kindle these days" is rarely the best answer.

More like our directions weren't convenient so instead you came to our house and got abusive because we didn't have Harry Potter in Latin.

On Thu, May 29, 2014 at 12:43:49PM -0500, Dimitri Maziuk wrote:
> On 05/29/2014 12:01 PM, Jay G. Scott wrote:
>
> > what's the answer for ... Centos, I guess...? And it does
> > embarrass me to have to ask that.
>
> Pacemaker/corosync -- 2+-node clusters, active-active clusters, active
> development. Support for free is 50% chance Lars will ask you if you're
> a paying Suse customer.
>
> Heartbeat 'R1' (i.e. as long as you don't use 'crm' mode) -- simple,
> stupid, has been rock solid (and, consequently, untouched) for years.
> 2-node active/passive clusters only, DIY external resource monitoring
> (mon), the level of support is: Digimer will tell you "upgrade to
> pacemaker".
>
> What do you intend to run in HA mode?

1. thx to all who replied. i've been hammered on for a few days and
got behind on reading the replies.

2. it'll be centos, and i'll do Pacemaker/corosync since
it's new and it's my thing -- no external requirements.

3. bind/named/dns, possible some fortran programs.

thanks again.

j.


> --
> Dimitri Maziuk
> Programmer/sysadmin
> BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
>



> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

--
Jay Scott 512-835-3553 gl@arlut.utexas.edu
Head of Sun Support, Sr. System Administrator
Applied Research Labs, Computer Science Div. S224
University of Texas at Austin
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 02/06/14 04:42 PM, Jay G. Scott wrote:
> On Thu, May 29, 2014 at 12:43:49PM -0500, Dimitri Maziuk wrote:
>> On 05/29/2014 12:01 PM, Jay G. Scott wrote:
>>
>>> what's the answer for ... Centos, I guess...? And it does
>>> embarrass me to have to ask that.
>>
>> Pacemaker/corosync -- 2+-node clusters, active-active clusters, active
>> development. Support for free is 50% chance Lars will ask you if you're
>> a paying Suse customer.
>>
>> Heartbeat 'R1' (i.e. as long as you don't use 'crm' mode) -- simple,
>> stupid, has been rock solid (and, consequently, untouched) for years.
>> 2-node active/passive clusters only, DIY external resource monitoring
>> (mon), the level of support is: Digimer will tell you "upgrade to
>> pacemaker".
>>
>> What do you intend to run in HA mode?
>
> 1. thx to all who replied. i've been hammered on for a few days and
> got behind on reading the replies.
>
> 2. it'll be centos, and i'll do Pacemaker/corosync since
> it's new and it's my thing -- no external requirements.

Good call. Be sure to use 6.5(+) and check the pacemaker website's docs
on configuring cman for use with pacemaker (a requirement that will go
away in RHEL 7, but has no fundamental impact of pacemaker's config and
use beyond initial setup). If you need help with this, don't hesitate to
ask. Effectively; Use 'ccs' to do the initial 'cman' config. This will
handle the corosync setup for you.

> 3. bind/named/dns, possible some fortran programs.

That should be no problem.

> thanks again.

Anytime. Pop by freenode's #linux-ha and/or #linux-cluster as well.
Great little HA community there.


--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 06/02/2014 03:42 PM, Jay G. Scott wrote:
> On Thu, May 29, 2014 at 12:43:49PM -0500, Dimitri Maziuk wrote:

>> What do you intend to run in HA mode?

> 3. bind/named/dns, possible some fortran programs.

Uhmm... why not just run 2 nameservers?

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

On 2014-05-31T11:15:20, Dmitri Maziuk <dmaziuk@bmrb.wisc.edu> wrote:

> >Is there a reason you keep spouting nonsense?
> Yes: I have a memory and it remembers. For example, this:
> http://www.gossamer-threads.com/lists/linuxha/users/81573?do=post_view_threaded#81573
> I don't remember that being an isolated incident either.

Uhm. I've just now stumbled across this wonderful discussion, and I was
torn a bit before responding.

That thread *was* an isolated incident. See, the whole business model
for SLES (and RHEL, for that matter) is that customers pay for support
and maintenance. There's several pricing levels from "maintenance
updates only" to "your personal engineer on-call 24/7". If you decide to
run SLES, you don't get to report a bug against a random openSUSE
version (for free) and expect it to be fixed in SLES (for free). That's
like expecting bugs reported against Fedora XY to be fixed in RHEL N.
Etc.

The whole *point* of the enterprise distributions is that they come with
support and certifications (the two usually being tied together).


And yes, it is true: occasionally I have asked people whom I know to be
SUSE customers to report bugs via the "official" channels. That
streamlines the process, allows us to get fixes to them officially too
(and in a way that doesn't leave their poor support engineer wondering
what version of software their customer is running and where they got
it), and also happens to allow me to demonstrate to my boss I'm doing
actual work instead of just lounging in community mailing lists ;-) To
the outside world, this could probably look like what you describe, but
the truth is a bit different.

Part of the reason for this is that it is unrealistic to expect the free
community to support the often patched versions of code that end up on
the enterprise distributions. (Try reporting a bug in the RHEL/SLES
kernel on LKML and see what response arrives ...) We take
responsibility for that - because otherwise, we annoy upstream. And bugs
specific to the Enterprise releases tend to lack meaning for the
community. If the issue is reproduced on upstream-latest, we'll also
work with upstream on that.

So I'd appreciate it if you'd not make those claims; I admit to feeling
slighted.

If you're running openSUSE Factory with the latest builds of everything
HA from network:ha-clustering:Factory on openSUSE (something I highly
recommend! Latest! Greatest! Bleeding edge! And if anything isn't,
branch + submitrequest your updates! Maintainers and contributors
accepted!), and hit an issue, we'll all happily discuss that right here
on the mailing lists or in our open bugzillas ;-)


Have a great weekend,
Lars

--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 06/06/2014 05:47 PM, Lars Marowsky-Bree wrote:

> So I'd appreciate it if you'd not make those claims; I admit to feeling
> slighted.

The claim that prompted this was that the level of support a centos user
gets is "for pacemaker: 50% chance that the Lars over there will ask if
he's a paying SuSe customer; for heartbeat: 100% chance that Digimer
will tell him to install pacemaker".

If you don't work here and you ask for help with my code, there's 50%
chance that out of the goodness of my heart I'll help you out in my
copious free time. I admit that.

If someone tries to deny that about me, please provide a counter-example
to prove (in mathematical sense) they're full of it. I promise I won't
feel slighted.

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

On 2014-06-07T16:13:05, Dimitri Maziuk <dmaziuk@bmrb.wisc.edu> wrote:

> > So I'd appreciate it if you'd not make those claims; I admit to feeling
> > slighted.
> The claim that prompted this was that the level of support a centos user
> gets is "for pacemaker: 50% chance that the Lars over there will ask if
> he's a paying SuSe customer;

Why on earth would I ask a CentOS user if they're a SUSE customer?

> for heartbeat: 100% chance that Digimer will tell him to install
> pacemaker".

... which is smart, because unless they are paying someone for support
;-), the community likely won't be helping them much, hence they should
upgrade.

EOD. This is pointless.


Regards,
Lars

--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems