feat: Live resource view

[jannfis]

What does this PR do / why we need it:

This PR introduces functionality to provide live resource view from the agents to the control plane. There are still a few caveats with this, and some things to sort out.

The general architecture is documented here.

It's also the pre-requisite for other upcoming features, such as log view, resource actions and resource manipulation, this is why I'd like to have the code in early.

The CLI components to manipulate cluster secrets will be a follow-up PR.

Which issue(s) this PR fixes:

Fixes #?

How to test changes / Special notes to the reviewer:

The CLI code for managing cluster secrets will be submitted in a different PR, thus, the code in here is potentially difficult to test.

Checklist

• Documentation update is required by this PR (and has been updated) OR no documentation update is required.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 47.33010% with 651 lines in your changes missing coverage. Please review.

Project coverage is 48.41%. Comparing base (d16afb3) to head (dd5d108).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
cmd/principal/main.go	0.00%	93 Missing ⚠️
principal/server.go	14.94%	68 Missing and 6 partials ⚠️
agent/inbound.go	10.25%	70 Missing ⚠️
cmd/cmdutil/log.go	0.00%	51 Missing ⚠️
internal/event/event.go	7.54%	49 Missing ⚠️
internal/argocd/cluster/informer.go	58.82%	26 Missing and 9 partials ⚠️
principal/resource.go	70.17%	27 Missing and 7 partials ⚠️
internal/argocd/cluster/conversion.go	42.30%	18 Missing and 12 partials ⚠️
cmd/cmdutil/term.go	0.00%	24 Missing ⚠️
principal/resourceproxy/resourceproxy.go	81.35%	14 Missing and 8 partials ⚠️
... and 17 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #267      +/-   ##
==========================================
+ Coverage   48.20%   48.41%   +0.21%     
==========================================
  Files          55       72      +17     
  Lines        5066     6219    +1153     
==========================================
+ Hits         2442     3011     +569     
- Misses       2424     2949     +525     
- Partials      200      259      +59     

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

[chetan-rns]

Added a couple of small questions. Everything else looks good to me.

[jgwest]

Looks great @jannfis, posted my thoughts below on anything that jumped out at me while working through the PR.

And one final question: I didn't see any E2E-style tests for the feature, what are your plans here?

[ishitasequeira]

If the err here is not nil, based on my understanding, we were not able to fetch any resources. Should we be returning the error from here itself?

[jannfis]

Hm. In my thought process, it is not an error condition for processIncomingResourceRequest itself when we could not fetch the resource from the local cluster. We rather need to let the other side know, that resource fetching failed (and the reason, e.g. resource not found or access forbidden).

[ishitasequeira]

That makes sense. Continuing on the same scenario, would the json marshaling (line 129 below) be considered more of an internal error or should we be returning that to the caller as well? My thought is that, we might loose sending the response in scenarios where we find errors in json marshaling.

[jannfis]

That's a good question, and one that could be asked about any error condition in that particular method.

For now, I think the answer is: We want to transport eventual status codes from the communication between the agent and Kubernetes API back to the principal, but nothing else. This is because the principal can then pass that status code on to the consumer of the resource proxy.

We could go ahead and send HTTP 500 status codes back to the principal whenever something goes wrong in processIncomingResourceRequest, then the question is, should we? I have not yet found a good answer to that question. The principal will notice that no reply has been sent from the agent anyway, and will let its consumer know.

[jannfis]

@jgwest I have not yet thought about e2e tests tbh. Agree we need to have some. Will work on them together with the corresponding CLI PR that's in the queue.