I am deploying a .Net Core Web API project to AWS Lambda. It works, but I have the following issue:
Previous Template Contains Parameter No Longer Used
A previous deployment of our Lambda created a CloudFormation template with a defined Parameter. For discussion, let's call it "BadParameter".
Now, we don't want to use that parameter anymore. We've updated our serverless.template so that it does not have that parameter anymore.
Now, all our deployments (using the update template) fail with the message:
Error creating CloudFormation change set: Parameters: [BadParameter]
do not exist in the template
I can fix this by downloading the template from CloudFormation, manually removing the parameter, then re-uploading the template, but that is tedious and error-prone.
Is there some way I can specify in my new template that the old parameter should be deleted?
I ran into this too. I'm going to give details on what I saw and what I did to fix it because my situation doesn't seem to be exactly the same as SouthShoreAK's situation, but is close enough that I'm certain we are experiencing the same issue.
Situation and Error
parent-template.yml is a CloudFormation template which is being deployed as part of the CI/CD process. Inside this template are several AWS::CloudFormation::StackSet resources, child-template-1.yml, child-template-2.yml, etc. Each child-template-*.yml StackSet resource is deploying into multiple accounts.
I was receiving this error on one of the AWS::CloudFormation::StackSet resources:
Parameters: [OldParameter1, OldParameter2] do not exist in the template
Changes Which Caused the Error
Recent changes were:
In child-template-1.yml I removed these two parameters, OldParameter1 and OldParameter2.
In parent-template.yml in one of the AWS::CloudFormation::StackSet resources I had been passing in values for OldParamter1 and OldParameter2. I removed these two ParameterKey-ParameterValues. In other words, I stopped providing these parameters as inputs to the child template.
Steps Taken
I went into child-template-1.yml and added the parameters OldParameter1 and OldParameter2 back into the template.
I gave both parameters a default value, "Dummy".
I re-deployed with aws cloudformation deploy
I went into child-template-1.yml and removed the parameters OldParameter1
and OldParameter2.
I re-deployed
At that point, the parameters have been removed from the templates. I do not know why this is necessary; it seems like a bug in CloudFormation to me.
Old question I know, but I just ran into this myself using CodePipeline. I cant tell from the OP's question whether they were using it though.
The solution was to remove the old parameters from the json file referenced at TemplateConfiguration in the CodePipeline CHANGE_SET_REPLACE stage.
Related
tldr; I can deploy a single CFN stack as part of my pipeline, but how do I deploy multiple dynamic stacks?
An even better tldr; How would you do this? forEach BuildStage.artifact invoke CloudFormation.build
I am using CodePipeline in a pretty conventional way. The goal is to source control my CloudFormation templates, push them through the pipeline when a template changes, and then automatically deploy the stack.
Source Stage (CodeCommit commit my CFN yaml templates)
Build Stage (CodeBuild finds the new files from the commit, and pushes them to S3)
Deploy Stage (CloudFormation deploys my templates as CFN stacks)
Almost everything is working great. I commit my template changes to CodeCommit, the build stage runs my codeBuild gatekeeper, which gathers only the files that have changed, and uploads them to S3. So far so good.
The challenge is that sometimes I have one template change, and sometimes I have multiple(n). I can detect changed files and get them up to S3 no problem in my build stage. If I commit a change for one template, everything works fine. I can create an exported variable with my template location on S3, pass that to my deploy stage, and have the CloudFormation deploy action use that file as the template source. But how would I handle this if I have 2 templates?
I can't just create endless exported variables in my build stage.
And if I can, AFAIK there is no way to iterate over each entry for the deploy stage.
My thought is I would need to do one of the following:
Inside of my current buildspec (after I upload the files to S3), use the AWS CLI to invoke a CFN stack build. I can add this as part of a loop, so it iterates on each file to be uploaded. OR
After my build stage, use a Lambda to perform the same as #1. Loop through each file, and then use the CLI or SDK to invoke a CFN stack build.
Both of these options seem to defeat the purpose of the deploy stage altogether, which seems clunky to me.
Are there other options I am missing? What would you do?
Just want to answer my own question, in case anyone else is trying to figure out how to do this.
I ended up going with option 1...just doing a cli CFN deployment directly from within CodeBuild. I was really trying to shoehorn the idea of using a CodePipeline deploy stage, but this works just fine.
If anyone else ends up coming along with a better solution, I am all ears.
Alright so I have no idea if this is possible, but I was told so by someone more experienced than me...
I have a pipeline in azure devops to create a cloud formation stack. The cloudformation stack is created from a template. The template requires some parameters
Currently i am passing the parameters through hardcoding the value in the template file. This is just for testing purposes.
But I was told that there is a way to, from azure devops, prompt the customer in a GUI like way and ask them for inputs that azure devops will then place to the template?
The GUI bit...is confusing for me. Hope this is clear if anyone can help?
Yes, you can.
When creating a first level yaml pipeline the parameters works like an input source for your pipeline execution.
Just declare your parameters and it's types and use it on your pipeline tals as you need.
For example:
Creating a parameter:
Running you pipeline:
I'm wondering if creating SSM documents via CloudFormation actually makes sense or if instead I should use another mechanism.
My concern is, that when the content changes, CloudFormation actually creates a new document and destroys the old one. In that process also the name of the document changes. The name cannot be hardcoded or CloudFormation complains with:
CloudFormation cannot update a stack when a custom-named resource requires replacing
With permanently changing names its going to be impossible to reference the document anywhere.
I haven't seen a possibility to create a new document version via CFN, as I can do manually in the AWS console.
What's best practice here?
I know I can create a custom CFN resource and deal with the document update in a lambda. But ain't there a simple solution?
The challenge you describe has, I think, been solved or mitigated by the (recently released?) UpdateMethod property for AWS::SSM::Document. Now, you can specify NewVersion for that property, and that will create a new version of the same document and set it as the default version.
See https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-document.html#cfn-ssm-document-updatemethod
I'm trying to deploy a Lambda function inside Cloud9, but it is failing.
When I right-click on the function and click Deploy, I get Application deployment failed, and then a popup:
AWS CloudFormation Deployment Errors
Stack:arn:aws:cloudformation:* is in UPDATE_COMPLETE_CLEANUP_IN_PROGRESS state and cannot be updated.
Cloudformation throws this error when part, or a sub-stack, of the CloudFormation template, could not be updated or rolled back properly. This can happen if something modified the portion in question outside of what the template says. Here is an excerpt from the docs regarding this issue:
A nested stack might fail to roll back because of changes that were made outside of AWS CloudFormation when the stack template doesn't accurately reflect the state of the stack. A nested stack might also fail if an Auto Scaling group in a nested stack had an insufficient resource signal timeout period when the group was created or updated.
Please read Troubleshooting AWS CloudFormation to find more information about your issue.
If your deployment is building another Stack in CloudFormation, you may want to check for existing ones with the same name that may be conflicting with the Stack created by your deployment.
Go to CloudFormation, find the conflicting Stack, delete all resources (in that stack), and finally delete the stack.
Deploy again and it should work this time.
Waiting for 5 minutes, and then trying the deployment again worked for me.
Have a look at cloudformation to understand what is failing. It seems stuck in IN_PROGRESS state probably due to retries but it will eventually complete as a failure after several failed attempts.
Simple question:
Does SAM Lambda auto-versioning using AutoPublishAlias work for AWS::Serverless::Function when code CodeUri changes but the actual code that it points to doesn't?
Background
We are deploying several Lambda#Edge functions using the SAM AWS::Serverless::Function resource type.
Our deployment runs via dropping code into an S3 bucket and then triggering a CloudFormation stack update. Our stack contains other things in addition to these Lambdas.
With this, we often have deployments that occur where the lambda code doesn't change.
Every deployment, however, the code URI changes to our newest deployment's bucket which, as intended, triggers a new version attempted to be published which is inline with note in SAM documentation (pasted below for context)
NOTE: AutoPublishAlias will publish a new version only when the CodeUri changes. Updates to other configuration (ex: MemorySize, Timeout) etc will not publish a new version. Hence your Alias will continue to point to old version that uses the old configurations.
The reason I am asking is because we've had some transient CloudFormation deployment issues that I've been trying to root cause that may be related to this. The error we get on the SAM generated version in the CloudFormation stack update is as follows:
A version for this Lambda function exists ( {some number} ). Modify the function to create a new version.
I've taken a look at the SAM code where the version is created and most of their documentation but couldn't find a clear answer.
We could likely manually create the AWS::Lambda::Function and AWS::Lambda::Version with a different logical ID on the version each time which should(?) fix the issue but we were trying to utilize SAM for auto-versioning of our Lambdas.
Any help is appreciated!
Yes, SAM will create a new version when CodeUri changes, however, Lambda will not allow you to create a new version if there have been no changes.
To workaround on that, I have a hack which is to create a NOUNCE environment variable with a random value that changes for every deploy. So CloudFormation believes that's a change on the code and deploy a new version of that Lambda and we have no more that version error.