Open Stack

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" <shardy at 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 at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev