Infrastructure Resource Changesets
Back to the Blog Page

Infrastructure Resource Changesets

by Chris Roberts | Thursday, November 5, 2015

Two new, and extremely powerful, features have recently been added to the SparkleFormation CLI (sfn) tool. These new features are focused on providing usable information around the changesets applied to running infrastructure stacks (updates).

What will this update change?

One of the most important pieces of information when pushing updates is what the resulting state of the system will be after the updates have been applied. The importance of this information is increased when the context is shifted to infrastructure that is generated and maintained by code. An unintended resource update can easily cause a cascading effect, destroying and recreating numerous resources (in some cases within numerous related stacks). Preventing these situations requires an understanding of how resources behave within a given orchestration API, how (or even if) updates of specific resources are handled, and how those updates affect other dependent resources.

Just diff the templates

Providing changeset related information has been (and remains) an incremental process. Thus the starting point was providing the most straight forward information: Displaying difference of an existing stack template, and a new template staged to be applied:

$ sfn diff test-vpc --file vpc

The diff command will perform the following steps:

  1. Fetch the existing template of test-vpc from the API
  2. Generate the local vpc template
  3. Perform a diff of the two templates
  4. Report any resources changes detected

In this example, the existing stack consists of a single VPC instance. The local template has been modified to change the VPC resource name, and add a new SecurityGroup resource. The result:


The diff command provides a clear list of resource modifications between the existing template and the new template. This is useful for seeing what changes exist at the template level between local development and existing infrastructure. What this information lacks, however, are changes that may occur at runtime that are not isolated to direct resource modifications.

But what is actually going to change?

The diff command, being the first iteration, provided the initial first step in the changeset related information. The next iteration started with what was learned building diff support and took a nice stride forward to provide update planning. Plans are an extension of the diff command, with one important difference: planning evaluates the resulting runtime state. To visualize the difference, lets walk through an example:

Using our updated template, lets assume our test-vpc stack has been updated and it now contains the updated resources:


This shows our stack contains two resources: a VPC resource and a SecurityGroup resource. To continue on with the example, lets assume that the CIDR for the VPC needs to be changed. This value is defined via a parameter within the template. When we run the diff command, there is no parameter usage:

no diff

There is no difference between the existing template and the new template to be applied thus our result shows no difference. Yet, if we change the CIDR parameter value, we know a change will occur. It is in this context that the planning support becomes extremely useful:


When the update command is run, a new planning stage is entered after all parameters have been collected. The planning stage can be viewed like running an expanded diff command. Since the updated parameters are now available it is possible to generate a complete complete runtime diff. This is evident in the output showing the replacement of the VPC resource due to the CIDR change.

It is important to note that not only are the the explicit resource changes detected, but implicit changes are detected as well. Notice the plan also includes the SecurityGroup resource in the replacement list. We made no direct changes to that resource. Due to the replacement of the VPC resource, any usage resource utilizing the ID of that VPC resource will also be modified. The SecurityGroup resource uses that ID within its VpcId property. Since updates to the SecurityGroup VpcId property cause the resource to be replaced, it is also flagged within the plan and displayed within the replacement list.

What is the next iteration?

The next iteration is tightening up the planning integration within the upcoming SparklePRO(vision) service to allow better controls and feedback of infrastructure changes.