cloudformations 4.0 Architectural Discovery Checklist CloudFormations

CloudFormations (ARCH-12/PRD-93) Cloudformations is an AWS resource deployment management service, that allows several AWS resources to be deployed together as a logical unit (called a "stack"). This allows for complete application setup with a small XML file. Stacks are defined in "template" XML files. Operations for Cloudformations are as follows:

create-stack – Creates a new stack (Create all the resources defined within the stack) – requires a template XML file as an argument.
delete-stack – Deletes a stack (Delete all the resources defined within a stack)
update-stack – Updates an existing stack (creates newly needed resources and deletes resources no longer required) – requires a template XML file as an argument.
list-stacks – Lists all (or selected) stacks. This command can show stacks that have been deleted, and returns more results than describe-stacks
describe-stacks – Describes all (or selected stacks).
describe-stack-resources – Describes all resources about a given stack
describe-stack-resource – Describes (in a bit more detail) particular resources in a given stack
describe-stack-events – Describes events that have occurred regarding a given stack. Creating, Updating, and Deleting stacks occur in several steps, so this command shows the steps, and the times that the steps have completed.
get-template – Returns the template XML file used to create or update the stack.
Cancel-update-stack – Cancels a stack update in progress. Rolls back the stack to the state before update was called.
Validate-template – Validates a template XML file. (In AWS this may actually create resources, so beware billing)

Note: The majority of Cloudformations involves the process of managing the resources within the stack. In addition, if an error occurs during any create or update process, rollback steps need to be available. A typical workflow for a cloudformations operation might be something as follows.

Parse the template XML file, determine which resources need to be created. [As part of this process, resources have configuration options called "parameters" which are also defined in the XML file, some are also required to be prompted for or passed in at the command line. More info about parameters later]
Determine the dependency order for resources. Some resources may require other resources to already have been defined or started previously.
For each resource, create/start it. [This may be done in parallel]
If any resource fails to be created, abort the process, and rollback all resources that have been created already. [This requires a list of resources and their current status]
Update the resource status and stack status for every step on #3 and #4.

Something like the above is also probably true of delete and update stack. Allowing for some parallelization, it may be possible that something like SWF may be useful in implementing the above. In my opinion, the above is a fairly limited workflow, and might be easier to write as a standalone workflow than fully implementing something like SWF.

What resources are supported: The following is a list of AWS defined resources that are supported by CloudFormations, and whether or not I think they can be implemented by Eucalyptus in the current release. (4.0).

Assumption: Parsing the template file, including handling "mappings", "functions" and "variables" is doable.

Assumption: Some framework for resource creation/update/rollback can be put in place.

Assumption: None of the unimplemented services in the list below will be implemented in 4.0. Even if they are implemented, hooking them into CloudFormations might take more time.

Additional information Templates consist of resources, as described above, parameters (which exist at the top level, as well as part of resources), mapping (which is essentially sets of conditional parameters, depending on key values), functions (some intrinsic, some which can be used with mappings, such as Fn::FindInMap), references (non-literal values for parameters, which are sometimes strings, sometimes numbers, sometimes complex types). Parsing and handling variables and functions, etc. is another task that needs to be done along with determining workflows.

Items to Research Further How to tie in SWF to the service, the entire control flow that is required for a stack to be created, the set of states, how rollback works.

Cloud-init, the scripts that are bundled with certain AMI's to allow configuration or installation of software.

What parsing of xml files need to be done, especially w/rt "functions", "references", conditional values.

The tools that one needs to use to deploy scripts. There does not appear to be a WSDL. How does Cloudformations send/receive data.

WaitCondition and WaitConditionHandle are resources that may need to be implemented but alter control flow.

Looking more in depth at each resource, see what other resources may be depended on.

Research error handling and rollback.

Much deeper dive into SWF, see what parts need to be implemented for CloudFormations.

tag:confluence tag:rls-4.0 tag:cloudformations

Architecture Wiki
- Contributing to...
- Organization of...

Tags
- Releases: 2.0, 3.0, 3.1, 3.2, 3.3, 3.4, 4.0, 4.1, 4.2, 4.3, 4.4, 5.0
- Features: dns, ebs, image management, selinux, vpc
- Services: autoscaling, cloudwatch, elb, iam, object storage, sqs
- Components: eucanetd

Contact Info
- email: [email protected]
- IRC: #eucalyptus-devel (freenode)

Eucalyptus Links

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cloudformations 4.0 Architectural Discovery Checklist CloudFormations

Clone this wiki locally