On Sat, Nov 16, 2013 at 10:22 AM, Lahiru Sandaruwan <[email protected]>wrote:
> > > > On Sat, Nov 16, 2013 at 10:10 AM, Nirmal Fernando > <[email protected]>wrote: > >> >> >> >> On Sat, Nov 16, 2013 at 9:59 AM, Lahiru Sandaruwan <[email protected]>wrote: >> >>> 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. >>> >> >> Yes. >> >>> >>>> 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. >>> >> >> Well, who selects the IaaS? It's the Autoscaler, right? In Cartridge >> definition, you map image ids etc, per IaaS basis. Hence, you need a >> mapping. >> > > Yes, Of course we need a validation when the partition.xml is deployed. We > have to check whether the defined IaaSes, Zones etc. actually there in the > IaaS. We can have a simple API from CC for this. Autoscaler pass the > "Partition" object and get it validated. > I think what we need is something just before the deployment, that is in the partition creation time. Otherwise, it's a nightmare for the person who configures partitions. I think we've already discussed about a tool to create these partitions. We might need to get that in. > So after the deployment, what Autoscaler see is just a set of partitions > and it takes decision on them. > > Thanks. > >> >>> 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 >>> >>> >> >> >> -- >> 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 > > -- Best Regards, Nirmal Nirmal Fernando. PPMC Member & Committer of Apache Stratos, Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
