argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
17.71k stars 5.4k forks source link

[UI] App of Apps 'Go-To-Parent' Button on Application Details View #19236

Open rhyswilliamsza opened 2 months ago

rhyswilliamsza commented 2 months ago

Summary

I would like to propose the addition of a 'Go-To-Parent' button, added to the Application Details page for all App-of-Apps applications. This conditional button would appear if the appLabelKey is found on the currently open application, representing that the opened application is owned & managed by a parent application.

It would look something like the below:

Screenshot 2024-07-25 at 16 16 33

Motivation

Navigating app-of-apps structures down is a breeze when navigating down the tree (using the image selector), however becomes challenging when wanting to navigate back up the tree. This feature solves this problem by adding a simple (go back) button to the top toolbar.

Proposal

We luckily have all the bits needed to make this happen! The existing /settings endpoint provides the selector currently used for app ownership (appLabelKey), which can be reverse engineered to compile a navigation URL to go 'back to' the parent.

Caveats

I foresee two caveats and I would appreciate any thoughts re: if they're (1) worth pursuing, and (2) possible solutions?

  1. I see that ArgoCD is adding support for multi-namespace applications/multi argo deploys. As far as I know, the current app label tag does not include a namespace as part of tracking, so it may be necessary to do some sort of 'lookup'. We can (hopefully!) circumnavigate this for now by dropping the namespace entirely and letting the default 'get application' flow figure it out. If this is deprecated, this feature will break.

  2. This technique wouldn't work if the system is setup to use annotation tracking instead of the default label tracking. We may need to work out a different way of providing the parent-child relationship to the frontend, though I am not 100% sure if this is worth the additional API work at this time (unless the annotation also includes the app name? I must check that!). In addition, there may also be a scenario - if using the default app.kubernetes.io/instance label - where a separate system tags our argo application. We'd likely need to build in some sort of check to detect whether the parent really exists before adding the button.

Please let me know what you think! I'm working on a proof of concept here, which I am keen to turn into a PR if this proposal is accepted 😃

agaudreault commented 2 months ago

@rhyswilliamsza Take a look at the UI code. I think you can leverage the isAppOfAppsPattern property from https://github.com/argoproj/argo-cd/blob/fe9aa54488fc7b9510e9b9fc82408598719a415c/ui/src/app/shared/models.ts#L143 and it might just requires change to the UI assets. To find the parent, I think using the ownerReference might be more accurate than the tracking annotations. If I am not mistaken, the ownerReference will be set to the parent App.

rhyswilliamsza commented 2 months ago

Thanks, @agaudreault!

I think you can leverage the isAppOfAppsPattern property from

Unfortunately when I looked this didn't appear to be set for an application on the application details page, but I'll look into implementing it for this context, too 🦾

I think using the ownerReference might be more accurate

100%, I actually didn't even know this existed. I'll take a stab and make a PR if all goes to plan :)

edit: hmm, looks like ownerReference may only be attached if ApplicationSets are in use. I'll see what I can do here. I'd much rather use a more opinionated field than a label/annotation if I can, so this is a good path to follow - thanks!

agaudreault commented 2 months ago

Ahhh that's true, app of apps won't set any owners reference field.

rhyswilliamsza commented 2 months ago

Hi @agaudreault

Do you perhaps have any guidance for me on the use of cross-namespace owners references by applications? After having a bit of a look, attaching cross-namespace owner refs seems to move against the K8s pattern (though this seems to already be happening in applicationset cases). The main limitation is due to the prohibition of cross-namespace depedencies.

image

Was the decision made to ignore this limitation in the context of ArgoCD? I think the main point of concern would be when two applications, with the same name, exist in different namespaces. The owner ref pattern should be able to distinguish due to the different UID, however how would ArgoCD determine the correct parent in its current form?

agaudreault commented 2 months ago

@rhyswilliamsza as you said previously, ownerReference is only used when the Applications are managed from an ApplciationSet. Argo does not Set ownerReference when an Application "syncs" another resource of kind Application. In that case, the tracking method is used.

Since the tracking is something server-side, I think the UI will have no choice but to receive an object/model from the server with a property that indicates the parent application/reference, based on the tracking method.

Maybe it would be possible to use ownerReference as a new tracking method, but there a probably a lot of limitations and it is a much larger change. You could create a new issue/discussion for this question specifically.

rhyswilliamsza commented 2 months ago

Thanks for the quick feedback! I understand, thanks for the clarification. For now, let me go down the route of attaching additional context via a dedicated property 👍