(5/5) [nexus] Implement Affinity/Anti-Affinity Groups in external API #7447
Conversation
|
Perhaps it would be useful to surface whether a member is presently satisfying an affinity request. I think I'd be interested to click into an affinity group and see its current affinity status. Or return a list of members that are currently failing to satisfy an affinity request. Then, the next question might be; how do I fix it? Which I presume in most cases is, stop and start the instance ... which the user can do. And occasionally, reduce overall utilization / wait for software update to finish / add more capacity – which the user might not be privy to. |
I filed #7614 to track this. I think it's a totally reasonable request.
This is more subtle - we could also presumably automatically resolve this in some cases, by live-migrating, but doing so feels a little opinionated. This may justify an additional policy for affinity groups, beyond the "policy = allow" that we currently have -- maybe we want "policy = allow, but if we can't fulfill it, keep it where it is" vs "policy = allow, and if we can't fulfill it now, move it later". |
Pulled out of #7076
This PR is a partial implementation of RFD 522
It adds:
nexus/db-queries/src/db/datastore/sled.rs, within (4/5) [nexus] Consider Affinity/Anti-Affinity Groups during instance placement #7446Fixes #1705