Support CloudFormation Parameters within Blueprint Variables

[mwildehahn]

Initial pass at fixing: #205.

It isn't as easy to understand as I'd like when reading through the code, but that's because we have so many different references to parameters all over the place from the old parameters. When we remove those this should be much simpler to follow.

This PR introduces a new concept of Blueprint variable "types". These can be used as the type value when defining a Variable the Blueprint accepts.

Right now all of the types are instances of CFNType which will cause the variable to be submitted as a CloudFormation Parameter when launching the stack.

I was going to exclude these from get_variables but I didn't see a downside to including it. I was thinking we might even be able to do something cool like within a blueprint be able to do something like:

from stacker.blueprints.base import Blueprint
from stacker.blueprints.types import CFNString


class SampleBlueprint(object):
    VARIABLES = {
         "CFNParameter": {
             "type": CFNString,
             "description": "A variable that will be submitted as a CFN Parameter",
          },
     }

     def create_template(self):
          t = self.template
          variables = self.get_variables()
          t.add_output(Output("CFNParameter", variables["CFNParameter"]))

Where calling variables["CFNParameter"] will resolve to a troposphere Ref value automatically? The implicit dependency of doing Ref("CFNParameter") always bothered me.

[mwildehahn]

this isn't true anymore

[phobologic]

Cool, yeah, I like your thoughts around this.

[troyready]

I ran it through a quick test and it looks good to me. More than functional enough as is (would be kinda cool to have the automatic transform to Ref()s as you mentioned but I also could see value in the simplicity of not having that).

Thanks again!

[phobologic]

This needs a Args docstring for value, it's a specific type, right?

[phobologic]

Minor nits, but this looks awesome and is going to provide a lot of flexibility. THanks for jumping on it so quickly. @troyready @acmcelwee might want to take a look at this.

Also, needs docs, but I figure you were waiting to get folks to look at it before documenting.

[acmcelwee]

Looks like the right direction to me

[phobologic]

We're down to only 2 PRs, this and #185. As soon as both are complete, I'm going to release a new stacker - I'm thinking we're getting pretty close to what I'd consider 1.0, but I'll probably go with .8 for this one, .9 for the release where we deprecate the old style Parameters entirely, and then 1.0 once that has stabilized for a bit. Sound good?

[mwildehahn]

I feel like 1.0.0 should drop parameters since it's a massively backwards incompatible change. I think a 1.0.0 of stacker and stacker_blueprints that moves parameters to variables. Then like 1.1.0 once its stable?

[phobologic]

That seems fair, sounds good to me.