Return-Path: X-Original-To: apmail-stratos-dev-archive@minotaur.apache.org Delivered-To: apmail-stratos-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1293C102C7 for ; Sat, 16 Nov 2013 06:36:47 +0000 (UTC) Received: (qmail 90068 invoked by uid 500); 16 Nov 2013 06:36:45 -0000 Delivered-To: apmail-stratos-dev-archive@stratos.apache.org Received: (qmail 90034 invoked by uid 500); 16 Nov 2013 06:36:44 -0000 Mailing-List: contact dev-help@stratos.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stratos.incubator.apache.org Delivered-To: mailing list dev@stratos.incubator.apache.org Received: (qmail 90026 invoked by uid 99); 16 Nov 2013 06:36:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Nov 2013 06:36:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lahirus@wso2.com designates 209.85.216.173 as permitted sender) Received: from [209.85.216.173] (HELO mail-qc0-f173.google.com) (209.85.216.173) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Nov 2013 06:36:37 +0000 Received: by mail-qc0-f173.google.com with SMTP id m4so2694518qcy.18 for ; Fri, 15 Nov 2013 22:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=URRwLEt7S8sYpbCD/+dcUgfyov863uPCk+pVA5nPbYE=; b=i8E1mzC+qjFvL94WoxphHEvHhRVZoS8Seoi6+JpwKXWCgsXZNCFeyqXTeaZj+6QEG3 eHm+xouYDM7kodYS2sVQZ7Kx1OllL+fNL8bsKVOvePnHo0lAQeXSjWpvO0rtSuLHapDc SMyrqlfPjTpWDN1zOySqYANA1FLQtETZL4pzU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=URRwLEt7S8sYpbCD/+dcUgfyov863uPCk+pVA5nPbYE=; b=FCX+FXjE7j6IfOmbB3Fdl3ZENfCpyKwsy42ZqBARazslzaUB5mXwhreEbwV/XVnKCr JO35S/RZsNoTOZnFqXulHrrejJp49h7tcoPMSGpBo9PFkTmf2mbiSvIkO1fiGExPEClv oyAOV2s3Kinj8tTEQIaHXlUrJRMCY9OYnG+PTVRL4lD93lDJQIBwjEpqK34bU1cczjIK y9N89jcZN6bPoFMfhP2pdDKYLEucRYBiJbjLjxPamAd7YAR6VFMxdnOq74coxmgWYngX yRg1Y+MzkNcGs/0j0Bu767PXHF3tvs3XCxY3hXdS5E6dCrr/KYo/akqtfD+QrP36pUPl 2+2Q== X-Gm-Message-State: ALoCoQmU8dMQlEpxI+X5FKORcrWNWpwBhPsMccIJddIdAJ5H7BAQX1ar1r3trHcv2+DWxIukE5o2 X-Received: by 10.224.75.200 with SMTP id z8mr16592751qaj.71.1384583775924; Fri, 15 Nov 2013 22:36:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.169.229 with HTTP; Fri, 15 Nov 2013 22:35:55 -0800 (PST) In-Reply-To: References: From: Lahiru Sandaruwan Date: Sat, 16 Nov 2013 12:05:55 +0530 Message-ID: Subject: Re: IaaS support for multiple partition To: "dev@stratos.incubator.apache.org" Content-Type: multipart/alternative; boundary=001a11c30c1e20455304eb458882 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c30c1e20455304eb458882 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 16, 2013 at 11:59 AM, Nirmal Fernando wrote: > > > > On Sat, Nov 16, 2013 at 11:48 AM, Lahiru Sandaruwan wrote: > >> >> >> >> On Sat, Nov 16, 2013 at 10:35 AM, Nirmal Fernando > > wrote: >> >>> >>> >>> >>> On Sat, Nov 16, 2013 at 10:22 AM, Lahiru Sandaruwan wrote: >>> >>>> >>>> >>>> >>>> On Sat, Nov 16, 2013 at 10:10 AM, Nirmal Fernando < >>>> nirmal070125@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Sat, Nov 16, 2013 at 9:59 AM, Lahiru Sandaruwan 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 < >>>>>> nirmal070125@gmail.com> 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 < >>>>>>> lahirus@wso2.com> 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 < >>>>>>>> reka@wso2.com> 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: lahirus@wso2.com 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: lahirus@wso2.com 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: lahirus@wso2.com 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: lahirus@wso2.com 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: lahirus@wso2.com 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 --001a11c30c1e20455304eb458882 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Nov 16, 2013 at 11:59 AM, Nirmal Fernando <nirmal0701= 25@gmail.com> wrote:



On Sat, Nov 16, 20= 13 at 11:48 AM, Lahiru Sandaruwan <lahirus@wso2.com> wrote:



On Sat, Nov 16, 2013 at 10:35 A= M, Nirmal Fernando <nirmal070125@gmail.com> wrote:



On Sat, Nov 16, 2013 at 10:22 AM, Lahiru Sandaruwan = <lahirus@wso2.com<= /a>> wrote:



On Sat, Nov 16, 2013 at 10:10 AM, Nirmal Fernando &l= t;nirmal070125@= gmail.com> wrote:

Yes.





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.<= /div>
But later we will provide the facility to deploy them from GUI.

Is that what you mean or a different tool? If so have w= e discussed on such a tool in dev(sorry if i have missed)?

Thanks.

=A0
I think we've already discussed about = a tool to create these partitions. We might need to get that in.
<= /div>

+1.

Thanks.


So after the deployment, what Autoscaler see is just a = set of partitions and it takes decision on them.=A0

Thanks.

WDYT?

Thanks.






On Sat, Nov 16, 2013 at 12:51 AM, Lahiru Sandaruwan <lahir= us@wso2.com> wrote:
Hi all,

I've been = thinking on the cloud partitions definition in the system. Currently we pla= n to define them in Cloud Controller config and then in the cartridge.xml a= s Reka also explained above.
In this design, we have to use a cartridge.xml if we want to hot deplo= y. 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 p= assed to Cloud Controller which has all the details to spwan the instance i= n correct partition.

Here are the advantages over current plan.

  • Definitions of cloud partitions are used in Autos= caler for making the decision on the capacity planing and the deployment pa= ttern.=A0
  • This will remove following limitation from the current design.=A0
    • <= /ul>
    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) o= f 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 &= lt;reka@wso2.com>= wrote:
Reka, it's good that you fo= llowed the same pattern we had in Cartridge design. It's best if you ca= n 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 r= eadability purpose. If it is redundant, then we can get rid of the id and g= o ahead with the type.
=A0
* How the policy file and cartridge definition relates? Sho= uld one configure policy file and cartridge definition together?
=A0Yah. Devop need to confi= gure cartridge definition as well as the policy file together. But still, a= ccording to my understanding, policy file can be generic and independent fr= om the cartridge definition. In this case, we might not able to apply all t= he policies to all the cartridge definition. So, it is Stratos Manger's= responsibility to validate the cartridge definition against the policy fil= es and display the applicable list of policies to a cartridge.

Thanks,
Reka
=
=A0

Thanks,
Reka
=A0=A0


--
Reka Thirunavukkarasu
Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007



--
Best Regards,
Nirmal

Nirmal Fernand= o.
PPMC Member & Committer of Apache Stratos,
Senior Software Eng= ineer, WSO2 Inc.




<= font color=3D"#888888">--



--
Best R= egards,
Nirmal

Nirmal Fernando.
PPMC Member & Committer of= Apache Stratos,
Senior Software Engineer, WSO2 Inc.




--
<= div dir=3D"ltr">Best Regards,
Nirmal

Nirmal Fernando.
PPMC Mem= ber & Committer of Apache Stratos,
Senior Software Engineer, WSO2 In= c.




--
<= div dir=3D"ltr">Best Regards,
Nirmal

Nirmal Fernando.
PPMC Mem= ber & Committer of Apache Stratos,
Senior Software Engineer, WSO2 In= c.




--
Best Regards,
Nirmal

Nirmal Fernando= .
PPMC Member & Committer of Apache Stratos,
Senior Software Engi= neer, WSO2 Inc.




--
--
Lahiru Sandaruwan
Softw= are Engineer,
Platform Technologies,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

email: lahirus@wso2.com cell: (+94) 773 325 954
blog: <= a href=3D"http://lahiruwrites.blogspot.com/" target=3D"_blank">http://lahir= uwrites.blogspot.com/
twitter: http://tw= itter.com/lahirus
linked-in: http://lk.linkedin.com/pub/l= ahiru-sandaruwan/16/153/146

--001a11c30c1e20455304eb458882--