[ClusterLabs] can't create master/slave resource
Hello, We have a 3-node cluster (CentOS 7.4) with several systemd resources configured. One of them I would like to create as a master/slave resource, so following the RedHat documentation: pcs resource create ivr systemd:japp@ivr - works, the service is started on one of the nodes. pcs resource master ivr-master ivr - doesn't work as expected: the service is stopped and the output of pcs resource show doesn't list it anymore. However, if I try the command again, I get an error saying the resource ivr already exists! I have to delete the resource and recreate it to get the service to run. pacemaker-libs-1.1.16-12.el7_4.2.x86_64 pacemaker-cluster-libs-1.1.16-12.el7_4.2.x86_64 pacemaker-1.1.16-12.el7_4.2.x86_64 pacemaker-cli-1.1.16-12.el7_4.2.x86_64 corosynclib-2.4.0-9.el7_4.2.x86_64 corosync-2.4.0-9.el7_4.2.x86_64 Am I doing something wrong? -- Tiemen Ruiten Systems Engineer R&D Media ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings
On Tue, 2017-09-19 at 10:18 +0300, Klechomir wrote:
> Hi Ken,
> Any plans that there will be "lost monitoring request" handling (an
> added
> syntax) in 2.0?
>
> Regards,
> Klecho
2.0 will be about removing legacy syntax rather than adding new
features. The X.Y.Z version numbering policy will become:
X (major): changes that prevent at least some rolling upgrades
Y (minor): changes that don't break any rolling upgrades but require
closer user attention (changes in configuration defaults, tool
behavior, and/or public C API)
Z (minor-minor): backward-compatible changes (features and bug fixes)
So, we can add new (backward-compatible) features in any release.
Specifically to your question, what do you mean by "lost monitoring
request"? If you mean the ability to ignore a certain number of failed
monitors before recovering, there are plans for that, but it will be
later than 2.0.
> On 18.9.2017 12:48:38 Ken Gaillot wrote:
> > As discussed at the recent ClusterLabs Summit, I plan to start the
> > release cycle for Pacemaker 1.1.18 soon.
> >
> > There will be the usual bug fixes and a few small new features, but
> the
> > main goal will be to provide a final 1.1 release that Pacemaker 2.0
> can
> > branch from.
> >
> > As such, 1.1.18 will start to log deprecation warnings for syntax
> that
> > is planned to be removed in 2.0. So, we need to decide fairly
> quickly
> > what we intend to remove.
> >
> > Below is what I'm proposing. If anyone feels strongly about keeping
> > support for any of these, speak now or forever hold your peace!
> >
> > * support for legacy cluster stacks (heartbeat, corosync 1 + CMAN,
> and
> > corosync 1 + pacemaker plugin). Pacemaker 2.0 will initially
> support
> > only corosync 2, though future support is planned for the new knet
> > stack.
> >
> > * compile-time option to directly support SNMP and ESMTP in crm_mon
> > (i.e. the --snmp-* and --mail-* options) (alerts are the current
> > syntax)
> >
> > * pcmk_*_cmd stonith attributes (pcmk_*_action is the current
> syntax)
> >
> > * pcmk_poweroff_action (pcmk_off_action is the current syntax)
> >
> > * "requires" operation meta-attribute ("requires" resource meta-
> > attribute is the current syntax)
> >
> > * undocumented "resource isolation" feature (bundles are current
> > syntax)
> >
> > * undocumented LRMD_MAX_CHILDREN environment variable
> > (PCMK_node_action_limit is the current syntax)
> >
> > * cluster properties that have been obsoleted by the rsc_defaults
> and
> > op_defaults sections
> > ** stonith-enabled or stonith_enabled (now "requires" in
> rsc_defaults)
> > ** default-resource-stickiness, default_resource_stickiness (now
> > "resource-stickiness" in rsc_defaults)
> > ** is-managed-default or is_managed_default (now "is-managed" in
> > rsc_defaults)
> > ** default-action-timeout or default_action_timeout (now "timeout"
> in
> > op_defaults)
> >
> > * undocumented old names of cluster properties
> > ** no_quorum_policy (now no-quorum-policy)
> > ** symmetric_cluster (now symmetric-cluster)
> > ** stonith_action (now stonith-action)
> > ** startup_fencing (now startup-fencing)
> > ** transition_idle_timeout (now cluster-delay)
> > ** default_action_timeout (now default-action-timeout)
> > ** stop_orphan_resources (now stop-orphan-resources)
> > ** stop_orphan_actions (now stop-orphan-actions)
> > ** remote_after_stop (now remove-after-stop)
> > ** dc_deadtime (now dc-deadtime)
> > ** cluster_recheck_interval (now cluster-recheck-interval)
> > ** election_timeout (now election-timeout)
> > ** shutdown_escalation (now shutdown-escalation)
> >
> > * undocumented old names of resource meta-attributes
> > ** resource-failure-stickiness, resource_failure_stickiness,
> default-
> > resource-failure-stickiness, and
> > default_resource_failure_stickiness (now migration-threshold)
> >
> > * undocumented and ignored -r option to lrmd
> >
> > * compile-time option to use undocumented "notification-agent" and
> > "notification-recipient" cluster properties instead of current
> "alerts"
> > syntax
> >
> > * compatibility with CIB schemas below 1.0, and schema 1.1 (should
> not
> > affect anyone who created their configuration using Pacemaker 1.0.0
> or
> > later)
--
Ken Gaillot
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings
On Tue, 2017-09-19 at 15:28 +0200, Jan Pokorný wrote: > On 19/09/17 08:45 +0200, Klaus Wenninger wrote: > > We could as well deprecate use of CRM_NOTIFY_* in alert-agents. > > Just don't know an easy way of writing out a deprecation warning > > upon a script using one of these. I considered dropping support for CRM_notify_* in 2.0, but I think we want to retain compatibility with scripts that people wrote for crm_mon -E (which itself will not be deprecated this go-around either). I think I'd rather wait for a future Pacemaker 2.x to break those, since alerts are still relatively new to users. The notification-agent/notification-recipient syntax is different, since it was never released upstream. > Rename to CRM_NOTIFY_DEPRECATED_* to allow emergency sed-based > re-enabling in script-based notification agents (100% now?) > while getting a clear message wrt. future across? Not necessary, it's equally easy to s/CRM_notify_/CRM_alert_/g > > > Of course one could search the alert-agents for the string when > > they are read from the CIB. Apart from the multiple points of > > ugliness this would impose positive point would be a log for non > > existentalert-agents prior to their unsuccessful first use. -- Ken Gaillot ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Antw: Pacemaker 1.1.18 deprecation warnings
On 19/09/17 09:13 +0200, Ulrich Windl wrote: Ken Gaillot schrieb am 18.09.2017 um 19:48 in Nachricht > <1505756918.5541.4.ca...@redhat.com>: >> As discussed at the recent ClusterLabs Summit, I plan to start the >> release cycle for Pacemaker 1.1.18 soon. >> >> There will be the usual bug fixes and a few small new features, but the >> main goal will be to provide a final 1.1 release that Pacemaker 2.0 can >> branch from. >> >> As such, 1.1.18 will start to log deprecation warnings for syntax that >> is planned to be removed in 2.0. So, we need to decide fairly quickly >> what we intend to remove. > > I think it should work the other way 'round: Once pacemaker 2.0 > implemented the replacements, declare the old versions as obsolete. As apparent from this list, more often than not, people are pretty conservative regarding the updates (1.1.12 or some such versions reported are still not an exception). That alone makes it pretty sensible to start warning about future incompatibilities as much ahead of time as possible, and therefore mark the transitional period clearly. This may save the hassles when a decision to finally update is made in the future, even though I'd expect there will be automated upgrade mechanisms, either in pacemaker proper, or through 3rd party like clufter (it would actually be a right task for that tool). > I see little sense in declaring features as obsolete as long as > there is no replacement available. I am pretty sure there will be easy to find guide explaining these replacements once the gory details are figured out, i.e., prior to 2.0 release for which it's going to indeed matter first. -- Jan (Poki) pgpY41hWdeQRQ.pgp Description: PGP signature ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Antw: Pacemaker 1.1.18 deprecation warnings
On Tue, 2017-09-19 at 09:13 +0200, Ulrich Windl wrote:
> >>> Ken Gaillot schrieb am 18.09.2017 um 19:48
> in Nachricht
> <1505756918.5541.4.ca...@redhat.com>:
> > As discussed at the recent ClusterLabs Summit, I plan to start the
> > release cycle for Pacemaker 1.1.18 soon.
> >
> > There will be the usual bug fixes and a few small new features, but
> the
> > main goal will be to provide a final 1.1 release that Pacemaker 2.0
> can
> > branch from.
> >
> > As such, 1.1.18 will start to log deprecation warnings for syntax
> that
> > is planned to be removed in 2.0. So, we need to decide fairly
> quickly
> > what we intend to remove.
>
> I think it should work the other way 'round: Once pacemaker 2.0
> implemented the replacements, declare the old versions as obsolete.
> I see little sense in declaring features as obsolete as long as there
> is no replacement available.
All of the items mentioned already have replacements. Most are either
already documented as deprecated, or undocumented -- this would just be
to get a log warning as well.
I'm thinking something along the lines of:
warning: configuration uses XXX, which will be removed in a future
release of Pacemaker; use YYY instead
> > Below is what I'm proposing. If anyone feels strongly about keeping
> > support for any of these, speak now or forever hold your peace!
> >
> > * support for legacy cluster stacks (heartbeat, corosync 1 + CMAN,
> and
> > corosync 1 + pacemaker plugin). Pacemaker 2.0 will initially
> support
> > only corosync 2, though future support is planned for the new knet
> > stack.
> >
> > * compile-time option to directly support SNMP and ESMTP in crm_mon
> > (i.e. the --snmp-* and --mail-* options) (alerts are the current
> > syntax)
> >
> > * pcmk_*_cmd stonith attributes (pcmk_*_action is the current
> syntax)
> >
> > * pcmk_poweroff_action (pcmk_off_action is the current syntax)
> >
> > * "requires" operation meta-attribute ("requires" resource meta-
> > attribute is the current syntax)
> >
> > * undocumented "resource isolation" feature (bundles are current
> > syntax)
> >
> > * undocumented LRMD_MAX_CHILDREN environment variable
> > (PCMK_node_action_limit is the current syntax)
> >
> > * cluster properties that have been obsoleted by the rsc_defaults
> and
> > op_defaults sections
> > ** stonith-enabled or stonith_enabled (now "requires" in
> rsc_defaults)
> > ** default-resource-stickiness, default_resource_stickiness (now
> > "resource-stickiness" in rsc_defaults)
> > ** is-managed-default or is_managed_default (now "is-managed" in
> > rsc_defaults)
> > ** default-action-timeout or default_action_timeout (now "timeout"
> in
> > op_defaults)
> >
> > * undocumented old names of cluster properties
> > ** no_quorum_policy (now no-quorum-policy)
> > ** symmetric_cluster (now symmetric-cluster)
> > ** stonith_action (now stonith-action)
> > ** startup_fencing (now startup-fencing)
> > ** transition_idle_timeout (now cluster-delay)
> > ** default_action_timeout (now default-action-timeout)
> > ** stop_orphan_resources (now stop-orphan-resources)
> > ** stop_orphan_actions (now stop-orphan-actions)
> > ** remote_after_stop (now remove-after-stop)
> > ** dc_deadtime (now dc-deadtime)
> > ** cluster_recheck_interval (now cluster-recheck-interval)
> > ** election_timeout (now election-timeout)
> > ** shutdown_escalation (now shutdown-escalation)
> >
> > * undocumented old names of resource meta-attributes
> > ** resource-failure-stickiness, resource_failure_stickiness,
> default-
> > resource-failure-stickiness, and
> > default_resource_failure_stickiness (now migration-threshold)
> >
> > * undocumented and ignored -r option to lrmd
> >
> > * compile-time option to use undocumented "notification-agent" and
> > "notification-recipient" cluster properties instead of current
> "alerts"
> > syntax
> >
> > * compatibility with CIB schemas below 1.0, and schema 1.1 (should
> not
> > affect anyone who created their configuration using Pacemaker 1.0.0
> or
> > later)
--
Ken Gaillot
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings
On 19/09/17 08:45 +0200, Klaus Wenninger wrote: > We could as well deprecate use of CRM_NOTIFY_* in alert-agents. > Just don't know an easy way of writing out a deprecation warning > upon a script using one of these. Rename to CRM_NOTIFY_DEPRECATED_* to allow emergency sed-based re-enabling in script-based notification agents (100% now?) while getting a clear message wrt. future across? > Of course one could search the alert-agents for the string when > they are read from the CIB. Apart from the multiple points of > ugliness this would impose positive point would be a log for non > existentalert-agents prior to their unsuccessful first use. -- Jan (Poki) pgp1sazWcxX4k.pgp Description: PGP signature ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] Antwort: Re: - webdav/davfs
Jan Pokorný schrieb am 22.08.2017 19:47:43: > Von: Jan Pokorný > An: Cluster Labs - All topics related to open-source clustering > welcomed > Datum: 22.08.2017 19:52 > Betreff: Re: [ClusterLabs] - webdav/davfs > > Hello Philipp, > > [first of all, I've noticed you are practising a pretty bad habit of > starting a new topic/thread by simply responding to an existing one, > hence distorting the clear thread overview of the exchanges going > on for some of us ... please stop that, there's nothing to be afraid > of going for "compose new" and copying the correct recipient email > address (users@clo)] ok, sorry - i will change that for my next request(s)! > > On 16/08/17 16:53 +0200, philipp.achmuel...@arz.at wrote: > > are there any resource agents available to mount webdav/davfs filesystem? > > in pacemaker world[*], it's not customary to have a dedicated resource > agent just for a specific file system, as there is catch-all > ocf:heartbeat:Filesystem. Admittedly, having a brief look at some > internal details, it will need a little bit of tweaking for it to > work as "mount -t davfs http(s)://addres:/path /mount/point" > under the hood without complaints. > > As a hint to start with, I'd try adding "|davfs" after each occurrence > of "|tmpfs", you get the point: > > https://github.com/ClusterLabs/resource-agents/blob/master/ > heartbeat/Filesystem > (or locally: /usr/lib/ocf/resource.d/heartbeat/Filesystem) > > If you have a positive progress and the solution works for you, please > share your changes as a pull request against the repository per above, > otherwise, it may be best if you'll open a new issue at the same > place. > i will try this, thank you! > > [*] unlike with rgmanager where the composability of the agents used > to be a significant configuration construct justifying plain/shared > file system dichotomy > > -- > Jan (Poki) > [Anhang "attmhhhx.dat" gelöscht von Philipp Achmüller/ARZ/AT] > ___ > Users mailing list: Users@clusterlabs.org > http://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org ___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings
Hi Ken,
Any plans that there will be "lost monitoring request" handling (an added
syntax) in 2.0?
Regards,
Klecho
On 18.9.2017 12:48:38 Ken Gaillot wrote:
> As discussed at the recent ClusterLabs Summit, I plan to start the
> release cycle for Pacemaker 1.1.18 soon.
>
> There will be the usual bug fixes and a few small new features, but the
> main goal will be to provide a final 1.1 release that Pacemaker 2.0 can
> branch from.
>
> As such, 1.1.18 will start to log deprecation warnings for syntax that
> is planned to be removed in 2.0. So, we need to decide fairly quickly
> what we intend to remove.
>
> Below is what I'm proposing. If anyone feels strongly about keeping
> support for any of these, speak now or forever hold your peace!
>
> * support for legacy cluster stacks (heartbeat, corosync 1 + CMAN, and
> corosync 1 + pacemaker plugin). Pacemaker 2.0 will initially support
> only corosync 2, though future support is planned for the new knet
> stack.
>
> * compile-time option to directly support SNMP and ESMTP in crm_mon
> (i.e. the --snmp-* and --mail-* options) (alerts are the current
> syntax)
>
> * pcmk_*_cmd stonith attributes (pcmk_*_action is the current syntax)
>
> * pcmk_poweroff_action (pcmk_off_action is the current syntax)
>
> * "requires" operation meta-attribute ("requires" resource meta-
> attribute is the current syntax)
>
> * undocumented "resource isolation" feature (bundles are current
> syntax)
>
> * undocumented LRMD_MAX_CHILDREN environment variable
> (PCMK_node_action_limit is the current syntax)
>
> * cluster properties that have been obsoleted by the rsc_defaults and
> op_defaults sections
> ** stonith-enabled or stonith_enabled (now "requires" in rsc_defaults)
> ** default-resource-stickiness, default_resource_stickiness (now
> "resource-stickiness" in rsc_defaults)
> ** is-managed-default or is_managed_default (now "is-managed" in
> rsc_defaults)
> ** default-action-timeout or default_action_timeout (now "timeout" in
> op_defaults)
>
> * undocumented old names of cluster properties
> ** no_quorum_policy (now no-quorum-policy)
> ** symmetric_cluster (now symmetric-cluster)
> ** stonith_action (now stonith-action)
> ** startup_fencing (now startup-fencing)
> ** transition_idle_timeout (now cluster-delay)
> ** default_action_timeout (now default-action-timeout)
> ** stop_orphan_resources (now stop-orphan-resources)
> ** stop_orphan_actions (now stop-orphan-actions)
> ** remote_after_stop (now remove-after-stop)
> ** dc_deadtime (now dc-deadtime)
> ** cluster_recheck_interval (now cluster-recheck-interval)
> ** election_timeout (now election-timeout)
> ** shutdown_escalation (now shutdown-escalation)
>
> * undocumented old names of resource meta-attributes
> ** resource-failure-stickiness, resource_failure_stickiness, default-
> resource-failure-stickiness, and
> default_resource_failure_stickiness (now migration-threshold)
>
> * undocumented and ignored -r option to lrmd
>
> * compile-time option to use undocumented "notification-agent" and
> "notification-recipient" cluster properties instead of current "alerts"
> syntax
>
> * compatibility with CIB schemas below 1.0, and schema 1.1 (should not
> affect anyone who created their configuration using Pacemaker 1.0.0 or
> later)
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
[ClusterLabs] Antw: Pacemaker 1.1.18 deprecation warnings
>>> Ken Gaillot schrieb am 18.09.2017 um 19:48 in
>>> Nachricht
<1505756918.5541.4.ca...@redhat.com>:
> As discussed at the recent ClusterLabs Summit, I plan to start the
> release cycle for Pacemaker 1.1.18 soon.
>
> There will be the usual bug fixes and a few small new features, but the
> main goal will be to provide a final 1.1 release that Pacemaker 2.0 can
> branch from.
>
> As such, 1.1.18 will start to log deprecation warnings for syntax that
> is planned to be removed in 2.0. So, we need to decide fairly quickly
> what we intend to remove.
I think it should work the other way 'round: Once pacemaker 2.0 implemented the
replacements, declare the old versions as obsolete.
I see little sense in declaring features as obsolete as long as there is no
replacement available.
>
> Below is what I'm proposing. If anyone feels strongly about keeping
> support for any of these, speak now or forever hold your peace!
>
> * support for legacy cluster stacks (heartbeat, corosync 1 + CMAN, and
> corosync 1 + pacemaker plugin). Pacemaker 2.0 will initially support
> only corosync 2, though future support is planned for the new knet
> stack.
>
> * compile-time option to directly support SNMP and ESMTP in crm_mon
> (i.e. the --snmp-* and --mail-* options) (alerts are the current
> syntax)
>
> * pcmk_*_cmd stonith attributes (pcmk_*_action is the current syntax)
>
> * pcmk_poweroff_action (pcmk_off_action is the current syntax)
>
> * "requires" operation meta-attribute ("requires" resource meta-
> attribute is the current syntax)
>
> * undocumented "resource isolation" feature (bundles are current
> syntax)
>
> * undocumented LRMD_MAX_CHILDREN environment variable
> (PCMK_node_action_limit is the current syntax)
>
> * cluster properties that have been obsoleted by the rsc_defaults and
> op_defaults sections
> ** stonith-enabled or stonith_enabled (now "requires" in rsc_defaults)
> ** default-resource-stickiness, default_resource_stickiness (now
> "resource-stickiness" in rsc_defaults)
> ** is-managed-default or is_managed_default (now "is-managed" in
> rsc_defaults)
> ** default-action-timeout or default_action_timeout (now "timeout" in
> op_defaults)
>
> * undocumented old names of cluster properties
> ** no_quorum_policy (now no-quorum-policy)
> ** symmetric_cluster (now symmetric-cluster)
> ** stonith_action (now stonith-action)
> ** startup_fencing (now startup-fencing)
> ** transition_idle_timeout (now cluster-delay)
> ** default_action_timeout (now default-action-timeout)
> ** stop_orphan_resources (now stop-orphan-resources)
> ** stop_orphan_actions (now stop-orphan-actions)
> ** remote_after_stop (now remove-after-stop)
> ** dc_deadtime (now dc-deadtime)
> ** cluster_recheck_interval (now cluster-recheck-interval)
> ** election_timeout (now election-timeout)
> ** shutdown_escalation (now shutdown-escalation)
>
> * undocumented old names of resource meta-attributes
> ** resource-failure-stickiness, resource_failure_stickiness, default-
> resource-failure-stickiness, and
> default_resource_failure_stickiness (now migration-threshold)
>
> * undocumented and ignored -r option to lrmd
>
> * compile-time option to use undocumented "notification-agent" and
> "notification-recipient" cluster properties instead of current "alerts"
> syntax
>
> * compatibility with CIB schemas below 1.0, and schema 1.1 (should not
> affect anyone who created their configuration using Pacemaker 1.0.0 or
> later)
> --
> Ken Gaillot
>
>
>
>
> ___
> Users mailing list: Users@clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
