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 Robertson<al...@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/
