[Pacemaker] About the difference in handling of "sequential".

[Andrew Beekhof]

On 19 Feb 2014, at 10:48 am, Kristoffer Grönlund <kgronlund at suse.com> wrote:

> Hi everyone,
> 
> On Mon, 17 Feb 2014 10:54:29 +0900 (JST)
> renayama19661014 at ybb.ne.jp wrote:
> 
>> Hi Andrew,
>> 
>> I found your correction.
>> 
>> https://github.com/beekhof/pacemaker/commit/37ff51a0edba208e6240e812936717fffc941a41
>> 
>> Many Thanks!
>> Hideo Yamauchi.
>> 
>> --- On Wed, 2014/2/12, renayama19661014 at ybb.ne.jp
>> <renayama19661014 at ybb.ne.jp> wrote:
>> 
>>> Hi All,
>>> 
>>> There is difference in two between handling of "sequential" of
>>> "resouce_set" of colocation.
>>> 
> 
> I suspect that sequential for resource sets is still broken. I have
> been trying to figure out what the expected value of sequential is if
> not explicitly set on a resource_set. It seems like the answer is "it
> depends".
> 
> In pengine/constraints.c, unpack_order_set, sequential defaults to true
> if not set, via the following logic:
> 
>    /* line 1368 */
>    const char *sequential_s = crm_element_value(set, "sequential");
>    /* line 1384 */
>    if (sequential_s == NULL) {
>        sequential_s = "1";
>    }
>    sequential = crm_is_true(sequential_s);
> 
> However, in pengine/constraints.c(450), template_to_set, sequential
> defaults to false:
> 
>    /* line 495 */
>    /* Set sequential="false" for the resource_set */
>    crm_xml_add(*rsc_set, "sequential", XML_BOOLEAN_FALSE);
> 
> Am I reading this wrong, or is this on purpose?

It appears Yan did this on purpose.
The reason would likely be that this set is for use in a location constraint (not ordering or colocation).
And in particular, it is creating a fake set for resources using the same template - so there is no reason to think they should be ordered.

So: 
1. sequential should _always_ default to true
2. please report it to me if you find somewhere that does not
3. since template_to_set() is creating (copying) a fake set, there is no conflict with 1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140219/6f5a13c6/attachment-0003.sig>