OLM V1 Upgrade UXs

[awgreene]

OLM V0 offered support for:

• channels
• Allowing bundles to define replaces, skips, and skip-range values

Right now, OLM V1 is being designed to:

• Support OLM V0 upgrade concepts
• Allow users to ignore the OLM V0 upgrade concepts

We should consider any other upgrade UXs that we might want to support. One usecase we discussed in the Community Meeting on June 27, 2023 was decoupling upgrade edges from channel memberships.

[joelanford]

Copying the text of a comment I left on a related PR: #274 (comment)

---

@perdasilva and I chatted, and I think we got onto the same page? (correct me if I'm wrong)

• For each bundle, make a variable. The bundle variable does not carry any channel information within itself. The bundle carries its identity (the image ref?)
• For each channel, make a variable. A channel variable knows the bundles that are the members of its channel, so it can generate a dependency constraint like C = DependsOn(B4, B3, B2, B1), where B* are the IDs of the bundle variables that correspond to the channel members. If the user specified this channel, the channel variable is marked as mandatory (i.e. X = Mandatory(C)).

These above two items would essentially replicate our existing logic. But this model could be extended to support other kinds of user-defined channel selection, where -- for example -- set-based choices can be made (e.g. in channels 1 and 2, but not 3, in which case 1 and 2 are mandatory and 3 is prohibited.

Then, when we move on to honoring the upgrade edges, the $thing that defines the upgrade edges (in our current FBC model, a channel) has a variable source that (a) figures out the variable ID corresponding to the bundle that is installed, and (b) figures out the variable IDs of all of the possible successors of the currently installed variable ID. So if B1 is installed, and B2 and B3 are both successors of B1, then you'd end up with U = DependsOn(B3, B2, B1), Y = Mandatory(U) -> translation: "I can upgrade to B3 or B2, and I can also stay on the current version, B1"

Getting back to the comments:

I think the channel matters because, without it, you could upgrade to a bundle in a different channel (e.g. out of stable) and it might put the user on an upgrade path that they don't necessarily want to have.

It needs to be possible to upgrade to a different channel though. It doesn't matter what channel a bundle was installed from. What matters is:

• What channel does the user want now?
• Is there an upgrade edge from the currently installed version to a bundle in the channel that I want now? It doesn't and shouldn't matter if the currently installed bundle is also in the channel I want.

In fact, the channel of the currently installed bundle doesn't even make sense, really. Consider this fairly standard scenario:

• We're resolving an Operator with just spec.package: foo
• Package foo has two channels, c1 and c2, each containing bundle bar
• We resolve bar. Hooray!

Which channel did we resolve bar from? Conceptually channel had no bearing on the resolution. Why would we arbitrarily (from the user's perspective) pick a channel at this point and then use that in future resolutions?

If, at a later point, a new catalog shows up that has channel c3 with a single member baz and baz skips bar, we absolutely want a user to be able to be upgraded to baz if they specify channel: c3 or if they don't specify a channel at all.

TL;DR:

What this all boils down to, IMO, is that our current model for channels serve two purposes:

1. Operator author-defined subset of bundles in a package (which can be used by a cluster admin to filter resolution)
2. As a provider of operator author-defined upgrade edges (which are used by default during resolution to allow only certain transitions)

These are disjoint concerns, in my opinion. I think we should model set-based channel membership filtering completely separate from upgrade edge filtering. With the current FBC schemas, they both originate from the same place, but that doesn't mean we need to co-mingle the implementations.

I could see a future where FBC schemas look like this:

---
schema: olm.channel.v2
entries:
- bundle1
- bundle2
- bundle3
---
schema: olm.upgradeEdges
edges:
  - from: bundle1
    to: bundle2
  - from: bundle1
    to: bundle3
  - from: bundle2
    to: bundle3

[joelanford]

As I mentioned in the WG meeting, I think it would also be interesting to consider implicit ordering and upgrade rules based on bundle versioning metadata. For example:

---
schema: olm.channel.v2
entries:
- bundle1
- bundle2
- bundle3

... and then OLMv1 on-cluster, implicitly derives an order and upgrade edges, perhaps with a mechanism similar to rpm/dnf

[ankitathomas]

From looking at how operator authors used channels in the past, they mostly boil down to:

• version based (x, x.y, x.y.z)
• maturity based ("dev", "unstable", "alpha", "fast", "hotfix", "rolling", "latest", "beta", "candidate", "preview", "early-access", "stable", "production", "current", "lts", "eus", "deprecated", "old")
• tenancy based: ("cluster", "namespaced")
• catalog based: ("community", "certified")
• some combination of the above

A lot of these can be replicated without actually using channels: version based channels won't be necessary if we can have semver based upgrade graphs, operators with different tenancy models feel like they could be their own package, and catalog based channels don't really feel necessary since they'd be on separate catalogs anyway. However, channels do help with the maturity based separation, we'd need some way to let a cluster admin specify the maturity level of packages and their dependencies on their cluster(channel/bundle level constraints?).

I don't know about separating channel membership from upgrade edges though, isn't the purpose of channels primarily to contain upgrade edge information? What would an upgradeEdge object do to simplify the schema?