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

Introduce size reservations for projects. #484

Merged
merged 23 commits into from
Jan 9, 2024
Merged

Conversation

Gerrit91
Copy link
Contributor

@Gerrit91 Gerrit91 commented Dec 28, 2023

I think we once discussed this in the past but for some reason we said it's impossible to implement. I can't remember why anymore, so here is a suggestion.

This allows reserving machines of a specific size for projects in the the allocation process.

This feature can be important for the operator to have some spare machines available, e.g. for updating Gardener Seed clusters while preventing regular users to allocate the last machines available in a partition. There are also use-cases where certain customers want to use a certain machine size exclusively, which can also be realized with this approach.

Unfortunately, just like the rack spreading, this algorithm is best-effort only. It can be tricked by heavy parallelization because we do not run the findMachineCandidate function in sync. And of course for the case when allocations were already made before the reservations were added, this is also best-effort only.

Possible extensions:

  • Show reserved machines in partition capacity
  • Show operator when reservations are ineffective (e.g. due to a project that was deleted), can be implemented client-side

This allows reserving machines of a specific size for projects in the the allocation process.

This is feature can be important for the operators to have some spare machines available, e.g. for updating Gardener Seed clusters while preventing regular users to allocate the last machines available in a partition. There are also use-cases where certain customers want to use a certain machine size exclusively, which can also be realized with this approach.
Copy link
Contributor

@majst01 majst01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea, great.
Both open points you already pointed out should be implemented before merging

cmd/metal-api/internal/datastore/machine.go Outdated Show resolved Hide resolved
cmd/metal-api/internal/metal/size.go Outdated Show resolved Hide resolved
@Gerrit91
Copy link
Contributor Author

Gerrit91 commented Jan 8, 2024

References #134.

@Gerrit91 Gerrit91 marked this pull request as ready for review January 8, 2024 13:03
@Gerrit91 Gerrit91 requested a review from a team as a code owner January 8, 2024 13:03
@Gerrit91 Gerrit91 requested a review from majst01 January 8, 2024 13:03
@Gerrit91 Gerrit91 merged commit 2bf3237 into master Jan 9, 2024
2 checks passed
@Gerrit91 Gerrit91 deleted the size-reservations branch January 9, 2024 10:00
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.

2 participants