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

Allow for ignoring a UID embedded in a dashboard or datasource #1674

Open
tculp opened this issue Sep 13, 2024 · 2 comments
Open

Allow for ignoring a UID embedded in a dashboard or datasource #1674

tculp opened this issue Sep 13, 2024 · 2 comments
Labels
enhancement New feature or request triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@tculp
Copy link
Contributor

tculp commented Sep 13, 2024

Is your feature request related to a problem? Please describe.
I am unable to add multiple copies of a dashboard using the grafanaCom method, as the dashboard in question has a uid embedded in the json. For example: https://grafana.com/grafana/dashboards/12776-redis/

(If applicable)If your feature request solves a bug please provide a link to the community issue
#1499

Describe the solution you'd like
I would like to be able to provide an alternate UID in the GrafanaDashboard resource, or have a flag to force a new random UID to be generated.

Describe alternatives you've considered
Manually download the json and use the configmap method

@tculp tculp added enhancement New feature or request needs triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Sep 13, 2024
@tculp
Copy link
Contributor Author

tculp commented Sep 13, 2024

Potential defaults that would use the embedded uid (current behavior):

uid: ""
generateUid: false

@theSuess
Copy link
Member

We discussed this issue and the way we'd like to solve it is by implementing #1636 for Dashboards. That way, the spec.uid field of the dashboard will always be the UID communicated to Grafana, regardless of the underlying JSON spec.

Keeping this issue open to make sure this use case is covered when implementing the functionality

@theSuess theSuess added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

2 participants