terraform-provider-opsgenie
terraform-provider-opsgenie copied to clipboard
opsgenie
Control order of Alert Policies
Hi there,
this is more a feature request than an issue report.
Terraform Version
0.14.3
Affected Resource(s)
- opsgenie_alert_policy
Terraform Configuration Files
resource "opsgenie_alert_policy" "test" {
name = "Test"
policy_description = "This is an example policy"
message = "{{message}}"
responders {
type = "team"
id = opsgenie_team.test.id
}
filter {}
}
Debug Output
n/a
Panic Output
n/a
Expected Behavior
It would be great to have control about the policy order.
Policies retrieved from WebAPI /webapi/policies have an element order.
{
"policyType": "alert",
"description": "This is an example policy",
"name": "Test",
"teamId": "",
"enabled": true,
"order": 1.0,
"conditionMatchType": 0,
"message": "{{message}}",
"responders": [
{
"id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
"type": "team",
"name": "Test"
}
]
}
Actual Behavior
It is not possible to define the order of (global) policies. As a result, one has to sort the policies manually.
Steps to Reproduce
n/a
Important Factoids
n/a
References
n/a
@ffahri Sorry for bothering you. Can you help us with this or is the maintenance of this project somehow on-hold?
I think https://github.com/opsgenie/terraform-provider-opsgenie/issues/191 is similar.
@emmahsax No, #191 is about conditions order inside a policy, not policies order.
@emmahsax No, #191 is about conditions order inside a policy, not policies order.
Okay. I just glanced briefly, not in detail... just saw they were both ordering issues.
@axdotl Looking at the policy API doc, the order can't be set when creating/updating a policy but only through a specific request: https://docs.opsgenie.com/docs/alert-and-notification-policy-api#change-policy-order
It's a bad API design leaded by the UI needs (you create the policy first, then change its order).
Not sure if the clean Terraform way to handle this should be to hide the second request behind the same alert policy resource, or to create a specific "alert policy order" resource.
Both looks dirty to me in their respective way, but as policies order may have a real impact on the result, I think it's important to fix this.
@gdlx Thanks for this investigation. You're right it's again a situation where the Opsgenie API design is not that great.
Based on your proposals I think the least dirty way is to introduce a new policy_order resource where one can reference existing policies.
Based on your proposals I think the least dirty way is to introduce a new
policy_orderresource where one can reference existing policies.
@axdotl I tended to agree but looking at the structure (long time since I coded for a TF provider), I think keeping a single resource (well, actually 2 with notification policies, but I'm not sure the order is as much important) may be better since there's no actual resource behind the change-order endpoint, so TF would have nothing with an ID to actually create/update/delete and store in the tfstate: at the end it's just a property in the policy itself.
This is actually worse than I thought since, unlike the WebAPI, the Policy API used by Terraform does not provide the order in the policy data. It's only given in the policies list. That means you also have to make an extra request to read the order 😩
@axdotl you may want to give a try: https://github.com/opsgenie/terraform-provider-opsgenie/pull/388
At present, the GET Api https://docs.opsgenie.com/docs/alert-and-notification-policy-api#get-policy doesn't provide us the attribute of order. So we will not be able to support this request in terraform.
At present, the GET Api https://docs.opsgenie.com/docs/alert-and-notification-policy-api#get-policy doesn't provide us the attribute of order. So we will not be able to support this request in terraform.
@agoel2-atlassian The order is provided by the policies list: https://docs.opsgenie.com/docs/alert-and-notification-policy-api#list-alert-policies
That's what I've used in #388.
Order has a strong impact on policies behavior. Not handling this almost prevents managing policies through terraform.
@agoel2-atlassian would it be possible to reopen this issue? This is a significant blocker to us defining alert policies in Terraform and it seems like gdx' PR would address the use case.
Looks like they closed it without even noting there's a PR fixing it. They didn't even review the PR.
