On Jul 2, 2013, at 8:17 PM, Clint Byrum <cl...@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!! _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev