...

1. HA Group membership is obtained from the node's hagroup resource in the Exchange. The existing support obtains this info from an internal representation of the node (in the code it's called the producer policy). The HA Group definition should be removed from this internal representation.
2. The existing HA support assumes that ALL services running on a node in an HA Group are supposed to be running on ALL nodes in the group. This assumption is no longer true in this design. The Agbot needs to perform some additional checking (before attempting a rolling upgrade) that the service being upgraded is intended to be running on all nodes in the group.

Exchange Changes API

When new resources are added to the system, the scope of change notification of those resources needs to be defined. The Agbot needs to be made aware of hagroup resource creation/update/deletion. Nodes do not need to be aware.

User Experience

<Describe which user roles are related to the problem AND the solution, e.g. admin, deployer, node owner, etc. If you need to define a new role in your design, make that very clear. Remember this is about what a user is thinking when interacting with the system before and after this design change. This section is not about a UI, it's more abstract than that. This section should explain all the aspects of the proposed feature that will surface to users.>

...

<Describe and new/changed/deprecated APIs, including before and after snippets for clarity. Include which components or users will use the APIs.>

The following new APIs are introduced in this design. Any user in an org can use these APIs (or corresponding CLI). Org users can only create/modify/delete ha groups containing nodes that the user has permission to modify.

The HAGroup object schema

...