Stacktician - CloudStack Collab Conference 2014

Moving up the stack with Stacktician

Amogh Vasekar

Agenda• Introduction• History• Architecture and Implementation• Current State• Enhancements

Agenda• Introduction• History• Architecture and Implementation• Current State• Enhancements

IntroductionWhat is Amazon CloudFormation?•Create and manage collection of related AWS resources•Typically, the resources will form your whole application “stack”

In essence, “Infrastructure-as-code”•JSON file•Describe resources•Describe dependencies•Readable, reusable, reviewable

Sample JSON template

Usefulness• Single click application deployment for multiple users• Transparent, reusable• Ease of resource management and dependencies• Atomic deployments• Thus, migrate new business applications to “cloud”

Simply put, CloudFormation for CloudStack Web interface for template and stack management

Agenda• Introduction

• History• Architecture and Implementation• Current State• Enhancements

History• Started by @chiradeep• Introduced at CCC-13 as a prototype• Execute AWS CloudFormation templates on CloudStack

*AS IS*• Problem – low fidelity between AWS and

CloudStack resource types (more on this later)

Agenda• Introduction• History

• Architecture and Implementation

• Current State• Enhancements

ArchitectureTwo components

StackMate•Execution engine for running the templates and interfacing with CloudStack

Stacktician •Web interface•Embeds StackMate underneath

StackMate in 2 mins• Treat template = stack definition as workflow• Execute workflow by making appropriate CloudStack API

calls• Core engine for executing templates, does the heavy lifting• Command line tool

Stacktician in 2 mins• Web UI for StackMate• Backed by database for persistence• Uses Ruby meta-programming to interface with StackMate

Where we were last time…• Resolve complex resource dependencies• Intrinsic functions• Wait Conditions• Create simple resources like AWS::Instance and

AWS::SecurityGroup using StackMate

AWS templates on CloudStack• Simple resources work well• Too many differences in more complex resources like VPC and networks

No route tables• Semantic differences between APIs for same resources

Different types of values for parameters• Dependency resolution for CloudStack using AWS templates became too

complex Sometimes, two AWS APIs act as a single one in CloudStack CloudStack networking renders AWS options like DhcpOptions

unnecessary Too many NoOp resources used as work-around for above

CloudStack Namespace• Instead create CloudStack specific namespace!• No more mapping of resources from AWS namespace to

CloudStack space• Adds the ability to validate API parameters• Every CloudStack resource becomes a “participant” in the

workflow execution• Essentially need to call create and delete APIs

CloudStack Namespace• Problems

New resources added frequently (e.g tags, UCS, Nicira) APIs evolve to support new parameters etc. Too many CloudStack resources to maintain (~51)

• Solution Use API discovery Auto generate code Use API information to validate all required parameters exist /

format of parameters

StackMate participants • Bootstrap StackMate• Publish CloudStack version specific gem

Errors and rollback• Want stack creation to be atomic• But, provide an option to user to disable rollback (e.g. for

debugging) Catch resource creation errors, and initiate rollback Execute deletion in reverse order of dependencies Skip any resources not yet created If error while deleting, notify user (log for StackMate, UI status for

Stacktician) Stacktician injects additional code in StackMate for DB

management

Metadata server• Resources, like VMs, can launch additional initialization scripts upon

configuration E.g. – Launch a script via “userdata” parameter

• Typically, script needs additional metadata to work with• Metadata is specific to a resource

Request metadata

Metadata server

And expose retrieval as API

Metadata Server• StackMateIn memory metadata, embeds a Sinatra server for

waitcondition and metadata

• StackticianRails serves metadata, persisted in DB

(Special thanks to Simon Waterhouse for integrating cfn-init scripts and creating scripts for Windows)

Stacktician Scaling Improvements• Ruby MRI has global interpreter lock. Eventually, allowed

for only one stack execution thread to run at a time Use JRuby container, run in JRuby compatible server

• Async wait for stack : one thread per stack launch would overwhelm server

GetBack gem for managing thread pool

Delete StackStacktician•Resource IDs in database•Execute delete APIs in reverse order of dependency creation•Not fully tested yet

StackMate•No DB, no IDs•Use resource tags to figure out resources, and delete •In progress

ImprovementsStackMate•Better logging, log level control•Light-weight CloudStack client for making API calls

Stacktician•Supports REST-based API for stack operations, querying and manipulation•Command line tools for all the above operations•sm-create-stack, sm-create-template etc

Agenda• Introduction• History• Architecture and Implementation

• Current State• Enhancements

Demo

Agenda• Introduction• History• Architecture and Implementation• Current State

• Enhancements

Future enhancementsBetter plugin architecture•Allow creation of custom type of resources•Interface with other types of Clouds – GCE, AWS etc.•Allow for scenarios like resource A on CloudStack, B on AWS within single stack•Currently only in StackMate, and very rudimentary. Enforces some basic constraints, uses tag “stackmate_participant = true” for discovery

Bad plugins rejected at run-time•Needs more work to make robust

Future enhancements• Nested stacks

Treat stack as first class object. Template can contain another stack definition as a resource

Works in StackMate, disabled for lack of good implementation

• Support conditional functions in template (e.g Fn:And, Fn:Or, Fn:If)

• Support update stack Semantics to be well defined

Q & AQuestions? Thoughts? Comments? Suggestions?

https://github.com/stackmateFeel free to log issues – more the better!Big thanks to Chiradeep for all the help