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)
pgpZzOgUePCnX.pgp
Description: PGP signature
_______________________________________________ Developers mailing list Developers@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/developers
