mikhailshilkov
commented
9 months ago Hi @m1n9o Could you please elaborate what "doesn't work" mean in this case? Does opsgenie.ApiIntegration fail to create? Does it not work as you expect? Thank you.
Open m1n9o opened 9 months ago
mikhailshilkov
commented
9 months ago Hi @m1n9o Could you please elaborate what "doesn't work" mean in this case? Does opsgenie.ApiIntegration fail to create? Does it not work as you expect? Thank you.
m1n9o
commented
9 months ago Sorry to the confusion, I can create Sentry integration with opsgenie.ApiIntegration successfully, and I can view the integration as well as the integration key on the console. However, the integration key seems not a valid integration key. This was the error message when I tried to send test notification. Interestingly, if you create a Sentry integration on the console manually, the integration key is invalid.
mikhailshilkov
commented
9 months ago Thank you for coming back to me.
The resource implementation looks extremely straightforward: it take the type property and passes it on to the API call: https://github.com/opsgenie/terraform-provider-opsgenie/blob/d4378be0718ba789c14cdb76888903a58c80e9be/opsgenie/resource_opsgenie_api_integration.go#L126-L140
It seems to be an issue with Opsgenie API. Do you have a way to ask for their support?
m1n9o
commented
9 months ago Thanks, I am curious who is the custodian of pulumi-opsgenie? I thought it was OpsGenie developers.
mikhailshilkov
commented
9 months ago We (Pulumi) currently take care of it. Our implementation is a fairly thin wrapper around their TF provider, which is run by OpsGenie folks.
benjaminmatthews-dev
commented
1 month ago Has this got something to do with an additional parameter on the OpsGenie API no utilised by the TF?
allowConfigurationAccess
We had this issue with setting up API keys for our Postman Integration via API. Our solution was to use pulumi to setup the API, and then after the pulumi stack has processed, we extract the integrationId then complete a PUT request to /v2/integrations/${integration} to set allowConfigurationAccess to true.
We are using Typescript. Our solution is to set the integrationIds that require elevated privileges onto the stack, and then we use axios to do a custom request to the OpsGenie PUT endpoint as a post deployment process after the stack has deployed.
async function setConfigAccess(integration: string, apiKey: string) {
try {
const current = await axios.get(`https://api.opsgenie.com/v2/integrations/${integration}`, {
headers: {
Authorization: `GenieKey ${apiKey}`,
},
});
if (current.data.data.allowConfigurationAccess !== true) {
console.log(`Setting configuration access for ${integration}`);
const dataToSend = {
...current.data.data,
allowConfigurationAccess: true,
};
await axios.put(`https://api.opsgenie.com/v2/integrations/${integration}`, dataToSend, {
headers: {
Authorization: `GenieKey ${apiKey}`,
},
});
console.log(`OpsGenie Configuration access set for ${integration} (${current.data.data.name})`);
}
} catch (error) {
console.error(`Error setting configuration access for ${integration} (${current.data.data.name})`, error);
}
}
What happened?
The Sentry alert can not be sent to OpsGenie with the integration key created by the Pulumi code.
Example
You can reproduce the issue with below code snippet.
Output of
pulumi aboutAdditional context
No response
Contributing
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).