Open helveticafire opened 7 years ago
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:
Just wanted to update this issue with the fact that serverless now supports this functionality as of v1.26.0 in this PR https://github.com/serverless/serverless/pull/4247
Thanks for the plugin. I am getting this error when your plugin to my serverless project file:
Let me know if you additional details?