How can AWS CloudFormation help? about cloudformation-ruby-dsl HOT 17 CLOSED

@cdandekar It'd be nice if we could perform an update on a stack without changing the template itself, but only other properties. For example, updating a stack by changing the value of a parameter with no other changes. Currently, CloudFormation doesn't detect this as a change and rejects the update, saying that there's nothing to update.

from cloudformation-ruby-dsl.

@jonaf we added parameter-only updates: http://aws.amazon.com/about-aws/whats-new/2014/05/12/aws-cloudformation-enables-parameter-only-stack-updates-and-stack-notification-topic-changes/

from cloudformation-ruby-dsl.

@cdandekar In practice, this doesn't seem to work without changes to the effective template. For example, a Parameter that does not produce a tangible change to any resources will return an error message, stating that there is nothing to change.

from cloudformation-ruby-dsl.

@jonaf The parameter-only updates is useful when you want to continue using the same stack template, but change any of the parameter values and have that take effect wherever the changed parameter value(s) is used in the stack resources.

Can you elaborate on the scenarios where you want to change parameter values, but do not necessarily want to change any stack resource?

from cloudformation-ruby-dsl.

One example might be where EC2 instances query the CloudFormation stack that created them for state information or updates. For example, a stack may be updated to reflect a more current version of automation or deployment code, and the EC2 instances provisioned by that stack may query the CloudFormation API to discover they need to self-update to the defined version. Parameters are a natural choice for this criteria because CloudFormation tags are immutable and EC2 tags are limited to a maximum of 10 (and you may have multiple AutoScaling Groups of EC2 instances as part of the same stack and only want to perform one, holistic update to effect changes to multiple AutoScaling Groups).

Another example would be for orchestration, deployment and/or dashboarding microservices that query various Amazon API's, including the CloudFormation API, in order to derive (current) information about infrastructure.

from cloudformation-ruby-dsl.

This isn't specific to the Ruby DSL but I would love to see the Cloudformation API support a dry-run mode for create/update stack that would go beyond basic template validation and report on what resources would be created, modified or replaced if executed for real.

Aside from saving engineer time while developing stacks it would be very useful for speeding up and saving costs when doing automated testing of commits/PRs for templates.

from cloudformation-ruby-dsl.

+1 for a dry run mode for the Cloudformation APIs.

Cheers,

Nathaniel Eliot
On Feb 13, 2015 3:59 AM, "Jim Croft" [email protected] wrote:

This isn't specific to the Ruby DSL but I would love to see the
Cloudformation API support a dry-run mode for create/update stack that
would go beyond basic template validation and report on what resources
would be created, modified or replaced if executed for real.

Aside from saving engineer time while developing stacks it would be very
useful for speeding up and saving costs when doing automated testing of
commits/PRs for templates.

—
Reply to this email directly or view it on GitHub
#28 (comment)
.

from cloudformation-ruby-dsl.

I second the +1 for dry-run -- I spend a lot of time waiting for a real run to complete, only to find several minutes later that there was a problem with one of my arguments. A fast dry-run would save me hours.

from cloudformation-ruby-dsl.

+1 for enabling "changeless" updates. Attempting to add an Output to a stack also fails with Malformed input-No updates are to be performed.

from cloudformation-ruby-dsl.

Another + 1 for dry-run. Stack updates are always dangerous from a regenerated template, and even blue-green stack replacements could benefit from the visibility.

from cloudformation-ruby-dsl.

+1 for dry run.

from cloudformation-ruby-dsl.

+1 for dry run

from cloudformation-ruby-dsl.

+1 for both suggestions. Dry run would be super useful for obvious reasons. And our build process also uses CF parameters to get information like which puppet environment to join or which role assign to itself.

from cloudformation-ruby-dsl.

Hi @cdandekar it's been six months. Any further information you can share??

from cloudformation-ruby-dsl.

Hi @cdandekar. Any updates?

from cloudformation-ruby-dsl.

I have conveyed your feedback and feature requests to the current AWS CloudFormation team. Going forward, lets use the AWS Forum (https://forums.aws.amazon.com/forum.jspa?forumID=92) and Twitter handle @AWSCloudFormer to provide feedback and receive updates.

from cloudformation-ruby-dsl.

Thanks for the update @cdandekar ! I'm closing this issue so that folks can continue the feedback/conversation on the more appropriate channel you identified.

from cloudformation-ruby-dsl.