Feature to be implemented: how to upgrade the eventing operator(applicable to serving operator as well)

[houshengbo]

I am currently planning to implement a new reconciler called version-controller, plus a version controller CRD, to conduct the upgrade and even downgrade of the operator.

We need to have an official release as the foundational one, which starts to support the upgrade and downgrade. For example, if we pick the coming release 0.11.0 as the first one, the releases after 0.11.0, like 0.12.0, 0.13.0, etc, will support upgrading from 0.11.0 to the current version.

How long shall we keep the support of the old version upgrade? We can decide based on how frequent operator releases. Let's say 12 months. If we have 5 official releases: 0.11, 0.12, 0.13, 0.14 and 0.15, within a year. We need to document that we support upgrade and downgrade among any two of them. For 0.16, we may drop the upgrade support of 0.11(It could be other release, depending on if there are major CRD changes or manifest changes).

A PoC is implemented in PR #53. The upgrade process is as below:

• Install old version operator
• Create old CR, then old version of knative eventing is installed
• Install new version operator
• Create the version controller CR, specifying to upgrade or downgrade from which version to which version
• New CR is created, based on the old CR, by the the version controller reconciler
• Operator reconciler detects the new version CR and install the new version knative eventing
• Old CR clean-up(Not yet)
• Differences in manifests between versions(Not yet)

[aliok]

@houshengbo

I understand the reasoning behind the separate version controller.
It doesn't make sense to delete old CRs and create new CRs within the eventing operator. The operator is managing those resources, so, wouldn't make sense if operator creates the resources it manages.

I have some concerns around the new CR though:

apiVersion: operator.knative.dev/v1alpha1
kind: KEVersionController
metadata:
  name: ke-version-controller
  namespace: knative-eventing
spec:
  source-version: 0.11.0
  target-version: 0.10.0

1. This seems very imperative to me. Kubernetes resources should be declarative, not imperative. In a declarative resource, you would simply tell the state you want to have. Having the source-version in that regard is an anti-pattern. IMO, we should somehow get rid of source-version. The version controller should be able to figure out the source version by looking at annotations/labels etc.

2. Furthermore, to build on top of getting rid of the source-version, can we not get rid of the KEVersionController CRD entirely? IMO, the version controller could be responsible for a single version only. That means, it could only support upgrading from N-1 to N. And, if the source version found in annotations is not the N-1 version it is looking for, it could reject doing things.

cc @bbrowning @k4leung4

I will now watch the recording of the last Operations WG and see what you guys discussed.

[aliok]

For future reference, this ticket was closed as the discussion moved from here to Knative operator upgrade design doc