Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(4/5) [nexus] Consider Affinity/Anti-Affinity Groups during instance placement #7446

Merged
merged 63 commits into from
Feb 24, 2025

Conversation

smklein
Copy link
Collaborator

@smklein smklein commented Jan 30, 2025

Pulled out of #7076

Modifies the instance placement logic to consider affinity and anti-affinity groups.
This is still technically "internal-only", because the HTTP endpoints to create affinity groups are, as of this PR, still unimplemented.

Base automatically changed from affinity-db-crud to main February 21, 2025 21:42
@smklein smklein enabled auto-merge (squash) February 24, 2025 20:56
@smklein smklein merged commit 057851b into main Feb 24, 2025
17 checks passed
@smklein smklein deleted the affinity-instance-integration branch February 24, 2025 23:07
smklein added a commit that referenced this pull request Feb 25, 2025
…#7447)

Pulled out of #7076

This PR is a partial implementation of RFD 522

It adds:
- Affinity and Anti-Affinity groups, contained within projects. These
groups are configured with a **policy** and **failure domain** can
currently contain zero or more **members**. Affinity groups attempt to
co-locate members, anti-affinity groups attempt to avoid co-locating
members.
- **Policy** describes "what to do if we cannot fulfill the co-location
request". Currently, these options are "fail" (reject the request) or
"allow" (continue with provisioning of the group member regardless).
- **Failure Domain** describes the scope of what is considered
"co-located". In this PR, the only option is "sled", but in the future,
this may be expanded to e.g. "rack".
- **Members** describe what can be added to affinity/anti-affinity
groups. In this PR, the only option is "instance". RFD 522 describes how
"anti-affinity groups may also contain affinity groups" -- which is why
this "member" terminology is introduced -- but it is not yet
implemented.
- (anti-)Affinity groups are exposed by the API, through a CRUD
interface
- (anti-)Affinity groups are considered during "sled reservation", where
instances are placed on a sled. This is most significantly implemented
(and tested) within `nexus/db-queries/src/db/datastore/sled.rs`, within
#7446

Fixes #1705
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants