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. >>
