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
