Kuadrant components CI/CD

[didierofrivia]

Partially closes #59
Aspects regarding the actual event of releasing: #46

[alexsnaps]

I like the -dev (or some equivalent suffix) for "in progress" work... another option is to use the git SHA as a suffix - tho I'd prefix it with something stable so semantic versioning (as pointed in the comments of that thread) is maintained. Or put the sha in the metadata, as:

Build metadata MUST be ignored when determining version precedence.

That's if we wanted to move keep some sort of "floating release" while achieving proper tracability

So using -dev, also would prevent us from using -alpha or -beta ... or anything "lower than -dev, as per semver

Identifiers with letters or hyphens are compared lexically in ASCII sort order.

Which means that 1.0.0-alpha < 1.0.0-dev... -rc would then be a stable release to depend on.

[guicassolato]

Authorino Operator uses nowadays a mix of all options below (1, 2 and 3).

There's is a build.yaml file (option 1) that is created by a script/make target (option 2), and committed to each release branch.

The file contains the version of the operand the operator is bound to (in the form of a container image ref) and the value of the replaces directive to be used in the operator bundle manifests. I.e. all info it needs to prepare a new release.

E.g. https://github.com/Kuadrant/authorino-operator/blob/release-v0.10.0/build.yaml

The process of creating the release branch with its build file, generating the operator bundle, and publishing the GitHub release notes is triggered in GitHub, by executing the Release operator action (option 3).

[guicassolato]

A couple things regarding this that I'm still trying to wrap my head around are:

1. The difference between releasing Kuadrant (the suite) vs. releasing each individual component
2. The fact that we have different kinds of components, with different required steps to accomplish what we perceive as a "release", but yet discussing options that would allegedly unify it all into a single process

1. Releasing Kuadrant vs Releasing components of Kuadrant

This RFC is clear about its aim of implementing a "new release process for Kuadrant components", not for Kuadrant itself. I wonder if this is because somehow it's believed that releasing Kuadrant is a process that reduces simply to releasing each of its components and then that it happens naturally, perhaps with "Kuadrant" here represented by one of the components, i.e., the Kuadrant Operator, rather than the composition. Or maybe because indeed covering this other part of the process, of what characterises releasing Kuadrant itself (not the components), is beyond scope for now.

Either way, it feels like we're trying to simplify releasing Kuadrant by removing the differences involved in releasing each of its inner parts. This not only neglects the part of defining what releasing Kuadrant even means (where perhaps some of the complexity lies), but may also put a bit too much hope IMO on unifying the processes for individual and essentially different components, which leads me to my second point.

2. Unified process for different components

If having a single unified process that works for all components is envisioned and described as simply as having a big "Release" button for each component, that abstracts the complexities of each individual process, then I'm totally fine with it. If, on the other hand, we want to slice that into finer details, then we have to remember that releasing component X is not the same as releasing component Y.

If such differences exist between every single pair of components whose release process we compare, then we're likely better with each component owning its own release process.

It's good that we document and even automate the steps as much as we can of course, but not everything has to come top-down as "this is the way to release", nor unified we need a central release control plane which can end up turning into a bunch of if's and else's.

What I understand has become a PITA and therefore deserves some attention is that we currently have multiple ways of releasing operators, and all our operators are based on the same tech (Golang, Operator SDK), with artifacts published to the same hubs. Unifying how we build, publish and release operators is a good thing, IMO.

In general, my recommendations for improving how we do releases:

1. All operators should be released the same way if possible - i.e. same scripts and tools, same types of artifacts, same publishing platforms/hubs
2. Different components should own their specific release particularities. E.g.: if releasing Authorino means creating a git tag and pushing a container image to quay.io, but Limitador requires a release branch and an additional step of publishing the crate to a particular registry, then these are details that belong to each of these components. The components should document their own release processes, and maybe Kuadrant does not have to provide much more than guidelines such as which architectures to build for, which registries to publish at, etc.
3. Define what releasing Kuadrant means in terms of the marginal effort involved, after each component has been released – from picking the stable/released versions of each component the next of Kuadrant will be based upon, to things like integration/conformance tests (if any), docs, change logs, cadence, and announcements.

IOW, this RFC could be just a set of guidelines on how to release operators and minimum requirements for the other (more special) components. In the future, describe what releasing Kuadrant means in a way that communicates to users of Kuadrant more than to maintainers what to expect.

[didierofrivia]

Thanks @guicassolato for the feedback! In simple words, I understand your concerns and agree with most of your recommendations and thoughts. I'll try to expand your main 2 points with my thoughts,

1. Releasing Kuadrant vs Kuadrant components:

From just the technical POV, we could define the release of Kuadrant by the process of releasing it's components, from services like Authorino and Limitador and their respective Operators to the Kuadrant Operator itself... Then, this RFC would represent the effort of solving the overhead we have when not only releasing, but providing the artifacts for different use cases. Just the unified interface/process/button abstracting or hiding the particularities of each component.

Then, regarding the "event" of releasing Kuadrant, as a project, where more aspects need to be considered, such as cadence, documentation, communication, etc.. Maybe we should address all that in a different RFC where we could be more focused. There's already something in the works in Paul's repo.

I would say that the current title of this RFC is a bit misleading and doesn't represent well its true meaning. Maybe changing it to something like "Kuadrant components CI/CD artifact delivery and technical release" might be more on point.

2. Unified process for different components

I've briefly commented in the previous point about unifying to a single process, but it's more about establishing the process, but then each component will manage its own particularities. The operators are easier to adopt the same process, but Limitador and Authorino given their different technologies are not. This doesn't mean that the way we tag, branch, and the interface for communicating our meaning for building the artifacts can't be the same(ish).

That being said, maybe we could agree on this RFC being the technical release aspect and we still need to define the broader aspect of the event of releasing.

[pehala]

That being said, maybe we could agree on this RFC being the technical release aspect and we still need to define the broader aspect of the event of releasing.

In that case, shouldn't the non-technical RFC take precedence and be agreed upon before we do this one? To define what we want to do and only after that how we do it?

[didierofrivia]

In that case, shouldn't the non-technical RFC take precedence and be agreed upon before we do this one? To define what we want to do and only after that how we do it?

I reckon we could advance independently, since the details regarding the event of releasing won't change the way we are building and delivering the artifacts, but how often and under which channels, conditions, communications, etc... Or maybe it would?

Maybe I could submit the other RFC needed and work in parallel?

[pehala]

Maybe I could submit the other RFC needed and work in parallel?

I think this would be the best approach, I would also rescope this RFC to only care about Kuadrant CI/CD

[alexsnaps]

Added the "Final Comment Period" to this RFC, so please try to consolidate responses within the coming week...
Other than major disagreement, we shall merge this after this period.

[pehala]

I think these components are outdated, both MGC and DNS operator are missing

[mikenairn]

This was on my list of things to update once the unified kuadrant PRs started merging. I can update and create a PR when i get a bit of time.

[didierofrivia]

@mikenairn That'd be great! thanks 🙏🏼

[pehala]

I am missing DNS operator and MGC for both current and new process

[didierofrivia]

@mikenairn maybe you could update also the current process ?

[mikenairn]

I added (not yet merged) a release doc to the dns operator repo https://github.com/Kuadrant/dns-operator/blob/88185359c731d41d8909c1ae45bf0a6ec14d0031/docs/RELEASE.md

Similar to what Gui describes here https://github.com/Kuadrant/architecture/pull/41/files#r1444455110, it has a file generated by a prepare-release task that is saved to the release branch, but its just a Makefile overriding the appropriate variables so that all the make targets function as expected if you were to run them on that branch.

Do we want all this copied into this doc, or can we just link to that file?

re. MGC, not sure what we did for a release there tbh, but it's an operator like most others and we probably just manually did it all. Branching tagging would be the same as what is described in the dns-operator doc.

[didierofrivia]

Yes, that should be added here too, since we're gonna be using this document's section to gather every detail of the current release process of the components. Thanks!

[david-martin]

Having a split between what to release and how to release sounds reasonable.

My understanding is is that https://github.com/Kuadrant/architecture/blob/main/rfcs/0008-kuadrant-release-process.md is the 'what to release' part.
And this PR is the 'how to release' part.

I believe the only thing holding up this PR is adding the DNS operator and MGC pieces.
@mikenairn if you have no objections, this PR can be merged to main and the DNS & MGC pieces be added after?
There are a couple of other release technical details I'd like to start proposing (for kaudrantctl and dashboards), so having this rfc back on main would be helpful to propose that.

[david-martin]

@didierofrivia is the rfc number of 0000 intentional, or a placeholder (I think the next number at this time is 0009)

[didierofrivia]

@david-martin it's just a placeholder and will be changed once the PR it's approved, in order to avoid overlapping with other RFCs in development.