cloudtools
blueprint versioning
Blueprints change rather often - there are two major ways they change that we should care about:
- the resources the blueprint produces change
- the blueprint class itself somehow changes, like if we add/remove arguments in init
In case 1 it'd be good to make sure that if there is a potentially dangerous change that would require the destruction of resources that we let people know that.
In case 2 - well, we need to make sure that the blueprints match their expected behavior in stacker.
Not sure how to handle this.
@mhahn @synfinatic I'd love your guys opinions on this. I think this is sort of handled via the new stacker_blueprints library, since we use hard versions in its requirements. Really don't want to catch someone off guard though if we change something that could cause potential issues later.
A good example of this would be moving the empire example from using the old postgres.py based RDS database to the "v2" version in rds/postgres.py that is much more full featured.
I don't have much to say here because I'm not using any of these examples/standard blueprints. One thing that is preventing me from doing so is that we realized it was better to put all the SecurityGroups in a single stack (we put them with the VPC) to make it easier to manage dependancies between SG's.
I will say that for #1 I wish that Troposphere tracked which parameters for a resource required that resource to be re-created... I think that is where that info needs to be tracked, not here.
