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