[ClusterLabs] ftime-imposed problems and compatibility going forward (Was: Final Pacemaker 2.0.3 release now available)

[Jan Pokorný]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20191126/7e8b1cd2/attachment.sig>