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

Improve parsing of configuration variables #449

Closed
wants to merge 3 commits into from

Conversation

aangelisc
Copy link
Contributor

When instantiating a new datasource the current flow assumes that all input variables in the config JSONData are of the correct type. This leads to the creation of the datasource failing if an environment variable is used to provide a value for a property that is of type bool.

Fixes #442

@aangelisc aangelisc self-assigned this Aug 16, 2022
@aangelisc aangelisc requested a review from a team as a code owner August 16, 2022 12:19
@aangelisc aangelisc requested review from asimpson and andresmgot and removed request for a team August 16, 2022 12:19
@github-actions
Copy link

github-actions bot commented Aug 16, 2022

Backend code coverage report for PR #449

Plugin Main PR Difference
azuredx 33.8% 33.8% 0%

@github-actions
Copy link

Frontend code coverage report for PR #449
No changes

d.CacheMaxAge = jsonData["cacheMaxAge"].(string)
}
if jsonData["dynamicCaching"] != nil {
if dynamicCaching, err := strconv.ParseBool(jsonData["dynamicCaching"].(string)); err == nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mmh, wouldn't this break if dynamicCaching is actually a boolean? which is the right thing to be, not a string

As far as I can see, from the original issue, the problem is that the user is trying to get boolean values from env variables, which are automatically translated to strings. I believe that can be solved simply casting the value in the YAML:

    jsonData:
      clusterUrl: ...
      tenantId: ...
      clientId: ...
      onBehalfOf: !!bool $ADX_ON_BEHALF_OF
      oauthPassThru: !!bool $ADX_OAUTH_PASS_THRU

Copy link
Contributor Author

@aangelisc aangelisc Aug 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've realised I originally had a different condition, let me switch this back and it should be safer.

Your suggested solution leads to the following Grafana error:

Datasource provisioning error: yaml: cannot decode !!str `$ADX_ON_BEHALF_OF` as a !!bool

I think casting and checking each type is probably a safer implementation that could avoid issues like these, wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mmh, I see, so the problem is that the system that parses the YAML receives the file unchanged so onBehalfOf is actually a string "$ADX_ON_BEHALF_OF" but at some point it gets replaced and the JSON data that the plugin receives is onBehalfOf: "true". Is that correct?

I think this is a bug that should be solved in Grafana, not in the plugin. I see some similar report grafana/grafana#32061 but didn't get any attention. It's not something scalable if we need to parse field-by-field to handle this situation. Do you mind creating an issue (or reopening that one) giving more information of how to reproduce it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep that's exactly correct, I'll reopen that issue with a reference to this one detailing how to recreate 😊

@aangelisc aangelisc closed this May 17, 2023
@aangelisc
Copy link
Contributor Author

Fixed upstream in grafana/grafana#63085

@aangelisc aangelisc deleted the 442-boolean-env-variables branch November 30, 2023 18:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Environment variables in data source provisioning files don't work with boolean properties
2 participants