[ClusterLabs] Antw: [pacemaker] Discretion with glib v2.59.0+ recommended
Ulrich.Windl at rz.uni-regensburg.de
Mon Jan 21 08:17:06 UTC 2019
IMHO it's like in Perl: When relying the hash keys to be returned in any
particular (or even stable) order, the idea is just broken! Either keep the
keys in an extra array for ordering, or sort them in some way...
>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 18.01.2019 um 20:32 in
<20190118193209.GE16775 at redhat.com>:
> It was discovered that this release of glib project changed sligthly
> some parameters of how distribution of values within hash tables
> structures work, undermining pacemaker's hard (alas unfeasible) attempt
> to turn this data type into fully predictable entity.
> Current impact is unknown beside some internal regression test failing
> due to this, so that, e.g., in the environment variables passed in the
> notification messages, the order of the active nodes (being a space
> separarated list) may be appear shuffled in comparison with the long
> standing (and perhaps making a false impression of determinism)
> behaviour witnessed with older versions of glib in the game.
> Variations like these are expected, and you may take it as an
> opportunity to fix incorrect order‑wise (like in the stated case)
> More serious troubles stemming from this expectation‑reality mismatch
> regarding said data type cannot be denied at this point, subject of
> further investigation. When in doubt, staying with glib up to and
> including v2.58.2 (said tests are passing with it, though any later
> v2.58.* may keep working "as always") is likely a good idea for the
> time being.
> Jan (Poki)
More information about the Users