Re: [Linux-ha-dev] Uniquness OCF Parameters
On 06/17/2011 02:43 AM, Lars Ellenberg wrote: On Thu, Jun 16, 2011 at 03:52:37PM -0600, Alan Robertson wrote: On 06/16/2011 02:51 AM, Lars Ellenberg wrote: On Thu, Jun 16, 2011 at 09:48:20AM +0200, Florian Haas wrote: On 2011-06-16 09:03, Lars Ellenberg wrote: With the current unique=true/false, you cannot express that. Thanks. You learn something every day. :) Sorry that I left off the As you are well aware of, introductionary phrase. ;-) I just summarized the problem: Depending on what we chose the meaning to be, parameters marked unique=true would be required to either be all _independently_ unique, or be unique as a tuple. And made a suggestion how to solve it: If we want to be able to express both, we need a different markup. Of course, we can move the markup out of the parameter description, into an additional markup, that spells them out, likeunique params=foo,bar /unique params=bla /. But using unique=0 as the current non-unique meaning, then unique=small-integer-or-even-named-label-who-cares, would name the scope for this uniqueness requirement, where parameters marked with the same such label would form a unique tuple. Enables us to mark multiple tuples, and individual parameters, at the same time. If we really think it _is_ a problem. If one wanted to, one could say unique=1,3 or unique=1 unique=3 Then parameters which share the same uniqueness list are part of the same uniqueness grouping. Since RAs today normally say unique=1, if one excluded the unique group 0 from being unique, then this could be done in a completely upwards-compatible way for nearly all resources. That is what I suggested, yes. Where unique=0 is basically not mentioning the unique hint. Originally that's what I thought you said. But somehow read it differently later. Perhaps I got my comment authorship cross-wired. Wouldn't be hard to imagine ;-) -- Alan Robertsonal...@unix.sh Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions. - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
Simon Talbot Chief Engineer Net Solutions Europe T: 020 3161 6001 F: 020 3161 6011 www.nse.co.uk The information contained in this e-mail and any attachments are private and confidential and may be legally privileged. It is intended for the named addressee(s) only. If you are not the intended recipient(s), you must not read, copy or use the information contained in any way. If you receive this email or any attachments in error, please notify us immediately by e-mail and destroy any copy you have of it. We accept no responsibility for any loss or damages whatsoever arising in any way from receipt or use of this e-mail or any attachments. This e-mail is not intended to create legally binding commitments on our behalf, nor do its comments reflect our corporate views or policies. Net Solutions Europe Ltd Registered Office: Baxter House, 48 Church Road, Ascot, Berkshire, SL5 8RR Registered in England No. 03203624. -Original Message- From: linux-ha-dev-boun...@lists.linux-ha.org [mailto:linux-ha-dev-boun...@lists.linux-ha.org] On Behalf Of Alan Robertson Sent: 16 June 2011 10:53 PM To: High-Availability Linux Development List Subject: Re: [Linux-ha-dev] Uniquness OCF Parameters On 06/16/2011 10:53 PM, Alan Robertson wrote: On 06/16/2011 02:51 AM, Lars Ellenberg wrote: On Thu, Jun 16, 2011 at 09:48:20AM +0200, Florian Haas wrote: On 2011-06-16 09:03, Lars Ellenberg wrote: With the current unique=true/false, you cannot express that. Thanks. You learn something every day. :) Sorry that I left off the As you are well aware of, introductionary phrase. ;-) I just summarized the problem: Depending on what we chose the meaning to be, parameters marked unique=true would be required to either be all _independently_ unique, or be unique as a tuple. And made a suggestion how to solve it: If we want to be able to express both, we need a different markup. Of course, we can move the markup out of the parameter description, into an additional markup, that spells them out, likeunique params=foo,bar /unique params=bla /. But using unique=0 as the current non-unique meaning, then unique=small-integer-or-even-named-label-who-cares, would name the scope for this uniqueness requirement, where parameters marked with the same such label would form a unique tuple. Enables us to mark multiple tuples, and individual parameters, at the same time. If we really think it _is_ a problem. If one wanted to, one could say unique=1,3 or unique=1 unique=3 Then parameters which share the same uniqueness list are part of the same uniqueness grouping. Since RAs today normally say unique=1, if one excluded the unique group 0 from being unique, then this could be done in a completely upwards-compatible way for nearly all resources. This would certainly cover most of the permutations I can think of and certainly all the ones in our environment, Simon Simon Talbot Chief Engineer Net Solutions Europe T: 020 3161 6001 F: 020 3161 6011 www.nse.co.uk ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On Thu, Jun 16, 2011 at 03:52:37PM -0600, Alan Robertson wrote: On 06/16/2011 02:51 AM, Lars Ellenberg wrote: On Thu, Jun 16, 2011 at 09:48:20AM +0200, Florian Haas wrote: On 2011-06-16 09:03, Lars Ellenberg wrote: With the current unique=true/false, you cannot express that. Thanks. You learn something every day. :) Sorry that I left off the As you are well aware of, introductionary phrase. ;-) I just summarized the problem: Depending on what we chose the meaning to be, parameters marked unique=true would be required to either be all _independently_ unique, or be unique as a tuple. And made a suggestion how to solve it: If we want to be able to express both, we need a different markup. Of course, we can move the markup out of the parameter description, into an additional markup, that spells them out, likeunique params=foo,bar /unique params=bla /. But using unique=0 as the current non-unique meaning, then unique=small-integer-or-even-named-label-who-cares, would name the scope for this uniqueness requirement, where parameters marked with the same such label would form a unique tuple. Enables us to mark multiple tuples, and individual parameters, at the same time. If we really think it _is_ a problem. If one wanted to, one could say unique=1,3 or unique=1 unique=3 Then parameters which share the same uniqueness list are part of the same uniqueness grouping. Since RAs today normally say unique=1, if one excluded the unique group 0 from being unique, then this could be done in a completely upwards-compatible way for nearly all resources. That is what I suggested, yes. Where unique=0 is basically not mentioning the unique hint. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On Wed, Jun 15, 2011 at 04:07:27PM +0200, Florian Haas wrote: On 2011-06-15 15:50, Alan Robertson wrote: On 06/14/2011 06:03 AM, Florian Haas wrote: On 2011-06-14 13:08, Dejan Muhamedagic wrote: Hi Alan, On Mon, Jun 13, 2011 at 10:32:02AM -0600, Alan Robertson wrote: On 06/13/2011 04:12 AM, Simon Talbot wrote: A couple of observations (I am sure there are more) on the uniqueness flag for OCF script parameters: Would it be wise for the for the index parameter of the SFEX ocf script to have its unique flag set to 1 so that the crm tool (and others) would warn if one inadvertantly tried to create two SFEX resource primitives with the same index? Also, an example of the opposite, the Stonith/IPMI script, has parameters such as interface, username and password with their unique flags set to 1, causing erroneous warnings if you use the same interface, username or password for multiple IPMI stonith primitives, which of course if often the case in large clusters? When we designed it, we intended that Unique applies to the complete set of parameters - not to individual parameters. It's like a multi-part unique key. It takes all 3 to create a unique instance (for the example you gave). That makes sense. Does it really? Then what would be the point of having some params that are unique, and some that are not? Or would the tuple of _all_ parameters marked as unique be considered unique? I don't know what you think I said, but A multi-part key to a database is a tuple which consists of all marked parameters. You just said what I said in a different way. So we agree. Jfyi, I was asking a question, not stating an opinion. Hence the use of a question mark. ;-) So then, if the uniqueness should be enforced for a unique key that is comprised of _all_ the parameters marked unique in a parameter set, then what would be the correct way to express required uniqueness of _individual_ parameters? In other words, if I have foo and bar marked unique, then one resource with foo=1 and bar=2, and another with foo=1, bar=3 does not violate the uniqueness constraint. What if I want both foo and bar to be unique in and of themselves, so any duplicate use of foo=1 should be treated as a uniqueness violation? With the current unique=true/false, you cannot express that. Depending on what we chose the meaning to be, parameters marked unique=true would be required to either be all _independently_ unique, or be unique as a tuple. If we want to be able to express both, we need a different markup. Of course, we can move the markup out of the parameter description, into an additional markup, that spells them out, like unique params=foo,bar /unique params=bla /. But using unique=0 as the current non-unique meaning, then unique=small-integer-or-even-named-label-who-cares, would name the scope for this uniqueness requirement, where parameters marked with the same such label would form a unique tuple. Enables us to mark multiple tuples, and individual parameters, at the same time. Question is: do we really want or need that. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On 2011-06-16 09:03, Lars Ellenberg wrote: With the current unique=true/false, you cannot express that. Thanks. You learn something every day. :) Depending on what we chose the meaning to be, parameters marked unique=true would be required to either be all _independently_ unique, or be unique as a tuple. If we want to be able to express both, we need a different markup. Of course, we can move the markup out of the parameter description, into an additional markup, that spells them out, like unique params=foo,bar /unique params=bla /. But using unique=0 as the current non-unique meaning, then unique=small-integer-or-even-named-label-who-cares, would name the scope for this uniqueness requirement, where parameters marked with the same such label would form a unique tuple. Enables us to mark multiple tuples, and individual parameters, at the same time. Question is: do we really want or need that. That is a discussion for the updated OCF RA spec discussion, really. And the driver of that discussion is currently submerged. :) Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On Thu, Jun 16, 2011 at 09:48:20AM +0200, Florian Haas wrote: On 2011-06-16 09:03, Lars Ellenberg wrote: With the current unique=true/false, you cannot express that. Thanks. You learn something every day. :) Sorry that I left off the As you are well aware of, introductionary phrase. ;-) I just summarized the problem: Depending on what we chose the meaning to be, parameters marked unique=true would be required to either be all _independently_ unique, or be unique as a tuple. And made a suggestion how to solve it: If we want to be able to express both, we need a different markup. Of course, we can move the markup out of the parameter description, into an additional markup, that spells them out, like unique params=foo,bar /unique params=bla /. But using unique=0 as the current non-unique meaning, then unique=small-integer-or-even-named-label-who-cares, would name the scope for this uniqueness requirement, where parameters marked with the same such label would form a unique tuple. Enables us to mark multiple tuples, and individual parameters, at the same time. If we really think it _is_ a problem. Question is: do we really want or need that. That is a discussion for the updated OCF RA spec discussion, really. And the driver of that discussion is currently submerged. :) I guess this was @LMB? Hey there ... do you read? :) As to stood the test of time, well, no. Not these resource agent parameter hints. Not yet. Especially the unique and type hints have been mostly ignored until now, the type hints are still wrong for some resource agents last time I checked, and also mostly ignored, and the unique hint just starts to throw a warning in crm shell now. So, because these hints have been ignored so far, they have not been tested, not even by time... These hints are also not enforced by the cib (which does not know about them anyways), but only hints to some frontend. And because some frontend now started to at least consider these hints, we are having this discussion now... Lars ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On 2011-06-16 10:51, Lars Ellenberg wrote: On Thu, Jun 16, 2011 at 09:48:20AM +0200, Florian Haas wrote: On 2011-06-16 09:03, Lars Ellenberg wrote: With the current unique=true/false, you cannot express that. Thanks. You learn something every day. :) Sorry that I left off the As you are well aware of, introductionary phrase. ;-) In case that wasn't clear earlier, I was very much not aware of this. I wasn't being ironic, for a change. :) Question is: do we really want or need that. That is a discussion for the updated OCF RA spec discussion, really. And the driver of that discussion is currently submerged. :) I guess this was @LMB? Hey there ... do you read? :) He is on a diving vacation in Croatia. Not only was I not being ironic; I referred to his literal submersion. Cheers, Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On 06/16/2011 02:51 AM, Lars Ellenberg wrote: On Thu, Jun 16, 2011 at 09:48:20AM +0200, Florian Haas wrote: On 2011-06-16 09:03, Lars Ellenberg wrote: With the current unique=true/false, you cannot express that. Thanks. You learn something every day. :) Sorry that I left off the As you are well aware of, introductionary phrase. ;-) I just summarized the problem: Depending on what we chose the meaning to be, parameters marked unique=true would be required to either be all _independently_ unique, or be unique as a tuple. And made a suggestion how to solve it: If we want to be able to express both, we need a different markup. Of course, we can move the markup out of the parameter description, into an additional markup, that spells them out, likeunique params=foo,bar /unique params=bla /. But using unique=0 as the current non-unique meaning, then unique=small-integer-or-even-named-label-who-cares, would name the scope for this uniqueness requirement, where parameters marked with the same such label would form a unique tuple. Enables us to mark multiple tuples, and individual parameters, at the same time. If we really think it _is_ a problem. If one wanted to, one could say unique=1,3 or unique=1 unique=3 Then parameters which share the same uniqueness list are part of the same uniqueness grouping. Since RAs today normally say unique=1, if one excluded the unique group 0 from being unique, then this could be done in a completely upwards-compatible way for nearly all resources. -- Alan Robertsonal...@unix.sh Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions. - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On 06/14/2011 06:03 AM, Florian Haas wrote: On 2011-06-14 13:08, Dejan Muhamedagic wrote: Hi Alan, On Mon, Jun 13, 2011 at 10:32:02AM -0600, Alan Robertson wrote: On 06/13/2011 04:12 AM, Simon Talbot wrote: A couple of observations (I am sure there are more) on the uniqueness flag for OCF script parameters: Would it be wise for the for the index parameter of the SFEX ocf script to have its unique flag set to 1 so that the crm tool (and others) would warn if one inadvertantly tried to create two SFEX resource primitives with the same index? Also, an example of the opposite, the Stonith/IPMI script, has parameters such as interface, username and password with their unique flags set to 1, causing erroneous warnings if you use the same interface, username or password for multiple IPMI stonith primitives, which of course if often the case in large clusters? When we designed it, we intended that Unique applies to the complete set of parameters - not to individual parameters. It's like a multi-part unique key. It takes all 3 to create a unique instance (for the example you gave). That makes sense. Does it really? Then what would be the point of having some params that are unique, and some that are not? Or would the tuple of _all_ parameters marked as unique be considered unique? I don't know what you think I said, but A multi-part key to a database is a tuple which consists of all marked parameters. You just said what I said in a different way. So we agree. -- Alan Robertsonal...@unix.sh Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions. - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On 06/14/2011 07:21 AM, Dejan Muhamedagic wrote: Hi Florian, On Tue, Jun 14, 2011 at 02:03:19PM +0200, Florian Haas wrote: On 2011-06-14 13:08, Dejan Muhamedagic wrote: Hi Alan, On Mon, Jun 13, 2011 at 10:32:02AM -0600, Alan Robertson wrote: On 06/13/2011 04:12 AM, Simon Talbot wrote: A couple of observations (I am sure there are more) on the uniqueness flag for OCF script parameters: Would it be wise for the for the index parameter of the SFEX ocf script to have its unique flag set to 1 so that the crm tool (and others) would warn if one inadvertantly tried to create two SFEX resource primitives with the same index? Also, an example of the opposite, the Stonith/IPMI script, has parameters such as interface, username and password with their unique flags set to 1, causing erroneous warnings if you use the same interface, username or password for multiple IPMI stonith primitives, which of course if often the case in large clusters? When we designed it, we intended that Unique applies to the complete set of parameters - not to individual parameters. It's like a multi-part unique key. It takes all 3 to create a unique instance (for the example you gave). That makes sense. Does it really? Then what would be the point of having some params that are unique, and some that are not? Or would the tuple of _all_ parameters marked as unique be considered unique? Consider the example above for sfex. It has a device and index which together determine which part of the disk the RA should use. Only the device:index tuple must be unique. Currently, neither device nor index is a unique parameter (in the meta-data). Otherwise we'd have false positives for the following configuration: disk1:1 disk1:2 disk2:1 disk2:2 Now, stuff such as configfile and pidfile obviously both must be unique independently of each other. There are probably other examples of both kinds. Although what you said makes sense and is obviously upwards compatible and useful - I don't think we thought it through to that detail originally. It was a long time ago, and we were trying to think all these kind of things through - and I don't recall that kind of detail in the discussions. I think we did a pretty good job. It's one of the things I think we did right. That's not saying it's perfect - nothing is. But, it's not bad, and I think it has stood the test of time pretty well. We met face to face for these discussions, and not every word we said was archived for posterity ;-). We wrote up the specs afterwards - several weeks later due to things like getting the web site set up and so on. Folks from two proprietary stacks, people from the user community, and folks from the Linux-HA community met to do these things together. About 8-12 people total. I remember most of them. Although we invited Red Hat - they didn't send anyone. It's a testament to the spec that in spite of not participating in the standard, that they implemented it anyway. I was certainly pleased with that. -- Alan Robertsonal...@unix.sh Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions. - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
Hi, On Mon, Jun 13, 2011 at 10:12:13AM +, Simon Talbot wrote: A couple of observations (I am sure there are more) on the uniqueness flag for OCF script parameters: I knew there are going to be quite a few :) Would it be wise for the for the index parameter of the SFEX ocf script to have its unique flag set to 1 so that the crm tool (and others) would warn if one inadvertantly tried to create two SFEX resource primitives with the same index? Perhaps. Don't know what's the typical usage. What needs to be unique is the combination of device and index. Also, an example of the opposite, the Stonith/IPMI script, has parameters such as interface, username and password with their unique flags set to 1, causing erroneous warnings if you use the same interface, username or password for multiple IPMI stonith primitives, which of course if often the case in large clusters? That should be changed. Thanks, Dejan Simon Simon Talbot Chief Engineer Net Solutions Europe T: 020 3161 6001 F: 020 3161 6011 www.nse.co.uk ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On 2011-06-14 13:08, Dejan Muhamedagic wrote: Hi Alan, On Mon, Jun 13, 2011 at 10:32:02AM -0600, Alan Robertson wrote: On 06/13/2011 04:12 AM, Simon Talbot wrote: A couple of observations (I am sure there are more) on the uniqueness flag for OCF script parameters: Would it be wise for the for the index parameter of the SFEX ocf script to have its unique flag set to 1 so that the crm tool (and others) would warn if one inadvertantly tried to create two SFEX resource primitives with the same index? Also, an example of the opposite, the Stonith/IPMI script, has parameters such as interface, username and password with their unique flags set to 1, causing erroneous warnings if you use the same interface, username or password for multiple IPMI stonith primitives, which of course if often the case in large clusters? When we designed it, we intended that Unique applies to the complete set of parameters - not to individual parameters. It's like a multi-part unique key. It takes all 3 to create a unique instance (for the example you gave). That makes sense. Does it really? Then what would be the point of having some params that are unique, and some that are not? Or would the tuple of _all_ parameters marked as unique be considered unique? Florian signature.asc Description: OpenPGP digital signature ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
Hi Florian, On Tue, Jun 14, 2011 at 02:03:19PM +0200, Florian Haas wrote: On 2011-06-14 13:08, Dejan Muhamedagic wrote: Hi Alan, On Mon, Jun 13, 2011 at 10:32:02AM -0600, Alan Robertson wrote: On 06/13/2011 04:12 AM, Simon Talbot wrote: A couple of observations (I am sure there are more) on the uniqueness flag for OCF script parameters: Would it be wise for the for the index parameter of the SFEX ocf script to have its unique flag set to 1 so that the crm tool (and others) would warn if one inadvertantly tried to create two SFEX resource primitives with the same index? Also, an example of the opposite, the Stonith/IPMI script, has parameters such as interface, username and password with their unique flags set to 1, causing erroneous warnings if you use the same interface, username or password for multiple IPMI stonith primitives, which of course if often the case in large clusters? When we designed it, we intended that Unique applies to the complete set of parameters - not to individual parameters. It's like a multi-part unique key. It takes all 3 to create a unique instance (for the example you gave). That makes sense. Does it really? Then what would be the point of having some params that are unique, and some that are not? Or would the tuple of _all_ parameters marked as unique be considered unique? Consider the example above for sfex. It has a device and index which together determine which part of the disk the RA should use. Only the device:index tuple must be unique. Currently, neither device nor index is a unique parameter (in the meta-data). Otherwise we'd have false positives for the following configuration: disk1:1 disk1:2 disk2:1 disk2:2 Now, stuff such as configfile and pidfile obviously both must be unique independently of each other. There are probably other examples of both kinds. Cheers, Dejan Florian ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/ ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Uniquness OCF Parameters
On 06/13/2011 04:12 AM, Simon Talbot wrote: A couple of observations (I am sure there are more) on the uniqueness flag for OCF script parameters: Would it be wise for the for the index parameter of the SFEX ocf script to have its unique flag set to 1 so that the crm tool (and others) would warn if one inadvertantly tried to create two SFEX resource primitives with the same index? Also, an example of the opposite, the Stonith/IPMI script, has parameters such as interface, username and password with their unique flags set to 1, causing erroneous warnings if you use the same interface, username or password for multiple IPMI stonith primitives, which of course if often the case in large clusters? When we designed it, we intended that Unique applies to the complete set of parameters - not to individual parameters. It's like a multi-part unique key. It takes all 3 to create a unique instance (for the example you gave). -- Alan Robertsonal...@unix.sh Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions. - William Wilberforce ___ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
