[Feature] Upgrade available endpoint / dependent upgrades #363
Comments
LalatenduMohanty
pushed a commit
to LalatenduMohanty/operator-controller
that referenced
this issue
Dec 19, 2024
* ⚠ Status condition clean up [RFC: ClusterCatalog Status Conditions](https://docs.google.com/document/d/1Kg8ovX8d25OqGa5utwcKbX3nN3obBl2KIYJHYz6IlKU/edit) implementation. Closes [363](operator-framework#363) Closes [364](operator-framework#364) Closes [365](operator-framework#365) Co-authored-by: Ankita Thomas <[email protected]> Co-authored-by: Anik Bhattacharjee <[email protected]> * Handle new finalizer code Signed-off-by: Todd Short <[email protected]> * Set StatusUpdated to true for finalizers Signed-off-by: Todd Short <[email protected]> --------- Signed-off-by: Todd Short <[email protected]> Co-authored-by: Ankita Thomas <[email protected]> Co-authored-by: Todd Short <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
In ACS we have a client<>server architecture in which our server should always be ahead or equal in its version of the clients.
Currently OLM auto-upgrades upgrade upgrade the client faster than the server, especially in our cloud environments this happens currently and need to support forward-compatible clients.
Solution
Expose an endpoint on the operator which OLM can query which marks an operator as "ready for upgrade". In this scenario, our operator can implement dependent upgrades: "Only upgrade client when central XYZ".
The endpoint can also expose the version the operator should upgrade to.
Example response:
The text was updated successfully, but these errors were encountered: