[openstack-dev] [Heat] How the autoscale API should control scaling in Heat

Steven Hardy shardy at redhat.com
Thu Sep 12 07:30:21 UTC 2013


On Thu, Sep 12, 2013 at 01:07:03AM +0000, Keith Bray wrote:
> There is context missing here.  heat==>trove interaction is through the
> trove API.  trove==>heat interaction is a _different_ instance of Heat,
> internal to trove's infrastructure setup, potentially provisioning
> instances.   Public Heat wouldn't be creating instances and then telling
> trove to make them into databases.

Well that's a deployer decision, you wouldn't need (or necessarily want) to
run an additional heat service (if that's what you mean by "instance" in
this case).

What you may want is for the trove-owned stacks to be created in
a different tenant (owned by the trove service user in the services
tenant?)

So the top level view would be:

User -> Trove -> (Heat -> Nova)

Or if the user is interacting via a Trove Heat resource

User -> Heat -> Trove -> (Heat -> Nova)

There is nothing circular here, Trove uses Heat as an internal
implementation detail:

* User defines a Heat template, and passes it to Heat
* Heat parses the template and translates a Trove resource into API calls
* Trove internally defines a stack, which is passes to Heat

In the last step, although Trove *could* just pass on the user token it has
from the top level API interaction to Heat, you may not want it to,
particularly in public cloud environments.

Steve



More information about the OpenStack-dev mailing list