Ah.. We had a lot of discussions with you, Lakmal, Imesh, and Reka. What i had my mind was the final outcome. Sorry that i didn't remember...
Anyway let's discuss the best solution here... :) On Sat, Nov 16, 2013 at 9:31 AM, Nirmal Fernando <[email protected]>wrote: > 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. > You mean the cartridge.xml and partition.xml ? I think cartridge.xml can be kept in the cloud controller. > > Hint: You should think carefully, how to map these two effectively. :) > I felt like we do not need a mapping here. Do we? Basically cartridge.xml is having account details of IaaS providers, instance types etc(what we had before). partition.xml is defined in Autoscaler side and when the Autoscaler decides to spawn/ terminate instance, it will pass the complete "Partition" object with the request to cloud controller. Then CC just get the information and do the needful. WDYT? Thanks. > > > > 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/ > -- -- 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
