I think we got it all wrong! :( I was thinking my head-off and finally found the correct relationship.
The actual validation of a deployment policy can only be made when we display the policies per a cartridge. System could have all sorts of policies but we should only allow subscriptions for valid policies of a given Cartridge (Since, it's the Cartridge which defines the IaaSes it could handle, it's not possible to validate before that). On Sat, Nov 16, 2013 at 12:05 PM, Lahiru Sandaruwan <[email protected]>wrote: > > > > On Sat, Nov 16, 2013 at 11:59 AM, Nirmal Fernando > <[email protected]>wrote: > >> >> >> >> On Sat, Nov 16, 2013 at 11:48 AM, Lahiru Sandaruwan <[email protected]>wrote: >> >>> >>> >>> >>> 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. >>> >> >> What I meant was to not let anyone define invalid partition, by enforcing >> the partition definition via a tool. >> > > Ahh. Ok.. > > What i had in my was to let the dev-op(or similar person) deploy all the > xmls manually as file in the serves. > But later we will provide the facility to deploy them from GUI. > > Is that what you mean or a different tool? If so have we discussed on such > a tool in dev(sorry if i have missed)? > > Thanks. > >> >>> >>> >>>> 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 >>> >>> >> >> >> -- >> 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/
