Adds a utility to make an "ownership tree" like an ls-tree for a k8s namespace

[bentito]

Also allows to store a state "fingerprint" based on getting the YAML for each resource in the tree and prompting an LLM for what is wrong with the ClusterExtension install.

commands are:

hack/tools/ownership_tree.py <namespace>
prints an lstree style list of the resources found in the namespace

hack/tools/ownership_tree.py <namespace> --no-events
same as w/ no flags, but Event resources are not shown

hack/tools/ownership_tree.py <namespace> --with-event-info
same as w/ no flags, but Event resources messages are also shown

hack/tools/ownership_tree.py <namespace> --gather-cluster-extension-state
same as w/ no flags, but also a "fingerprint" is created from getting all the YAML for the each resource in the tree, file is JSON and will have the name: <namespace>-state.json

hack/tools/ownership_tree.py <namespace> --prompt
same as with --gather-cluster-extension-state flag set, but the "fingerprint" is created and sent as part of a prompt to an LLM for diagnosis of ClusterExtension problems.

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	c879510
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/675c43df169bab000832fd6e
😎 Deploy Preview	https://deploy-preview-1523--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.68%. Comparing base (e51c0c2) to head (c879510).
Report is 7 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1523   +/-   ##
=======================================
  Coverage   74.68%   74.68%           
=======================================
  Files          42       42           
  Lines        3271     3271           
=======================================
  Hits         2443     2443           
  Misses        652      652           
  Partials      176      176           

Flag	Coverage Δ
e2e	52.15% <ø> (ø)
unit	57.96% <ø> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[camilamacedo86]

I do not mean to be contrary, but this raises some interesting questions:

1. Are we considering adding tooling options to the operator project itself, or are we planning to use something like an OLM tool to help users? If so, is this the right place to address that?
2. Why would we introduce tools in Python when the entire project is written in Go? If we decide to add tooling, shouldn’t it also be implemented in Go to stay consistent with the rest of the project? What would justify deviating from this approach?
3. Everything we add, we must support. Do we really want to take on the responsibility of supporting this tooling in the operator itself?
4. Do we have an RFC or brief for this, or are you still in the exploration phase?

[bentito]

Hi Camila,
Thanks for the comment, see inline below for specifics, but TL;DR; of my response: It's a Draft PR and just exploration.

I do not mean to be contrary, but this raises some interesting questions:

1. Are we considering adding tooling options to the operator project itself, or are we planning to use something like an OLM tool to help users? If so, is this the right place to address that?

Likely we would want something located here in hack/ or maybe off separately in a tooling repo if we end up creating one.

2. Why would we introduce tools in Python when the entire project is written in Go? If we decide to add tooling, shouldn’t it also be implemented in Go to stay consistent with the rest of the project? What would justify deviating from this approach?

As noted in the live (and recorded) demo: This was done in Python as a PoC and one-off. Definitely there is no reason to do this in Python if we wanted to make a tool like this.

3. Everything we add, we must support. Do we really want to take on the responsibility of supporting this tooling in the operator itself?

This is a draft PR. I think in general, no need to comment about where stuff is going to land or anything like for a draft PR.

4. Do we have an RFC or brief for this, or are you still in the exploration phase?

This was a Hack and Hustle Day exploration. It's up in Draft PR form so that people can see the code, and get more insight beyone the demo.

[joelanford]

How much overlap is there between this and https://github.com/ahmetb/kubectl-tree?