This goal of this research spike is to research how we can get to an Operator Level 2: Seamless Upgrades

Doing updates for most applications is usually fairly straight forward. The operator will perform any requires steps to bring the resources it controls to the next version. This may include updating custom resources, performing database transactions, etc 

With Kogito, this gets a bit tricky since we don't always control the runtime pieces.

For instance, lets say we are on version 'A' of Kogito. We have deployed the Kogito Operator and data index. A user deploys a Kogito runtimes image that they build using version 'A' of Kogito.

When we move to version 'B' of Kogito, we can update the Operator and components such as data index to version 'B', but we can't rebuild the Kogito runtime, it will still be the same version that was built using version 'A'

We need to figure out how we can handle these type of updates and what happens if a runtime of version 'A' doesn't work with the other components of version 'B'.

We also support artifact builds of runtimes, such as uploading a dmn/bpmn file. For these types of runtimes, we should be able to do a rebuild then a newer version during the update process.

As a research spike, the goal of this task is not to solve this solution or work on an implementation. The goal is to do research, investigate, engage with the rest of the team and have a discussion around what our possible options are. The deliverable for this task is an agreement and plan for implementation