Handling upgrades and downgrades
As Operator developers, we are concerned with the versioning of two primary applications: the Operand and the Operator itself. Seamless upgrades are also the core feature of a Level II Operator, which we have decided is our goal for the initial Operator design. For that reason, we must ensure that our Operator can handle upgrades for both itself and the nginx Operand. For our use case, upgrading the Operand is fairly straightforward. We can simply pull the new image tag and update the Operand Deployment. However, if the Operand changed significantly, then the Operator may also need to be updated in order to properly manage the new Operand version.
Operator upgrades arise when changes to the Operator code, API, or both need to be shipped to users. Operator Lifecycle Manager (OLM) makes upgrading Operators with newer released versions easy from a user standpoint. The Operator's ClusterServiceVersion (CSV) allows developers to define specific upgrade...
