Description
When using the Grafana API through the Pulumi-Grafana provider, we encountered an issue during operations that replace or delete a ContactPoint. The Grafana API does not allow deleting a ContactPoint if it is being referenced by a NotificationPolicy. As a result, attempts to replace or delete a ContactPoint lead to errors in Pulumi deployments.
Current Behavior
When replacing or deleting a ContactPoint that is referenced by a NotificationPolicy, Pulumi throws an error due to the Grafana API restrictions.
This occurs because the API does not permit deletion of a contact point when it is in use.
Potential Workaround
One potential workaround discussed is to set the ContactPoint as a parent resource of the NotificationPolicy. However, this creates a new challenge:
The NotificationPolicy can have multiple policies associated to multiple ContactPoints.
Currently, the Pulumi design does not allow a resource to have multiple parents, making this approach challenging.
What is the best approach to achieve robust Infrastructure as Code (IaC) in this scenario?
Discussion Points
Hierarchical Structure: Is it viable to create a hierarchy of ContactPoints—with the NotificationPolicy attached to the leaf node of the hierarchy—thus ensuring that deletions or replacements occur safely?
Alternative Designs: Are there any recommended patterns or alternative designs to manage multiple ContactPoints for a single NotificationPolicy that align well with Pulumi's resource management model?
Terraform Parallel: There is a related discussion/bug on the Terraform provider side that might shed some light on this issue (Terraform Provider Issue #1806). Any insights from that context would be beneficial.
Request
Could the Pulumi-Grafana community or the maintainers provide guidance on:
Whether establishing a hierarchy of ContactPoints is the recommended solution.
Any alternative approaches or best practices to handle the deletion and replacement of ContactPoints used by NotificationPolicies.
Workarounds or future improvements planned to mitigate the current limitation in the Grafana API handling.
Any help or direction would be greatly appreciated!
By the way, I'm still using this old plugin: 0.5.1, but I did not see any improvement on that front in newer version
Description
When using the Grafana API through the Pulumi-Grafana provider, we encountered an issue during operations that replace or delete a ContactPoint. The Grafana API does not allow deleting a ContactPoint if it is being referenced by a NotificationPolicy. As a result, attempts to replace or delete a ContactPoint lead to errors in Pulumi deployments.
Current Behavior
When replacing or deleting a ContactPoint that is referenced by a NotificationPolicy, Pulumi throws an error due to the Grafana API restrictions.
This occurs because the API does not permit deletion of a contact point when it is in use.
Potential Workaround
One potential workaround discussed is to set the ContactPoint as a parent resource of the NotificationPolicy. However, this creates a new challenge:
The NotificationPolicy can have multiple policies associated to multiple ContactPoints.
Currently, the Pulumi design does not allow a resource to have multiple parents, making this approach challenging.
What is the best approach to achieve robust Infrastructure as Code (IaC) in this scenario?
Discussion Points
Hierarchical Structure: Is it viable to create a hierarchy of ContactPoints—with the NotificationPolicy attached to the leaf node of the hierarchy—thus ensuring that deletions or replacements occur safely?
Alternative Designs: Are there any recommended patterns or alternative designs to manage multiple ContactPoints for a single NotificationPolicy that align well with Pulumi's resource management model?
Terraform Parallel: There is a related discussion/bug on the Terraform provider side that might shed some light on this issue (Terraform Provider Issue #1806). Any insights from that context would be beneficial.
Request
Could the Pulumi-Grafana community or the maintainers provide guidance on:
Whether establishing a hierarchy of ContactPoints is the recommended solution.
Any alternative approaches or best practices to handle the deletion and replacement of ContactPoints used by NotificationPolicies.
Workarounds or future improvements planned to mitigate the current limitation in the Grafana API handling.
Any help or direction would be greatly appreciated!
By the way, I'm still using this old plugin: 0.5.1, but I did not see any improvement on that front in newer version