Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for pre/post-apply/delete actions #163

Open
samuelsuarezsanchez opened this issue Mar 13, 2017 · 1 comment
Open

Add support for pre/post-apply/delete actions #163

samuelsuarezsanchez opened this issue Mar 13, 2017 · 1 comment

Comments

@samuelsuarezsanchez
Copy link
Contributor

samuelsuarezsanchez commented Mar 13, 2017

It would be great if stacks could be setup so certain actions (or hooks) could run before and after applying and deleting them.

In my head, indicating the actions would be done in the stack_master.yml itself. Something like:

stacks:
  us-east-1:
    my-s3-bucket:
      pre_apply: delete-if-exists.rb
      post_apply: print-outputs.rb
      pre_delete: delete-bucket-contents.rb
      post_delete: notify-admins.rb
  • On a very basic version, we would be talking about executable scripts in any language that would receive as parameters:
Action Parameters
pre_apply The compiled CloudFormation JSON template to be applied and parameter values.
post_apply The compiled CloudFormation JSON template that was applied, parameter values and output values.
pre_delete The compiled CloudFormation JSON template to be deleted, parameter values and output values.
post_delete Same as pre_delete.
  • If the script returns zero, then stack_master would continue execution. Any non-zero return code would interrupt the execution.

  • Actions would be located under an actions directory at the same level as parameters, templates, etc.

@petervandoros
Copy link
Contributor

Thanks for writing this up @samuelsuarezsanchez!

I like the proposal :)

Here's some feedback:

  • consider grouping all the "command hooks" under hooks or command_hooks instead of directly under the template name.
  • an extension would be to support all/other commands other than apply and delete.
  • consider renaming the actions directory to hooks or command_hooks.
  • depending on use case, it may be preferable to always execute the post_<command> hooks regardless if the exit status of the pre_<command> hooks. In this case, a "command status" parameter is passed to the post hooks. For example, the post hooks could be used for some cleanup of the pre hooks that you always want to run.
  • should post command hooks be executed if the command fails?

To be clear, I'm not suggesting increasing the scope of this proposal, just some things to think about so it can be extended in the future :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants