Design for upgrade #38
Description
Describe the feature you'd like to have.
We need to have a design for:
- How the operator will handle upgrades of itself
- How the operator will perform upgrades on the Gluster cluster
What is the value to the end user? (why is it a priority?)
Users expect to be able to deploy the latest version of GCS and have the system upgrade automatically. This includes proper sequencing of the upgrade process and multi-step upgrades where necessary. The user needs to be able to set the version and walk away because they will not typically have the in-depth knowledge to perform a manual system upgrade
How will we know we have a good solution? (acceptance criteria)
- If operator version n is running in the cluster, operator version n+1 may be deployed at any time
- The operator has the ability to upgrade underlying components from any previous stable release of the operator
Additional context
The requirements above come from the behavior of OLM. OLM upgrades the operator by stepping through its versions. However, it does not have the ability to wait for underlying resources to be upgraded. As soon as the operator's Deployment becomes ready, it is subject to upgrade if a new version is available. This means the current version of the operator may see an arbitrarily old version of the Gluster cluster and must be able to upgrade it.