cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions
Date Sat, 09 Nov 2013 14:20:04 GMT
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.


On Sat, Nov 9, 2013 at 1:53 AM, Chip Childers <> 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 <>
>> 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]
>>> On 11/7/13 11:58 AM, "Chip Childers" <> wrote:
>>> On Thu, Nov 7, 2013 at 2:37 PM, Chiradeep Vittal
>>> <> 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.

View raw message