A clarification on the correct usage of the Policy Edge nodes API:
The policy edge nodes represent the member index within the edge cluster to which edge / transport nodes connect. The policy edge nodes, as referenced by path "
/infra/sites/<site-id>/enforcement-points/<enforcementpoint-id>/edge-clusters/<edge-cluster-id>/edge-nodes/<edge-node-id>", should not be mistaken for the transport nodes or edge nodes themselves. The user may choose to replace an attached edge node with a different edge node at a given index (represented by the policy edge node) within an edge cluster. In such a case, the same policy edge node with its original path will refer to the new edge node with a different UUID.
The procedure to fetch the transport node that is represented by a given policy edge node path
The UUID of the attached edge node (or transport node) can be fetched from the
nsx_id property of the policy edge node, while the member index within the cluster can be fetched from the
member_index property. The path of the policy edge node which has the
member_index or the
nsx_id matching the required values can be used in consuming services.
Any attempt to remove an edge node from an edge cluster and then re-add it back to the same cluster at a different index may cause issues when being referenced through the policy edge nodes. The edge nodes need to be removed from NSX and then added back, this ensures a different UUID is generated to represent them, before placing them back in the same edge cluster.
Note: The format of the internally generated path of the policy edge node objects will be changed to represent the index (instead of using the UUID of the first edge node to attach to that index) in future NSX releases. This is primarily for these reasons:
- To simplify the workflow for removing and re-adding an edge node back to the same edge cluster
- To reduce the confusion caused by the use of the transport node UUID in the path of the policy edge node