Allow grouping in the UI by custom label/annotation

[dhirschfeld]

Summary

At the moment it appears that grouping groups the same resource types together.

it would be good if there were an option to group by a custom label or annotation.

Motivation

Some of my helm charts deploy multiple different services each of which deploys a number of resources of different types. It would be useful if there were some way to group "related" resources i.e. resources belonging to the same microservice.

Proposal

If you could group resources by a custom label or annotation, I could make sure the resources for each of my microservices were uniquely labelled so that I could e.g. group by microservice-name in the UI

[dhirschfeld]

If the group surfaced info showing if any of the underlying resources were unhealthy it would make it quicker to figure out which microservice had a problem and hence aid debugging,

[crenshaw-dev]

@dhirschfeld is breaking the Helm chart into multiple Applications a viable option? You could still manage them from one app-of-apps.

[dhirschfeld]

I'll have to look into the app-of-apps angle - I'm aware it exists but have never looked into it.

It sounds like it might fit the bill, if I was all in on ArgoCD, however I'd ideally like to ensure things also Just Work as a plain helm install, and having a laundry-list of helm (un)install commands to run is a significant step backwards in terms of UX.

I'm trying to sell ArgoCD as The Way Forward, and one selling point is that it just installs Helm Charts and doesn't add any business logic on top of that so investigating it's use doesn't lock us into using it. When you start to define what services belong to an application inside of ArgoCD itself it makes Helm a bit of a second-class citizen. There are probably benefits to doing so, but we're not at the stage yet where we want to start sacrificing the plain Helm UX in favour of ArgoCD.

[dhirschfeld]

If app-of-apps is the way to solve this problem in ArgoCD, I'm happy for this issue to be closed as wontfix.

[crenshaw-dev]

investigating it's use doesn't lock us into using it

That's fair. Anything that's kept in Argo CRDs (e.g. Helm chart names and potentially parameters/settings in an Application) represent lock-in. I can imagine an App-of-Apps where the Application manifests are as minimal as possible and have a logical mapping to plain-Helm constructs so it's reasonably easy to switch over.

I'd save give App-of-Apps a test run. If it fits your use case, feel free to close the issue. If not, we can discuss what feature(s) would help avoid lock-in. :-)

[drew-viles]

App of apps doesn't really fix this in all scenarios.

Take the following scenario:

I have a bunch of clusters all which use the app-of-apps pattern. The top level application, in this example called cluster-aoa, on any one of these clusters deploys a custom helm chart which contains a bunch of Applications, which get deployed. The custom helm chart layout is akin to the following:

templates
     | - app1
             | - application.yaml
             | - secret.yaml
    | - app2
             | - application.yaml
             | - secret.yaml
    | - app3
             | - application.yaml
             | - secret.yaml

The application.yaml's are just bootstrap ones for deploying things such as External-DNS, Cert-manager - you know, the usual suspects. They are all setup to use a helm chart as the source. Those charts need additional resources, such as ClusterIssuers for CertManager and Secrets for External DNS to talk to the DNS provider. The problem I have is that the secrets get grouped under the cluster-aoa Application resource instead of the corresponding app. For example, I want the ClusterIssuer to be grouped under the CertManager Application as that's where it logically belongs.

I've tried adding labels and annotations galore to the resources but Argo either ignores them or overwrites them. I've used this to try and get around it with annotations and labels but if I set the label on the resource and apply it, the same happens.

A label such as argo.argoproj.io/group-by: app-name could solve this for just nicely displaying it in the UI.

The only way I can currently see around this - but I'm yet to test- is having some sort of subchart inception going on.