I was under the impression that from the UI you could select the current region and view/manipulate resources.
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? Thanks. Sent from my HTC ----- Reply message ----- From: "Marcus Sorensen" <shadow...@gmail.com> To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> 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 <kishan.kav...@citrix.com> wrote: > >> -----Original Message----- >> From: Marcus Sorensen [mailto:shadow...@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 >
