A great idea by @jgallagher .
We already allow changing trust quorum config in case of a misconfiguration. We should also allow changing the RackNetworkConfig before we stop the join service from running, so that we don't have to clean-slate if a mistake was made in configuration.
However, we do need to know when to stop accepting changes. The best signal we can use here is when Nexus can actually communicate with the started-sled agent running the multirack join service over the underlay network.
The current plan is this:
- Add a watch channel (or some other notifier) that gets passed into the multirack join service
- Allow changes until the notification is seen
- Provide a sled-agent API that nexus can hit to indicate that it has seen the sled-agent in inventory. This can be part of rack adoption.
- Trigger the notification when sled-agent receives the request. Since the multirack join service runs in the same process as sled-agent, this works great.
We'll implement the sled-agent side as part of this PR and then use the API when we add the rack adoption API.
A great idea by @jgallagher .
We already allow changing trust quorum config in case of a misconfiguration. We should also allow changing the
RackNetworkConfigbefore we stop the join service from running, so that we don't have to clean-slate if a mistake was made in configuration.However, we do need to know when to stop accepting changes. The best signal we can use here is when Nexus can actually communicate with the started-sled agent running the multirack join service over the underlay network.
The current plan is this:
We'll implement the sled-agent side as part of this PR and then use the API when we add the rack adoption API.