Operator should fail if attempting to upgrade knative from N to N+2 or greater

[trshafer]

When the user upgrades the operator, the operator should evaluate the current version of knative and if the operator is unable to update the version one at a time, then the operator should fail the upgrade.

[greghaynes]

Interesting question - how does one know what version of knative is currently installed? AFAIK we don't have anything from serving that says this

[evankanderson]

There is actually an annotation in all the yaml files which gets snapped with the release version.

…

On Tue, Jun 11, 2019 at 9:04 AM Gregory Haynes ***@***.***> wrote: Interesting question - how does one know what version of knative is currently installed? AFAIK we don't have anything from serving that says this — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=AB4XENZNHX6JYJSPKKOMYB3PZ7EJRA5CNFSM4HUMQVY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXNUS5Y#issuecomment-500910455>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4XEN4UNG3JCGGRHHRKNWLPZ7EJRANCNFSM4HUMQVYQ> .

-- Evan Anderson <argent@google.com>

[jcrossley3]

There is a label in all the resources, e.g. https://github.com/openshift-knative/knative-serving-operator/blob/v0.6.0/deploy/resources/knative-serving-0.6.0.yaml#L6
But because it was set to "devel" in the 0.5.2 manifest, we used this instead: https://github.com/openshift-knative/knative-serving-operator/blob/master/version/version.go#L1
The operator set KnativeServing.Status.Version to the value in the second file after applying the first file.
So whenever upstream cut a new release, we'd update both files.

[jcrossley3]

Possibly relevant: https://groups.google.com/d/msg/operator-framework/NkC43XyMqWc/iV4NeO0ZBQAJ

[trshafer]

/assign cynocracy

[jcrossley3]

I'm curious why we want to fail an upgrade to N+2 or greater. What's the harm in doing so? Just trying to be clear about the justification for this issue.

[Cynocracy]

Personally, I don't think we should fail, but rather follow an upgrade path that's been tested.

I don't think we should allow customers using the Operator to take upgrade paths that are untested and thus potentially unsafe.

[trshafer]

It was inspired from the 0.6 -> 0.9 (I think) upgrade. It was a migration from clusterroute to route IIRF. Users needed to migrate from 0.6 -> 0.7 or 0.8 before going to 0.9.

[jcrossley3]

I'd like to be able to say something like this: for any version X of the operator, we'll support upgrades from the last N releases of the operand. I think serving mandates N=4 (where is that doc'd, btw?) but that would mean the 0.9 operator would've needed to be able to update a 0.6 operand to 0.8 before installing 0.9. Is that reasonable?

[trshafer]

0.6->.8 and then .9 is probably fine. or if jumping from 0.6 -> 0.12 then have 0.6 -> 0.8 -> 0.10 -> 0.12.

[markusthoemmes]

fwiw: jumps by two are tested nowhere. Serving only tests upgrading from N-1.