cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: regions
Date Fri, 18 Oct 2013 15:24:38 GMT
I was under the impression that from the UI you could select the current region and view/manipulate

I was planning on using this to deploy a region for local dev work at a client's office, but
maintain admin authority. Simply allowing tasks to be processed locally to them.

Perhaps I miss-interpreted the use of regions.

Does this mean I need to set the remote office as a dedicated cluster and have all that management
traffic over the site to site link?


Sent from my HTC

----- Reply message -----
From: "Marcus Sorensen" <>
To: "" <>
Subject: regions
Date: Fri, Oct 18, 2013 8:13 AM

Thanks for the reply.

On Fri, Oct 18, 2013 at 8:46 AM, Kishan Kavala <> wrote:
>> -----Original Message-----
>> From: Marcus Sorensen []
>> Sent: Friday, 18 October 2013 4:28 AM
>> To:
>> Subject: regions
>> I'm looking for more information on use cases for regions. I've been through:
>> 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,

> [1]
> [2]
> [3]
> [4]
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message