stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <im...@apache.org>
Subject Re: Hangout Presentation
Date Tue, 19 Nov 2013 04:21:06 GMT
Thanks Ishmal!! Appreciate your feedback!!

Thanks
Imesh




On Tue, Nov 19, 2013 at 12:16 AM, Nirmal Fernando <nirmal070125@gmail.com>wrote:

> 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