Hi All, Following is how we are to use dep-sync to sync user store configurations across clusters, with some inputs from Charitha, Prabath and Pradeep.
- repository/conf/userstores/user-mgt.xml - configuration of super admin - repositoty/conf/userstores/tenants/1/user-mgt.xml - configuration for tenant with tenant-id: 1 - repositoty/conf/userstores/tenants/2/user-mgt.xml - configuration for tenant with tenant-id: 2 likewise 1. This is similar to the structure used in deploying artifacts at repository/tenants/1/ for tenants, as currently existing. 2. So we already have two folders synced with dep-sync in a product. One at repositoy/deployment/server/ and one at repository/tenants/. 3. We are to add one more folder to be synced with dep-sync at repository/conf/userstores/ Correct me, if I have got anything wrong. Glad to know any concerns or thoughts. 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 Fri, May 31, 2013 at 2:52 PM, Prabath Siriwardena <prab...@wso2.com>wrote: > I guess dep sync based approach will solve these... > > Thanks & regards, > -Prabath > > > 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 >> 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 >> >> > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > > _______________________________________________ > 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
