stacker.md

Taxonomy

• Don't re-use CFN taxonomies for our own domain, except when directly interacting with the resources
• Stacks -> Blueprints
• StackTemplate -> Plan? Bundle? (Using "bundle" for the remainder of the doc)

Config YAML

• Like YAML. In stratosphere, I was aiming to lock down a Python API first, which people could write ConfigLoaders for to implement any config format that suits them. Probably better to name them Marshalers if we wanted to go this route.
• Like the class mapping.

API

• Would prefer to move the package to more of a library; remove the likes of "domain", "max zones" from the args list. Allow addition of these global-level parameters & settings via bundle decoration.

Design Considerations

• We should aim to allow concurrent execution of blueprints. Generate a dependency graph and see what blueprints can be executed in parallel.

Awesome, thx Rob. Some comments:

• Definitely agree about the mixing of taxonomy
• By Stacks do you mean the config settings/classes, etc that come out of the YAML config? This is part of the problem with the way I use 'stack' in this, even I don't know what I mean sometimes :)
• I really want to come up with something that makes the Stack Definition -> Stack Template terminology make more sense. Like if the StackTemplate were a Blueprint, the Stack Definition feeds into the StackTemplate or BluePrint. Or maybe visa versa. It's a really hard thing for me to figure out.
• Definitely agree about coming up with the Python API. Right now it's basically totally tied to the STackTemplate object, and I'm not sure that's great. Really open to any ideas here.

I'll dig in more when I have more time. Thanks again! Really happy to have more eyes on this :)

Agree with taxonomy. Definitely need to have it documented so people know what we're talking about.

And agree with getting the Python API right. Adding config loaders will be easy after you know how to interact with the library.