Re: [ClusterLabs] pcs 0.10.1 released
On 2018-11-26 12:26 p.m., Tomas Jelinek wrote: I am happy to announce the latest release of pcs, version 0.10.1. Source code is available at: https://github.com/ClusterLabs/pcs/archive/0.10.1.tar.gz or https://github.com/ClusterLabs/pcs/archive/0.10.1.zip This is the first final release of the pcs-0.10 branch. Pcs-0.10 is the new main pcs branch supporting Corosync 3.x and Pacemaker 2.x clusters while dropping support for older Corosync and Pacemaker versions. Pcs-0.9, being in maintenance mode, continues to support Corosync 1.x/2.x and Pacemaker 1.x clusters. Main changes compared to 0.9 branch: * Corosync 3.x and Kronosnet is supported while Corosync 2.x and older as well as CMAN are not * Node names are now fully supported * Pacemaker 2.x is supported while Pacemaker 1.x is not * Promotable clone resources replaced master resources; creating master resources is no longer possible but managing existing master resources is supported * Options starting with '-' and '--' are no longer accepted by commands for which those options have no effect * Obsoleting parameters of resource and fence agents are now supported and preferred over deprecated parameters * Several deprecated and / or undocumented pcs commands / options have been removed * Python 3.6+ and Ruby 2.2+ is now required Complete change log for this release against 0.9.163: ## [0.10.1] - 2018-11-23 ### Removed - Pcs-0.10 removes support for CMAN, Corosync 1.x, Corosync 2.x and Pacemaker 1.x based clusters. For managing those clusters use pcs-0.9.x. - Pcs-0.10 requires Python 3.6 and Ruby 2.2, support for older Python and Ruby versions has been removed. - `pcs resource failcount reset` command has been removed as `pcs resource cleanup` is doing exactly the same job. ([rhbz#1427273]) - Deprecated commands `pcs cluster remote-node add | remove` have been removed as they were replaced with `pcs cluster node add-guest | remove-guest` - Ability to create master resources has been removed as they are deprecated in Pacemaker 2.x ([rhbz#1542288]) - Instead of `pcs resource create ... master` use `pcs resource create ... promotable` or `pcs resource create ... clone promotable=true` - Instead of `pcs resource master` use `pcs resource promotable` or `pcs resource clone ... promotable=true` - Deprecated --clone option from `pcs resource create` command - Ability to manage node attributes with `pcs property set|unset|show` commands (using `--node` option). The same functionality is still available using `pcs node attribute` command. - Undocumented version of the `pcs constraint colocation add` command, its syntax was `pcs constraint colocation add [score] [options]` - Deprecated commands `pcs cluster standby | unstandby`, use `pcs node standby | unstandby` instead - Deprecated command `pcs cluster quorum unblock` which was replaced by `pcs quorum unblock` - Subcommand `pcs status groups` as it was not showing a cluster status but cluster configuration. The same functionality is still available using command `pcs resource group list` - Undocumented command `pcs acl target`, use `pcs acl user` instead ### Added - Validation for an unaccessible resource inside a bundle ([rhbz#1462248]) - Options to filter failures by an operation and its interval in `pcs resource cleanup` and `pcs resource failcount show` commands ([rhbz#1427273]) - Commands for listing and testing watchdog devices ([rhbz#1578891]) - Commands for creating promotable clone resources `pcs resource promotable` and `pcs resource create ... promotable` ([rhbz#1542288]) - `pcs resource update` and `pcs resource meta` commands change master resources to promotable clone resources because master resources are deprecated in Pacemaker 2.x ([rhbz#1542288]) - Support for the `promoted-max` bundle option replacing the `masters` option in Pacemaker 2.x ([rhbz#1542288]) - Support for OP_NO_RENEGOTIATION option when OpenSSL supports it (even with Python 3.6) ([rhbz#1566430]) - Support for container types `rkt` and `podman` into bundle commands ([rhbz#1619620]) - Support for promotable clone resources in pcsd and web UI ([rhbz#1542288]) - Obsoleting parameters of resource and fence agents are now supported and preferred over deprecated parameters ([rhbz#1436217]) - `pcs status` now shows failed and pending fencing actions and `pcs status --full` shows the whole fencing history. Pacemaker supporting fencing history is required. ([rhbz#1615891]) - `pcs stonith history` commands for displaying, synchronizing and cleaning up fencing history. Pacemaker supporting fencing history is required. ([rhbz#1620190]) - Validation of node existence in a cluster when creating location constraints ([rhbz#1553718]) - Command `pcs client local-auth` for authentication of pcs client against local pcsd. This is required when a non-root user wants to execute a command which requires root permissions (e.g. `pcs cluster start`).
[ClusterLabs] [Problem] The crmd fails to connect with pengine.
Hi All, This problem occurred with our users. The following problem occurred in a two-node cluster that does not set STONITH. The problem seems to have occurred in the following procedure. Step 1) Configure the cluster with 2 nodes. The DC node is the second node. Step 2) Several resources are running on the first node. Step 3) It stops almost at the same time in order of 2nd node and 1st node. Step 4) After the second node stops, the first node tries to calculate the state transition for the resource stop. However, crmd fails to connect with pengine and does not calculate state transitions. - Dec 27 08:36:00 rh74-01 crmd[12997]: warning: Setup of client connection failed, not adding channel to mainloop - As a result, Pacemaker will stop without stopping the resource. The problem seems to have occurred in the following environment. - libqb 1.0 - corosync 2.4.1 - Pacemaker 1.1.15 I tried to reproduce this problem, but for now it can not be reproduced. Do you know the cause of this problem? Best Regards, Hideo Yamacuhi. ___ Users mailing list: Users@clusterlabs.org https://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: Re: SuSE12SP3 HAE SBD Communication Issue
Hi! Offline a SCSI disk: "echo offline > /sys/block/sd/device/state". The opposite is not "online", BTW, but: ""echo running > /sys/block/sd/device/state". You could also try "echo "scsi remove-single-device" > /proc/scsi/scsi", where MAGIC is (AFAIR) "HOST BUS TARGET LUN". Regards, Ulrich >>> Fulong Wang 24.12.18 7.10 Uhr >>> Yan, klaus and Everyone, Merry Christmas!!! Many thanks for your advice! I added the "-v" param in "SBD_OPTS", but didn't see any apparent change in the system message log, am i looking at a wrong place? By the way, we want to test when the disk access paths (multipath devices) lost, the sbd can fence the node automatically. what's your recommendation for this scenario? [cid:d2557952-5a58-49b8-a6c2-6903bd401f6b] [cid:3fcb9b0d-f08f-4d5f-bec7-678841f848ca] The "crm node fence" did the work. [cid:1454a9c9-fd84-4aae-9625-600c756ab587] [cid:3917dddb-ce98-430b-9cfc-d02cc9569748] [cid:c0fa78fd-49fa-4780-b24b-27bf85db0796] Regards Fulong From: Gao,Yan Sent: Friday, December 21, 2018 20:43 To: kwenn...@redhat.com; Cluster Labs - All topics related to open-source clustering welcomed; Fulong Wang Subject: Re: [ClusterLabs] SuSE12SP3 HAE SBD Communication Issue First thanks for your reply, Klaus! On 2018/12/21 10:09, Klaus Wenninger wrote: > On 12/21/2018 08:15 AM, Fulong Wang wrote: >> Hello Experts, >> >> I'm New to this mail lists. >> Pls kindlyforgive me if this mail has disturb you! >> >> Our Company recently is evaluating the usage of the SuSE HAE on x86 >> platform. >> Wen simulating the storage disaster fail-over, i finally found that >> the SBD communication functioned normal on SuSE11 SP4 but abnormal on >> SuSE12 SP3. > > I have no experience with SBD on SLES but I know that handling of the > logging verbosity-levels has changed recently in the upstream-repo. > Given that it was done by Yan Gao iirc I'd assume it went into SLES. > So changing the verbosity of the sbd-daemon might get you back > these logs. Yes, I think it's the issue. Could you please retrieve the latest maintenance update for SLE12SP3 and try? Otherwise of course you could temporarily enable verbose/debug logging by adding a couple of "-v" into "SBD_OPTS" in /etc/sysconfig/sbd. But frankly, it makes more sense to manually trigger fencing for example by "crm node fence" and see if it indeed works correctly. > And of course you can use the list command on the other node > to verify as well. The "test" message in the slot might get overwritten soon by a "clear" if the sbd daemon is running. Regards, Yan > > Klaus > >> The SBD device was added during the initialization of the first >> cluster node. >> >> I have requested help from SuSE guys, but they didn't give me any >> valuable feedback yet now! >> >> >> Below are some screenshots to explain what i have encountered. >> ~~~ >> >> on a SuSE11 SP4 HAE cluster, i run the sbd test command as below: >> >> >> then there will be some information showed up in the local system >> message log >> >> >> >> on the second node, we can found that the communication is normal by >> >> >> >> but when i turn to a SuSE12 SP3 HAE cluster, ran the same command as >> above: >> >> >> >> I didn't get any response in the system message log. >> >> >> "systemctl status sbd" also doesn't give me any clue on this. >> >> >> >> ~~ >> >> What could be the reason for this abnormal behavior? Is there any >> problems with my setup? >> Any suggestions are appreciate! >> >> Thanks! >> >> >> Regards >> FuLong >> >> >> ___ >> Users mailing list:Users@clusterlabs.org >> https://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 > https://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 https://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
