Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of daan.hoogland@gmail.com
 designates 209.85.223.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2CC95E5C-671A-4270-873E-E913D975D4F4@gmail.com>
References: <CEA2B708.321D1%chiradeep.vittal@citrix.com>
 <2CC95E5C-671A-4270-873E-E913D975D4F4@gmail.com>
From: Daan Hoogland <daan.hoogland@gmail.com>
Date: Sat, 9 Nov 2013 15:20:04 +0100
Message-ID: 
 <CAGQtxvaVCxmr4_-=X-hxJ9jvtzB-HAs9SGh=d+ht8V6W_o0aRw@mail.gmail.com>
Subject: Re: [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions
To: dev <dev@cloudstack.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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.childers@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.Vittal@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" <chipchilders@apache.org> wrote:
>>>
>>> On Thu, Nov 7, 2013 at 2:37 PM, Chiradeep Vittal
>>> <Chiradeep.Vittal@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.
>>