Upgrade scenario for knative

[j-zimnowoda]

The knative-serving version is hardcoded in otomi-core

The knative operator requires that an knative-serving upgrade is done one by one.
It means that we can't upgrade from 0.16 to 0.19.

It is problematic because each customer/cluster can use different knative-serving, thus in some case an admin is not able to upgrade it without modifying otomi-core.

I see two solutions:

1. To expose knative-version to values repo, so the admin can upgrade the version by chaining the values.
2. to release otomi-core with each knative version and then to upgrade otomi-core one by one.

And what do you think about that?

[j-zimnowoda]

The more I think about it the more I like solution 2) The otomi delivers a containers platform not single apps. Therefore core apps versions should not exposed to ensure compatibility with other parts.

[Morriz]

Given these facts:

• knative version is tied to k8s version
• we don't support upgrading with increments involving 2 minor k8s releases

We can conclude that:

• every minor k8s upgrade involves at max one knative version upgrade
• an administrator MUST choose an otomi version that is at maximum one k8s version higher, and only then will the deployment become eligible for the next upgrade.

Therefor I conclude this to be a non-issue, and wish to not spend more time on this. If there are REAL problems on our horizon I would like to know about them. But this is not one

[j-zimnowoda]

Your conclusion is made on assumptions that a user knows about compatibility between k8s version and otomi version.
That's not the case right now. Therefore

• we need to provide this information to the users.

I agree that iterative upgrade scenario makes sense and can protect us against breaking changes.

• we need to describe it in https://otomi.io/docs/upgrades

[Morriz]

I asked Sebastiaan to add it to a new section under “docs/lifecycle-management/versioning”

[j-zimnowoda]

Unfortunately, I can't find that document :(

[Morriz]

Let's not worry about this any longer. We provide documentation and release notes describing versions deployed, and we can provide a sample knative service, but it is up to the devs to read up on knative@version.