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/

Reply via email to