On Tue, Jun 25, 2013 at 3:05 PM, Pushpalanka Jayawardhana <la...@wso2.com>wrote:
> 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
>
Technically speaking this is not correct. User-mgt.xml is used to configure
UserRealm not only the userstore. So it should be usermanager.
But in this case what we want to dep-synch only the userstores. so my
suggestion is to put them under userstores folder with the store name.
eg. repository/deployment/server/userstores/userstore1.xml
repository/deployment/server/userstores/userstore2.xml.
For an example if we change one userstore there is not reason to dep-sychn
all user-mgt.xml and re initialise all user stores.
thanks,
Amila.
>
> 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
>
>
--
*Amila Suriarachchi*
Software Architect
WSO2 Inc. ; http://wso2.com
lean . enterprise . middleware
phone : +94 71 3082805
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
