Steve, I think I see where I introduced some confusion... Below, when you draw: User -> Trove -> (Heat -> Nova) I come at it from a view that the version of Nova that Trove talks to (via Heat or not) is not necessarily a publicly available Nova endpoint (I.e. Not in the catalog), although it *could* be. For example, there are reasons that Trove may provision to an internal-only Nova end-point that is tricked out with custom scheduler or virt driver (e.g. Containers) or special DB performant hardware, etc. This Nova endpoint would be different than the Nova endpoint in the end-user's catalog. But, I realize that Trove could interact with the catalog endpoint for Nova as well. I'm sorry for the confusion I introduced by how I was thinking about that. I guess this is one of those differences between a default OpenStack setup vs. how a service provider might want to run the system for scale and performance. The cool part is, I think Heat and all these general services can work in a variety of cool configurations!
-Keith On 9/12/13 2:30 AM, "Steven Hardy" <sha...@redhat.com> wrote: >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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev