On Sat, Nov 16, 2013 at 10:35 AM, Nirmal Fernando <[email protected]>wrote:
> > > > 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. > Exactly, i was trying to say the same. Validation should happen at the deployment time and let the person who configure/ deploy them whether it was successful. I mean if the validation fails, deployment should fail. > I think we've already discussed about a tool to create these partitions. > We might need to get that in. > +1. Thanks. > > >> 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/ > -- -- 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
