Change Details

See https://github.com/ClusterLabs/pacemaker/pull/3301#discussion_r1439629079.

See https://github.com/ClusterLabs/pacemaker/pull/3301#discussion_r1439629079. "server" has always been used in the remote RA's metadata, so that's what users are accustomed to. However, "addr" is used everywhere within Pacemaker. "server" is used only as an alternate name for the parameter within the remote RA. Getting rid of "addr" causes a change to the config hash, so if we go that route, we have to wait until a compatibility/rolling-upgrade break. Deprecating or dropping "server" is arguably disruptive, so that can also wait. However, it should be noted that "addr" is **also** documented: we use the "remote-addr" meta-attribute, not the "remote-server" meta-attribute. So there is public precedent for the "addr" terminology, and it be reasonable to shift everything to "addr" at a break IMO. No issue with shifting everything to "server" as long as we're consistent.

See https://github.com/ClusterLabs/pacemaker/pull/3301#discussion_r1439629079. "server" has always been used in the remote RA's metadata, so that's what users are accustomed to. However, "addr" is used everywhere within Pacemaker. "server" is used only as an alternate name for the parameter within the remote RA. Getting rid of "addr" causes a change to the config hash, so if we go that route, we have to wait until a compatibility/rolling-upgrade break. Deprecating or dropping "server" is arguably disruptive, so that can also wait. However, it should be noted that "addr" is **also** documented: we use the "remote-addr" meta-attribute, not the "remote-server" meta-attribute. So there is public precedent for the "addr" terminology, and it be reasonable to shift everything to "addr" at a break IMO. No issue with shifting everything to "server" as long as we're consistent.