Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for arbitrary links in app dashboard #3487

Closed
carsonoid opened this issue Apr 24, 2020 · 8 comments
Closed

Add support for arbitrary links in app dashboard #3487

carsonoid opened this issue Apr 24, 2020 · 8 comments
Labels
component:ui User interfaces bugs and enhancements enhancement New feature or request type:usability Enhancement of an existing feature

Comments

@carsonoid
Copy link
Contributor

carsonoid commented Apr 24, 2020

Summary

Add the ability to enrich the dashboard with extra links. Links to things like monitoring pages or documentation instead of just ingress hosts or other apps.

Motivation

I love the way that I can jump between apps or directly to an ingress host from the app dashboard. In fact, I love it so much that I wish I could put more, arbitrary links to things in that dashboard so that it can be a single view for all the relevant details for an app.

Proposal

Argo-CD could support a per-resource annotation that would cause the app dashboard to generate clickable links to outside pages on that resource.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-svc
  annotations:
    argocd.argoproj.io/external-link: http://my-grafana.com/pre-generated-link

Then, whenever any resource as that annotation, it generates an additional link button to the given url on that resource.

There could also be a sort of "Phase 2" implementation of this concept with a new CRD. Maybe somthing like:

apiVersion: argoproj.io/v1alpha1
kind: ArgoCDInterfaceTile
metadata:
  name: my-svc-dashboard
spec:
  link:
    text: Grafana Dashboard
    url: http://my-grafana.com/pre-generated-link
    color: light-red
    text-color: black
    # image would be optional
    image:
      source:
        # emojiName is mutually exclusive with url. You should be able to give it a text
        # name for an emoji and the dashboard will attempt to render it, but render nothing if it doesn't
        # match a known emoji name
        emojiName: heavy_exclamation_mark

        # url is mutually exclusive with emojiName. It is the full url
        # to the the image source and will be hot-linked
        # url: http://my-image-source.com/images/dashboard.png

Putting that into an app would cause an extra tile to show up with the given information. This might be overkill, but I really think that Argo-CD's interface is one of it's best features so it would be awesome to be able to do just a bit more with it.

Since the resource is defined as a CRD, end-users would still have all the normal mechanisms for resource generation (helm, kustomize, etc).

@carsonoid carsonoid added the enhancement New feature or request label Apr 24, 2020
@jannfis jannfis added component:ui User interfaces bugs and enhancements type:usability Enhancement of an existing feature labels May 14, 2020
carsonoid added a commit to carsonoid/argo-cd that referenced this issue Sep 29, 2020
jannfis pushed a commit that referenced this issue Sep 30, 2020
@nahum-litvin-hs
Copy link

I cannot find if something like this already exists
do we have something link proposed kind: ArgoCDInterfaceTile?
or any other way to create a contextual menu for tiles?

@carsonoid
Copy link
Contributor Author

You can add links to tiles by adding annotations to resources. That is merged into main.

The interface tile proposal has not had any approval or progress yet. Although I would love to see it get pulled in. I still feel like the left half of the app page is a lot of empty space that we should make usable by users.

@tyrken
Copy link
Contributor

tyrken commented Dec 10, 2021

The current feature is as merged in #4380 is ok, but it's annoying that the early returns such as

case "extensions", "networking.k8s.io":
switch gvk.Kind {
case kube.IngressKind:
populateIngressInfo(un, res)
return
}
skip lines 55-62 which read the annotation into ExternalURLs.

My use case is adding a link to an AWS ALB ingress - TBH I'd rather override the existing one lifted from the status/loadBalancer/ingress/hostname as that won't match the TLS cert I'm attaching, but just getting the correct DNS as one of the options would be useful. Not sure if any other of the early returns are blocking other use cases.

@carsonoid
Copy link
Contributor Author

I have no problem with adding annotation based links to all resources. I think the original proposal was just trying to make a minimal change. But I would be happy to create a PR to include links from annotations for all resources, even those with native link support. It should be a very simple and minimal change.


Coming up with a way to skip one or all links that would normally be generated for a resource type is a different issue. We would have to have some other special annotation or markup to tell the controller to skip one or all normal links.

The Argo-CD team may be more reticent to allow that change. They are trying to keep the number of "knobs" to a minimum and another special annotations for ingress might be more than they want to allow in the project.

@tyrken
Copy link
Contributor

tyrken commented Dec 14, 2021

Thanks & agree overriding the normal ingress link can wait - I've created #7923 to allow all resources to add links, if you could please approve it so it can build & run tests.

keithchong added a commit to keithchong/argo-cd that referenced this issue Jan 19, 2022
Signed-off-by: Keith Chong <kykchong@redhat.com>
alexmt pushed a commit that referenced this issue Jan 25, 2022
Signed-off-by: Keith Chong <kykchong@redhat.com>
@alexef
Copy link
Member

alexef commented Oct 31, 2022

Can we close this as it was implemented in #8231 #7923 #3487 ?

So are we still keeping it open for Part 2?

@carsonoid
Copy link
Contributor Author

I would love to see part 2 become a thing. But I could move that to it's own issue so we can track it separately.

@carsonoid
Copy link
Contributor Author

carsonoid commented Oct 31, 2022

#11128 is a new issue summarizing phase 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:ui User interfaces bugs and enhancements enhancement New feature or request type:usability Enhancement of an existing feature
Projects
None yet
Development

No branches or pull requests

5 participants