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

Joshua Harlow harlowja at yahoo-inc.com
Wed Sep 11 17:53:48 UTC 2013


I just have this idea that if u imagine a factory. Heat is the 'robot' in
an assembly line that ensures the 'assembly line' is done correctly. At
different stages heat makes sure the 'person/thing' putting a part on does
it correctly and heat verifies that the part is in the right place (for
example, nova didn't put the wheel on backwards). The 'robot' then moves
the partially completed part to the next person and repeats the same
checks.

So to me, autoscaling say a database would be like going through the
stages of that assembly line via a non-user triggered system (the
autoscaler) and then the final 'paint job' on the vms would be done by the
handoff from heat -> trove. Then trove doesn't need to call back into heat
to make vms that it uses, heat does this for trove as part of the assembly
line.

+2 for factory example, ha.

On 9/11/13 9: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




More information about the OpenStack-dev mailing list