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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
