Kuadrant components CI/CD

[didierofrivia]

Partially closes https://github.com/Kuadrant/architecture/issues/59 Aspects regarding the actual event of releasing: https://github.com/Kuadrant/architecture/pull/46

[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.

[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.