Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Mon, May 9, 2011 at 8:44 PM, Holger Teutsch holger.teut...@web.de wrote: On Wed, 2011-04-27 at 13:25 +0200, Andrew Beekhof wrote: On Sun, Apr 24, 2011 at 4:31 PM, Holger Teutsch holger.teut...@web.de wrote: ... Remaining diffs seem to be not related to my changes. Unlikely I'm afraid. We run the regression tests after every commit and complain loudly if they fail. What is the regression test output? That's the output of tools/regression.sh of pacemaker-devel *without* my patches: Version: parent: 10731:bf7b957f4cbe tip see attachment There seems to be something not quite right with your environment. Had you built the tools directory before running the test? In a clean chroot it passes onboth opensuse and fedora: http://build.clusterlabs.org:8010/builders/opensuse-11.3-i386-devel/builds/48/steps/cli_test/logs/stdio and http://build.clusterlabs.org:8010/builders/fedora-13-x86_64-devel/builds/48/steps/cli_test/logs/stdio What distro are you on? Could you try running it as: /full/path/to/pacemaker/sources/tools/regression.sh The PATH magic that allows the tests to be run from the source directory may not be fully functional. -holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Tue, 2011-05-10 at 08:24 +0200, Andrew Beekhof wrote: On Mon, May 9, 2011 at 8:44 PM, Holger Teutsch holger.teut...@web.de wrote: On Wed, 2011-04-27 at 13:25 +0200, Andrew Beekhof wrote: On Sun, Apr 24, 2011 at 4:31 PM, Holger Teutsch holger.teut...@web.de wrote: ... Remaining diffs seem to be not related to my changes. Unlikely I'm afraid. We run the regression tests after every commit and complain loudly if they fail. What is the regression test output? That's the output of tools/regression.sh of pacemaker-devel *without* my patches: Version: parent: 10731:bf7b957f4cbe tip see attachment There seems to be something not quite right with your environment. Had you built the tools directory before running the test? Yes, + install In a clean chroot it passes onboth opensuse and fedora: http://build.clusterlabs.org:8010/builders/opensuse-11.3-i386-devel/builds/48/steps/cli_test/logs/stdio and http://build.clusterlabs.org:8010/builders/fedora-13-x86_64-devel/builds/48/steps/cli_test/logs/stdio What distro are you on? Opensuse 11.4 Could you try running it as: /full/path/to/pacemaker/sources/tools/regression.sh The PATH magic that allows the tests to be run from the source directory may not be fully functional. Did not help, will do further investigation. -holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On 5/10/2011 at 08:22 PM, Holger Teutsch holger.teut...@web.de wrote: On Tue, 2011-05-10 at 08:24 +0200, Andrew Beekhof wrote: On Mon, May 9, 2011 at 8:44 PM, Holger Teutsch holger.teut...@web.de wrote: On Wed, 2011-04-27 at 13:25 +0200, Andrew Beekhof wrote: On Sun, Apr 24, 2011 at 4:31 PM, Holger Teutsch holger.teut...@web.de wrote: ... Remaining diffs seem to be not related to my changes. Unlikely I'm afraid. We run the regression tests after every commit and complain loudly if they fail. What is the regression test output? That's the output of tools/regression.sh of pacemaker-devel *without* my patches: Version: parent: 10731:bf7b957f4cbe tip see attachment There seems to be something not quite right with your environment. Had you built the tools directory before running the test? Yes, + install In a clean chroot it passes onboth opensuse and fedora: http://build.clusterlabs.org:8010/builders/opensuse-11.3-i386-devel/builds/ 48/steps/cli_test/logs/stdio and http://build.clusterlabs.org:8010/builders/fedora-13-x86_64-devel/builds/48 /steps/cli_test/logs/stdio What distro are you on? Opensuse 11.4 Works for me on openSUSE 11.4 with a clean checkout of devel tip, so presumably isn't endemic (not that this really helps you, sorry, but I had to test). Regards, Tim -- Tim Serong tser...@novell.com Senior Clustering Engineer, OPS Engineering, Novell Inc. ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Fri, 2011-05-06 at 16:15 +0200, Andrew Beekhof wrote:
On Fri, May 6, 2011 at 12:28 PM, Holger Teutsch holger.teut...@web.de wrote:
On Fri, 2011-05-06 at 11:03 +0200, Andrew Beekhof wrote:
On Fri, May 6, 2011 at 9:53 AM, Andrew Beekhof and...@beekhof.net wrote:
On Thu, May 5, 2011 at 5:43 PM, Holger Teutsch holger.teut...@web.de
wrote:
On Fri, 2011-04-29 at 09:41 +0200, Andrew Beekhof wrote:
Unfortunately the devel code does not run at all in my environment
so I
have to fix this first.
Oh? I ran CTS on it the other day and it was fine here.
I installed pacemaker-devel on top of a compilation of pacemaker-1.1. In
addition I tried make uninstall for both versions and then again
make install for devel. Pacemaker does not come up, crm_mon shows
nodes as offline.
I suspect reason is
May 5 17:09:34 devel1 crmd: [5942]: notice: crmd_peer_update: Status
update: Client devel1/crmd now has status [online] (DC=null)
May 5 17:09:34 devel1 crmd: [5942]: info: crm_update_peer: Node
devel1: id=1790093504 state=unknown addr=(null) votes=0 born=0 seen=0
proc=00111312 (new)
May 5 17:09:34 devel1 crmd: [5942]: info: pcmk_quorum_notification:
Membership 0: quorum retained (0)
May 5 17:09:34 devel1 crmd: [5942]: debug: do_fsa_action:
actions:trace: #011// A_STARTED
May 5 17:09:34 devel1 crmd: [5942]: info: do_started: Delaying start,
no membership data (0010)
^
May 5 17:09:34 devel1 crmd: [5942]: debug: register_fsa_input_adv:
Stalling the FSA pending further input: cause=C_FSA_INTERNAL
Any ideas ?
Hg version? Corosync config?
I'm running -devel here right now and things are fine.
Uh, I think I see now.
Try http://hg.clusterlabs.org/pacemaker/1.1/rev/b94ce5673ce4
Yeah, I realized afterwards that it was specific to devel.
What does your corosync config look like?
I run corosync-1.3.0-3.1.x86_64.
It's exactly the same config that worked with
pacemaker 1.1 rev 10608:b4f456380f60
# Please read the corosync.conf.5 manual page
compatibility: whitetank
aisexec {
# Run as root - this is necessary to be able to manage
# resources with Pacemaker
user: root
group: root
}
service {
# Load the Pacemaker Cluster Resource Manager
ver:1
name: pacemaker
use_mgmtd: yes
use_logd: yes
}
totem {
# The only valid version is 2
version:2
# How long before declaring a token lost (ms)
token: 5000
# How many token retransmits before forming a new configuration
token_retransmits_before_loss_const: 10
# How long to wait for join messages in the membership protocol (ms)
join: 60
# How long to wait for consensus to be achieved before starting
# a new round of membership configuration (ms)
consensus: 6000
# Turn off the virtual synchrony filter
vsftype:none
# Number of messages that may be sent by one processor on
# receipt of the token
max_messages: 20
# Limit generated nodeids to 31-bits (positive signed integers)
clear_node_high_bit: yes
# Disable encryption
secauth:off
# How many threads to use for encryption/decryption
threads:0
# Optionally assign a fixed node id (integer)
# nodeid: 1234
rrp_mode: active
interface {
ringnumber: 0
# The following values need to be set based on your environment
bindnetaddr:192.168.178.0
mcastaddr: 226.94.40.1
mcastport: 5409
}
interface {
ringnumber: 1
# The following values need to be set based on your environment
bindnetaddr:10.1.1.0
mcastaddr: 226.94.41.1
mcastport: 5411
}
}
logging {
fileline: off
to_stderr: no
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: on
timestamp: off
}
amf {
mode: disabled
}
___
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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Mon, May 9, 2011 at 9:58 AM, Holger Teutsch holger.teut...@web.de wrote: On Fri, 2011-05-06 at 16:15 +0200, Andrew Beekhof wrote: On Fri, May 6, 2011 at 12:28 PM, Holger Teutsch holger.teut...@web.de wrote: On Fri, 2011-05-06 at 11:03 +0200, Andrew Beekhof wrote: On Fri, May 6, 2011 at 9:53 AM, Andrew Beekhof and...@beekhof.net wrote: On Thu, May 5, 2011 at 5:43 PM, Holger Teutsch holger.teut...@web.de wrote: On Fri, 2011-04-29 at 09:41 +0200, Andrew Beekhof wrote: Unfortunately the devel code does not run at all in my environment so I have to fix this first. Oh? I ran CTS on it the other day and it was fine here. I installed pacemaker-devel on top of a compilation of pacemaker-1.1. In addition I tried make uninstall for both versions and then again make install for devel. Pacemaker does not come up, crm_mon shows nodes as offline. I suspect reason is May 5 17:09:34 devel1 crmd: [5942]: notice: crmd_peer_update: Status update: Client devel1/crmd now has status [online] (DC=null) May 5 17:09:34 devel1 crmd: [5942]: info: crm_update_peer: Node devel1: id=1790093504 state=unknown addr=(null) votes=0 born=0 seen=0 proc=00111312 (new) May 5 17:09:34 devel1 crmd: [5942]: info: pcmk_quorum_notification: Membership 0: quorum retained (0) May 5 17:09:34 devel1 crmd: [5942]: debug: do_fsa_action: actions:trace: #011// A_STARTED May 5 17:09:34 devel1 crmd: [5942]: info: do_started: Delaying start, no membership data (0010) ^ May 5 17:09:34 devel1 crmd: [5942]: debug: register_fsa_input_adv: Stalling the FSA pending further input: cause=C_FSA_INTERNAL Any ideas ? Hg version? Corosync config? I'm running -devel here right now and things are fine. Uh, I think I see now. Try http://hg.clusterlabs.org/pacemaker/1.1/rev/b94ce5673ce4 Yeah, I realized afterwards that it was specific to devel. What does your corosync config look like? I run corosync-1.3.0-3.1.x86_64. It's exactly the same config that worked with pacemaker 1.1 rev 10608:b4f456380f60 If it works for that version, then it should work for any of the 7 commits since. None of them could produce: May 5 17:09:33 devel1 pacemakerd: [5929]: info: get_cluster_type: Cluster type is: 'corosync' Going back through the commit logs, it looks like the following is when things broke: http://hg.clusterlabs.org/pacemaker/1.1/rev/44e5f4e760f6 Specifically this need to be removed: +setenv(HA_cluster_type, corosync,1); Could you see if that change helps? ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
I thought you said you were running 1.1? May 5 17:09:33 devel1 pacemakerd: [5929]: info: read_config: Reading configure for stack: corosync This message is specific to the devel branch. Update to get the following fix and you should be fine: http://hg.clusterlabs.org/pacemaker/devel/rev/84ef5401322f ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
I had 1.1 but Dejan asked my to rebase my patches on devel. So long story short: devel now works after upgrading to the rev you mentioned and I got back to working on my patches. Thanx Holger On Mon, 2011-05-09 at 10:58 +0200, Andrew Beekhof wrote: I thought you said you were running 1.1? May 5 17:09:33 devel1 pacemakerd: [5929]: info: read_config: Reading configure for stack: corosync This message is specific to the devel branch. Update to get the following fix and you should be fine: http://hg.clusterlabs.org/pacemaker/devel/rev/84ef5401322f ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Wed, 2011-04-27 at 13:25 +0200, Andrew Beekhof wrote: On Sun, Apr 24, 2011 at 4:31 PM, Holger Teutsch holger.teut...@web.de wrote: ... Remaining diffs seem to be not related to my changes. Unlikely I'm afraid. We run the regression tests after every commit and complain loudly if they fail. What is the regression test output? That's the output of tools/regression.sh of pacemaker-devel *without* my patches: Version: parent: 10731:bf7b957f4cbe tip see attachment -holger Using local binaries from: . * Passed: cibadmin - Require --force for CIB erasure * Passed: cibadmin - Allow CIB erasure with --force * Passed: cibadmin - Query CIB * Passed: crm_attribute - Set cluster option * Passed: cibadmin - Query new cluster option * Passed: cibadmin - Query cluster options * Passed: cibadmin - Delete nvpair * Passed: cibadmin - Create operaton should fail with: -21, The object already exists * Passed: cibadmin - Modify cluster options section * Passed: cibadmin - Query updated cluster option * Passed: crm_attribute - Set duplicate cluster option * Passed: crm_attribute - Setting multiply defined cluster option should fail with -216, Could not set cluster option * Passed: crm_attribute - Set cluster option with -s * Passed: crm_attribute - Delete cluster option with -i * Passed: cibadmin - Create node entry * Passed: cibadmin - Create node status entry * Passed: crm_attribute - Create node attribute * Passed: cibadmin - Query new node attribute * Passed: cibadmin - Digest calculation * Passed: cibadmin - Replace operation should fail with: -45, Update was older than existing configuration * Passed: crm_standby- Default standby value * Passed: crm_standby- Set standby status * Passed: crm_standby- Query standby value * Passed: crm_standby- Delete standby value * Passed: cibadmin - Create a resource * Passed: crm_resource - Create a resource meta attribute * Passed: crm_resource - Query a resource meta attribute * Passed: crm_resource - Remove a resource meta attribute * Passed: crm_resource - Create a resource attribute * Passed: crm_resource - List the configured resources * Passed: crm_resource - Set a resource's fail-count * Passed: crm_resource - Require a destination when migrating a resource that is stopped * Passed: crm_resource - Don't support migration to non-existant locations * Passed: crm_resource - Migrate a resource * Passed: crm_resource - Un-migrate a resource --- ./regression.exp2011-05-09 20:26:27.669381187 +0200 +++ ./regression.out2011-05-09 20:38:27.112098949 +0200 @@ -616,7 +616,7 @@ /status /cib * Passed: crm_resource - List the configured resources -cib epoch=16 num_updates=2 admin_epoch=0 validate-with=pacemaker-1.2 +cib epoch=16 num_updates=1 admin_epoch=0 validate-with=pacemaker-1.2 configuration crm_config cluster_property_set id=cib-bootstrap-options/ @@ -642,19 +642,13 @@ constraints/ /configuration status -node_state id=clusterNode-UUID uname=clusterNode-UNAME - transient_attributes id=clusterNode-UUID -instance_attributes id=status-clusterNode-UUID - nvpair id=status-clusterNode-UUID-fail-count-dummy name=fail-count-dummy value=10/ -/instance_attributes - /transient_attributes -/node_state +node_state id=clusterNode-UUID uname=clusterNode-UNAME/ /status /cib * Passed: crm_resource - Set a resource's fail-count Resource dummy not moved: not-active and no preferred location specified. Error performing operation: cib object missing -cib epoch=16 num_updates=2 admin_epoch=0 validate-with=pacemaker-1.2 +cib epoch=16 num_updates=1 admin_epoch=0 validate-with=pacemaker-1.2 configuration crm_config cluster_property_set id=cib-bootstrap-options/ @@ -680,19 +674,13 @@ constraints/ /configuration status -node_state id=clusterNode-UUID uname=clusterNode-UNAME - transient_attributes id=clusterNode-UUID -instance_attributes id=status-clusterNode-UUID - nvpair id=status-clusterNode-UUID-fail-count-dummy name=fail-count-dummy value=10/ -/instance_attributes - /transient_attributes -/node_state +node_state id=clusterNode-UUID uname=clusterNode-UNAME/ /status /cib * Passed: crm_resource - Require a destination when migrating a resource that is stopped Error performing operation: i.dont.exist is not a known node Error performing operation: The object/attribute does not exist -cib epoch=16 num_updates=2 admin_epoch=0 validate-with=pacemaker-1.2 +cib epoch=16 num_updates=1 admin_epoch=0 validate-with=pacemaker-1.2 configuration crm_config cluster_property_set id=cib-bootstrap-options/ @@ -718,13 +706,7 @@ constraints/ /configuration status -node_state id=clusterNode-UUID uname=clusterNode-UNAME - transient_attributes id=clusterNode-UUID -
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Thu, May 5, 2011 at 5:43 PM, Holger Teutsch holger.teut...@web.de wrote: On Fri, 2011-04-29 at 09:41 +0200, Andrew Beekhof wrote: Unfortunately the devel code does not run at all in my environment so I have to fix this first. Oh? I ran CTS on it the other day and it was fine here. I installed pacemaker-devel on top of a compilation of pacemaker-1.1. In addition I tried make uninstall for both versions and then again make install for devel. Pacemaker does not come up, crm_mon shows nodes as offline. I suspect reason is May 5 17:09:34 devel1 crmd: [5942]: notice: crmd_peer_update: Status update: Client devel1/crmd now has status [online] (DC=null) May 5 17:09:34 devel1 crmd: [5942]: info: crm_update_peer: Node devel1: id=1790093504 state=unknown addr=(null) votes=0 born=0 seen=0 proc=00111312 (new) May 5 17:09:34 devel1 crmd: [5942]: info: pcmk_quorum_notification: Membership 0: quorum retained (0) May 5 17:09:34 devel1 crmd: [5942]: debug: do_fsa_action: actions:trace: #011// A_STARTED May 5 17:09:34 devel1 crmd: [5942]: info: do_started: Delaying start, no membership data (0010) ^ May 5 17:09:34 devel1 crmd: [5942]: debug: register_fsa_input_adv: Stalling the FSA pending further input: cause=C_FSA_INTERNAL Any ideas ? Hg version? Corosync config? I'm running -devel here right now and things are fine. -holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Fri, May 6, 2011 at 9:53 AM, Andrew Beekhof and...@beekhof.net wrote: On Thu, May 5, 2011 at 5:43 PM, Holger Teutsch holger.teut...@web.de wrote: On Fri, 2011-04-29 at 09:41 +0200, Andrew Beekhof wrote: Unfortunately the devel code does not run at all in my environment so I have to fix this first. Oh? I ran CTS on it the other day and it was fine here. I installed pacemaker-devel on top of a compilation of pacemaker-1.1. In addition I tried make uninstall for both versions and then again make install for devel. Pacemaker does not come up, crm_mon shows nodes as offline. I suspect reason is May 5 17:09:34 devel1 crmd: [5942]: notice: crmd_peer_update: Status update: Client devel1/crmd now has status [online] (DC=null) May 5 17:09:34 devel1 crmd: [5942]: info: crm_update_peer: Node devel1: id=1790093504 state=unknown addr=(null) votes=0 born=0 seen=0 proc=00111312 (new) May 5 17:09:34 devel1 crmd: [5942]: info: pcmk_quorum_notification: Membership 0: quorum retained (0) May 5 17:09:34 devel1 crmd: [5942]: debug: do_fsa_action: actions:trace: #011// A_STARTED May 5 17:09:34 devel1 crmd: [5942]: info: do_started: Delaying start, no membership data (0010) ^ May 5 17:09:34 devel1 crmd: [5942]: debug: register_fsa_input_adv: Stalling the FSA pending further input: cause=C_FSA_INTERNAL Any ideas ? Hg version? Corosync config? I'm running -devel here right now and things are fine. Uh, I think I see now. Try http://hg.clusterlabs.org/pacemaker/1.1/rev/b94ce5673ce4 ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Fri, 2011-05-06 at 11:03 +0200, Andrew Beekhof wrote: On Fri, May 6, 2011 at 9:53 AM, Andrew Beekhof and...@beekhof.net wrote: On Thu, May 5, 2011 at 5:43 PM, Holger Teutsch holger.teut...@web.de wrote: On Fri, 2011-04-29 at 09:41 +0200, Andrew Beekhof wrote: Unfortunately the devel code does not run at all in my environment so I have to fix this first. Oh? I ran CTS on it the other day and it was fine here. I installed pacemaker-devel on top of a compilation of pacemaker-1.1. In addition I tried make uninstall for both versions and then again make install for devel. Pacemaker does not come up, crm_mon shows nodes as offline. I suspect reason is May 5 17:09:34 devel1 crmd: [5942]: notice: crmd_peer_update: Status update: Client devel1/crmd now has status [online] (DC=null) May 5 17:09:34 devel1 crmd: [5942]: info: crm_update_peer: Node devel1: id=1790093504 state=unknown addr=(null) votes=0 born=0 seen=0 proc=00111312 (new) May 5 17:09:34 devel1 crmd: [5942]: info: pcmk_quorum_notification: Membership 0: quorum retained (0) May 5 17:09:34 devel1 crmd: [5942]: debug: do_fsa_action: actions:trace: #011// A_STARTED May 5 17:09:34 devel1 crmd: [5942]: info: do_started: Delaying start, no membership data (0010) ^ May 5 17:09:34 devel1 crmd: [5942]: debug: register_fsa_input_adv: Stalling the FSA pending further input: cause=C_FSA_INTERNAL Any ideas ? Hg version? Corosync config? I'm running -devel here right now and things are fine. Uh, I think I see now. Try http://hg.clusterlabs.org/pacemaker/1.1/rev/b94ce5673ce4 Page not found. ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Fri, May 6, 2011 at 12:28 PM, Holger Teutsch holger.teut...@web.de wrote: On Fri, 2011-05-06 at 11:03 +0200, Andrew Beekhof wrote: On Fri, May 6, 2011 at 9:53 AM, Andrew Beekhof and...@beekhof.net wrote: On Thu, May 5, 2011 at 5:43 PM, Holger Teutsch holger.teut...@web.de wrote: On Fri, 2011-04-29 at 09:41 +0200, Andrew Beekhof wrote: Unfortunately the devel code does not run at all in my environment so I have to fix this first. Oh? I ran CTS on it the other day and it was fine here. I installed pacemaker-devel on top of a compilation of pacemaker-1.1. In addition I tried make uninstall for both versions and then again make install for devel. Pacemaker does not come up, crm_mon shows nodes as offline. I suspect reason is May 5 17:09:34 devel1 crmd: [5942]: notice: crmd_peer_update: Status update: Client devel1/crmd now has status [online] (DC=null) May 5 17:09:34 devel1 crmd: [5942]: info: crm_update_peer: Node devel1: id=1790093504 state=unknown addr=(null) votes=0 born=0 seen=0 proc=00111312 (new) May 5 17:09:34 devel1 crmd: [5942]: info: pcmk_quorum_notification: Membership 0: quorum retained (0) May 5 17:09:34 devel1 crmd: [5942]: debug: do_fsa_action: actions:trace: #011// A_STARTED May 5 17:09:34 devel1 crmd: [5942]: info: do_started: Delaying start, no membership data (0010) ^ May 5 17:09:34 devel1 crmd: [5942]: debug: register_fsa_input_adv: Stalling the FSA pending further input: cause=C_FSA_INTERNAL Any ideas ? Hg version? Corosync config? I'm running -devel here right now and things are fine. Uh, I think I see now. Try http://hg.clusterlabs.org/pacemaker/1.1/rev/b94ce5673ce4 Yeah, I realized afterwards that it was specific to devel. What does your corosync config look like? ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Fri, 2011-04-29 at 09:41 +0200, Andrew Beekhof wrote: Unfortunately the devel code does not run at all in my environment so I have to fix this first. Oh? I ran CTS on it the other day and it was fine here. I installed pacemaker-devel on top of a compilation of pacemaker-1.1. In addition I tried make uninstall for both versions and then again make install for devel. Pacemaker does not come up, crm_mon shows nodes as offline. I suspect reason is May 5 17:09:34 devel1 crmd: [5942]: notice: crmd_peer_update: Status update: Client devel1/crmd now has status [online] (DC=null) May 5 17:09:34 devel1 crmd: [5942]: info: crm_update_peer: Node devel1: id=1790093504 state=unknown addr=(null) votes=0 born=0 seen=0 proc=00111312 (new) May 5 17:09:34 devel1 crmd: [5942]: info: pcmk_quorum_notification: Membership 0: quorum retained (0) May 5 17:09:34 devel1 crmd: [5942]: debug: do_fsa_action: actions:trace: #011// A_STARTED May 5 17:09:34 devel1 crmd: [5942]: info: do_started: Delaying start, no membership data (0010) ^ May 5 17:09:34 devel1 crmd: [5942]: debug: register_fsa_input_adv: Stalling the FSA pending further input: cause=C_FSA_INTERNAL Any ideas ? -holger May 5 17:09:33 devel1 pacemakerd: [5929]: info: Invoked: pacemakerd May 5 17:09:33 devel1 pacemakerd: [5929]: info: crm_log_init_worker: Changed active directory to /var/lib/heartbeat/cores/root May 5 17:09:33 devel1 pacemakerd: [5929]: info: get_cluster_type: Cluster type is: 'corosync' May 5 17:09:33 devel1 pacemakerd: [5929]: info: read_config: Reading configure for stack: corosync May 5 17:09:33 devel1 corosync[2101]: [CONFDB] lib_init_fn: conn=0x6872f0 May 5 17:09:33 devel1 pacemakerd: [5929]: info: config_find_next: Processing additional logging options... May 5 17:09:33 devel1 pacemakerd: [5929]: info: get_config_opt: Found 'on' for option: debug May 5 17:09:33 devel1 pacemakerd: [5929]: info: get_config_opt: Found 'no' for option: to_logfile May 5 17:09:33 devel1 pacemakerd: [5929]: info: get_config_opt: Found 'yes' for option: to_syslog May 5 17:09:33 devel1 pacemakerd: [5929]: info: get_config_opt: Found 'daemon' for option: syslog_facility May 5 17:09:33 devel1 corosync[2101]: [CONFDB] exit_fn for conn=0x6872f0 May 5 17:09:33 devel1 pacemakerd: [5931]: info: crm_log_init_worker: Changed active directory to /var/lib/heartbeat/cores/root May 5 17:09:33 devel1 pacemakerd: [5931]: info: main: Starting Pacemaker 1.1.5 (Build: unknown): ncurses corosync-quorum corosync May 5 17:09:33 devel1 pacemakerd: [5931]: info: main: Maximum core file size is: 18446744073709551615 May 5 17:09:33 devel1 pacemakerd: [5931]: debug: cluster_connect_cfg: Our nodeid: 1790093504 May 5 17:09:33 devel1 pacemakerd: [5931]: debug: cluster_connect_cfg: Adding fd=5 to mainloop May 5 17:09:33 devel1 corosync[2101]: [CPG ] lib_init_fn: conn=0x68bfc0, cpd=0x6903f0 May 5 17:09:33 devel1 pacemakerd: [5931]: debug: cluster_connect_cpg: Our nodeid: 1790093504 May 5 17:09:33 devel1 pacemakerd: [5931]: debug: cluster_connect_cpg: Adding fd=6 to mainloop May 5 17:09:33 devel1 pacemakerd: [5931]: info: update_node_processes: 0x60d920 Node 1790093504 now known as devel1 (was: (null)) May 5 17:09:33 devel1 pacemakerd: [5931]: info: update_node_processes: Node devel1 now has process list: 0002 (was ) May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] mcasted message added to pending queue May 5 17:09:33 devel1 corosync[2101]: [CPG ] got mcast request on 0x68bfc0 May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] Delivering 24 to 25 May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] Delivering MCAST message with seq 25 to pending delivery queue May 5 17:09:33 devel1 corosync[2101]: [CPG ] got procjoin message from cluster node 1790093504 May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] Received ringid(192.168.178.106:332) seq 25 May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] Received ringid(192.168.178.106:332) seq 25 May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] mcasted message added to pending queue May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] Delivering 25 to 26 May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] Delivering MCAST message with seq 26 to pending delivery queue May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] Received ringid(192.168.178.106:332) seq 26 May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] Received ringid(192.168.178.106:332) seq 26 May 5 17:09:33 devel1 corosync[2101]: [TOTEM ] releasing messages up to and including 25 May 5 17:09:33 devel1 pacemakerd: [5931]: info: start_child: Forked child 5935 for process stonith-ng May 5 17:09:33 devel1 pacemakerd: [5931]: info: update_node_processes: Node devel1 now has process list: 0012 (was
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Thu, Apr 28, 2011 at 9:53 AM, Holger Teutsch holger.teut...@web.de wrote: Hi Dejan, On Tue, 2011-04-26 at 17:58 +0200, Dejan Muhamedagic wrote: Hi Holger, On Sun, Apr 24, 2011 at 04:31:33PM +0200, Holger Teutsch wrote: On Mon, 2011-04-11 at 20:50 +0200, Andrew Beekhof wrote: why? CMD_ERR(Resource %s not moved: specifying --master is not supported for --move-from\n, rsc_id); it did not look sensible to me but I can't recall the exact reasons 8-) It's now implemented. also the legacy handling is a little off - do a make install and run tools/regression.sh and you'll see what i mean. Remaining diffs seem to be not related to my changes. other than that the crm_resource part looks pretty good. can you add some regression testcases in tools/ too please? Will add them once the code is in the repo. Latest diffs are attached. The diffs seem to be against the 1.1 code, but this should go into the devel repository. Can you please rebase the patches against the devel code. Unfortunately the devel code does not run at all in my environment so I have to fix this first. Oh? I ran CTS on it the other day and it was fine here. ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi Dejan, On Tue, 2011-04-26 at 17:58 +0200, Dejan Muhamedagic wrote: Hi Holger, On Sun, Apr 24, 2011 at 04:31:33PM +0200, Holger Teutsch wrote: On Mon, 2011-04-11 at 20:50 +0200, Andrew Beekhof wrote: why? CMD_ERR(Resource %s not moved: specifying --master is not supported for --move-from\n, rsc_id); it did not look sensible to me but I can't recall the exact reasons 8-) It's now implemented. also the legacy handling is a little off - do a make install and run tools/regression.sh and you'll see what i mean. Remaining diffs seem to be not related to my changes. other than that the crm_resource part looks pretty good. can you add some regression testcases in tools/ too please? Will add them once the code is in the repo. Latest diffs are attached. The diffs seem to be against the 1.1 code, but this should go into the devel repository. Can you please rebase the patches against the devel code. Unfortunately the devel code does not run at all in my environment so I have to fix this first. - holger Cheers, Dejan -holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Sun, Apr 24, 2011 at 4:31 PM, Holger Teutsch holger.teut...@web.de wrote: On Mon, 2011-04-11 at 20:50 +0200, Andrew Beekhof wrote: why? CMD_ERR(Resource %s not moved: specifying --master is not supported for --move-from\n, rsc_id); it did not look sensible to me but I can't recall the exact reasons 8-) It's now implemented. also the legacy handling is a little off - do a make install and run tools/regression.sh and you'll see what i mean. Remaining diffs seem to be not related to my changes. Unlikely I'm afraid. We run the regression tests after every commit and complain loudly if they fail. What is the regression test output? other than that the crm_resource part looks pretty good. can you add some regression testcases in tools/ too please? Will add them once the code is in the repo. Latest diffs are attached. -holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi Holger,
On Sun, Apr 24, 2011 at 04:31:33PM +0200, Holger Teutsch wrote:
On Mon, 2011-04-11 at 20:50 +0200, Andrew Beekhof wrote:
why?
CMD_ERR(Resource %s not moved:
specifying --master is not supported for
--move-from\n, rsc_id);
it did not look sensible to me but I can't recall the exact reasons 8-)
It's now implemented.
also the legacy handling is a little off - do a make install and run
tools/regression.sh and you'll see what i mean.
Remaining diffs seem to be not related to my changes.
other than that the crm_resource part looks pretty good.
can you add some regression testcases in tools/ too please?
Will add them once the code is in the repo.
Latest diffs are attached.
The diffs seem to be against the 1.1 code, but this should go
into the devel repository. Can you please rebase the patches
against the devel code.
Cheers,
Dejan
-holger
diff -r b4f456380f60 shell/modules/ui.py.in
--- a/shell/modules/ui.py.in Thu Mar 17 09:41:25 2011 +0100
+++ b/shell/modules/ui.py.in Sun Apr 24 16:18:59 2011 +0200
@@ -738,8 +738,9 @@
rsc_status = crm_resource -W -r '%s'
rsc_showxml = crm_resource -q -r '%s'
rsc_setrole = crm_resource --meta -r '%s' -p target-role -v '%s'
-rsc_migrate = crm_resource -M -r '%s' %s
-rsc_unmigrate = crm_resource -U -r '%s'
+rsc_move_to = crm_resource --move-to -r '%s' %s
+rsc_move_from = crm_resource --move-from -r '%s' %s
+rsc_move_cleanup = crm_resource --move-cleanup -r '%s'
rsc_cleanup = crm_resource -C -r '%s' -H '%s'
rsc_cleanup_all = crm_resource -C -r '%s'
rsc_param = {
@@ -776,8 +777,12 @@
self.cmd_table[demote] = (self.demote,(1,1),0)
self.cmd_table[manage] = (self.manage,(1,1),0)
self.cmd_table[unmanage] = (self.unmanage,(1,1),0)
+# the next two commands are deprecated
self.cmd_table[migrate] = (self.migrate,(1,4),0)
self.cmd_table[unmigrate] = (self.unmigrate,(1,1),0)
+self.cmd_table[move-to] = (self.move_to,(2,4),0)
+self.cmd_table[move-from] = (self.move_from,(1,4),0)
+self.cmd_table[move-cleanup] = (self.move_cleanup,(1,1),0)
self.cmd_table[param] = (self.param,(3,4),1)
self.cmd_table[meta] = (self.meta,(3,4),1)
self.cmd_table[utilization] = (self.utilization,(3,4),1)
@@ -846,9 +851,67 @@
if not is_name_sane(rsc):
return False
return set_deep_meta_attr(is-managed,false,rsc)
+def move_to(self,cmd,*args):
+usage: move-to rsc[:master] node [lifetime] [force]
+elem = args[0].split(':')
+rsc = elem[0]
+master = False
+if len(elem) 1:
+master = elem[1]
+if master != master:
+common_error(%s is invalid, specify 'master' % master)
+return False
+master = True
+if not is_name_sane(rsc):
+return False
+node = args[1]
+lifetime = None
+force = False
+if len(args) == 3:
+if args[2] == force:
+force = True
+else:
+lifetime = args[2]
+elif len(args) == 4:
+if args[2] == force:
+force = True
+lifetime = args[3]
+elif args[3] == force:
+force = True
+lifetime = args[2]
+else:
+syntax_err((cmd,force))
+return False
+
+opts = ''
+if node:
+opts = --node='%s' % node
+if lifetime:
+opts = %s --lifetime='%s' % (opts,lifetime)
+if force or user_prefs.get_force():
+opts = %s --force % opts
+if master:
+opts = %s --master % opts
+return ext_cmd(self.rsc_move_to % (rsc,opts)) == 0
+
def migrate(self,cmd,*args):
-usage: migrate rsc [node] [lifetime] [force]
-rsc = args[0]
+Deprecated: migrate rsc [node] [lifetime] [force]
+common_warning(migrate is deprecated, use move-to or move-from)
+if len(args) = 2 and args[1] in listnodes():
+return self.move_to(cmd, *args)
+return self.move_from(cmd, *args)
+
+def move_from(self,cmd,*args):
+usage: move-from rsc[:master] [node] [lifetime] [force]
+elem = args[0].split(':')
+rsc = elem[0]
+master = False
+if len(elem) 1:
+master = elem[1]
+if master != master:
+common_error(%s is invalid, specify 'master' % master)
+return False
+master = True
if not is_name_sane(rsc):
return False
node = None
@@ -888,12 +951,18 @@
opts = %s --lifetime='%s' % (opts,lifetime)
if force or user_prefs.get_force():
opts = %s --force % opts
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Mon, 2011-04-11 at 20:50 +0200, Andrew Beekhof wrote:
why?
CMD_ERR(Resource %s not moved:
specifying --master is not supported for
--move-from\n, rsc_id);
it did not look sensible to me but I can't recall the exact reasons 8-)
It's now implemented.
also the legacy handling is a little off - do a make install and run
tools/regression.sh and you'll see what i mean.
Remaining diffs seem to be not related to my changes.
other than that the crm_resource part looks pretty good.
can you add some regression testcases in tools/ too please?
Will add them once the code is in the repo.
Latest diffs are attached.
-holger
diff -r b4f456380f60 shell/modules/ui.py.in
--- a/shell/modules/ui.py.in Thu Mar 17 09:41:25 2011 +0100
+++ b/shell/modules/ui.py.in Sun Apr 24 16:18:59 2011 +0200
@@ -738,8 +738,9 @@
rsc_status = crm_resource -W -r '%s'
rsc_showxml = crm_resource -q -r '%s'
rsc_setrole = crm_resource --meta -r '%s' -p target-role -v '%s'
-rsc_migrate = crm_resource -M -r '%s' %s
-rsc_unmigrate = crm_resource -U -r '%s'
+rsc_move_to = crm_resource --move-to -r '%s' %s
+rsc_move_from = crm_resource --move-from -r '%s' %s
+rsc_move_cleanup = crm_resource --move-cleanup -r '%s'
rsc_cleanup = crm_resource -C -r '%s' -H '%s'
rsc_cleanup_all = crm_resource -C -r '%s'
rsc_param = {
@@ -776,8 +777,12 @@
self.cmd_table[demote] = (self.demote,(1,1),0)
self.cmd_table[manage] = (self.manage,(1,1),0)
self.cmd_table[unmanage] = (self.unmanage,(1,1),0)
+# the next two commands are deprecated
self.cmd_table[migrate] = (self.migrate,(1,4),0)
self.cmd_table[unmigrate] = (self.unmigrate,(1,1),0)
+self.cmd_table[move-to] = (self.move_to,(2,4),0)
+self.cmd_table[move-from] = (self.move_from,(1,4),0)
+self.cmd_table[move-cleanup] = (self.move_cleanup,(1,1),0)
self.cmd_table[param] = (self.param,(3,4),1)
self.cmd_table[meta] = (self.meta,(3,4),1)
self.cmd_table[utilization] = (self.utilization,(3,4),1)
@@ -846,9 +851,67 @@
if not is_name_sane(rsc):
return False
return set_deep_meta_attr(is-managed,false,rsc)
+def move_to(self,cmd,*args):
+usage: move-to rsc[:master] node [lifetime] [force]
+elem = args[0].split(':')
+rsc = elem[0]
+master = False
+if len(elem) 1:
+master = elem[1]
+if master != master:
+common_error(%s is invalid, specify 'master' % master)
+return False
+master = True
+if not is_name_sane(rsc):
+return False
+node = args[1]
+lifetime = None
+force = False
+if len(args) == 3:
+if args[2] == force:
+force = True
+else:
+lifetime = args[2]
+elif len(args) == 4:
+if args[2] == force:
+force = True
+lifetime = args[3]
+elif args[3] == force:
+force = True
+lifetime = args[2]
+else:
+syntax_err((cmd,force))
+return False
+
+opts = ''
+if node:
+opts = --node='%s' % node
+if lifetime:
+opts = %s --lifetime='%s' % (opts,lifetime)
+if force or user_prefs.get_force():
+opts = %s --force % opts
+if master:
+opts = %s --master % opts
+return ext_cmd(self.rsc_move_to % (rsc,opts)) == 0
+
def migrate(self,cmd,*args):
-usage: migrate rsc [node] [lifetime] [force]
-rsc = args[0]
+Deprecated: migrate rsc [node] [lifetime] [force]
+common_warning(migrate is deprecated, use move-to or move-from)
+if len(args) = 2 and args[1] in listnodes():
+return self.move_to(cmd, *args)
+return self.move_from(cmd, *args)
+
+def move_from(self,cmd,*args):
+usage: move-from rsc[:master] [node] [lifetime] [force]
+elem = args[0].split(':')
+rsc = elem[0]
+master = False
+if len(elem) 1:
+master = elem[1]
+if master != master:
+common_error(%s is invalid, specify 'master' % master)
+return False
+master = True
if not is_name_sane(rsc):
return False
node = None
@@ -888,12 +951,18 @@
opts = %s --lifetime='%s' % (opts,lifetime)
if force or user_prefs.get_force():
opts = %s --force % opts
-return ext_cmd(self.rsc_migrate % (rsc,opts)) == 0
-def unmigrate(self,cmd,rsc):
-usage: unmigrate rsc
+if master:
+opts = %s --master % opts
+return ext_cmd(self.rsc_move_from % (rsc,opts)) == 0
+def move_cleanup(self,cmd,rsc):
+usage: move_cleanup rsc
if not is_name_sane(rsc):
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi Holger,
On Fri, Apr 08, 2011 at 03:21:31PM +0200, Holger Teutsch wrote:
On Thu, 2011-04-07 at 12:33 +0200, Dejan Muhamedagic wrote:
New syntax:
---
crm_resource --move-from --resource myresource --node mynode
- all resource variants: check whether active on mynode, then create
standby constraint
crm_resource --move-from --resource myresource
- primitive/group: set --node `current_node`, then create standby
constraint
- clone/master: refused
crm_resource --move-to --resource myresource --node mynode
- all resource variants: create prefer constraint
crm_resource --move-to --resource myresource --master --node mynode
- master: check whether active as slave on mynode, then create prefer
constraint for master role
- others: refused
crm_resource --move-cleanup --resource myresource
- zap constraints
As we are already short on meaningful single letter options I vote for
long options only.
Backwards Compatibility:
crm_resource {-M|--move} --resource myresource
- output deprecation warning
- treat as crm_resource --move-from --resource myresource
crm_resource {-M|--move} --resource myresource --node mynode
- output deprecation warning
- treat as crm_resource --move-to --resource myresource --node mynode
crm_resource {-U|--unmove} --resource myresource
- output deprecation warning
- treat as crm_resource --move-cleanup --resource myresource
All looks fine to me.
For the shell:
Should we go for similar commands or keep migrate-XXX
migrate is a bit of a misnomer, could be confused with the
migrate operation. I'd vote to leave old migrate/unmigrate
as deprecated and introduce just move-from/to/cleanup variants.
Deajn Andrew,
please find attached the patches that implement these commands for
review. The require the patch
Low: lib/common/utils.c: Don't try to print unprintable option values in
crm_help
that I send separately because it is not directly related to the
movement stuff.
I think that the preceding discussions were very valuable to fully
understand issues and implications and I'm confident that the new
command set is consistent and behaves with predictable outcome.
The shell part seems to be OK, if it works :) In a few usage
messages there's '_' used instead of '-' in command names. Also,
in deprecation messages the part in the future can be dropped,
for instance:
+common_warning(Deprecation warning: Instead of unmigrate use
move-cleanup in the future)
common_warning(unmigrate is deprecated, use move-cleanup)
Cheers,
Dejan
___
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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
why?
CMD_ERR(Resource %s not moved:
specifying --master is not supported for
--move-from\n, rsc_id);
also the legacy handling is a little off - do a make install and run
tools/regression.sh and you'll see what i mean.
other than that the crm_resource part looks pretty good.
can you add some regression testcases in tools/ too please?
On Fri, Apr 8, 2011 at 3:21 PM, Holger Teutsch holger.teut...@web.de wrote:
On Thu, 2011-04-07 at 12:33 +0200, Dejan Muhamedagic wrote:
New syntax:
---
crm_resource --move-from --resource myresource --node mynode
- all resource variants: check whether active on mynode, then create
standby constraint
crm_resource --move-from --resource myresource
- primitive/group: set --node `current_node`, then create standby
constraint
- clone/master: refused
crm_resource --move-to --resource myresource --node mynode
- all resource variants: create prefer constraint
crm_resource --move-to --resource myresource --master --node mynode
- master: check whether active as slave on mynode, then create prefer
constraint for master role
- others: refused
crm_resource --move-cleanup --resource myresource
- zap constraints
As we are already short on meaningful single letter options I vote for
long options only.
Backwards Compatibility:
crm_resource {-M|--move} --resource myresource
- output deprecation warning
- treat as crm_resource --move-from --resource myresource
crm_resource {-M|--move} --resource myresource --node mynode
- output deprecation warning
- treat as crm_resource --move-to --resource myresource --node mynode
crm_resource {-U|--unmove} --resource myresource
- output deprecation warning
- treat as crm_resource --move-cleanup --resource myresource
All looks fine to me.
For the shell:
Should we go for similar commands or keep migrate-XXX
migrate is a bit of a misnomer, could be confused with the
migrate operation. I'd vote to leave old migrate/unmigrate
as deprecated and introduce just move-from/to/cleanup variants.
Deajn Andrew,
please find attached the patches that implement these commands for
review. The require the patch
Low: lib/common/utils.c: Don't try to print unprintable option values in
crm_help
that I send separately because it is not directly related to the
movement stuff.
I think that the preceding discussions were very valuable to fully
understand issues and implications and I'm confident that the new
command set is consistent and behaves with predictable outcome.
Regards
Holger
___
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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
___
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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Thu, 2011-04-07 at 12:33 +0200, Dejan Muhamedagic wrote:
New syntax:
---
crm_resource --move-from --resource myresource --node mynode
- all resource variants: check whether active on mynode, then create
standby constraint
crm_resource --move-from --resource myresource
- primitive/group: set --node `current_node`, then create standby
constraint
- clone/master: refused
crm_resource --move-to --resource myresource --node mynode
- all resource variants: create prefer constraint
crm_resource --move-to --resource myresource --master --node mynode
- master: check whether active as slave on mynode, then create prefer
constraint for master role
- others: refused
crm_resource --move-cleanup --resource myresource
- zap constraints
As we are already short on meaningful single letter options I vote for long
options only.
Backwards Compatibility:
crm_resource {-M|--move} --resource myresource
- output deprecation warning
- treat as crm_resource --move-from --resource myresource
crm_resource {-M|--move} --resource myresource --node mynode
- output deprecation warning
- treat as crm_resource --move-to --resource myresource --node mynode
crm_resource {-U|--unmove} --resource myresource
- output deprecation warning
- treat as crm_resource --move-cleanup --resource myresource
All looks fine to me.
For the shell:
Should we go for similar commands or keep migrate-XXX
migrate is a bit of a misnomer, could be confused with the
migrate operation. I'd vote to leave old migrate/unmigrate
as deprecated and introduce just move-from/to/cleanup variants.
Deajn Andrew,
please find attached the patches that implement these commands for
review. The require the patch
Low: lib/common/utils.c: Don't try to print unprintable option values in
crm_help
that I send separately because it is not directly related to the
movement stuff.
I think that the preceding discussions were very valuable to fully
understand issues and implications and I'm confident that the new
command set is consistent and behaves with predictable outcome.
Regards
Holger
diff -r b4f456380f60 doc/crm_cli.txt
--- a/doc/crm_cli.txt Thu Mar 17 09:41:25 2011 +0100
+++ b/doc/crm_cli.txt Fri Apr 08 14:23:59 2011 +0200
@@ -810,28 +810,44 @@
unmanage rsc
...
-[[cmdhelp_resource_migrate,migrate a resource to another node]]
- `migrate` (`move`)
-
-Migrate a resource to a different node. If node is left out, the
-resource is migrated by creating a constraint which prevents it from
-running on the current node. Additionally, you may specify a
+[[cmdhelp_resource_move-to,move a resource to another node]]
+ `move-to`
+
+Move a resource to a different node. The resource is moved by creating
+a constraint which forces it to run on the specified node.
+Additionally, you may specify a lifetime for the constraint---once it
+expires, the location constraint will no longer be active.
+For a master resource specify rsc:master to move the master role.
+
+Usage:
+...
+move-to rsc[:master] node [lifetime] [force]
+...
+
+[[cmdhelp_resource_move-from,move a resource away from the specified node]]
+ `move-from`
+
+Move a resource away from the specified node.
+If node is left out, the the node where the resource is currently active
+is used.
+The resource is moved by creating a constraint which prevents it from
+running on the specified node. Additionally, you may specify a
lifetime for the constraint---once it expires, the location
constraint will no longer be active.
Usage:
...
-migrate rsc [node] [lifetime] [force]
+move-from rsc [node] [lifetime] [force]
...
-[[cmdhelp_resource_unmigrate,unmigrate a resource to another node]]
- `unmigrate` (`unmove`)
-
-Remove the constraint generated by the previous migrate command.
+[[cmdhelp_resource_move-cleanup,Cleanup previously created move constraint]]
+ `move-cleanup`
+
+Remove the constraint generated by the previous move-to/move-from command.
Usage:
...
-unmigrate rsc
+move-cleanup rsc
...
[[cmdhelp_resource_param,manage a parameter of a resource]]
diff -r b4f456380f60 tools/crm_resource.c
--- a/tools/crm_resource.c Thu Mar 17 09:41:25 2011 +0100
+++ b/tools/crm_resource.c Fri Apr 08 15:02:39 2011 +0200
@@ -52,7 +52,8 @@
const char *prop_id = NULL;
const char *prop_set = NULL;
char *move_lifetime = NULL;
-char rsc_cmd = 'L';
+int move_master = 0;
+int rsc_cmd = 'L';
char *our_pid = NULL;
IPC_Channel *crmd_channel = NULL;
char *xml_file = NULL;
@@ -192,6 +193,33 @@
return 0;
}
+/* return role of resource on node */
+static int
+role_on_node(resource_t *rsc, const char *node_uname)
+{
+GListPtr lpc = NULL;
+
+if(rsc-variant pe_native) {
+/* recursively call down */
+
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Wed, Apr 6, 2011 at 3:38 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: On Wed, Apr 06, 2011 at 01:00:36PM +0200, Andrew Beekhof wrote: On Tue, Apr 5, 2011 at 12:27 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Ah, right, sorry, wanted to ask about the difference between move-off and move. The description looks the same as for move. Is it that in this case it is for clones so crm_resource needs an extra node parameter? You wrote in the doc: +Migrate a resource (-instance for clones/masters) off the specified node. The '-instance' looks somewhat funny. Why not say Move/migrate a clone or master/slave instance away from the specified node? I must say that I still find all this quite confusing, i.e. now we have move, unmove, and move-off, but it's probably just me :) Not just you. The problem is that we didn't fully understand all the use case permutations at the time. I think, not withstanding legacy computability, move should probably be renamed to move-to and this new option be called move-from. That seems more obvious and syntactically consistent with the rest of the system. Yes, move-to and move-from seem more consistent than other options. The problem is that the old move is at times one and then at times another. Thats ok, we can make the compat code work as expected. In the absence of a host name, each uses the current location for the named group/primitive resource and complains for clones. The biggest question in my mind is what to call unmove... move-cleanup perhaps? move-remove? :D Actually, though the word is a bit awkward, unmove sounds fine to me. I think the challenge with unmove is that it appears to imply that the resource will move back - when in fact it just arranges things so that it could. So move-remove and move-cleanup get the user thinking in the right direction. ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Wed, Apr 6, 2011 at 5:48 PM, Holger Teutsch holger.teut...@web.de wrote: On Wed, 2011-04-06 at 15:38 +0200, Dejan Muhamedagic wrote: On Wed, Apr 06, 2011 at 01:00:36PM +0200, Andrew Beekhof wrote: On Tue, Apr 5, 2011 at 12:27 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Ah, right, sorry, wanted to ask about the difference between move-off and move. The description looks the same as for move. Is it that in this case it is for clones so crm_resource needs an extra node parameter? You wrote in the doc: +Migrate a resource (-instance for clones/masters) off the specified node. The '-instance' looks somewhat funny. Why not say Move/migrate a clone or master/slave instance away from the specified node? I must say that I still find all this quite confusing, i.e. now we have move, unmove, and move-off, but it's probably just me :) Not just you. The problem is that we didn't fully understand all the use case permutations at the time. I think, not withstanding legacy computability, move should probably be renamed to move-to and this new option be called move-from. That seems more obvious and syntactically consistent with the rest of the system. Yes, move-to and move-from seem more consistent than other options. The problem is that the old move is at times one and then at times another. In the absence of a host name, each uses the current location for the named group/primitive resource and complains for clones. The biggest question in my mind is what to call unmove... move-cleanup perhaps? move-remove? :D Actually, though the word is a bit awkward, unmove sounds fine to me. I would vote for move-cleanup. It's consistent to move-XXX and to my (german) ears unmove seems to stand for the previous move being undone and the stuff comes back. BTW: Has someone already tried out the code or do you trust me 8-D ? I trust no-one - which is why we have regression tests :-) Stay tuned for updated patches... - holger Thanks, Dejan ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Thu, 2011-04-07 at 08:57 +0200, Andrew Beekhof wrote:
On Wed, Apr 6, 2011 at 5:48 PM, Holger Teutsch holger.teut...@web.de wrote:
On Wed, 2011-04-06 at 15:38 +0200, Dejan Muhamedagic wrote:
On Wed, Apr 06, 2011 at 01:00:36PM +0200, Andrew Beekhof wrote:
On Tue, Apr 5, 2011 at 12:27 PM, Dejan Muhamedagic deja...@fastmail.fm
wrote:
Ah, right, sorry, wanted to ask about the difference between
move-off and move. The description looks the same as for move. Is
it that in this case it is for clones so crm_resource needs an
extra node parameter? You wrote in the doc:
+Migrate a resource (-instance for clones/masters) off the
specified node.
The '-instance' looks somewhat funny. Why not say Move/migrate a
clone or master/slave instance away from the specified node?
I must say that I still find all this quite confusing, i.e. now
we have move, unmove, and move-off, but it's probably just me :)
Not just you. The problem is that we didn't fully understand all the
use case permutations at the time.
I think, not withstanding legacy computability, move should probably
be renamed to move-to and this new option be called move-from.
That seems more obvious and syntactically consistent with the rest of
the system.
Yes, move-to and move-from seem more consistent than other
options. The problem is that the old move is at times one and
then at times another.
In the absence of a host name, each uses the current location for the
named group/primitive resource and complains for clones.
The biggest question in my mind is what to call unmove...
move-cleanup perhaps?
move-remove? :D
Actually, though the word is a bit awkward, unmove sounds fine
to me.
I would vote for move-cleanup. It's consistent to move-XXX and to my
(german) ears unmove seems to stand for the previous move being
undone and the stuff comes back.
BTW: Has someone already tried out the code or do you trust me 8-D ?
I trust no-one - which is why we have regression tests :-)
Stay tuned for updated patches...
Now, after an additional discussion round I propose the following:
Please note that for consistency the --node argument is optional for
--move-from
New syntax:
---
crm_resource --move-from --resource myresource --node mynode
- all resource variants: check whether active on mynode, then create
standby constraint
crm_resource --move-from --resource myresource
- primitive/group: set --node `current_node`, then create standby constraint
- clone/master: refused
crm_resource --move-to --resource myresource --node mynode
- all resource variants: create prefer constraint
crm_resource --move-to --resource myresource --master --node mynode
- master: check whether active as slave on mynode, then create prefer
constraint for master role
- others: refused
crm_resource --move-cleanup --resource myresource
- zap constraints
As we are already short on meaningful single letter options I vote for long
options only.
Backwards Compatibility:
crm_resource {-M|--move} --resource myresource
- output deprecation warning
- treat as crm_resource --move-from --resource myresource
crm_resource {-M|--move} --resource myresource --node mynode
- output deprecation warning
- treat as crm_resource --move-to --resource myresource --node mynode
crm_resource {-U|--unmove} --resource myresource
- output deprecation warning
- treat as crm_resource --move-cleanup --resource myresource
For the shell:
Should we go for similar commands or keep migrate-XXX
Coming back to Dejan's proposal of move-remove:
That can be implemented of reexecuting the last move (a remove).
Reimplemeting unmove as undo of the last move you have shortcuts for your
favorite move operation
move
move-unmove - back
move-remove - and forth
Just kidding...
- holger
___
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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi Holger,
On Thu, Apr 07, 2011 at 10:03:49AM +0200, Holger Teutsch wrote:
On Thu, 2011-04-07 at 08:57 +0200, Andrew Beekhof wrote:
On Wed, Apr 6, 2011 at 5:48 PM, Holger Teutsch holger.teut...@web.de
wrote:
On Wed, 2011-04-06 at 15:38 +0200, Dejan Muhamedagic wrote:
On Wed, Apr 06, 2011 at 01:00:36PM +0200, Andrew Beekhof wrote:
On Tue, Apr 5, 2011 at 12:27 PM, Dejan Muhamedagic
deja...@fastmail.fm wrote:
Ah, right, sorry, wanted to ask about the difference between
move-off and move. The description looks the same as for move. Is
it that in this case it is for clones so crm_resource needs an
extra node parameter? You wrote in the doc:
+Migrate a resource (-instance for clones/masters) off the
specified node.
The '-instance' looks somewhat funny. Why not say Move/migrate a
clone or master/slave instance away from the specified node?
I must say that I still find all this quite confusing, i.e. now
we have move, unmove, and move-off, but it's probably just me
:)
Not just you. The problem is that we didn't fully understand all the
use case permutations at the time.
I think, not withstanding legacy computability, move should probably
be renamed to move-to and this new option be called move-from.
That seems more obvious and syntactically consistent with the rest of
the system.
Yes, move-to and move-from seem more consistent than other
options. The problem is that the old move is at times one and
then at times another.
In the absence of a host name, each uses the current location for the
named group/primitive resource and complains for clones.
The biggest question in my mind is what to call unmove...
move-cleanup perhaps?
move-remove? :D
Actually, though the word is a bit awkward, unmove sounds fine
to me.
I would vote for move-cleanup. It's consistent to move-XXX and to my
(german) ears unmove seems to stand for the previous move being
undone and the stuff comes back.
BTW: Has someone already tried out the code or do you trust me 8-D ?
I trust no-one - which is why we have regression tests :-)
Stay tuned for updated patches...
Now, after an additional discussion round I propose the following:
Please note that for consistency the --node argument is optional for
--move-from
New syntax:
---
crm_resource --move-from --resource myresource --node mynode
- all resource variants: check whether active on mynode, then create
standby constraint
crm_resource --move-from --resource myresource
- primitive/group: set --node `current_node`, then create standby
constraint
- clone/master: refused
crm_resource --move-to --resource myresource --node mynode
- all resource variants: create prefer constraint
crm_resource --move-to --resource myresource --master --node mynode
- master: check whether active as slave on mynode, then create prefer
constraint for master role
- others: refused
crm_resource --move-cleanup --resource myresource
- zap constraints
As we are already short on meaningful single letter options I vote for long
options only.
Backwards Compatibility:
crm_resource {-M|--move} --resource myresource
- output deprecation warning
- treat as crm_resource --move-from --resource myresource
crm_resource {-M|--move} --resource myresource --node mynode
- output deprecation warning
- treat as crm_resource --move-to --resource myresource --node mynode
crm_resource {-U|--unmove} --resource myresource
- output deprecation warning
- treat as crm_resource --move-cleanup --resource myresource
All looks fine to me.
For the shell:
Should we go for similar commands or keep migrate-XXX
migrate is a bit of a misnomer, could be confused with the
migrate operation. I'd vote to leave old migrate/unmigrate
as deprecated and introduce just move-from/to/cleanup variants.
Coming back to Dejan's proposal of move-remove:
That can be implemented of reexecuting the last move (a remove).
Reimplemeting unmove as undo of the last move you have shortcuts for your
favorite move operation
move
move-unmove - back
move-remove - and forth
Well, how about remove-move? ;-)
Cheers,
Dejan
Just kidding...
- holger
___
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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started:
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Tue, Apr 5, 2011 at 12:27 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Ah, right, sorry, wanted to ask about the difference between move-off and move. The description looks the same as for move. Is it that in this case it is for clones so crm_resource needs an extra node parameter? You wrote in the doc: +Migrate a resource (-instance for clones/masters) off the specified node. The '-instance' looks somewhat funny. Why not say Move/migrate a clone or master/slave instance away from the specified node? I must say that I still find all this quite confusing, i.e. now we have move, unmove, and move-off, but it's probably just me :) Not just you. The problem is that we didn't fully understand all the use case permutations at the time. I think, not withstanding legacy computability, move should probably be renamed to move-to and this new option be called move-from. That seems more obvious and syntactically consistent with the rest of the system. In the absence of a host name, each uses the current location for the named group/primitive resource and complains for clones. The biggest question in my mind is what to call unmove... move-cleanup perhaps? ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Wed, Apr 06, 2011 at 01:00:36PM +0200, Andrew Beekhof wrote: On Tue, Apr 5, 2011 at 12:27 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Ah, right, sorry, wanted to ask about the difference between move-off and move. The description looks the same as for move. Is it that in this case it is for clones so crm_resource needs an extra node parameter? You wrote in the doc: +Migrate a resource (-instance for clones/masters) off the specified node. The '-instance' looks somewhat funny. Why not say Move/migrate a clone or master/slave instance away from the specified node? I must say that I still find all this quite confusing, i.e. now we have move, unmove, and move-off, but it's probably just me :) Not just you. The problem is that we didn't fully understand all the use case permutations at the time. I think, not withstanding legacy computability, move should probably be renamed to move-to and this new option be called move-from. That seems more obvious and syntactically consistent with the rest of the system. Yes, move-to and move-from seem more consistent than other options. The problem is that the old move is at times one and then at times another. In the absence of a host name, each uses the current location for the named group/primitive resource and complains for clones. The biggest question in my mind is what to call unmove... move-cleanup perhaps? move-remove? :D Actually, though the word is a bit awkward, unmove sounds fine to me. Thanks, Dejan ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Wed, 2011-04-06 at 15:38 +0200, Dejan Muhamedagic wrote: On Wed, Apr 06, 2011 at 01:00:36PM +0200, Andrew Beekhof wrote: On Tue, Apr 5, 2011 at 12:27 PM, Dejan Muhamedagic deja...@fastmail.fm wrote: Ah, right, sorry, wanted to ask about the difference between move-off and move. The description looks the same as for move. Is it that in this case it is for clones so crm_resource needs an extra node parameter? You wrote in the doc: +Migrate a resource (-instance for clones/masters) off the specified node. The '-instance' looks somewhat funny. Why not say Move/migrate a clone or master/slave instance away from the specified node? I must say that I still find all this quite confusing, i.e. now we have move, unmove, and move-off, but it's probably just me :) Not just you. The problem is that we didn't fully understand all the use case permutations at the time. I think, not withstanding legacy computability, move should probably be renamed to move-to and this new option be called move-from. That seems more obvious and syntactically consistent with the rest of the system. Yes, move-to and move-from seem more consistent than other options. The problem is that the old move is at times one and then at times another. In the absence of a host name, each uses the current location for the named group/primitive resource and complains for clones. The biggest question in my mind is what to call unmove... move-cleanup perhaps? move-remove? :D Actually, though the word is a bit awkward, unmove sounds fine to me. I would vote for move-cleanup. It's consistent to move-XXX and to my (german) ears unmove seems to stand for the previous move being undone and the stuff comes back. BTW: Has someone already tried out the code or do you trust me 8-D ? Stay tuned for updated patches... - holger Thanks, Dejan ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Mon, 2011-04-04 at 21:31 +0200, Holger Teutsch wrote: On Mon, 2011-04-04 at 15:24 +0200, Andrew Beekhof wrote: On Mon, Apr 4, 2011 at 2:43 PM, Holger Teutsch holger.teut...@web.de wrote: On Mon, 2011-04-04 at 11:05 +0200, Andrew Beekhof wrote: On Sat, Mar 19, 2011 at 11:55 AM, Holger Teutsch holger.teut...@web.de wrote: Hi Dejan, On Fri, 2011-03-18 at 14:24 +0100, Dejan Muhamedagic wrote: Hi, On Fri, Mar 18, 2011 at 12:21:40PM +0100, Holger Teutsch wrote: Hi, I would like to submit 2 patches of an initial implementation for discussion. .. To recall: crm_resource --move resource creates a standby rule that moves the resource off the currently active node while crm_resource --move resource --node newnode creates a prefer rule that moves the resource to the new node. When dealing with clones and masters the behavior was random as the code only considers the node where the first instance of the clone was started. The new code behaves consistently for the master role of an m/s resource. The options --master and rsc:master are somewhat redundant as a slave move is not supported. Currently it's more an acknowledgement of the user. On the other hand it is desirable (and was requested several times on the ML) to stop a single resource instance of a clone or master on a specific node. Should that be implemented by something like crm_resource --move-off --resource myresource --node devel2 ? or should crm_resource refuse to work on clones and/or should moving the master role be the default for m/s resources and the --master option discarded ? I think that we also need to consider the case when clone-max is less than the number of nodes. If I understood correctly what you were saying. So, all of move slave and move master and move clone should be possible. I think the following use cases cover what can be done with such kind of interface: crm_resource --moveoff --resource myresource --node mynode - all resource variants: check whether active on mynode, then create standby constraint crm_resource --move --resource myresource - primitive/group: convert to --moveoff --node `current_node` - clone/master: refused crm_resource --move --resource myresource --node mynode - primitive/group: create prefer constraint - clone/master: refused Not sure this needs to be refused. I see the problem that the node where the resource instance should be moved off had to be specified as well to get predictable behavior. Consider a a 2 way clone on a 3 node cluster. If the clone is active on A and B what should crm_resource --move --resource myClone --node C do ? I would expect it to create the +inf constraint for C but no contraint(s) for the current location(s) You are right. These are different and valid use cases. crm_resource --move --resource myClone --node C - I want an instance on C, regardless where it is moved off crm_resource --move-off --resource myClone --node C - I want the instance moved off C, regardless where it is moved on I tried them out with a reimplementation of the patch on a 3 node cluster with a resource with clone-max=2. The behavior appears logical (at least to me 8-) ). This would require an additional --from-node or similar. Other than that the proposal looks sane. My first thought was to make --move behave like --move-off if the resource is a clone or /ms, but since the semantics are the exact opposite, that might introduce introduce more problems than it solves. That was my perception as well. Does the original crm_resource patch implement this? No, I will submit an updated version later this week. - holger Hi, I submit revised patches for review. Summarizing preceding discussions the following functionality is implemented: crm_resource --move-off --resource myresource --node mynode - all resource variants: check whether active on mynode, then create standby constraint crm_resource --move --resource myresource - primitive/group: convert to --move-off --node `current_node` - clone/master: refused crm_resource --move --resource myresource --node mynode - all resource variants: create prefer constraint crm_resource --move --resource myresource --master --node mynode - master: check whether active as slave on mynode, then create prefer constraint for master role - others: refused The patch shell_migrate.diff supports this in the shell. This stuff is agnostic of what crm_migrate really does. Regards Holger diff -r b4f456380f60 doc/crm_cli.txt --- a/doc/crm_cli.txt Thu Mar 17 09:41:25 2011 +0100 +++ b/doc/crm_cli.txt Mon Apr 04
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi Holger, On Tue, Apr 05, 2011 at 01:19:56PM +0200, Holger Teutsch wrote: Hi Dejan, On Tue, 2011-04-05 at 12:27 +0200, Dejan Muhamedagic wrote: On Tue, Apr 05, 2011 at 12:10:48PM +0200, Holger Teutsch wrote: Hi Dejan, On Tue, 2011-04-05 at 11:48 +0200, Dejan Muhamedagic wrote: Hi Holger, On Mon, Apr 04, 2011 at 09:31:02PM +0200, Holger Teutsch wrote: On Mon, 2011-04-04 at 15:24 +0200, Andrew Beekhof wrote: [...] crm_resource --move-off --resource myClone --node C - I want the instance moved off C, regardless where it is moved on What is the difference between move-off and unmigrate (-U)? --move-off - create a constraint that a resource should *not* run on the specific node (partly as before --move without --node) -U: zap all migration constraints (as before) Ah, right, sorry, wanted to ask about the difference between move-off and move. The description looks the same as for move. Is it that in this case it is for clones so crm_resource needs an extra node parameter? You wrote in the doc: +Migrate a resource (-instance for clones/masters) off the specified node. The '-instance' looks somewhat funny. Why not say Move/migrate a clone or master/slave instance away from the specified node? Moving away works for all kinds of resources so the text now looks like: diff -r b4f456380f60 doc/crm_cli.txt --- a/doc/crm_cli.txt Thu Mar 17 09:41:25 2011 +0100 +++ b/doc/crm_cli.txt Tue Apr 05 13:08:10 2011 +0200 @@ -818,10 +818,25 @@ running on the current node. Additionally, you may specify a lifetime for the constraint---once it expires, the location constraint will no longer be active. +For a master resource specify rsc:master to move the master role. Usage: ... -migrate rsc [node] [lifetime] [force] +migrate rsc[:master] [node] [lifetime] [force] +... + +[[cmdhelp_resource_migrateoff,migrate a resource off the specified node]] + `migrateoff` (`moveoff`) + +Migrate a resource away from the specified node. +The resource is migrated by creating a constraint which prevents it from +running on the specified node. Additionally, you may specify a +lifetime for the constraint---once it expires, the location +constraint will no longer be active. + +Usage: +... +migrateoff rsc node [lifetime] [force] ... [[cmdhelp_resource_unmigrate,unmigrate a resource to another node]] I must say that I still find all this quite confusing, i.e. now we have move, unmove, and move-off, but it's probably just me :) Think of move == move-to then it is simpler 8-) ... keeping in mind that for backward compatibility crm_resource --move --resource myResource is equivalent crm_resource --move-off --resource myResource --node $(current node) But as there is no current node for clones / masters the old implementation did some random movements... OK. Thanks for the clarification. I'd like to revise my previous comment about restricting use of certain constructs. For instance, in this case, if the command would result in a random movement then the shell should at least issue a warning about it. Or perhaps refuse to do that completely. I didn't take a look yet at the code, perhaps you've already done that. Thanks, Dejan Regards Holger Cheers, Dejan ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi Dejan, On Tue, 2011-04-05 at 13:40 +0200, Dejan Muhamedagic wrote: Hi Holger, On Tue, Apr 05, 2011 at 01:19:56PM +0200, Holger Teutsch wrote: Hi Dejan, On Tue, 2011-04-05 at 12:27 +0200, Dejan Muhamedagic wrote: On Tue, Apr 05, 2011 at 12:10:48PM +0200, Holger Teutsch wrote: Hi Dejan, On Tue, 2011-04-05 at 11:48 +0200, Dejan Muhamedagic wrote: Hi Holger, On Mon, Apr 04, 2011 at 09:31:02PM +0200, Holger Teutsch wrote: On Mon, 2011-04-04 at 15:24 +0200, Andrew Beekhof wrote: [...] crm_resource --move-off --resource myClone --node C - I want the instance moved off C, regardless where it is moved on What is the difference between move-off and unmigrate (-U)? --move-off - create a constraint that a resource should *not* run on the specific node (partly as before --move without --node) -U: zap all migration constraints (as before) Ah, right, sorry, wanted to ask about the difference between move-off and move. The description looks the same as for move. Is it that in this case it is for clones so crm_resource needs an extra node parameter? You wrote in the doc: +Migrate a resource (-instance for clones/masters) off the specified node. The '-instance' looks somewhat funny. Why not say Move/migrate a clone or master/slave instance away from the specified node? Moving away works for all kinds of resources so the text now looks like: diff -r b4f456380f60 doc/crm_cli.txt --- a/doc/crm_cli.txt Thu Mar 17 09:41:25 2011 +0100 +++ b/doc/crm_cli.txt Tue Apr 05 13:08:10 2011 +0200 @@ -818,10 +818,25 @@ running on the current node. Additionally, you may specify a lifetime for the constraint---once it expires, the location constraint will no longer be active. +For a master resource specify rsc:master to move the master role. Usage: ... -migrate rsc [node] [lifetime] [force] +migrate rsc[:master] [node] [lifetime] [force] +... + +[[cmdhelp_resource_migrateoff,migrate a resource off the specified node]] + `migrateoff` (`moveoff`) + +Migrate a resource away from the specified node. +The resource is migrated by creating a constraint which prevents it from +running on the specified node. Additionally, you may specify a +lifetime for the constraint---once it expires, the location +constraint will no longer be active. + +Usage: +... +migrateoff rsc node [lifetime] [force] ... [[cmdhelp_resource_unmigrate,unmigrate a resource to another node]] I must say that I still find all this quite confusing, i.e. now we have move, unmove, and move-off, but it's probably just me :) Think of move == move-to then it is simpler 8-) ... keeping in mind that for backward compatibility crm_resource --move --resource myResource is equivalent crm_resource --move-off --resource myResource --node $(current node) But as there is no current node for clones / masters the old implementation did some random movements... OK. Thanks for the clarification. I'd like to revise my previous comment about restricting use of certain constructs. For instance, in this case, if the command would result in a random movement then the shell should at least issue a warning about it. Or perhaps refuse to do that completely. I didn't take a look yet at the code, perhaps you've already done that. Thanks, Dejan I admit you have to specify more verbosely what you want to achieve but then the patched versions (based on patches I submitted today around 10:01) execute consistent and without surprises - at least for my test cases. Regards Holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Sat, Mar 19, 2011 at 11:55 AM, Holger Teutsch holger.teut...@web.de wrote: Hi Dejan, On Fri, 2011-03-18 at 14:24 +0100, Dejan Muhamedagic wrote: Hi, On Fri, Mar 18, 2011 at 12:21:40PM +0100, Holger Teutsch wrote: Hi, I would like to submit 2 patches of an initial implementation for discussion. .. To recall: crm_resource --move resource creates a standby rule that moves the resource off the currently active node while crm_resource --move resource --node newnode creates a prefer rule that moves the resource to the new node. When dealing with clones and masters the behavior was random as the code only considers the node where the first instance of the clone was started. The new code behaves consistently for the master role of an m/s resource. The options --master and rsc:master are somewhat redundant as a slave move is not supported. Currently it's more an acknowledgement of the user. On the other hand it is desirable (and was requested several times on the ML) to stop a single resource instance of a clone or master on a specific node. Should that be implemented by something like crm_resource --move-off --resource myresource --node devel2 ? or should crm_resource refuse to work on clones and/or should moving the master role be the default for m/s resources and the --master option discarded ? I think that we also need to consider the case when clone-max is less than the number of nodes. If I understood correctly what you were saying. So, all of move slave and move master and move clone should be possible. I think the following use cases cover what can be done with such kind of interface: crm_resource --moveoff --resource myresource --node mynode - all resource variants: check whether active on mynode, then create standby constraint crm_resource --move --resource myresource - primitive/group: convert to --moveoff --node `current_node` - clone/master: refused crm_resource --move --resource myresource --node mynode - primitive/group: create prefer constraint - clone/master: refused Not sure this needs to be refused. Other than that the proposal looks sane. My first thought was to make --move behave like --move-off if the resource is a clone or /ms, but since the semantics are the exact opposite, that might introduce introduce more problems than it solves. Does the original crm_resource patch implement this? crm_resource --move --resource myresource --master --node mynode - master: create prefer constraint for master role - others: refused They should work (witch foreseeable outcome!) regardless of the setting of clone-max. Regards Holger Cheers, Dejan Regards Holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
On Mon, Apr 4, 2011 at 2:43 PM, Holger Teutsch holger.teut...@web.de wrote: On Mon, 2011-04-04 at 11:05 +0200, Andrew Beekhof wrote: On Sat, Mar 19, 2011 at 11:55 AM, Holger Teutsch holger.teut...@web.de wrote: Hi Dejan, On Fri, 2011-03-18 at 14:24 +0100, Dejan Muhamedagic wrote: Hi, On Fri, Mar 18, 2011 at 12:21:40PM +0100, Holger Teutsch wrote: Hi, I would like to submit 2 patches of an initial implementation for discussion. .. To recall: crm_resource --move resource creates a standby rule that moves the resource off the currently active node while crm_resource --move resource --node newnode creates a prefer rule that moves the resource to the new node. When dealing with clones and masters the behavior was random as the code only considers the node where the first instance of the clone was started. The new code behaves consistently for the master role of an m/s resource. The options --master and rsc:master are somewhat redundant as a slave move is not supported. Currently it's more an acknowledgement of the user. On the other hand it is desirable (and was requested several times on the ML) to stop a single resource instance of a clone or master on a specific node. Should that be implemented by something like crm_resource --move-off --resource myresource --node devel2 ? or should crm_resource refuse to work on clones and/or should moving the master role be the default for m/s resources and the --master option discarded ? I think that we also need to consider the case when clone-max is less than the number of nodes. If I understood correctly what you were saying. So, all of move slave and move master and move clone should be possible. I think the following use cases cover what can be done with such kind of interface: crm_resource --moveoff --resource myresource --node mynode - all resource variants: check whether active on mynode, then create standby constraint crm_resource --move --resource myresource - primitive/group: convert to --moveoff --node `current_node` - clone/master: refused crm_resource --move --resource myresource --node mynode - primitive/group: create prefer constraint - clone/master: refused Not sure this needs to be refused. I see the problem that the node where the resource instance should be moved off had to be specified as well to get predictable behavior. Consider a a 2 way clone on a 3 node cluster. If the clone is active on A and B what should crm_resource --move --resource myClone --node C do ? I would expect it to create the +inf constraint for C but no contraint(s) for the current location(s) This would require an additional --from-node or similar. Other than that the proposal looks sane. My first thought was to make --move behave like --move-off if the resource is a clone or /ms, but since the semantics are the exact opposite, that might introduce introduce more problems than it solves. That was my perception as well. Does the original crm_resource patch implement this? No, I will submit an updated version later this week. - holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi Dejan, On Mon, 2011-03-21 at 16:11 +0100, Dejan Muhamedagic wrote: Hi Holger, On Sat, Mar 19, 2011 at 11:55:57AM +0100, Holger Teutsch wrote: Hi Dejan, On Fri, 2011-03-18 at 14:24 +0100, Dejan Muhamedagic wrote: Hi, On Fri, Mar 18, 2011 at 12:21:40PM +0100, Holger Teutsch wrote: Hi, I would like to submit 2 patches of an initial implementation for discussion. .. To recall: crm_resource --move resource creates a standby rule that moves the resource off the currently active node while crm_resource --move resource --node newnode creates a prefer rule that moves the resource to the new node. When dealing with clones and masters the behavior was random as the code only considers the node where the first instance of the clone was started. The new code behaves consistently for the master role of an m/s resource. The options --master and rsc:master are somewhat redundant as a slave move is not supported. Currently it's more an acknowledgement of the user. On the other hand it is desirable (and was requested several times on the ML) to stop a single resource instance of a clone or master on a specific node. Should that be implemented by something like crm_resource --move-off --resource myresource --node devel2 ? or should crm_resource refuse to work on clones and/or should moving the master role be the default for m/s resources and the --master option discarded ? I think that we also need to consider the case when clone-max is less than the number of nodes. If I understood correctly what you were saying. So, all of move slave and move master and move clone should be possible. I think the following use cases cover what can be done with such kind of interface: crm_resource --moveoff --resource myresource --node mynode - all resource variants: check whether active on mynode, then create standby constraint crm_resource --move --resource myresource - primitive/group: convert to --moveoff --node `current_node` - clone/master: refused crm_resource --move --resource myresource --node mynode - primitive/group: create prefer constraint - clone/master: refused crm_resource --move --resource myresource --master --node mynode - master: create prefer constraint for master role - others: refused They should work (witch foreseeable outcome!) regardless of the setting of clone-max. This seems quite complicated to me. Took me a while to figure out what's what and where :) Why bother doing the thinking for I'm afraid the matter *is* complicated. The current implementation of crm_resource --move --resource myResource (without node name) is moving off the resource from the node it is currently active on by creating a standby constraint. For clones and masters there is no such *single* active node the constraint can be constructed for. Consider this use case: I have 2 nodes and a clone or master and would like to safely get rid of one instance on a particular node (e.g. with agents 1.0.5 the slave of a DB2 HADR pair 8-) ). No idea how that should be done without a move-off functionality. users? The only case which seems to me worth considering is refusing setting role for non-ms resources. Otherwise, let's let the user move things around and enjoy the consequences. Definitely not true for production clusters. The tools should produce least surprise consequences. Cheers, Over the weekend I implemented the above mentioned functionality. Drop me note if you want to play with an early snapshot 8-) Regards Holger ___ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
[Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi,
I would like to submit 2 patches of an initial implementation for
discussion.
Patch 1 implements migration of the Master role of an m/s resource to
another node in crm_resource
Patch 2 adds support for the shell.
crm_resource does this with options
crm_resource --move --resource ms_test --master --node devel2
The shell does the same with
crm resource migrate ms_test:master devel2
crm_resource insist on the options --master --node xxx if dealing with
m/s resources.
It is not easy to assess the expectations that a move command should
fulfill for something more complex than a group.
To recall:
crm_resource --move resource
creates a standby rule that moves the resource off the currently
active node
while
crm_resource --move resource --node newnode
creates a prefer rule that moves the resource to the new node.
When dealing with clones and masters the behavior was random as the code
only considers the node where the first instance of the clone was
started.
The new code behaves consistently for the master role of an m/s
resource. The options --master and rsc:master are somewhat redundant
as a slave move is not supported. Currently it's more an
acknowledgement of the user.
On the other hand it is desirable (and was requested several times on
the ML) to stop a single resource instance of a clone or master on a
specific node.
Should that be implemented by something like
crm_resource --move-off --resource myresource --node devel2 ?
or should
crm_resource refuse to work on clones
and/or should moving the master role be the default for m/s resources
and the --master option discarded ?
Regards
Holger
# HG changeset patch
# User Holger Teutsch holger.teut...@web.de
# Date 1300439791 -3600
# Branch mig
# Node ID dac1a4eae844f0bd857951b1154a171c80c25772
# Parent b4f456380f60bd308acdc462215620f5bf530854
crm_resource.c: Add support for move of Master role of a m/s resource
diff -r b4f456380f60 -r dac1a4eae844 tools/crm_resource.c
--- a/tools/crm_resource.c Thu Mar 17 09:41:25 2011 +0100
+++ b/tools/crm_resource.c Fri Mar 18 10:16:31 2011 +0100
@@ -52,6 +52,7 @@
const char *prop_id = NULL;
const char *prop_set = NULL;
char *move_lifetime = NULL;
+int move_master = 0;
char rsc_cmd = 'L';
char *our_pid = NULL;
IPC_Channel *crmd_channel = NULL;
@@ -192,6 +193,32 @@
return 0;
}
+/* is m/s resource in master role on a host? */
+static int
+is_master_on(resource_t *rsc, const char *check_uname)
+{
+GListPtr lpc = NULL;
+
+if(rsc-variant pe_native) {
+/* recursively call down */
+ GListPtr gIter = rsc-children;
+ for(; gIter != NULL; gIter = gIter-next) {
+ if(is_master_on(gIter-data, check_uname))
+ return 1;
+}
+ return 0;
+}
+
+for(lpc = rsc-running_on; lpc != NULL; lpc = lpc-next) {
+ node_t *node = (node_t*)lpc-data;
+ if(rsc-variant == pe_native rsc-role == RSC_ROLE_MASTER
+safe_str_eq(node-details-uname, check_uname)) {
+return 1;
+}
+}
+return 0;
+}
+
#define cons_string(x) x?x:NA
static void
print_cts_constraints(pe_working_set_t *data_set)
@@ -797,6 +824,7 @@
static int
move_resource(
const char *rsc_id,
+int move_master,
const char *existing_node, const char *preferred_node,
cib_t * cib_conn)
{
@@ -935,6 +963,10 @@
crm_xml_add(rule, XML_ATTR_ID, id);
crm_free(id);
+if(move_master) {
+crm_xml_add(rule, XML_RULE_ATTR_ROLE, Master);
+}
+
crm_xml_add(rule, XML_RULE_ATTR_SCORE, INFINITY_S);
crm_xml_add(rule, XML_RULE_ATTR_BOOLEAN_OP, and);
@@ -1093,6 +1125,8 @@
crm_free(prefix);
}
+/* out of single letter options */
+#define OPT_MASTER (256 + 'm')
static struct crm_option long_options[] = {
/* Top-level Options */
{help,0, 0, '?', \t\tThis text},
@@ -1120,10 +1154,10 @@
{get-property,1, 0, 'G', Display the 'class', 'type' or 'provider' of a resource, 1},
{set-property,1, 0, 'S', (Advanced) Set the class, type or provider of a resource, 1},
{move,0, 0, 'M',
- \t\tMove a resource from its current location, optionally specifying a destination (-N) and/or a period for which it should take effect (-u)
+ \t\tMove a resource from its current location, optionally specifying a role (--master), a destination (-N) and/or a period for which it should take effect (-u)
\n\t\t\t\tIf -N is not specified, the cluster will force the resource to move by creating a rule for the current location and a score of -INFINITY
\n\t\t\t\tNOTE: This will prevent the resource from running on this node until the constraint is removed with -U},
-{un-move, 0, 0, 'U', \tRemove all constraints created by a move command},
+{un-move, 0, 0, 'U', \t\tRemove all constraints created by a move command},
{-spacer-, 1, 0, '-', \nAdvanced Commands:},
{delete, 0, 0, 'D', \t\tDelete a resource from the CIB},
@@ -1137,6 +1171,7 @@
{resource-type, 1, 0, 't', Resource type
Re: [Pacemaker] [PATCH]Bug 2567 - crm resource migrate should support an optional role parameter
Hi,
On Fri, Mar 18, 2011 at 12:21:40PM +0100, Holger Teutsch wrote:
Hi,
I would like to submit 2 patches of an initial implementation for
discussion.
Patch 1 implements migration of the Master role of an m/s resource to
another node in crm_resource
Patch 2 adds support for the shell.
Great.
crm_resource does this with options
crm_resource --move --resource ms_test --master --node devel2
The shell does the same with
crm resource migrate ms_test:master devel2
crm_resource insist on the options --master --node xxx if dealing with
m/s resources.
It is not easy to assess the expectations that a move command should
fulfill for something more complex than a group.
To recall:
crm_resource --move resource
creates a standby rule that moves the resource off the currently
active node
while
crm_resource --move resource --node newnode
creates a prefer rule that moves the resource to the new node.
When dealing with clones and masters the behavior was random as the code
only considers the node where the first instance of the clone was
started.
The new code behaves consistently for the master role of an m/s
resource. The options --master and rsc:master are somewhat redundant
as a slave move is not supported. Currently it's more an
acknowledgement of the user.
On the other hand it is desirable (and was requested several times on
the ML) to stop a single resource instance of a clone or master on a
specific node.
Should that be implemented by something like
crm_resource --move-off --resource myresource --node devel2 ?
or should
crm_resource refuse to work on clones
and/or should moving the master role be the default for m/s resources
and the --master option discarded ?
I think that we also need to consider the case when clone-max is
less than the number of nodes. If I understood correctly what you
were saying. So, all of move slave and move master and move clone
should be possible.
Cheers,
Dejan
Regards
Holger
# HG changeset patch
# User Holger Teutsch holger.teut...@web.de
# Date 1300439791 -3600
# Branch mig
# Node ID dac1a4eae844f0bd857951b1154a171c80c25772
# Parent b4f456380f60bd308acdc462215620f5bf530854
crm_resource.c: Add support for move of Master role of a m/s resource
diff -r b4f456380f60 -r dac1a4eae844 tools/crm_resource.c
--- a/tools/crm_resource.cThu Mar 17 09:41:25 2011 +0100
+++ b/tools/crm_resource.cFri Mar 18 10:16:31 2011 +0100
@@ -52,6 +52,7 @@
const char *prop_id = NULL;
const char *prop_set = NULL;
char *move_lifetime = NULL;
+int move_master = 0;
char rsc_cmd = 'L';
char *our_pid = NULL;
IPC_Channel *crmd_channel = NULL;
@@ -192,6 +193,32 @@
return 0;
}
+/* is m/s resource in master role on a host? */
+static int
+is_master_on(resource_t *rsc, const char *check_uname)
+{
+GListPtr lpc = NULL;
+
+if(rsc-variant pe_native) {
+/* recursively call down */
+ GListPtr gIter = rsc-children;
+ for(; gIter != NULL; gIter = gIter-next) {
+if(is_master_on(gIter-data, check_uname))
+ return 1;
+}
+ return 0;
+}
+
+for(lpc = rsc-running_on; lpc != NULL; lpc = lpc-next) {
+ node_t *node = (node_t*)lpc-data;
+ if(rsc-variant == pe_native rsc-role == RSC_ROLE_MASTER
+safe_str_eq(node-details-uname, check_uname)) {
+return 1;
+}
+}
+return 0;
+}
+
#define cons_string(x) x?x:NA
static void
print_cts_constraints(pe_working_set_t *data_set)
@@ -797,6 +824,7 @@
static int
move_resource(
const char *rsc_id,
+int move_master,
const char *existing_node, const char *preferred_node,
cib_t * cib_conn)
{
@@ -935,6 +963,10 @@
crm_xml_add(rule, XML_ATTR_ID, id);
crm_free(id);
+if(move_master) {
+crm_xml_add(rule, XML_RULE_ATTR_ROLE, Master);
+}
+
crm_xml_add(rule, XML_RULE_ATTR_SCORE, INFINITY_S);
crm_xml_add(rule, XML_RULE_ATTR_BOOLEAN_OP, and);
@@ -1093,6 +1125,8 @@
crm_free(prefix);
}
+/* out of single letter options */
+#define OPT_MASTER (256 + 'm')
static struct crm_option long_options[] = {
/* Top-level Options */
{help,0, 0, '?', \t\tThis text},
@@ -1120,10 +1154,10 @@
{get-property,1, 0, 'G', Display the 'class', 'type' or
'provider' of a resource, 1},
{set-property,1, 0, 'S', (Advanced) Set the class, type or
provider of a resource, 1},
{move,0, 0, 'M',
- \t\tMove a resource from its current location, optionally specifying a
destination (-N) and/or a period for which it should take effect (-u)
+ \t\tMove a resource from its current location, optionally specifying a
role (--master), a destination (-N) and/or a period for which it should take
effect (-u)
\n\t\t\t\tIf -N is not specified, the cluster will force the resource
to move by creating a rule
