serving-operator
serving-operator copied to clipboard
knative
Operator should fail if attempting to upgrade knative from N to N+2 or greater
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.
Interesting question - how does one know what version of knative is currently installed? AFAIK we don't have anything from serving that says this
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 [email protected] 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 https://github.com/knative/serving-operator/issues/3?email_source=notifications&email_token=AB4XENZNHX6JYJSPKKOMYB3PZ7EJRA5CNFSM4HUMQVY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXNUS5Y#issuecomment-500910455, or mute the thread https://github.com/notifications/unsubscribe-auth/AB4XEN4UNG3JCGGRHHRKNWLPZ7EJRANCNFSM4HUMQVYQ .
-- Evan Anderson [email protected]
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.
Possibly relevant: https://groups.google.com/d/msg/operator-framework/NkC43XyMqWc/iV4NeO0ZBQAJ
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.
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.
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.
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?
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.
fwiw: jumps by two are tested nowhere. Serving only tests upgrading from N-1.
