All, I'm new to the cloudstack project, so there can be something I missed for consideration, but the current region support seems to be inadequate (I hope this does not offend anyone...) because even if a customer can have multiple regions, the resources in each region are totally separated like resources of different customers. So my personal opinion is that it looks like this functionality is must-have not good-to-have to support the actual multiple regions. Once again, I can be wrong, and please correct me if so.
Anyway, I've added more design specs in wiki including the consideration of the support as a plug-in in resolving the #1 restriction. Please review them and let me know what you think. Thanks Alex Ough On Sat, Nov 9, 2013 at 8:20 AM, Daan Hoogland <daan.hoogl...@gmail.com>wrote: > H Guys, > > Can you shoot at my claims below, please? > > syncing being optional does not conflict with the code being in the > core server. It seems that making a plugin for this is misuse of the > plugin mechanism. To me it is more of an option to switch on or of > with a global setting, having some extra configuration. > > Also, cloudstack being a slave to the real user db is a separate issue > from cloudstack syncing its copy. > > As for answerring the cap; this is a security answer as well as an > operational answer. > > thanks, > Daan > > On Sat, Nov 9, 2013 at 1:53 AM, Chip Childers <chip.child...@gmail.com> > wrote: > > We are already (generally) AP for most infra changes really. I'd use > that model. Eventual consistency is better in this scenario. > > > >> On Nov 8, 2013, at 6:49 PM, Chiradeep Vittal < > chiradeep.vit...@citrix.com> wrote: > >> > >> I'd also like to highlight that it isn't a trivial problem. > >> Let's say there's 3 regions: this means there are 3 copies of the user > >> database that are geographically separated by network links that fail > >> quite often (orders of magnitude more than intra-DC networks). > >> > >> Here we run into the consequences of the CAP theorem [1]. > >> We can either have a CP or AP system: either approach makes some > tradeoffs: > >> 1. If we run a AP system, then the challenge is to resolve conflicting > >> updates > >> 2. If we run a CP system, then the challenge is to detect partitions > >> reliably and disallow updates during partitions. > >> > >> [1] http://en.wikipedia.org/wiki/CAP_theorem > >> > >>> On 11/7/13 11:58 AM, "Chip Childers" <chipchild...@apache.org> wrote: > >>> > >>> On Thu, Nov 7, 2013 at 2:37 PM, Chiradeep Vittal > >>> <chiradeep.vit...@citrix.com> wrote: > >>>> It may be an admin burden, but it has to be optional. There are other > >>>> ways > >>>> to achieve global sync (e.g., LDAP/AD/Oauth). > >>>> A lot of service providers who run cloudstack have their own user > >>>> database > >>>> / portal. In their implementations the CloudStack database is not the > >>>> master source of user records, but a slave. > >>> > >>> +1 to it being optional. > >> > >
