Thanks all for the ideas.
Will be moving forward with option 2.
repository/conf/userstores/user-mgt.xml
repositoty/conf/tenants/1/userstores/user-mgt.xml - configuration for
tenant with tenant-id: 1
repositoty/conf/tenants/2/userstores/user-mgt.xml - configuration for
tenant with tenant-id: 2
So a product will have 2 locations, inside repository/conf to be synced
with dep-sync as,
- repositoty/conf/userstores ('userstores' just to avoid syncing all
content in conf directory) and
- repository/conf/tenants
Thanks,
Pushpalanka Jayawardhana
Software Engineer
WSO2 Lanka (pvt) Ltd
[image:
Facebook]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.facebook.com%2Fpushpalanka>
[image:
Twitter]<http://s.wisestamp.com/links?url=http%3A%2F%2Ftwitter.com%2FPushpalanka>
[image:
LinkedIn]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.linkedin.com%2Fprofile%2Fview%3Fid%3D75175642%26trk%3Dtab_pro>
[image:
Blogger]<http://s.wisestamp.com/links?url=http%3A%2F%2Fpushpalankajaya.blogspot.com%2F>
[image:
SlideShare]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2FPushpalanka>
Mobile: +94779716248
<http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Dc984892c0c4ca423%26v%3D3.13.2%26t%3D1361257731639%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>
On Tue, Jun 25, 2013 at 11:46 AM, Dhanuka Ranasinghe <dhan...@wso2.com>wrote:
> Hi,
>
> I am not much aware about carbon architecture, but have few thoughts to
> achieve above requirements.
>
> 1. Having a high available singleton (HA) service (through MBeans) then
> make sure it is active only in master node.
> 2. When the master node down one of other member in cluster become a
> master node and it's HA service will be activated.
> 3. All the configurations done and read through that HA service, by doing
> this whether it's UI or local file system change it will be synch with
> every time with every member.
>
>
> Cheers,
> Dhanuka
>
> *Dhanuka Ranasinghe*
>
> Senior Software Engineer
> WSO2 Inc. ; http://wso2.com
> lean . enterprise . middleware
>
> phone : +94 715381915
>
>
> On Fri, May 31, 2013 at 2:41 PM, Srinath Perera <srin...@wso2.com> wrote:
>
>> Hi All,
>>
>> Azeez and myself was chatting, and following are some of the conflicting
>> requirements.
>>
>> 1. like to edit configs from file system, and via UI avoiding two copies
>> if possible (have to avoid case where we edit file, then we edit via UI
>> where we lost the file updates).
>> 2. Need a way to sync configs across the cluster
>> 3. Make the sync model clear and consistent for both configs and
>> artifacts (currently we use dep-sync only with artifacts)
>> 4. Like to sync only one folder in the product with dep-sync
>>
> ^This will not be achieved, with the option.
> 5. We should not do product folder structure before major release (C5?)
>>
>> We need to find the best solution out of that.
>>
>> --Srinath
>>
>>
>>
>> On Thu, May 30, 2013 at 9:20 PM, Senaka Fernando <sen...@wso2.com> wrote:
>>
>>> Hi Srinath,
>>>
>>> IMHO, relying on a dep-sync-based model sounds appropriate here. We can
>>> have several strategies for dep-sync (i.e. registry, svn, manual etc), but
>>> the server will be driven by what's on the filesystem. IMHO, that's very
>>> straightforward.
>>>
>>> And, I think we need to first of all figure out what and what's going to
>>> be sync'ed and what's not. When it comes to some configuration files it
>>> might make sense to sync portions and keep some static. In that case, do we
>>> need to split those files in two? Also, we need to focus on the "things
>>> that change across environments and things that don't" for the sever
>>> configuration as in the "CAR-based Governance Story" for ESB configurations.
>>>
>>> Also, the dep-sync's notification model should work like the
>>> hierarchical cache invalidation model that Azeez proposed, making sure that
>>> things will scale.
>>>
>>> Thanks,
>>> Senaka.
>>>
>>>
>>> On Thu, May 30, 2013 at 4:46 PM, Jeewantha Dharmaparakrama <
>>> jeewan...@wso2.com> wrote:
>>>
>>>> Hi Srinath,
>>>>
>>>> If the node which detects the change in its config file redeploys the
>>>> config in every other node explicitly, we can ensure that every node sees
>>>> the change since there will always be one node which is responsible in
>>>> informing the others. I guess thats what depsync does IINM.
>>>>
>>>> If the config is stored in a central place, every node will have to
>>>> pull the change from that place. Here if one node fails to redeploy the
>>>> change, other nodes will be unaware about it so that the system will be
>>>> unstable. IMHO we should prefer the former.
>>>>
>>>> Jeewantha
>>>>
>>>>
>>>> On Thu, May 30, 2013 at 3:44 PM, Srinath Perera <srin...@wso2.com>wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> We just finished a review on UI for user stores and figured we are
>>>>> doing this in several ways. Pradeep, Prabath, and myself had a chat, and
>>>>> following are our thoughts.
>>>>>
>>>>> We have different types of configurations with carbon server
>>>>>
>>>>> 1) Some are only apply for one node (e.g. carbon.xml, registry.xml ..)
>>>>> 2) Some might be useful across a cluster, but we ask users to copy it
>>>>> to all the nodes (e.g. data sources, xacml policies, keystores ?? )
>>>>> 3) It is proposed that we will automatically replicate user-store
>>>>> configurations using deployment synchronizer when it is added to one node.
>>>>>
>>>>> To share the same configurations across all nodes in the cluster, we
>>>>> have several options.
>>>>>
>>>>> 1) We can have a config files, and use deployment sync to sync them
>>>>> across the cluster (Then, I think we need to have a cluster folder in conf
>>>>> or make clear what configurations are replicated).
>>>>>
>>>>> 2) We have a config file, but once read, we store them in a DB or in
>>>>> registry, since all nodes share same DB/ registry there is no need to
>>>>> replication (we can send a cluster message saying there is a update). Risk
>>>>> of this is after bring edited by UI and directly via the file, two sources
>>>>> might go out of sync and some updates can be lost when next update
>>>>> happend.
>>>>>
>>>>> 3) Data sources can be added via UI (goes to registry) or via file
>>>>> system (not replicated), which is a mix.
>>>>>
>>>>> I think we need to stick to one model out of #1 and #2. We thought dep
>>>>> sync model is the best as it is clear. But then we have to tell which part
>>>>> of the configs get replicated.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> --Srinath
>>>>>
>>>>> --
>>>>> ============================
>>>>> Srinath Perera, Ph.D.
>>>>> Senior Software Architect, WSO2 Inc.
>>>>> Visiting Faculty, University of Moratuwa
>>>>> Member, Apache Software Foundation
>>>>> Research Scientist, Lanka Software Foundation
>>>>> Blog: http://srinathsview.blogspot.com/
>>>>> Photos: http://www.flickr.com/photos/hemapani/
>>>>> Phone: 0772360902
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jeewantha Dharmaparakrama
>>>> Software Engineer; WSO2, Inc.; http://wso2.com/
>>>> Phone : (+94) 774726790
>>>> Skype : prasad.jeewantha
>>>> LinkedIn : http://www.linkedin.com/in/jeewanthad
>>>> Twitter: https://twitter.com/jeewamp
>>>> Blog: http://jeewanthad.blogspot.com/
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Senaka Fernando*
>>> Member - Integration Technologies Management Committee;
>>> Technical Lead; WSO2 Inc.; http://wso2.com*
>>> Member; Apache Software Foundation; http://apache.org
>>>
>>> E-mail: senaka AT wso2.com
>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>>> Linked-In: http://linkedin.com/in/senakafernando
>>>
>>> *Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>> ============================
>> Srinath Perera, Ph.D.
>> Director, Research, WSO2 Inc.
>>
>> Visiting Faculty, University of Moratuwa
>> Member, Apache Software Foundation
>> Research Scientist, Lanka Software Foundation
>> Blog: http://srinathsview.blogspot.com/
>> Photos: http://www.flickr.com/photos/hemapani/
>> Phone: 0772360902
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
