Deployment with existing stack causes error
helveticafire opened this issue · comments
Thanks for the plugin. I am getting this error when your plugin to my serverless project file:
sls deploy
Serverless: Installing required Python packages...
Serverless: Linking required Python packages...
Serverless: Packaging service...
Serverless: Unlinking required Python packages...
Serverless: Deploying additional stacks...
Serverless: Additional stack permanent has not changed.
Serverless: Commencing API Gateway stage configuration
Serverless: API Gateway stage configuration complete
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading service .zip file to S3 (17.21 MB)...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
.................................................................................................................................................Serverless: Deployment failed!
Serverless Error ---------------------------------------
An error occurred while provisioning your stack: ApiGatewayStagefoo
- foo already exists.
Stack Trace --------------------------------------------
ServerlessError: An error occurred while provisioning your stack: ApiGatewayStagefoo - foo already exists.
at provider.request.then (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/plugins/aws/lib/monitorStack.js:112:33)
From previous event:
at AwsDeploy.monitorStack (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/plugins/aws/lib/monitorStack.js:29:12)
at provider.request.then (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/plugins/aws/lib/updateStack.js:90:30)
From previous event:
at AwsDeploy.update (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/plugins/aws/lib/updateStack.js:90:8)
From previous event:
at AwsDeploy.BbPromise.bind.then.then (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/plugins/aws/lib/updateStack.js:111:12)
From previous event:
at AwsDeploy.updateStack (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/plugins/aws/lib/updateStack.js:103:8)
From previous event:
at Object.deploy:deploy [as fn] (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/plugins/aws/deploy/index.js:55:10)
at BbPromise.reduce (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/classes/PluginManager.js:210:55)
at runCallback (timers.js:666:20)
at tryOnImmediate (timers.js:639:5)
at processImmediate [as _immediateCallback] (timers.js:611:5)
From previous event:
at PluginManager.invoke (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/classes/PluginManager.js:210:22)
at PluginManager.run (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/classes/PluginManager.js:225:17)
at Serverless.run (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/lib/Serverless.js:97:31)
at serverless.init.then (/Users/foo/.nvm/versions/node/v6.10.1/lib/node_modules/serverless/bin/serverless:23:50)
Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Forums: forum.serverless.com
Chat: gitter.im/serverless/serverless
Your Environment Information -----------------------------
OS: darwin
Node Version: 6.10.1
Serverless Version: 1.10.1
Let me know if you additional details?
Hi @helveticafire, the error message is saying that the foo stage already exists. Did you add the plugin after already deploying without the plugin? I'm not sure what the behaviour is for that. If possible you might want to try removing the deployment, making sure everything is cleaned up (via AWS console) and doing a fresh install.
@helveticafire By the way, I intend to develop this plugin further, so I'm by no means brushing you off here. I'm interested in whether there's a workaround, which will help in the meantime, but also I will then know that there is a problem specifically with adding the plugin to an existing project, so I can look into working around that, or at least documenting the limitation.
@leftclickben I did add the plugin after the first deployment. Awesome to hear that you want to develop the plugin further! Removing the stage variable and deploying does work as expected. However, the log level is not set in the console, see:
Should it not be set?
I think it is reasonable to expect that you would not have to remove any part of a living system i.e. "a production system" so that you would not have any downtime for a service. It is possible to enable this feature on the AWS API Gateway console after a stage variable has been created so it would be great to have this ability in this plugin too. Thank you for the plugin.
If there is any way can help move this along, let me know.
Thanks for this plugin! Really useful!
I've run into this same error on an existing stack. Unfortunately, I am not able to remove the existing stack as it would cause an unacceptable interruption of service. I'm interested in helping in whatever way I can to find a fix for this. I'm digging into the code now and if I find a way forward I'll create a PR. Let me know if there's any other way I can help move this forward!
It looks like I could get around this by deleting only the existing API stage (instead of the entire stack). That may be sufficient for my use case since I won't have to tear things down like persistent data stores. That makes the downtime a lot more acceptable.
UPDATE: This workaround does work (you may have to also manually delete base path mappings), but unfortunately the short downtime is still unacceptable for us. I'll be looking into a fix.
So ultimately we ended up working around this by following these steps:
- Manually clone the current API Gateway stage.
- Manually cut the base path mapping over to the cloned stage.
- Delete the original stage.
- Redeploy (which will recreate the original stage)
- Ensure the base path mapping is directed to the newly created stage from the deploy (this might happen automatically)
- Delete the cloned stage.
Just wanted to update this issue with the fact that serverless now supports this functionality as of v1.26.0 in this PR serverless/serverless#4247