Question on Veneers

[phantomjinx]

Started looking at this as an alternative to improve our e2e operator testing. We have scripted the downloading of the existing catalog then use a combination of sed and awk to update the channel entries to conform with where the test compiled bundle is expected to be inserted. This is not foolproof and has some quite complex scripting (probably could improve with yq but not there yet).

By migrating the existing catalog to a veneer, it would make this insertion and maintenance of channels easier. Using yq we can script up this migration but the veneer is not much use without the ability to generate the test index from channels other than Stable, Candidate, Fast. So far it seems that other channel names are being ignored (using 1.24.0).

Is this likely something that will be supported, please?

[joelanford]

@phantomjinx thank you for this feedback/question! A similar question was asked here, so this is definitely a topic we've been actively discussing.

The current alpha version of the semver veneer was specifically designed to help drive consistency of terminology and upgrade predictability to the benefit of cluster administrators, aligning closely with what's outlined in OLM's channel naming best practices: https://olm.operatorframework.io/docs/best-practices/channel-naming/#recommended-channel-naming

If a large chunk of operators in a catalog use the same channel names and upgrade graph building logic, cluster administrators can apply the same general conceptual knowledge to every decision they make when deciding what channels to use. So that's why you see that veneer having a super rigid configuration.

From a practical perspective, I don't think we expect many operator packages to be able to pick up the semver veneer and have it "just work" as a migration from their existing sqlite-based package structure. In the meantime, you might be better off using basic veneer with some yq/jq fu to keep the channels updated as you wish. Or even better, if you're happy with the upgrade graphs within the channels and would like to change the channel names, you could use the semver veneer with just a sprinkling of yq/jq to change the channel names.

Separately, we're going to be looking into ways we can improve the experience of enabling channel deprecation notices to cluster admins, which would enable operator authors to slowly migrate to a new set of (hopefully universally consistent) channels.

Having said all of that, this is still alpha, so the intention for now is specifically to collect feedback and see how people use it and understand the rough edges so that we can fine-tune and improve. I think making channel naming less rigid is certainly a direction that will be under consideration. It's also possible that this tooling is relaxed, but catalog maintainers may include their own policies about what is acceptable (or not) in their catalog.

[phantomjinx]

Thanks @joelanford. That is really interesting. Am looking into your suggestions and will keep an eye on how this progresses.