Incompatibility with serverless-plugin-aws-alerts

[krohrsb]

Seems this plugin may be incompatible with https://github.com/ACloudGuru/serverless-plugin-aws-alerts

The CloudFormation template is invalid: Template format error: Unresolved resource dependencies [AwsAlertsAlarm, AwsAlertsInsufficientData, AwsAlertsOk] in the Resources block of the template

This is attempting to deploy the initial stage/alias. Tried against a pre-existing deployment as well as removing and trying fresh.

[HyperBrain]

Hey @BlackBarn , thanks for bringing this up.

If the alerts plugin modifies functions and the CF stack, the order in the plugins array in your serverless.yml is important. Then the alerts plugin must be added BEFORE the alias plugin.
BTW: The same is true for the warmup plugin which works correctly although it adds resources and functions.

[krohrsb]

Thanks for responding. However the alerts plugin is already defined before the alias plugin:

plugins: 
  - serverless-offline
  - serverless-jest-plugin
  - serverless-domain-manager
  - serverless-plugin-aws-alerts
  - raml-serverless
  - serverless-aws-alias

I've also tried flipping them just for kicks. Same result.

[krohrsb]

Also it appears if I remove the alerts plugin, it hangs up on the domain-manager one as well :(

  The CloudFormation template is invalid: Template format error: Unresolved resource dependencies [ApiGatewayDeployment1513960531513] in the Resources block of the template

Commenting out domain manager and alerts allows it to pass.

[HyperBrain]

@BlackBarn Thanks for testing.

So I assume we need to add support for both plugins. I'm sure that both add resources that depend on the api gateway deployment, which is moved to the alias stack by the plugin.
So the dependencies have to be resolved by the plugin and then it should work.

#84 Is nearly the same - it is most likely caused by the use of domain manager too.

I'll create separate feature requests to support the resources created by the 2 plugins.

[beldougie]

Is there any update on this? Not using serverless-domain-manager isn't an option for us but we'd really like to take advantage of this plugin too. The initial deployment works for me currently, but as soon as I try to add an alias I get an error.

An error occurred: pathmapping - Base path already exists for this domain name (Service: AmazonApiGateway; Status Code: 409; Error Code: ConflictException; Request ID: d3715fb1-6e33-11e8-9d18-d1f30f610ad4).

I am not setting the basePath parameter manually - I assume the alias plugin is doing that when the default alias is created? I'll have to manage aliases manually for now but would be better if I could add this functionality as part of my CI configuration

[HyperBrain]

Hi @beldougie , yes this is still on the roadmap, but there was no update yet. I agree that supporting the plugin is needed. It seems that the mapping resource has to be adjusted by the plugin to make it work (so that it uses the APIG stage/alias correctly.
The alias plugin itself does only create APIG stages for each alias.

[mbruning24]

My team and I tried to set up the cloudwatch alarm and the sns notification in the Resources section manually (without the alerts plugin) and got the same resource dependency error. We were able to get the cloudwatch alarm set up by itself without the alarm actions property, but the SNS topic would not create, nor the alarm actions property, so it seems that there's a level of dependency regardless of the alerts plugin, more having to do with Cloudformation itself.

[mbruning24]

@HyperBrain I think I've found where the problem is. When the artifacts are uploaded to S3 after processing the SNS events in the aliasRestructureStack.js file, there are two files in the S3 bucket:

1. /compiled-cloudformation-template.json
2. /compiled-cloudformation-template-alias.json

The SNS topics end up in the -template-alias.json file.
The cloudwatch alarms end up in the -template.json, referencing the SNS topics that are not are not in the same file.

./lib/stackops/snsEvents.js:46 deletes the topic from the stageStack, which explains the lack of resource in the stage file.

Is there a good reason for deleting the SNS topic from the stageStack? or would leaving it in there be a potential solution?