Proposed title of this feature request

Bring kepler operator to level 2

Description

As explained in the operator SDK, level 2 is related to providing seamless upgrades:

Seamless upgrades mean the upgrade is as easy as possible for the user. You should support seamless upgrades of both your operator and operand, these would normally go hand in hand, an upgrade of the operator would automatically ensure the instantiated resources for each CR are in the new desired state and which would upgrade your operand. Upgrade may also be defined in multiple ways, such as updating the software of the operand - and other internals specific to the application - such as schema migrations. It should be very clear what is upgraded when this takes place, and what is not.

List any affected packages or components.

• Kepler
• Kepler operator

Acceptance criteria

Upgrade of the managed workload

• Operand can be upgraded in the process of upgrading the Operator, or
• Operand can be upgraded as part of changing the CR
• Operator understands how to upgrade older versions of the Operand, managed previously by an older version of the Operator

Upgrade of the Operator

• Operator can be upgraded seamlessly and can either still manage older versions of the Operand or update them
• Operator conveys inability to manage an unsupported version of the Operand in the status section of the CR

Guiding questions to determine Operator reaching Level 2

1. Can your Operator upgrade your Operand?

1. Does your Operator upgrade your Operand during updates of the Operator?

1. Can your Operator manage older Operand version versions?

1. Is the Operand upgrade non disruptive?

1. If there is downtime during an upgrade, does the Operator convey this in the status of the CR?