-
Notifications
You must be signed in to change notification settings - Fork 3
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
base: main
Are you sure you want to change the base?
Allow image id or selector #23
Conversation
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. |
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. |
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.