Well, yes, you can manipulate the current region via the UI, but 'current region' is just basically just the same as the normal UI view, from what I can tell. You can see the zones, everything within the zone, and manage resources within those zones. The current region doesn't look or act any different from a standalone (or single-region as it were) setup. There are now links to your other management servers under the 'regions' section and at the top of the page, but it acts just like you were to log into one standalone mgmt server, then log into the other.
On Fri, Oct 18, 2013 at 9:24 AM, kel...@backbonetechnology.com <kel...@backbonetechnology.com> wrote: > 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 >>
