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

Allow image id or selector #23

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

nsricardor
Copy link
Contributor

Downstream services (such as Slonk) may have specific requirements and logic for selecting a server image. This PR enhances the compute service, enabling a compute workload pool to either use a specific image ID or apply an image selector.

@spjmurray
Copy link
Member

My initial thoughts are from an operational, not technical, perspective. If we allow selectors on the CRD, then any service restart may suddenly involve a new image being selected, that will then lead to upgrades that are out of control and lead to end user downtime/disruption. Having the selection logic in the API makes a stable, point in time, decision that will survive any restarts.

Perhaps what we are really after is a hybrid solution where the API chooses an image, and that's gospel. The CRD can remember the image selector, and that can be consumed by a monitor service to perform upgrades when we or the customer allows them. It's mostly the same idea, just with more control!

Now, this does remind me, a cluster update in the API needs to preserve an existing image ID, again. to not trigger things that weren't asked for. The kubernetes API does a similar kind of thing when it chooses flavours iirc as a reference.

@nsricardor
Copy link
Contributor Author

nsricardor commented Dec 12, 2024

The implementation is quite close to your suggestions/thoughts. The Selector stored in the CRD is primarily used to remember the user input on the POST request, ensuring that subsequent GET requests return consistent results. This approach prevents issues like broken or inconsistent responses if the image, for example, is deleted.

The API is still responsible for selecting the image based on the selector (if provided) and storing the resulting image ID in the CRD. As a result, the provisioner always uses the image ID (whether provided by the user or derived from the selector) and never the image selector itself, so the image used is stable even if the controller restarts.

As for your last point, some adjustments might be necessary. The chooseImage function is re-executed during a PUT request, which could potentially lead to a different image ID being selected.

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