Bug 2008298

Paul, any ideas as to what might be causing these issues on big endian platforms?  Thanks!

I was looking into the source code of the PMDA and I found some mishmash in type definition

In file "pmda.c" is the following code:

<snip pmda.c>
        { .m_desc = {
                PMDA_PMID(CLUSTER_DRBD_PEER_DEVICE, DRBD_PEER_DEVICE_CONNECTIONS_RECEIVED),
                PM_TYPE_U64, DRBD_PEER_DEVICE_INDOM, PM_SEM_INSTANT,
                PMDA_PMUNITS(0,0,1,PM_SPACE_KBYTE,0,PM_COUNT_ONE) } },
        { .m_desc = {
                PMDA_PMID(CLUSTER_DRBD_PEER_DEVICE, DRBD_PEER_DEVICE_CONNECTIONS_SENT),
                PM_TYPE_U64, DRBD_PEER_DEVICE_INDOM, PM_SEM_INSTANT,
                PMDA_PMUNITS(0,0,1,PM_SPACE_KBYTE,0,PM_COUNT_ONE) } },
        { .m_desc = {
                PMDA_PMID(CLUSTER_DRBD_PEER_DEVICE, DRBD_PEER_DEVICE_CONNECTIONS_PENDING),
                PM_TYPE_U32, DRBD_PEER_DEVICE_INDOM, PM_SEM_INSTANT,
                PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) } },
        { .m_desc = {
                PMDA_PMID(CLUSTER_DRBD_PEER_DEVICE, DRBD_PEER_DEVICE_CONNECTIONS_UNACKED),
                PM_TYPE_U32, DRBD_PEER_DEVICE_INDOM, PM_SEM_INSTANT,
                PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) } },
</snip>

however in "drbd.h" the data types are defined differently:
<snip drbd.h>
        uint32_t connections_received;
        uint32_t connections_sent;
        uint64_t connections_pending;
        uint64_t connections_unacked;
</snip>



Similarly for "ha_cluster.corosync.member_votes.node_id" merics, the datatypes differs in "pmda.c" resp. "corosync.h" files:

<snip pmda.c>
        { .m_desc = {
                PMDA_PMID(CLUSTER_COROSYNC_NODE, COROSYNC_MEMBER_VOTES_NODE_ID),
                PM_TYPE_U32, COROSYNC_NODE_INDOM, PM_SEM_INSTANT,
                PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) } },
</snip>

<snip corosync.h>
struct member_votes {
        uint32_t        votes;
        uint8_t         local;
        uint64_t        node_id;
};
</snip>


Due to some time constraints I have not tried yet to modify the code and test it with aligned data types, however IMO this is the core of the issue.
If I am mistaken, then feel free to correct me :-)

> If I am mistaken, then feel free to correct me :-)

Those are exactly the sorts of places to look at Jan.  The other place where things can go wrong is in the fetchCallback routine, where we copy into the pmAtomValue union field of each type - if the wrong field (ll, ull, l, ul) is used, truncation or sign extension can result.

Merged upstream (Paul, can you also review?  LGTM).

commit cf5aefe663ba48ef0848290a1d5b51850c336702
Author: Jan Kurik <jkurik>
Date:   Wed Sep 29 18:26:42 2021 +0200

    Fix of bz2008298
    
    Fix of datatypes for ha_cluster.corosync.member_votes.node_id and
    ha_cluster.drbd.connections_* metrics.

Hi,

Can confirm the changes look good to me also (ACK), not too sure how the mismatches happened there. Have double-checked each other type definition and they look correct.

Thanks Jan for the fix!

Cheers,

Paul

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (pcp bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1765