pulumi-azure-native
pulumi-azure-native copied to clipboard
Azure native package creates invalid dashboard and the current configuration does not allow us to pass valid metadata property.
Hello!
- Vote on this issue by adding a 👍 reaction
- To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already)
I'm not able to create Dashboards using pulumi, even with the sample provided here
Steps to reproduce
- go to https://www.pulumi.com/registry/packages/azure-native/api-docs/portal/dashboard/
- Use the language of your choice. I've used Typescript
- use command
pulumi up - Go to azure portal and check newly created dashboard
Expected: Dashboard should be accessible Actual: While navigating to the dashboard, it says Dashboard not found
I was able to repro this. Oddly enough, the dashboard shows up as a resource within the resource group, but navigating the dashboard produces the error as described above.
Those examples come from Azure Open API specs repository - sometimes they may be wrong, unfortunately. It would be useful to create a simple dashboard manually, then export its ARM template and see if we can spot a difference between what is defined in Pulumi vs. what the portal creates. @ramhari-bandlab are you in a position to give that a try?
@mikhailshilkov sure I'll give it a try.
invalidtemplate.txt validtemplate.txt @mikhailshilkov I've uploaded one valid and one invalid ARM template file(could not upload with json extension). Azure native pulumi package always produces dashboard with invalid ARM template. Each part in the dashboard settings must have its own "metadata" object. In the template generated by pulumi, the "metadata" object is at "lenses" level, so if it is moved inside the first "part" object, then the dashboard will load correctly. But, it is not possible with the current AN package. Although we can generate a dashboard by using empty metadata property, due to strong typing of language (typescript, C#) all metadata properties can not be defined.

Here's a snapshot on the difference between a valid and invalid ARM template,
- As you can see on the left which is generated by Pulumi having the
metadataobject underneath thepositionobject which is wrong. - Whereas on the right which is valid, the
metadataandpositionobjects are inline underneath the first index.
I personally felt there's a schema translation issue, I wonder how @mikhailshilkov we can proceed with this ?
As of today, using Pulumi 3.130.0 and azure-native 2.58.0, the dashboard creation still fails.
@mablanco We have a test example which seems to succeed for us: https://github.com/pulumi/pulumi-azure-native/tree/master/examples/cs-dashboard
Can you share more details about your code and the failure that you get?
Hi @mikhailshilkov The sample dashboard at https://www.pulumi.com/registry/packages/azure-native/api-docs/portal/dashboard/#create-or-update-a-dashboard (I'm using Python) successfully creates the dashboard resource in Azure. However, when you try to open it, you get an error stating that the dashboard doesn't exist anymore and that it used to have a specific URN.
I've also tried to import into Pulumi stack several dashboards that were manually created. When I use the code that pulumi import outputs to and then run pulumi up I get the same error again.
I hope this helps. Do you want me to try something else?
I've just tried the test example you mentioned above, translating it first to Python, and it both deployed successfully and I was able to access it.
Then I removed it from my stack, imported it back to Pulumi and added the suggested code to my Python file. When I run pulumi up I got the following differences:
~ properties: {
~ metadata: {
~ model: {
- timeRange : {
- type : "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
- value: {
- relative: {
- duration: 24
- timeUnit: 1
}
}
}
+ time_range: {
+ type : "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
+ value: {
+ relative: {
+ duration : 24
+ time_unit: 1
}
}
}
}
}
}
After applying them I was again unable to open the dashboard, obtaining the following error (he dashboard was also marked as read-only.:
Dashboard 'Test Dashboard' no longer exists. It was previously published to resource group 'dashRG02c97f3c' in subscription 'XXX'.
It seems that pulumi import suggests an incorrect format for attributes, using snake_case instead of camelCase. I've seen this same wrong behavior when importing alert rules.
Fixing the case on those attributes and redeploying doesn't fix the issue. Moreover, removing the dashboard and redeploy it from scratch using the fixed case creates a new dashboard which is also not accessible, this time with this error:
Dashboard 'arm/subscriptions/XXX/resourceGroups/dashRG02c97f3c/providers/Microsoft.Portal/dashboards/dash0b8aeffa' no longer exists. It was previously published to resource group 'dashRG02c97f3c' in subscription 'XXX'.
So maybe the wrong case format in certain attributes is not the source of the issue. I hope all this troubleshooting gives you more info on the problem.
That said, I wish there was an easy (and safe) way to import existing dashboards into Pulumi, so a lot of effort (and possible errors when designing dashboards) could be saved.
Let me also upload the exported templates for each dashboard just in case they're useful for troubleshooting:
@mablanco Can you also share your code for the JSON files above?
Sure, here you are (added .txt extension to allow upload in GH):
The first part is the translation of your .NET code while the second part creates the bad dashboard. I've tweaked the dashboards names to make it easier to follow.
Here's the diff between the bad -> good dashboard examples provided:
diff bad_dashboard.json good_dashboard.json
5,6c5,6
< "dashboards_dash0b8aeffa_name": {
< "defaultValue": "dash0b8aeffa",
---
> "dashboards_dash84b4f108_name": {
> "defaultValue": "dash84b4f108",
15c15
< "name": "[parameters('dashboards_dash0b8aeffa_name')]",
---
> "name": "[parameters('dashboards_dash84b4f108_name')]",
18c18
< "hidden-title": "My Test Dashboard"
---
> "hidden-title": "Test Dashboard"
32a33
> "inputs": [],
80a82
> "settings": {},
The only significant diff here looks like the additional, empty inputs and settings properties. Perhaps these are required, but not marked as such in the spec, and they're being dropped during the translation due to being empty.
The only significant diff here looks like the additional, empty inputs and settings properties. Perhaps these are required, but not marked as such in the spec, and they're being dropped during the translation due to being empty.
Yes, pretty sure I've seen this in the past. Those empty values are indeed expected by Azure and we should not drop them.
This issue has been addressed in PR #3566 and shipped in release v2.62.0.
Thanks guys, great job!