Ensure health status for custom resources implementing kstatus

[erikgb]

What changed?

This PR will compute the kstatus for resource types without existing custom health checks code. This should improve the visualization of custom resources implementing kstatus.

Why was this change made?

We are using many controllers for custom resources in our clusters. For all the operators we are maintaining, we have implemented kstatus, and this seems to be an emerging standard adopted by more and more open-source projects. The changes proposed in this PR will improve the user feedback for kstatus-compatible resources in weave-gitops.

In-tree types shows up quite nicely:

And I am hoping the kstatus compute function as a fallback for health will improve the visualization for many custom resources:

How was this change implemented?

I attempt to replace all/some of the custom code for health indicator with kstatus compute, but that broke many tests - which could represent a breaking change for some users. I think we could consider switching out some of the custom code (e.g. for Deployment), but I'll leave that for an eventual follow-up PR.

How did you validate the change?

Added new test cases to existing test.

Release notes

N/A: I don't think so.

Documentation Changes

[kingdonb]

Thanks @erikgb for submitting this PR

I see some test failing, I am not a WG release engineer so I'm not sure if that means anything.

It is uncertain when there will be another release, but for anyone that comes by who wants to test this, can you tell us what steps to build the image you took, and how to test it using your build / our own build?

Maybe this is all documented, but I want to make it clear, I don't think there is any maintainer here to merge this and release it. I'm sure you saw the announcement about Weaveworks is closing down. The weave.works website is gone already, it may return in some form, but docs.gitops.weave.works is hopefully on a free hosting with GitHub pages and may persist forever?

I don't know if you have any interest in forking this and changing the name, or does your company offer Flux support - we could mention it on the ecosystem page if you're going to maintain it in the future!

[kingdonb]

If we can merge and release this without a lot of ceremony, I'll be happy to throw the levers. As long as my access holds out, but I'm not sure how we can guarantee that, (or if rebranding will be needed first.)

[kingdonb]

To be clearer about what this does fix - does the HelmRepository of type: oci reflect as ready with this change? That's the main issue people have been reporting since Flux GA.

[erikgb]

@kingdonb Thanks for the review. First to the failing build. I think it fails because some dependencies are outdated. This is the error message from the failing log:

yarn audit --production
yarn audit v1.22.21
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ moderate      │ Follow Redirects improperly handles URLs in the url.parse()  │
│               │ function                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ follow-redirects                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=1.15.4                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ http-proxy-middleware                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ http-proxy-middleware > http-proxy > follow-redirects        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://www.npmjs.com/advisories/10[9](https://github.com/weaveworks/weave-gitops/actions/runs/7807149219/job/21294940962#step:7:10)6353                     │
└───────────────┴──────────────────────────────────────────────────────────────┘
1 vulnerabilities found - Packages audited: [10](https://github.com/weaveworks/weave-gitops/actions/runs/7807149219/job/21294940962#step:7:11)[15](https://github.com/weaveworks/weave-gitops/actions/runs/7807149219/job/21294940962#step:7:16)
Severity: 1 Moderate
Done in 0.63s.
make: *** [Makefile:[19](https://github.com/weaveworks/weave-gitops/actions/runs/7807149219/job/21294940962#step:7:20)1: ui-audit] Error 4
Error: Process completed with exit code 2.

This could be fixed by #4186. But CI on that PR is also failing. So in general I would recommend renovating the project before we merge any functional PRs like this one. But that might be challenging - since maintainers are not available...

[erikgb]

To be clearer about what this does fix - does the HelmRepository of type: oci reflect as ready with this change? That's the main issue people have been reporting since Flux GA.

I think this PR might fix this issue. The change is pretty simple: It just tries to compute the resource health status assuming resources implement kstatus. This is done after the hand-coded health checks already implemented, for selective resource types, are run. So if Flux resources follow the kstatus specification, which I think they do, this PR will represent an improvement in this area.

[kingdonb]

I just looked into #4186, I (may?) have write access to this project but I am not an authorized user to merge PRs to main.

So we may need to fork this, and republish it somewhere else. I don't know if I have the energy to do all that.

[erikgb]

I just looked into #4186, I (may?) have write access to this project but I am not an authorized user to merge PRs to main.

So we may need to fork this, and republish it somewhere else. I don't know if I have the energy to do all that.

Thanks for looking deeper into this, @kingdonb! I don't think we have the resources or skills to fork and continue this project somewhere else. Are you aware of some other good GUI for FluxCD? It's painful to say this, but if there is no GUI to visualize the status of Flux resources in our clusters, we'll probably have to consider migrating to ArgoCD.

[kingdonb]

I am still picking up the pieces after the closing of Weaveworks in my home lab, I depended heavily on Weave GitOps Enterprise and now I am not licensed to use it anymore.

I'll let you know what I come up with in a few weeks. I'm not focused on the GUI, I am focused on keeping the Flux team together and answering this question broadly though.

I heard Gimlet is in active development, and also there's Flamingo. The UI of Flux is the Kubernetes status condition. So any UI which is built to manage CRDs broadly should work with Flux, as long as it handles kstatus well and can elevate negative polarity status conditions to the UI then I think it should be good.

But again, I've been avoiding those UIs and focusing on our own as a user for DX purposes, I am the wrong person to ask about other UIs for Flux. My job depended on using this UI.

Edit: there's also the VSCode GitOps Tools, which I think will continue its development independently. We secured the assets to produce new releases of that one, and we can show we still continued to support it after Weaveworks, in limited maintenance for now while we figure things out. Flamingo or Flux Subsystem for Argo can also say the same, from what I can tell.

• Future of Flamingo project flux-subsystem-argo/flamingo#50
• The extension is broken since December vscode-gitops-tools#503

[erikgb]

@casibbald Thanks for looking at this PR! Are you able to review also - as the CI is finally green now? We'll probably have to migrate to some other Flux GUI soon, but it would be awesome to get a release of weave-gitops with this new feature! 🙏

[casibbald]

Hi Erik I am going to start putting in time to maintain the GUI as I need it for my own projects. 1. Get everything green, I had to disable some stuff (will enable uploads etc soon) 2. fix lcense checks 3. update for flux 2.3.0 4. update for flux 2.4.0 There are some features that I need for my own projects so will be prioritizing those first. After that, I will look to work with other contributors regarding new features and bringing this amazing product back on track! Assistance and contribution is required for a healthy project, maybe we can arrange a call with interested parties to see how we can revive and take this forward?

…

On 14 Nov 2024, at 19:29, Erik Godding Boye ***@***.***> wrote: @casibbald <https://github.com/casibbald> Thanks for looking at this PR! Are you able to review also - as the CI is finally green now? We'll probably have to migrate to some other Flux GUI soon, but it would be awesome to get a release of weave-gitops with this new feature! 🙏 — Reply to this email directly, view it on GitHub <#4192 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6C36Z6GC2QJMA4UNRY2D2ATMZFAVCNFSM6AAAAABRIGRJ3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZXGAYTQMJYGM>. You are receiving this because you were mentioned.