Support dumping out rendered cloudformation templates for each stack

[mwildehahn]

Output looks like:

$ stacker build -r us-west-2 conf/lunohq/development.env conf/lunohq/config.yaml --dump dump
[2016-05-17T14:05:33] Dumping "Create/Update stacks"...
[2016-05-17T14:05:33] Writing stack "dev-lunohq-vpc" -> dump/vpc-3ea2d331.json
[2016-05-17T14:05:33] Writing stack "dev-lunohq-empireDB" -> dump/empireDB-2bc493a4.json
[2016-05-17T14:05:33] Writing stack "dev-lunohq-empireMinion" -> dump/empireMinion-6b3bcb53.json
[2016-05-17T14:05:33] Writing stack "dev-lunohq-empireController" -> dump/empireController-92678c3c.json
...

[phobologic]

Doesn't seem like these need to be mutually exclusive, right? The command doesn't give any feedback like that, so might as well allow both. Maybe

if not outline and not dump:
    ... actual build ...
else:
    if outline:
        ... outline ...
    if dump:
        ... dump ...

?

[mwildehahn]

ah yea, we can do that.

[phobologic]

Awesome 👍 Did you get a chance to look at the local parameters 'issue'?

[ejholmes]

Sweet 👍 this will be really nice to have.

I was thinking it would be cool if stacker just compiled all of the blueprints down to a single "metastack" template, which could then be executed by stacker itself. If we exposed a subcommand to execute a metastack template, then this could open up other use cases for stacker (people that want the "stack glue" aspect of stacker, but not troposphere/python), and you could just dump the metastack to stdout (e.g. stacker compile | stacker execute).

Anyways, definitely not something we should do in this PR, just something I was thinking about.

[phobologic]

Honestly for the non-troposphere/python users, I think we should provide a concept of 'drivers'. You don't need to use a Blueprint in that case, we could have a 'json' driver or something that just reads a regular old CF template and uses that.