[Pacemaker] Pacemaker-1.1.4, when?

Andrew Beekhof andrew at beekhof.net
Mon Nov 29 14:27:33 EST 2010


On Mon, Nov 29, 2010 at 10:47 AM, Keisuke MORI
<keisuke.mori+ha at gmail.com> wrote:
> Hi Andrew,
>
> 2010/11/15 Andrew Beekhof <andrew at beekhof.net>:
>> If someone can fix the patch so that the regression tests pass I'll
>> apply it, but I won't have any time to work on it for at least a few
>> weeks.
>
> I've been trying to write a patch for this, and it almost works fine,
> but I found that it is very hard to make it 100% compatible with the
> latest glib2 because of the implementation difference of GHashTable
> between glib2-2.12(RHEL5) and glib2-2.26.
>
> The attached patch almost works well, except that the regression tests
> fails on 3 items regarding to the utilization test cases.
> (the patch and the failed diff are attached)
> ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
>  Test utilization-order1:       Utilization Order - Simple
>      * FAILED:  xml-file changed
>  Test utilization-order2:       Utilization Order - Complex
>      * FAILED:  xml-file changed
>  Test utilization-order3:       Utilization Order - Migrate
>      * FAILED:  xml-file changed
>
>      * ERROR:   Results of 3 failed tests (out of 293) are in
> ./.regression.failed.diff....
> ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
>
> It seems only the difference of the processing order of the nodes at
> pengine/native.c:native_internal_constraints().
>
> This difference comes because GHashTable is implemented differently,
> where glib2-2.12 uses a linked list for iteration, while glib2-2.26 no
> longer uses a linked list and just go through an array.
>
>
> I think that the possible options that we can take are:
>
> 1) Apply the patch and just ignore the errors on RHEL5
>   - as long as they're considered harmless.

Given the nature of the differences, they can be safely ignored.
The relative ordering of actions in the raw XML has little/no affect
on the cluster.

So I think this our best approach.

The implementation of g_hash_table_nth_data() looks a little scary,
but presumably it works sufficiently well for the PE's iterative
usage.
Applying to 1.1 now.

Good work!

> 2) Sort the node list when creating the graph of the utilization
>   - although it may cause another performance penalty.
> 3) Revert using GList for the node list
>   - if the node lookup is not the major factor of the performance issue.
>
> It's all up to you.
>
> Hope it helps.
> Thanks,
>
> Keisuke MORI
>
>>
>> On Mon, Nov 15, 2010 at 2:59 AM, nozawat <nozawat at gmail.com> wrote:
>>> Hi Andrew and Nikola,
>>>
>>>   Oneself carried out regression test, too, and an error was given equally.
>>>
>>> Regards,
>>> Tomo
>>>
>>>
>>> 2010/11/12 Nikola Ciprich <extmaillist at linuxbox.cz>
>>>>
>>>> (resent)
>>>> 1.1.4 with new glib2: tests pass smoothly
>>>> 1.1.4 + patch and older glib2 - all tests are segfaulting...
>>>>
>>>> ie:
>>>> Program terminated with signal 11, Segmentation fault.
>>>> #0  IA__g_str_hash (v=0x0) at gstring.c:95
>>>> 95    guint32 h = *p;
>>>> (gdb) bt
>>>> #0  IA__g_str_hash (v=0x0) at gstring.c:95
>>>> #1  0x00007fe087bb6128 in g_hash_table_lookup_node (hash_table=0x1390ec0,
>>>> key=0x0, value=0x13a3b00) at ghash.c:231
>>>> #2  IA__g_hash_table_insert (hash_table=0x1390ec0, key=0x0,
>>>> value=0x13a3b00) at ghash.c:336
>>>> #3  0x00007fe089367953 in convert_graph_action (resource=0x13a30a0,
>>>> action=0x139cb80, status=0, rc=7) at unpack.c:308
>>>> #4  0x000000000040362a in exec_rsc_action (graph=0x1394fa0,
>>>> action=0x139cb80) at crm_inject.c:359
>>>> #5  0x00007fe089368642 in initiate_action (graph=0x1394fa0,
>>>> action=0x139cb80) at graph.c:172
>>>> #6  0x00007fe08936899d in fire_synapse (graph=0x1394fa0,
>>>> synapse=0x139ba60) at graph.c:204
>>>> #7  0x00007fe089368dbd in run_graph (graph=0x1394fa0) at graph.c:262
>>>> #8  0x000000000040428f in run_simulation (data_set=0x7fff712280a0) at
>>>> crm_inject.c:540
>>>> #9  0x000000000040632a in main (argc=9, argv=0x7fff71228308) at
>>>> crm_inject.c:1148
>>>>
>>>>
>
>
> --
> Keisuke MORI
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at 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
>
>




More information about the Pacemaker mailing list