stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chalfant, Dale (DTI)" <Dale.Chalf...@state.de.us>
Subject RE: IaaS support for multiple partition
Date Mon, 18 Nov 2013 15:26:33 GMT
(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).

[cid:image002.png@01CEE448.A6F16820]




[cid:image004.png@01CEE448.A6F16820]


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<mailto:nirmal070125@gmail.com>>
wrote:


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


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


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


On Sat, Nov 16, 2013 at 10:10 AM, Nirmal Fernando <nirmal070125@gmail.com<mailto:nirmal070125@gmail.com>>
wrote:


On Sat, Nov 16, 2013 at 9:59 AM, Lahiru Sandaruwan <lahirus@wso2.com<mailto: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<mailto: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<mailto: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<mailto: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<tel:%2B94776442007>



--
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<tel:%2B94776442007>




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

email: lahirus@wso2.com<mailto:lahirus@wso2.com> cell: (+94) 773 325 954<tel:%28%2B94%29%20773%20325%20954>
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<mailto:lahirus@wso2.com> cell: (+94) 773 325 954<tel:%28%2B94%29%20773%20325%20954>
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<mailto:lahirus@wso2.com> cell: (+94) 773 325 954<tel:%28%2B94%29%20773%20325%20954>
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<mailto:lahirus@wso2.com> cell: (+94) 773 325 954<tel:%28%2B94%29%20773%20325%20954>
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<mailto: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


Mime
View raw message