You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Marcus Sorensen <sh...@gmail.com> on 2013/10/18 00:58:00 UTC

regions

I'm looking for more information on use cases for regions. I've been through:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-Style+Regions+Functional+Spec

And I've set up two management servers as separate regions. From what
I can tell, I'm not sure why I'd want to use it.  1) accounts need to
be replicated manually, and 2)I can't make an API call to one MS to
deploy in another region (or at least I don't see a documented way to
do this). Between those two limitations, it means I could also set up
two standalone management servers and they'd function the same, aside
from the slight UI change of having another region listed in the UI. I
realize there are GSLB and portable IP features, but they're not
mentioned in the functional spec. I'm just looking for the differences
from a management perspective and I don't see much.

Re: regions

Posted by Marcus Sorensen <sh...@gmail.com>.
Thanks for the reply.

On Fri, Oct 18, 2013 at 8:46 AM, Kishan Kavala <Ki...@citrix.com> wrote:
>
>> -----Original Message-----
>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>> Sent: Friday, 18 October 2013 4:28 AM
>> To: dev@cloudstack.apache.org
>> Subject: regions
>>
>> I'm looking for more information on use cases for regions. I've been through:
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-
>> Style+Regions+Functional+Spec
>>
> [KK] Requirements doc has some info on use cases [1]
>> And I've set up two management servers as separate regions. From what I can
>> tell, I'm not sure why I'd want to use it.  1) accounts need to be replicated
>> manually, and
> [KK] Account sync need not be manual. Currently it is expected that sync is done outside CS. Either though integrating with directory service or using a portal layer above.
> Alex Ough started a discussion [2] to use messaging framework to sync account data

Ok, that's good to know. To me this is pretty much the one thing from
a management perspective that would differentiate regions vs
standalone clusters. If a cloud operator has the means to manage
external accounts on their own then they can also easily deploy
multiple standalone management clusters and treat them as endpoints
with the same amount of effort. If they don't, then regions become
really useful if the feature handles account sync.

>
> 2)I can't make an API call to one MS to deploy in another region
> [KK] AWS also doesn't support making API call to another region. You need select an end_point before making an API call.

Sure, but I don't generally think of CloudStack in terms of what AWS
does or doesn't do. It never really occurs to me that a feature might
do or not do something because it's what AWS does. I think we do that
a bit too much. At any rate, I was just looking for reasons from a
management perspective to use regions over standalone management
clusters; if I have to choose an endpoint then at least in this regard
it doesn't matter if that endpoint is a standalone cloudstack install
or a region.

>
>> (or at least I don't see a documented way to do this). Between those two
>> limitations, it means I could also set up two standalone management servers
>> and they'd function the same, aside from the slight UI change of having another
>> region listed in the UI. I realize there are GSLB and portable IP features, but
>> they're not mentioned in the functional spec.I'm just looking for the
>> differences from a management perspective and I don't see much.
> [KK] GSLB spec [3]. EIP spec [4]

Thanks. I also see that in some of the docs there are unimplemented
things. I realize that it's a work in progress. Portable IPs look to
be a feature within a region, and not cross-region, so this feature
would apply to standalone mgmt servers, each being their own
standalone region, correct?

In a nutshell, if a cloud operator is managing their own accounts
outside of CS, and has no intentions of buying a netscaler, there is
currently no reason to link multiple sites into regions. Just treat
each standalone site as its own endpoint. Is this a correct
assessment? Also, it seems fairly straightforward to link two sites
together into regions later as the feature gains more functionality,
correct?

>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-Style+Regions
> [2] http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201310.mbox/browser
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+%28Global+Server+Load+Balancing%29+Functional+specification+and+Design+Document
> [4] https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+IP
>

RE: regions

Posted by Kishan Kavala <Ki...@citrix.com>.
> -----Original Message-----
> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> Sent: Friday, 18 October 2013 4:28 AM
> To: dev@cloudstack.apache.org
> Subject: regions
> 
> I'm looking for more information on use cases for regions. I've been through:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-
> Style+Regions+Functional+Spec
> 
[KK] Requirements doc has some info on use cases [1]
> And I've set up two management servers as separate regions. From what I can
> tell, I'm not sure why I'd want to use it.  1) accounts need to be replicated
> manually, and 
[KK] Account sync need not be manual. Currently it is expected that sync is done outside CS. Either though integrating with directory service or using a portal layer above.
Alex Ough started a discussion [2] to use messaging framework to sync account data

2)I can't make an API call to one MS to deploy in another region
[KK] AWS also doesn't support making API call to another region. You need select an end_point before making an API call.

> (or at least I don't see a documented way to do this). Between those two
> limitations, it means I could also set up two standalone management servers
> and they'd function the same, aside from the slight UI change of having another
> region listed in the UI. I realize there are GSLB and portable IP features, but
> they're not mentioned in the functional spec.I'm just looking for the
> differences from a management perspective and I don't see much.
[KK] GSLB spec [3]. EIP spec [4]

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-Style+Regions
[2] http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201310.mbox/browser
[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+%28Global+Server+Load+Balancing%29+Functional+specification+and+Design+Document
[4] https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+IP