Open Stack

Ah, thx keith, that seems to make a little more sense with that context.

Maybe that different instance will be doing other stuff also?

Is that the general heat 'topology' that should/is recommended for trove?

For say autoscaling trove, will trove emit a set of metrics via ceilometer
that heat (or a separate autoscaling thing) will use to analyze if
autoscaling should occur? I suppose nova would also emit its own set and
it will be up to the autoscaler to merge those together (as trove
instances are nova instances). Its a very interesting set of problems to
make an autoscaling entity that works well without making that autoscaling
entity to aware of the internals of the various projects. Making it to
aware and then the whole system is fragile but not making it aware enough
and then it will not do its job very well.

On 9/11/13 6:07 PM, "Keith Bray" <keith.bray at RACKSPACE.COM> 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.
>
>At least, that's what I understand from conversations with the Trove
>folks.  I could be wrong here also.
>
>-Keith
>
>On 9/11/13 11:11 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:
>
>>Sure,
>>
>>I was thinking that since heat would do autoscaling persay, then heat
>>would say ask trove to make more databases (autoscale policy here) then
>>this would cause trove to actually callback into heat to make more
>>instances.
>>
>>Just feels a little weird, idk.
>>
>>Why didn't heat just make those instances "on behalf of trove" to begin
>>with and then tell trove "make these instances into databases". Then
>>trove doesn't really need to worry about calling into heat to do the
>>instance creation "work", and trove can just worry about converting those
>>"blank instances " into databases (for example).
>>
>>But maybe I am missing other context also :)
>>
>>Sent from my really tiny device...
>>
>>On Sep 11, 2013, at 8:04 AM, "Clint Byrum" <clint at fewbar.com> wrote:
>>
>>> Excerpts from Joshua Harlow's message of 2013-09-11 01:00:37 -0700:
>>>> +1
>>>> 
>>>> The assertions are not just applicable to autoscaling but to software
>>>>in general. I hope we can make autoscaling "just enough" simple to
>>>>work.
>>>> 
>>>> The circular heat<=>trove example is one of those that does worry me a
>>>>little. It feels like something is not structured right if that it is
>>>>needed (rube goldberg like). I am not sure what could be done
>>>>differently, just my gut feeling that something is "off".
>>> 
>>> Joshua, can you elaborate on "the circular heat<=>trove example"?
>>> 
>>> I don't see Heat and Trove's relationship as circular. Heat has a Trove
>>> resource, and (soon? now?) Trove can use Heat to simplify its control
>>> of underlying systems. This is a stack, not a circle, or did I miss
>>> something?
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev