date:20130623

Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there

2013-06-23 Thread Vladislav Bogdanov

24.06.2013 04:17, Andrew Beekhof wrote:
> Either people have given up on testing, or rc5[1] is looking good for the 
> final release.

Is it going to be 1.1.10 or 1.2.0 (2.0.0)?

> 
> So just a reminder, we're particularly looking for feedback in the following 
> areas:
> 
> | plugin-based clusters, ACLs, the new –ban and –clear commands, and admin 
> actions
> | (such as  moving and stopping resources, calls to stonith_admin) which are 
> hard 
> | to test in an automated manner.
> |
> | Also any light that can be shed on possible memory leaks would be much 
> appreciated.
> 
> I would very much like to hear the observations (good or bad) of people that 
> have taken it for a spin.
> 
> -- Andrew
> 
> [1] http://blog.clusterlabs.org/blog/2013/release-candidate-1-dot-1-10-rc5/
> ___
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
> 


___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [Pacemaker] error when build pacemaker 1.1.10-rc5 and corosync-2.3.0

2013-06-23 Thread Takatoshi MATSUO

Hi Andrew

2013/6/24 Andrew Beekhof :
>
> On 24/06/2013, at 12:46 PM, Takatoshi MATSUO  wrote:
>
>> Hi Andrew
>>
>> I received similar error using 6ea4b7e(HEAD) under RHEL6.
>> -
>> # export WITH='--without cman --without heartbeat'; make rpm-dep
>> (snip)
>> --> Finished Dependency Resolution
>> Error: Package: clusterlib-3.0.12.1-32.el6.x86_64 (sl)
>>   Requires: libconfdb.so.4(COROSYNC_CONFDB_1.0)(64bit)
>> Error: Package: clusterlib-3.0.12.1-32.el6.x86_64 (sl)
>>   Requires: libconfdb.so.4()(64bit)
>> You could try using --skip-broken to work around the problem
>> You could try running: rpm -Va --nofiles --nodigest
>> make: *** [rpm-dep] Error 1
>> -
>>
>> So I removed all references to clusterlib-devel from pacemaker.spec.in
>> as follows.
>> 
>> # If you want to build for unofficial installs of corosync-2 on RHEL < 7
>> # or fedora < 17, remove all references to clusterlib-devel below
>>
>> #%if 0%{?fedora} > 0
>> #%if 0%{?fedora} < 17
>> #BuildRequires: clusterlib-devel
>> #%endif
>> #%endif
>> #
>> #%if 0%{?rhel} > 0
>> #%if 0%{?rhel} < 7
>> #BuildRequires: clusterlib-devel
>> #%endif
>> #%endif
>> -
>
> The reason for this is that I'm trying to streamline the spec file.
> It had become an unreadable mess trying to cater to everyone.
>
> Since cman is available for RHEL6, have you thought about installing it from 
> RH or CentOS?

Does cman require High Availability add-on license under RHEL6 ?

>>
>> But I received another error.
>> -
>> # export WITH='--without cman --without heartbeat'; make rpm
>
> The cman and heartbeat conditionals also went in the cleanup, so they'll be 
> having no effect here.

How about not requiring clusterlib-devel when using "--without cman" ?
Is it go against  streamlining the spec file ?

>> (snip)
>> Processing files: pacemaker-debuginfo-1.1.10-1.el6.x86_64
>> Checking for unpackaged file(s): /usr/lib/rpm/check-files
>> /root/rpmbuild/BUILDROOT/pacemaker-1.1.10-1.fedora.x86_64
>> error: Installed (but unpackaged) file(s) found:
>>   /usr/lib64/heartbeat/attrd
>>   /usr/lib64/heartbeat/cib
>>   /usr/lib64/heartbeat/crmd
>>   /usr/lib64/heartbeat/pengine
>>   /usr/lib64/heartbeat/stonithd
>>   /usr/sbin/crm_uuid
>
> It looks like the machine you're building on has heartbeat installed which is 
> confusing configure.
> Any reason to not just remove it?

I just built Pacemaker 1.0.x which supports heartbeat under same
machine a short time ago
I succeed in built after removing it.
Thank you for the advice,

>>
>> RPM build errors:
>>Installed (but unpackaged) file(s) found:
>>   /usr/lib64/heartbeat/attrd
>>   /usr/lib64/heartbeat/cib
>>   /usr/lib64/heartbeat/crmd
>>   /usr/lib64/heartbeat/pengine
>>   /usr/lib64/heartbeat/stonithd
>>   /usr/sbin/crm_uuid
>> make: *** [rpm] Error 1
>> -
>>
>> Regards,
>> Takatoshi MATSUO
>>
>> 2013/6/21 Andrew Beekhof :
>>>
>>> On 20/06/2013, at 11:22 PM, Andrey Groshev  wrote:
>>>
 Hi, again.
 Still one week ago package normaly rebuilding.
 Today, I resive error:
>>>
>>> Just remove all references to clusterlib-devel from pacemaker.spec.in
>>> I'll see what I can do
>>>

 # make rpm-dep
 if [ x != x`which yum-builddep 2>/dev/null` ]; then \
   echo "Installing with yum-builddep";\
   sudo yum-builddep pacemaker-fedora.spec;\
   elif [ x != x`which yum 2>/dev/null` ]; then 
\
   echo -e "Installing:  python-curses python-xml  automake 
 autoconf libtool pkgconfig python libtool-ltdl-devel  glib2-devel 
 libxml2-devel libxslt-d
 evel libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
 resource-agents  libqb-devel   ncurses-devel openssl-devel 
 libselinux-devel docbook-
 style-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
 gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
 cluster-glue-libs
 -devel  publican inkscape asciidoc \n\n";   \
   sudo yum install  python-curses python-xml  automake autoconf 
 libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
 libxslt-devel
 libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
 resource-agents  libqb-devel   ncurses-devel openssl-devel 
 libselinux-devel docbook-styl
 e-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
 gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
 cluster-glue-libs-dev
 el  publican inkscape asciidoc ;\
   elif [ x != x`which zypper` ]; then \
   echo -e "Installing:  python-curses python-xml  automake 
 autoconf libtool pkgconfig python libtool-ltdl-devel  glib2-devel 
 libxml2-devel libxslt-d
 evel libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
 resource-agents  libqb-devel   n

Re: [Pacemaker] error when build pacemaker 1.1.10-rc5 and corosync-2.3.0

2013-06-23 Thread Andrew Beekhof


On 24/06/2013, at 12:46 PM, Takatoshi MATSUO  wrote:

> Hi Andrew
> 
> I received similar error using 6ea4b7e(HEAD) under RHEL6.
> -
> # export WITH='--without cman --without heartbeat'; make rpm-dep
> (snip)
> --> Finished Dependency Resolution
> Error: Package: clusterlib-3.0.12.1-32.el6.x86_64 (sl)
>   Requires: libconfdb.so.4(COROSYNC_CONFDB_1.0)(64bit)
> Error: Package: clusterlib-3.0.12.1-32.el6.x86_64 (sl)
>   Requires: libconfdb.so.4()(64bit)
> You could try using --skip-broken to work around the problem
> You could try running: rpm -Va --nofiles --nodigest
> make: *** [rpm-dep] Error 1
> -
> 
> So I removed all references to clusterlib-devel from pacemaker.spec.in
> as follows.
> 
> # If you want to build for unofficial installs of corosync-2 on RHEL < 7
> # or fedora < 17, remove all references to clusterlib-devel below
> 
> #%if 0%{?fedora} > 0
> #%if 0%{?fedora} < 17
> #BuildRequires: clusterlib-devel
> #%endif
> #%endif
> #
> #%if 0%{?rhel} > 0
> #%if 0%{?rhel} < 7
> #BuildRequires: clusterlib-devel
> #%endif
> #%endif
> -

The reason for this is that I'm trying to streamline the spec file.
It had become an unreadable mess trying to cater to everyone.

Since cman is available for RHEL6, have you thought about installing it from RH 
or CentOS?

> 
> 
> But I received another error.
> -
> # export WITH='--without cman --without heartbeat'; make rpm

The cman and heartbeat conditionals also went in the cleanup, so they'll be 
having no effect here.

> (snip)
> Processing files: pacemaker-debuginfo-1.1.10-1.el6.x86_64
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /root/rpmbuild/BUILDROOT/pacemaker-1.1.10-1.fedora.x86_64
> error: Installed (but unpackaged) file(s) found:
>   /usr/lib64/heartbeat/attrd
>   /usr/lib64/heartbeat/cib
>   /usr/lib64/heartbeat/crmd
>   /usr/lib64/heartbeat/pengine
>   /usr/lib64/heartbeat/stonithd
>   /usr/sbin/crm_uuid

It looks like the machine you're building on has heartbeat installed which is 
confusing configure.
Any reason to not just remove it?

> 
> 
> RPM build errors:
>Installed (but unpackaged) file(s) found:
>   /usr/lib64/heartbeat/attrd
>   /usr/lib64/heartbeat/cib
>   /usr/lib64/heartbeat/crmd
>   /usr/lib64/heartbeat/pengine
>   /usr/lib64/heartbeat/stonithd
>   /usr/sbin/crm_uuid
> make: *** [rpm] Error 1
> -
> 
> Regards,
> Takatoshi MATSUO
> 
> 2013/6/21 Andrew Beekhof :
>> 
>> On 20/06/2013, at 11:22 PM, Andrey Groshev  wrote:
>> 
>>> Hi, again.
>>> Still one week ago package normaly rebuilding.
>>> Today, I resive error:
>> 
>> Just remove all references to clusterlib-devel from pacemaker.spec.in
>> I'll see what I can do
>> 
>>> 
>>> # make rpm-dep
>>> if [ x != x`which yum-builddep 2>/dev/null` ]; then \
>>>   echo "Installing with yum-builddep";\
>>>   sudo yum-builddep pacemaker-fedora.spec;\
>>>   elif [ x != x`which yum 2>/dev/null` ]; then  
>>>   \
>>>   echo -e "Installing:  python-curses python-xml  automake autoconf 
>>> libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
>>> libxslt-d
>>> evel libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
>>> resource-agents  libqb-devel   ncurses-devel openssl-devel libselinux-devel 
>>> docbook-
>>> style-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
>>> gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
>>> cluster-glue-libs
>>> -devel  publican inkscape asciidoc \n\n";   \
>>>   sudo yum install  python-curses python-xml  automake autoconf 
>>> libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
>>> libxslt-devel
>>> libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
>>> resource-agents  libqb-devel   ncurses-devel openssl-devel libselinux-devel 
>>> docbook-styl
>>> e-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
>>> gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
>>> cluster-glue-libs-dev
>>> el  publican inkscape asciidoc ;\
>>>   elif [ x != x`which zypper` ]; then \
>>>   echo -e "Installing:  python-curses python-xml  automake autoconf 
>>> libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
>>> libxslt-d
>>> evel libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
>>> resource-agents  libqb-devel   ncurses-devel openssl-devel libselinux-devel 
>>> docbook-
>>> style-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
>>> gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
>>> cluster-glue-libs
>>> -devel  publican inkscape asciidoc \n\n";   \
>>>   sudo zypper install  python-curses python-xml  automake autoconf 
>>> libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
>>> libxslt-de
>>> vel libuuid-devel  pkgconfig pytho

Re: [Pacemaker] error when build pacemaker 1.1.10-rc5 and corosync-2.3.0

2013-06-23 Thread Takatoshi MATSUO

Hi Andrew

I received similar error using 6ea4b7e(HEAD) under RHEL6.
-
# export WITH='--without cman --without heartbeat'; make rpm-dep
(snip)
--> Finished Dependency Resolution
Error: Package: clusterlib-3.0.12.1-32.el6.x86_64 (sl)
   Requires: libconfdb.so.4(COROSYNC_CONFDB_1.0)(64bit)
Error: Package: clusterlib-3.0.12.1-32.el6.x86_64 (sl)
   Requires: libconfdb.so.4()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
make: *** [rpm-dep] Error 1
-

So I removed all references to clusterlib-devel from pacemaker.spec.in
as follows.

# If you want to build for unofficial installs of corosync-2 on RHEL < 7
# or fedora < 17, remove all references to clusterlib-devel below

#%if 0%{?fedora} > 0
#%if 0%{?fedora} < 17
#BuildRequires: clusterlib-devel
#%endif
#%endif
#
#%if 0%{?rhel} > 0
#%if 0%{?rhel} < 7
#BuildRequires: clusterlib-devel
#%endif
#%endif
-


But I received another error.
-
# export WITH='--without cman --without heartbeat'; make rpm
(snip)
Processing files: pacemaker-debuginfo-1.1.10-1.el6.x86_64
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/root/rpmbuild/BUILDROOT/pacemaker-1.1.10-1.fedora.x86_64
error: Installed (but unpackaged) file(s) found:
   /usr/lib64/heartbeat/attrd
   /usr/lib64/heartbeat/cib
   /usr/lib64/heartbeat/crmd
   /usr/lib64/heartbeat/pengine
   /usr/lib64/heartbeat/stonithd
   /usr/sbin/crm_uuid


RPM build errors:
Installed (but unpackaged) file(s) found:
   /usr/lib64/heartbeat/attrd
   /usr/lib64/heartbeat/cib
   /usr/lib64/heartbeat/crmd
   /usr/lib64/heartbeat/pengine
   /usr/lib64/heartbeat/stonithd
   /usr/sbin/crm_uuid
make: *** [rpm] Error 1
-

Regards,
Takatoshi MATSUO

2013/6/21 Andrew Beekhof :
>
> On 20/06/2013, at 11:22 PM, Andrey Groshev  wrote:
>
>> Hi, again.
>> Still one week ago package normaly rebuilding.
>> Today, I resive error:
>
> Just remove all references to clusterlib-devel from pacemaker.spec.in
> I'll see what I can do
>
>>
>> # make rpm-dep
>> if [ x != x`which yum-builddep 2>/dev/null` ]; then \
>>echo "Installing with yum-builddep";\
>>sudo yum-builddep pacemaker-fedora.spec;\
>>elif [ x != x`which yum 2>/dev/null` ]; then  
>>   \
>>echo -e "Installing:  python-curses python-xml  automake autoconf 
>> libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
>> libxslt-d
>> evel libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
>> resource-agents  libqb-devel   ncurses-devel openssl-devel libselinux-devel 
>> docbook-
>> style-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
>> gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
>> cluster-glue-libs
>> -devel  publican inkscape asciidoc \n\n";   \
>>sudo yum install  python-curses python-xml  automake autoconf 
>> libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
>> libxslt-devel
>> libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
>> resource-agents  libqb-devel   ncurses-devel openssl-devel libselinux-devel 
>> docbook-styl
>> e-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
>> gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
>> cluster-glue-libs-dev
>> el  publican inkscape asciidoc ;\
>>elif [ x != x`which zypper` ]; then \
>>echo -e "Installing:  python-curses python-xml  automake autoconf 
>> libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
>> libxslt-d
>> evel libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
>> resource-agents  libqb-devel   ncurses-devel openssl-devel libselinux-devel 
>> docbook-
>> style-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
>> gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
>> cluster-glue-libs
>> -devel  publican inkscape asciidoc \n\n";   \
>>sudo zypper install  python-curses python-xml  automake autoconf 
>> libtool pkgconfig python libtool-ltdl-devel  glib2-devel libxml2-devel 
>> libxslt-de
>> vel libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel pam-devel  
>> resource-agents  libqb-devel   ncurses-devel openssl-devel libselinux-devel 
>> docbook-s
>> tyle-xsl  bison byacc flex help2man  systemd-devel   libgnutls-devel   
>> gnutls-devel  clusterlib-devel  clusterlib-devel  corosynclib-devel  
>> cluster-glue-libs-
>> devel  publican inkscape asciidoc ;\
>>else\
>>echo "I don't know how to install  python-curses python-xml  
>> automake autoconf libtool pkgconfig python libtool-ltdl-devel  glib2-devel 
>> libxml2-de
>> vel libxslt-devel libuuid-devel  pkgconfig python-devel gcc-c++ bzip2-devel 
>> pam-devel  resource-a

[Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there

2013-06-23 Thread Andrew Beekhof

Either people have given up on testing, or rc5[1] is looking good for the final 
release.

So just a reminder, we're particularly looking for feedback in the following 
areas:

| plugin-based clusters, ACLs, the new –ban and –clear commands, and admin 
actions
| (such as  moving and stopping resources, calls to stonith_admin) which are 
hard 
| to test in an automated manner.
|
| Also any light that can be shed on possible memory leaks would be much 
appreciated.

I would very much like to hear the observations (good or bad) of people that 
have taken it for a spin.

-- Andrew

[1] http://blog.clusterlabs.org/blog/2013/release-candidate-1-dot-1-10-rc5/
___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [Pacemaker] Pacemaker fails to switch on or off PDU sockets with fence_wti

2013-06-23 Thread Andrew Beekhof


On 21/06/2013, at 5:38 PM, Thibaut Pouzet  
wrote:

> Le 20/06/2013 12:23, Andrew Beekhof a écrit :
>> On 20/06/2013, at 6:51 PM, Thibaut Pouzet  
>> wrote:
>> 
>>> Le 19/06/2013 23:57, Andrew Beekhof a écrit :
 On 20/06/2013, at 1:57 AM, Thibaut Pouzet 
  wrote:
 
> Hi,
> 
> I am trying to configure fencing on a test platform with two nodes under 
> corosync+cman+pacemaker on CentOS 6.4. Both nodes have a double power 
> supply from a WTI NPS-8HD16-3. IPMI fencing works like a charm, however I 
> cannot get the WTI fencing to work.
> 
> The problem is that the parameter  action="" seems to be ignored by 
> pacemaker.
> * This is the primitive :
> primitive wti_fence02_port2_off stonith:fence_wti \
>params ipaddr="" action="off" pcmk_host_check="none" port="A2" 
> pcmk_host_check="static-list" pcmk_host_list="fence02.lyra-network.com" 
> login="" passwd="" shell_timeout="20" login_timeout="20"
> 
> * These are the corresponding log lines :
> Jun 19 16:56:45 fence01 stonith-ng[19266]:   notice: log_operation: 
> Operation 'reboot' [19953] (call 0 from crmd.19268) for host 
> 'fence02.lyra-network.com' with device 'wti_fence02_port2_off' returned: 
> 0 (OK)
> Jun 19 16:56:45 fence01 stonith-ng[19266]:   notice: 
> process_remote_stonith_exec: Call to wti_fence02_port2_off for 
> fence02.lyra-network.com on behalf of 
> crmd.19...@fence01.lyra-network.com: passed (0)
> 
> * These are the version used :
> pacemaker-1.1.8-7.el6.x86_64
> corosync-1.4.1-15.el6.x86_64
> cman-3.0.12.1-49.el6.x86_64
> fence-agents-3.1.5-25.el6_4.2.x86_64
> 
> The same thing happens with "on" actions.
> 
> When I run fence_wti from command line, it works perfectly fine with ON 
> or OFF actions ! I feel there is a workaround with something like 
> pcmk_reboot_action="/ON", but I don't understand how to use this...
> 
> (FYI, I'm using fencing topology like this :
> fencing_topology \
>fence01.lyra-network.com: 
> wti_fence01_port1_off,wti_fence01_port5_off,wti_fence01_port5_on,wti_fence01_port1_on
>  ipmi_fence01 \
>fence02.lyra-network.com: 
> wti_fence02_port2_off,wti_fence02_port6_off,wti_fence02_port6_on,wti_fence02_port2_on
>  ipmi_fence02 )
> 
> What is wrong here ?
 I believe you're trying to use the per-agent pcmk_reboot_action option 
 (man stonithd)
 But you might be better off with the global stonith-action option (man 
 pengine)
 
>>> Hum, I think I've not been clear enough on the initial e-mail. The usage of 
>>> "pcmk_reboot_action" or "stonith-action" is not the root of my problem. The 
>>> initial problem is that when I configure action="off"
>> My point would be that action=off is not the correct way to configure what 
>> you're trying to do.
>> 
>>> with a stonith primitive,  when this primitive is called, the actual action 
>>> that is launched through fence_wti is "reboot".
>>> 
>>> Therefore, when a node needs to be fenced, instead of having on the PDU :
>>> Port 2 OFF -> Port 6 OFF -> Port 6 ON -> Port 2 ON
>>> I have :
>>> Port 2 Reboot -> Port 6 Reboot -> Port 6 Reboot -> Port 2 Reboot
>>> 
>>> All actions are successful, pacemaker changes the fenced node's status from 
>>> "UNCLEAN" to "OFFLINE", while the node has not been rebooted at all.
>>> 
>>> -- 
>>> Thibaut Pouzet
>>> 
>>> 
> Okay, I took a look at these options, and replaced action="" from my 
> primitives with stonith-action="off" as a global property. I removed the 
> useless primitives and changed the topology :
> 
> fencing_topology \
>fence01.lyra-network.com: wti_fence01_port1_off,wti_fence01_port5_off 
> ipmi_fence01 \
>fence02.lyra-network.com: wti_fence02_port2_off,wti_fence02_port6_off 
> ipmi_fence02
> 
> My faulty node is off now, it's been shut down through the WTI. Next step : 
> rebooting the nodes. I'm not sure we can achieve such thing with this method 
> though...

This should do the trick:
   stonith_admin --unfence fence01.lyra-network.com

A future version of the agent should actually support reboot with multiple 
ports though.
If you're impatient, you could try the latest upstream release.

> 
> I looked at the code of fence_wti, and how it was called from pacemaker, and 
> I believe there could be a minor patch to the fencing agent that would make 
> everything easier :
> * On WTI switches, you can configure named port groups, and reboot a port 
> group (i.e. several PSUs) the same way you reboot a single port.
> * These port groups can be monitored via the command '/SG' in opposition to 
> single ports, monitored with '/S'. The output is a bit different, but not so 
> different.
> * When you call fence_wti with a named port group, the script wants to get 
> the status of the port group before making any action. Since the port groups 
> statuses are not reachable from '/S

Re: [Pacemaker] known problem with corosync 1.4.1 on centos64 ?

2013-06-23 Thread Andrew Beekhof


On 22/06/2013, at 5:13 AM, Andreas Mock  wrote:

> Hi Andreas,
>  
> my two cents to your questions:
>  
> a) If you want to learn most, take any distro and compile the components from
> source and afterwards use them. => Most learned.

Well, yes, but not always about clustering and not always things that couldn't 
have been learned from reading the docs (and staying awake).

>  
> b) I don't know how others think about it: But I use a cluster to try to 
> increase uptime.
> If I know that a disto's component is buggy causing failures while doing the 
> first steps
> with a more or less standard config (corosync/pacemaker/drbd + some service) 
> I have
> two choices when I have to stick to a distro's repos:
> 1) Take the next step distro…6.4 in your case.

Absolutely.

> But it can have bugs too.

True, but they might not be ones that affect you.

> 2) Ask why it is important to stick to the ditro's repos with a certain 
> software stack.

The answer should be "support".
IMHO, you should obtain the packages from whoever is going to be supplying it 
(otherwise you're making it impossible for them to help).

If you're here, I'd suggest upstream packages unless you're using a paid-for 
distro like RHEL or SLES.

> In your case I don't know why it is "allowed" to build drbd from source and 
> it's not
> "allowed" to build the cluster stack from source. Especially while getting 
> the feet wet
> with corosync/pacemaker and all the stuff is much more effort compared to the 
> effort
> understanding, configuring and maintaining a cluster.
>  
> My policy is also to keep as close as possible to the distro's repos. But when
> I need a newer or more stable version of a software, I have to use it.
>  
> Best regards
> Andreas
>  
>  
>  
> Von: andreas graeper [mailto:agrae...@googlemail.com] 
> Gesendet: Freitag, 21. Juni 2013 15:00
> An: The Pacemaker cluster resource manager
> Betreff: Re: [Pacemaker] known problem with corosync 1.4.1 on centos64 ?
>  
> hi,
> > old version :
> i shall maintain a centos63 with, except drbd (build from source), only 
> standard-repos are used.
> for testing i installed newest centos64, but .. .
> 
> there is no chance to get rid of that centos63, but for learning/testing what 
> are the best distros ? not in general, but for use with 
> drbd+corosync+pacemaker.
> 
>  
> 
> 2013/6/21 Lars Marowsky-Bree 
> On 2013-06-21T10:56:29, andreas graeper  wrote:
> 
> > hi,
> > when only i remove or add resources, corosync starts to eat up all cpu.
> > drbd 8.4.1 (build from source)
> > corosync 1.4.1
> 
> yes, corosync 1.4.1 had one such error, I recall. If you're building
> from source, why are you sticking to such an old version?
> 
> 
> 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
> 
> 
> ___
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>  
> ___
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org


___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there

Re: [Pacemaker] error when build pacemaker 1.1.10-rc5 and corosync-2.3.0

Re: [Pacemaker] error when build pacemaker 1.1.10-rc5 and corosync-2.3.0

Re: [Pacemaker] error when build pacemaker 1.1.10-rc5 and corosync-2.3.0

[Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there

Re: [Pacemaker] Pacemaker fails to switch on or off PDU sockets with fence_wti

Re: [Pacemaker] known problem with corosync 1.4.1 on centos64 ?

7 matches

Site Navigation

Mail list logo

Footer information