On 25/11/19 20:32 -0600, Ken Gaillot wrote: > The final release of Pacemaker version 2.0.3 is now available at: > > https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-2.0.3
For downstream and individual builders of the codebase ====================================================== ... let it be known that we suffered some late moment difficulties imposed by the fact that upcoming glibc (allegedly targeting v2.31) will make it even more tough to use ftime(3) function (otherwise marked deprecated for ages, including in POSIX specifications) in the face our purposefully imposed -Werror, turning the respective warning into an error and consequently failing the out-of-the-box build process. Due to this timing, the effect of the fix was kept minimal for the time being, mostly allowing for a smooth opt-in continuity down the road. While it opens a broader topic of using anything but monotonic time for measuring/supervising the timeouts being the killer of naturally expected HA robustness on its own (for that, we currently do not have a capacity for a full detail review, with one of the outcomes being either ceasing the support for platforms where such a time measuring is unattainable, for good, altogether, or at least enforcing the build conductors to willingly accept the responsibility with something like an extra HA_I_TOLERATE_RISKY_TIMERS=1 environment variable required in the build environment [*1]), there are two things you may want to pay attention to with said tagged v2.0.3 release: A. in case you run to said out-of-the-box build issues due to ftime(3) invocation (currently, is known to happen, e.g., with Fedora Rawhide), the workaround is along the lines of env CPPFLAGS="$CPPFLAGS -UPCMK_TIME_EMERGENCY_CGT" ./configure B. the same trick, possibly in a slightly extended form env CPPFLAGS="$CPPFLAGS -UPCMK_TIME_EMERGENCY_CGT" \ ac_cv_header_sys_timeb_h=no ./configure will allow you to check _forward_ compatibility --- statically in build-time and possibly even in run-time when the respective log-related behaviours of pacemaker_remoted get tested afterwards --- with a switch to a state where ftime(3) is dropped (limited to cases whereby `configure` script will report: `checking whether CLOCK_MONOTONIC is declared... yes`); it is hence strongly recommended to test that in particular variations of OS & libc of interest _ahead of time_ to avoid bad surprises in 2.0.4+ (especially if release candidates chronically miss the interest of some minor combos that are possibly under compatibility risks the most[*2]) [*1] one more reason _not_ to make any compromises regarding fencing at this current potentially suboptimal status quo, see the other sub-thread by Digimer [*2] speaking of that, would be nice to receive some feedback on the usefulness of these offically marked release candidatate for early testing, and obtain thus rough stats how these get used at all, since I am pessimistic these would get as much attention as we would ideally hope for Full context at the respective PR (especially last two comments): https://github.com/ClusterLabs/pacemaker/pull/1943 Hope this helps to get ready for the next release; feedback, if any, can influence the direction in this matter. -- Jan (Poki)
pgpkVnXfA9Fo2.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/