CloudFormation wait condition on update stack

Question

I have a cloud formation pattern that I set a wait condition to receive a signal when the user script data runs out. This works great!

Now I use cfn-hup to update my application with the new version. I update the stack with a new parameter and the script downloads the new version and install it on the server. But since I am not updating the resource of the waiting condition, it does not recreate or wait for the signal. Is there any way to make a resource of a wait resource wait?

Answer 1

Great question. I myself was looking for a solution, but it seems like this is impossible. Since 2013: Invent session:

• cfn-hup cannot interact with CloudFormation workflow
  • Workflow will not wait for cfn-hup
  • cfn-hup cannot execute workflow
  • cfn-hup cannot push data onto the stack

Source: http://www.slideshare.net/AmazonWebServices/aws-cloudformation-under-the-hood-dmg303-aws-reinvent-2013-28437139/72

"If cfn-hup crashes and burns and it fails, the CloudFormation workflow will say that the update is complete."

Source: https://www.youtube.com/watch?v=ZhGMaw67Yu0&t=36m39s

Answer 2

To update the application using CloudFormation, you update the data in the Metadata section of the Instance or LaucnConfig element. In your case, you change the value of the parameter referenced by the Metadata section. I assume the source is updated? The cron job for your instance (s) is configured to run cfn-hup, and when it does, it reads the information onto the CloudFormation stack and sees that it has changed. Then it performs the actions specified in the hooks.conf file (or in the files in the hooks.d directory), which is usually run by cfn-init. The cfn-init command extracts all files from the specified sources and runs all the commands specified in the "Metadata" section. The result is an updated application.

For the waiting condition, in order to “reactivate” something would have to say this, which, by the way, I do not think is possible. Since the only thing you change is instance metadata, and all actions happen locally with the instance, I don’t think that what you are trying to do would be possible. A new wait condition should be created and signaled by a cfn signal (which, I believe, should be called in hooks.conf). An interesting scenario: what to do if the following happens: you rename the wait condition and change the metadata for the update. The instance cannot signal completely, and CloudFormation returns the template to its previous state. The next time cfn-hup is called, the instance sees that the stack has been changed, but the reverse hangs and cannot complete the recording again. Would we be stuck in an endless loop?

Answer 3

thanks for sharing, I encountered a similar problem and I created my own solution, even this is not nice, but I'm glad to share it here:

The main problem here is cfn-hup runs asynchronously, and there is no way to get it back to cloud information.

Here is my solution: - as part of cfn-auto-reload.conf , - we call cfn-init cmd to update the stack, - and we use another script to capture the exit code cfn-init cmd and the version of the installed application, - then put them in file on S3.

• then, as a follow-up deployment to the CI pipeline, the validation task will check this file on S3 to verify both the exit code and version.

not elegant, but it works :)