Open Stack

On 04/04/14 13:58, Clint Byrum wrote:
>> >We could keep roughly the same structure: a separate template for each
>> >OpenStack service (compute, block storage, object storage, ironic, nova
>> >baremetal). We would then use Heat environments to treat each of these
>> >templates as a custom resource (e.g. OS::TripleO::Nova,
>> >OS::TripleO::Swift, etc.).
>> >
> I've never fully embraced providers for composition. Perhaps I've missed
> that as a key feature. An example of this would be helpful. I think if
> we deprecated all of merge.py except the "merge unique params and
> resources into one template" part, we could probably just start using
> nested stacks for that and drop merge.py. However, I'm not a huge fan of
> nested stacks as they are a bit clunky. Maybe providers would make that
> better?
>
> Anyway, I think I need to see how this would actually work before I can
> really grasp it.

AIUI this use case is pretty much a canonical example of where you'd 
want to use providers. You have a server that you would like to treat as 
just a server, but can't because it comes with a WaitCondition and a 
random string generator (or whatever) into the bargain. So you group 
those resources together into a provider template behind a server-like 
facade, and just treat them like the single server you'd prefer them to be.

This could actually be a big win where you're creating multiple ones 
with a similar configuration, because you can parametrise it and move it 
inside the template and then you only need to specify the custom parts 
rather than repeat the whole declaration when you add more resources in 
the same "group".

 From there moving into scaling groups when the time comes should be 
trivial. I'm actually pushing for the autoscaling code to literally use 
the providers mechanism to implement scaling of stacks, but the 
ResourceGroup does something basically equivalent too - splitting your 
scaling unit into a separate template is in all cases the first step.

cheers,
Zane.