Open Stack

On Jul 2, 2013, at 3:52 PM, Clint Byrum wrote:

> Excerpts from Michael Basnight's message of 2013-07-02 15:17:09 -0700:
>> Howdy,
>> 
>> one of the TC requests for integration of trove was to integrate heat. While this is a small task for single instance installations, when we get into clustering it seems a bit more painful. Id like to submit the following as a place to start the discussion for why we would/wouldnt integrate heat (now). This is, in NO WAY, to say we will not integrate heat. Its just a matter of timing and requirements for our 'soon to be' cluster api. I am, however, targeting getting trove to work in a rpm environment, as it is tied to apt currently.
> 
> Hi Michael. I do think that it is very cool that Trove will be making
> use of Heat for cluster configuration.

I know it really fits the bill!

> 
>> 
>> 1) Companies who are looking at trove are not yet looking at heat, and a hard dependency might stifle growth of the product initially
>>    • CERN
> 
> I'm sure these users don't explicitly want "MySQL" (or whatever DB
> you use) and "RabbitMQ" (or whatever RPC you use) either, but they
> are plumbing, and thus things that need to be deployed in the larger
> architecture.

Well sure but i also dont want to stop trove from adoption because a company has not investigated heat. Rabbit and the DB are shared resources between all OpenStack services. Heat and Trove are not.

> 
>> 2) homogeneous LaunchConfiguration
>>    • a database cluster is heterogeneous
>>    • Our cluster configuration will need to specify different sized slaves, and allow a customer to upgrade a single slaves configuration
>>    • heat said if this is something that has a good use case, they could potentially make it happen (not sure of timeframe)
> 
> There's no requirement that you use AWS::EC2::AutoScalingGroup or
> OS::Heat::InstanceGroup. In fact I find them rather cumbersome and
> limited. Since all Heat templates are just data structures (expressed
> as yaml or json) you can just maintain an array of instances of the size
> that you want.

Oh good!

> 
>> 3) have to modify template to scale out
>>    • This doable but will require hacking a template in code and pushing that template
>>    • I assume removing a slave will require the same finagling of the template
>>    • I understand that a better version of this is coming (not sure of timeframe)
>> 
> 
> The word template makes it sound like it is a text only thing. It is
> a data structure, and as such, it is quite easy to modify and maintain
> in code.
> ...
> I hope all of that makes some sense. Eventually yes, resizable arrays
> of servers will be in the new format, HOT, but for now, the CFN method
> is still useful as you get signals and dependency graph management.

It does, with one caveat. Can i say slave00001 has a flavor of 512m and slave00002 has a flavor 2048m? I didnt see that in the example. Its really useful for a reporting slave to be smaller than a master, and for a particular slave to be larger due to any sort of requirement that i cant necessarily dictate!