Hi Pulasthi, All configuration files needs to be under repository/conf..
Thanks & regards, -Prabath On Tue, Jun 25, 2013 at 10:54 AM, Pulasthi Supun <[email protected]> wrote: > Hi All > > > On Tue, Jun 25, 2013 at 10:36 AM, Darshana Gunawardana > <[email protected]>wrote: > >> Hi, >> >> >> >> On Tue, Jun 25, 2013 at 10:00 AM, Pushpalanka Jayawardhana < >> [email protected]> wrote: >> >>> >>> 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 12:08 AM, Pulasthi Supun <[email protected]>wrote: >>> >>>> >>>> >>>> >>>> On Mon, Jun 24, 2013 at 11:55 PM, Pradeep Fernando <[email protected]>wrote: >>>> >>>>> --Pradeep >>>>> sent from my phone >>>>> >>>>> On Jun 24, 2013 11:25 PM, "Pushpalanka Jayawardhana" <[email protected]> >>>>> wrote: >>>>> > >>>>> > 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 >>>>> >>>>> Is it possible to have the tenant directory structure independent from >>>>> the user store directory. In the future there will be few config files >>>>> with >>>>> similar requirements I believe... >>>>> >>>> +1. If we move forward with the option 1, suggested by Prabath, then >>> there is no userstores directory. So this will be resolved. >>> repository/conf/user-mgt.xml >>> repositoty/conf/tenants/1/user-mgt.xml - configuration for tenant with >>> tenant-id: 1 >>> repositoty/conf/tenants/2/user-mgt.xml - configuration for tenant with >>> tenant-id: 2 >>> >>> Just is it ok to sync everything inside repository/conf? >>> >> >> AFAIK, syncing everything in repository/conf may not be suitable since >> conf directory can contain configurations specific to local node in a >> cluster. For an example, a node can have a data-source configurations which >> is used to mount its local registry. >> > > What i am proposing is a small variation of the second option. I think it > would be nice to have all the conf files related to a single tenant in a > one place or it will be messy when we add more conf files, what i am > proposing is like this. > > repository/conf/userstores/user-mgt.xml > repository/tenants/1/conf/userstores/user-mgt.xml - configuration for > tenant with tenant-id: 1 > repository/tenants/2/conf/userstores/user-mgt.xml - configuration for > tenant with tenant-id: 2 > > Since the " repository/tenants" is already synced there will be no need to > add an additional folder to be synced. And all the configurations files > that need to be synced can be added under the conf folder. This is just > what came to my mind. > > So i think the better approach will be the second approach. >> >> Thanks, >> Darshana. >> >> >>> This also came to my mind can we have some structure like the >>>> following >>>> repository/tenants/1/conf/userstores/user-mgt.xml this way whenever we >>>> want to add another config file that needs to be synced we can just add it >>>> under the "repository/tenants/1/conf/". Otherwise we will have tenant >>>> information here and there. >>>> >>> Yes. We have to select from whether we keep configuration files at one >>> place or tenant specific files in one place. >>> I think having tenant's configurations in one place will be better. If >>> all tenant configurations(that are allowed to be modified by the tenant >>> admin) are in one folder, permission needs to be given only to that folder, >>> if tenant admin wish to change any. >>> >>> >>>> >>>> >>>>> > This is similar to the structure used in deploying artifacts at >>>>> repository/tenants/1/ for tenants, as currently existing. >>>>> > So we already have two folders synced with dep-sync in a product. >>>>> One at repositoy/deployment/server/ and one at repository/tenants/. >>>>> > 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 >>>>> > >>>>> > >>>>> > Mobile: +94779716248 >>>>> >>>>> > >>>>> > On Fri, May 31, 2013 at 2:52 PM, Prabath Siriwardena < >>>>> [email protected]> wrote: >>>>> >> >>>>> >> I guess dep sync based approach will solve these... >>>>> >> >>>>> >> Thanks & regards, >>>>> >> -Prabath >>>>> >> >>>>> >> >>>>> >> On Fri, May 31, 2013 at 2:41 PM, Srinath Perera <[email protected]> >>>>> 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 <[email protected]> >>>>> 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 < >>>>> [email protected]> 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 < >>>>> [email protected]> 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 >>>>> >>>>>> [email protected] >>>>> >>>>>> 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 >>>>> >>>>> [email protected] >>>>> >>>>> 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 >>>>> >>> [email protected] >>>>> >>> 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 >>>>> >> [email protected] >>>>> >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >> >>>>> > >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Pulasthi Supun >>>> Software Engineer; WSO2 Inc.; http://wso2.com, >>>> Email: [email protected] >>>> Mobile: +94 (71) 9258281 >>>> Blog : http://pulasthisupun.blogspot.com/ >>>> Git hub profile: https://github.com/pulasthi >>>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Regards, >> >> * >> Darshana Gunawardana >> *Software Engineer >> WSO2 Inc.; http://wso2.com* >> E-mail: [email protected] >> **Mobile: +94718566859 >> * >> Lean . Enterprise . Middleware >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > Regards, > Pulasthi > > > > -- > -- > Pulasthi Supun > Software Engineer; WSO2 Inc.; http://wso2.com, > Email: [email protected] > Mobile: +94 (71) 9258281 > Blog : http://pulasthisupun.blogspot.com/ > Git hub profile: https://github.com/pulasthi > > _______________________________________________ > Architecture mailing list > [email protected] > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
