[ClusterLabs Developers] Heads up for potential Pacemaker API change

[Jan Pokorný]

On 01/11/18 16:41 -0500, Ken Gaillot wrote:
> I ran into a situation recently where a fix would require changing
> libpe_status's pe_working_set_t data type.
> 
> I ran into a situation recently where a fix would require changing
> libpe_status's pe_working_set_t data type.
> For most data types in the Pacemaker API, we require (usually by
> documented policy rather than code) that library-provided
> constructors be used to allocate them. That allows us to add new
> members at the end of structs without existing applications needing
> to be rebuilt.

Note this is not a panacea unless the struct definition is moved to
private only header and the respective pointers are all what's exposed
in public API.  So currently the client programs can just as well get
broken on future struct expansion (imagine an array of structs).

> A bit of searching turned up only sbd, fence-virt, and pacemaker-mgmt
> using libpe_status (and I'm not sure pacemaker-mgmt is still active).
> But I'm curious if anyone has custom applications that might be
> affected, or has an opinion on the problem and solution here.

With fence-virt (never occurred to me that it ever had a pacemaker
backend!) was inevitably broken since 1.1.8 at latest since the
renaming of "new_ha_date" function:
https://github.com/ClusterLabs/pacemaker/commit/9d2805ab00a117ddf3d1c67e2383c7778a81230f#diff-917f93b8d6f4434bbf21cd5b8240895cL1044
hence I bet it was never actively used (HA cluster of virtual nodes
spread across clustered hypervisors and/or even mixed topologies?
is the idea worth reviving?).

-- 
Nazdar,
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/developers/attachments/20181102/89892dd4/attachment-0002.sig>