stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nirmal Fernando <nirmal070...@gmail.com>
Subject Re: Hangout Presentation
Date Mon, 18 Nov 2013 18:46:20 GMT
Ishmal,

You can find the slides from here (Imesh shared it in another thread):
http://www.slideshare.net/imesh/load-balancer-component-architecture-apache-stratos-400


On Mon, Nov 18, 2013 at 11:58 PM, Ishmal Bartley <
Ishmal.Bartley@caremore.com> wrote:

>  Great Presentation today!
>
> Is it possible to get a copy of the slide deck that was presented.
>
>
>
>
>
>
>
>
>
> Thanks!
>
>
>
> -IB
>
>
>
> *From:* Chalfant, Dale (DTI) [mailto:Dale.Chalfant@state.de.us]
> *Sent:* Monday, November 18, 2013 7:27 AM
> *To:* dev@stratos.incubator.apache.org
> *Cc:* pvereycken@greaterbrain.com
> *Subject:* RE: IaaS support for multiple partition
>
>
>
> (Adding Paul Vereycken)
>
>
>
> Hello:
>
>
>
> If we are to span a system across two clouds due to a need for an increase
> in capacity, it would be neat to take into consideration data gravity.
> Picture rubber bands connecting our components together wherever there is
> port-to-port communication.  If there is a heavy need for components to be
> near one another because (say a strong affinity due to the data going
> between them in the case where a component that talks a LOT to another
> component), we would have a really strong rubber band connecting the two.
> If there are small packets that are callouts to functionality with small
> documents, we would similarly use a smaller rubber band.
>
>
>
> Then based upon where we want to slot the extended capacity, the rubber
> bands would naturally draw the components together when needed.  But, if no
> capacity is available to handle (and the cost or other factors are really
> big) to have the two components together, the components **can** stretch
> between the clouds; we may even end up with a components in different
> regions/providers.  Granted, as we adjust our capacity on the next cycle,
> the draw of the rubber bands may cause change to get the components next to
> one another (say a spot instance opens up).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Kind regards,
>
>
>
>
>
> Dale Chalfant
>
> Enterprise Architect
>
> (302) 739-9653
>
>
>
>
>
>
>
> *From:* Lahiru Sandaruwan [mailto:lahirus@wso2.com]
> *Sent:* Saturday, November 16, 2013 1:36 AM
> *To:* dev@stratos.incubator.apache.org
> *Subject:* Re: IaaS support for multiple partition
>
>
>
>
>
>
>
> On Sat, Nov 16, 2013 at 11:59 AM, Nirmal Fernando <nirmal070125@gmail.com>
> wrote:
>
>
>
>
>
> On Sat, Nov 16, 2013 at 11:48 AM, Lahiru Sandaruwan <lahirus@wso2.com>
> wrote:
>
>
>
>
>
> On Sat, Nov 16, 2013 at 10:35 AM, Nirmal Fernando <nirmal070125@gmail.com>
> wrote:
>
>
>
>
>
> On Sat, Nov 16, 2013 at 10:22 AM, Lahiru Sandaruwan <lahirus@wso2.com>
> 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 <lahirus@wso2.com>
> 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
>
>
>



-- 
Best Regards,
Nirmal

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

Blog: http://nirmalfdo.blogspot.com/

Mime
View raw message