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. > > 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/
