Allow the Notification controller to provide more rich payloads to GitHub dispatch_workflow

[xunholy]

Hi, certain KRM tools output dynamic values into the .status of their custom resource once provisioned. For example; When you create a cluster in KCC unlike other KRM operators it outputs its connection configuration via the .status of the Cluster resource.

I would like to propose that the notification controller can be configured in such a way that once a resource is created it could submit a more rich payload of either the .status or subset of the information within. Currently the payload is only something like resource/name was created. Which means we need our GitHub workflow to then interrogate the cluster which isn't ideal.

What I feel could be a better solution is a more extensible and configurable payload that can provide more meaningful information. Using the above usecase, if we create a Cluster KRM resource, and a new cluster is provisioned in our cloud provider, it would be great if it sends the clusters connection config in the payload to the GitHub dispatch_workflow which subsequently would run a flux bootstrap command into that cluster dynamically for us.

https://fluxcd.io/flux/components/notification/provider/#setting-up-the-github-dispatch-provider

[kingdonb]

The status shouldn't have any secrets in it, so I can't think of any reason to shoot this down at least immediately. Preview environments is something that is requested all the time, I know of one Flux off-shoot project besides our own paid product WGE that supports a preview environment workflow, this article is from one month ago: https://kluctl.io/blog/2022/12/28/template-controller/

I have not tried kluctl, or the preview environments feature from our own product frankly, but I am getting around to it.

Any solution to this issue will have to consider the context of those other solutions. I've seen one similar solution archived recently, I assume it was done because this space is getting crowded, and there are already several good or very good solutions out there which makes it harder for Flux to compete, maybe better for users in the long run if we spend the resources elsewhere if it's already possible to do this with Flux using another third-party tool added on. I will definitely put preview environments on my personal feature capabilities roadmap, and consider to do a "preview environments" demo some time in the future.

What you're proposing here sounds like a major change in Flux that would open the floodgate to new automations to be built from it. I don't want to sound flippant, but such a change will need to have careful consideration and an RFC to cover the benefits and risks, the surface area changes, etc. If the capability you're trying to garner is preview environments, we'll have to show how adding this feature can better enable preview environments, as it isn't clear to me what this is for after reading a brief description of the idea.

I also don't think we can expect this change to land quickly based on the scope of impact, but sometimes it's easier to make the change in a fork and show how it's used (rather than writing up a long and involved RFC only to uncover that it won't work.)

Is this work you would consider to undertake and share with us, or is it more broadly as a feature request?

[kingdonb]

I thought more about this and I dreamed up the idea of a templates controller with a conditions engine for the sub-resources.

In the template, you would declare sub-resources (like the Cluster resource we use it for in our multi-cluster management solution)

https://docs.gitops.weave.works/docs/gitops-templates/templates/#how-to-add-a-gitops-template-to-create-a-cluster

Then, alongside the sub-resources in the template header, you would express some positive and negative conditions based on expectations about the status or conditions in the sub-resources.

For sub-resources with a rich condition-enhanced status already, we could simply promote the status details in full, or filter down to specific conditions and promote only those that require an alert (now think dispatch triggers – this is where it connects to your feature idea) you could define something like healthChecks that would promote a status through the template parent resource.

I think there's definitely something to your feature request, but I think there's no question that a change like this presents a major upgrade to the existing APIs, so requires more discussion to implement. There is possibly a bigger feature that this change ought to be made with consideration around, so we don't solve half a problem only. And full disclosure, if you didn't guess from the link above, our paid product has prior art in the vicinity – I think that we're going to see less template related work in Flux itself, because the company builds a product that's focused on templating. So if "rich payloads" requires templates, it's unlikely to land in Flux soon, unless it were donated by Weaveworks from the product. I think it still represents future work even if I could sell you the product right here on forum.

[kingdonb]

Of course I'm conflicted, because well you know we're a company and we need to sell the product to stay in business ;)

I'd like to solve your problem generally within Flux if we can, ... but to be clear, the Flux team has already the work planned out for it on the roadmap for I think the next 6 months at least, and according to that plan, Notifications APIs are not scheduled to get any overhaul until at least Q3.

It could happen before then, but it's unlikely from my perspective to come from the Flux team. But there's a chance that our product (Weave GitOps) could already be close to solving this issue, then there's an even greater chance our product team can build the needed changes, whatever is needed to close any feature gaps between how we envision the solution and where the product is now. Perhaps there's something there?

It is frankly a lot higher likelihood that this work gets done by commission than that we find ourselves adding new roadmap items to the Flux project team in near term. If you work with a company that can devote the resources (Hello, that's us, yes, still here on the line!) I truly don't think this is the place for upselling, but I'm also afraid that if you get my drift, we are all in sales now. ⛳️