I brought the same concern out, in an offline discussion with you, since cloud-controller no more decides the information on where the instance would get spawned, it is best to keep those information in Autoscaler.
Please come up with a two separate config files and let's discuss them here and come to a consensus. Hint: You should think carefully, how to map these two effectively. :) On Sat, Nov 16, 2013 at 12:51 AM, Lahiru Sandaruwan <[email protected]>wrote: > Hi all, > > I've been thinking on the cloud partitions definition in the system. > Currently we plan to define them in Cloud Controller config and then in the > cartridge.xml as Reka also explained above. > In this design, we have to use a cartridge.xml if we want to hot deploy. > Also the new partition definition is limited to that cartridge. > > In a second thought i though of following design, > > Define cloud partitions in a separate xml file which is hot deployable > inside Autoscaler. Then the 'partition' object is passed to Cloud > Controller which has all the details to spwan the instance in correct > partition. > > Here are the advantages over current plan. > > > - Definitions of cloud partitions are used in Autoscaler for making > the decision on the capacity planing and the deployment pattern. > - This will remove following limitation from the current design. > > Defined partition will be limited to a particular cartridge as we define > it in a cartridge.xml in the current design. > > - Here, all the partition definitions are deployed by the dev-op > role(or equal) of the client. So there is no point of limiting a partition > definition to a particular cartridge. > > Thoughts please. > > Thanks. > > > > > > > > On Tue, Nov 12, 2013 at 12:40 PM, Reka Thirunavukkarasu <[email protected]>wrote: > >> Reka, it's good that you followed the same pattern we had in Cartridge >> design. It's best if you can generate the XSD and validate the definition, >> if not already done. >> +1. Will generate and validate against XSD. >> >>> >>> Question: >>> >>> * Why we need both type and id? >>> >> "id" introduced for a readability purpose. If it is redundant, then we >> can get rid of the id and go ahead with the type. >> >> >>> * How the policy file and cartridge definition relates? Should one >>> configure policy file and cartridge definition together? >>> >> Yah. Devop need to configure cartridge definition as well as the policy >> file together. But still, according to my understanding, policy file can be >> generic and independent from the cartridge definition. In this case, we >> might not able to apply all the policies to all the cartridge definition. >> So, it is Stratos Manger's responsibility to validate the cartridge >> definition against the policy files and display the applicable list of >> policies to a cartridge. >> >> Thanks, >> Reka >> >>> >>> >>>> >>>> Thanks, >>>> Reka >>>> >>>> >>>> >>>> -- >>>> Reka Thirunavukkarasu >>>> Software Engineer, >>>> WSO2, Inc.:http://wso2.com, >>>> Mobile: +94776442007 >>>> >>> >>> >>> >>> -- >>> Best Regards, >>> Nirmal >>> >>> Nirmal Fernando. >>> PPMC Member & Committer of Apache Stratos, >>> Senior Software Engineer, WSO2 Inc. >>> >>> Blog: http://nirmalfdo.blogspot.com/ >>> >> >> >> >> -- >> Reka Thirunavukkarasu >> Software Engineer, >> WSO2, Inc.:http://wso2.com, >> Mobile: +94776442007 >> >> >> > > > -- > -- > Lahiru Sandaruwan > Software Engineer, > Platform Technologies, > WSO2 Inc., http://wso2.com > lean.enterprise.middleware > > email: [email protected] cell: (+94) 773 325 954 > blog: http://lahiruwrites.blogspot.com/ > twitter: http://twitter.com/lahirus > linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 > > -- Best Regards, Nirmal Nirmal Fernando. PPMC Member & Committer of Apache Stratos, Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
