Nirmal, Actually there are two levels of validations,
1. Whether the mentioned partition parameters are available and can be accessed through CC(Jclouds layer) 2. Whether the this policy can be matched with a particular cartridge. On Sun, Nov 24, 2013 at 11:35 AM, Nirmal Fernando <[email protected]>wrote: > I think we got it all wrong! :( I was thinking my head-off and finally > found the correct relationship. > IMO what we have been discussing is #1. > > 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). > This use case is #2. +1 for your suggestion. We can follow this model exactly when we display policies against Cartridges at an UI for subscription. We should only display eligible policies against a cartridge. Thanks. > > > 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/ > -- -- 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
