Open Stack

On Jul 2, 2013, at 8:17 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Michael Basnight's message of 2013-07-02 19:04:01 -0700:
>> 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.
> 
> I do understand that. Heat has some growing up to do before it is in the
> same category as those other pieces. Please keep us in the loop where
> you need features and/or bug fixes for Heat.
> 
>>> 
>>>> 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!
> 
> Of course flavor can differ per-server. That is kind of my point, the cfn
> template format is fairly low level, making Heat into sort of a really
> smart client library for all of OpenStack. So you can really maintain
> the list of slaves however you want. You could have ReportingSlave0001
> and QuerySlave0002 or just use UUID's for them and give them names
> in Metadata.
> 

Great! <3. Thx again for shedding some light!!