On Tue, Jun 25, 2013 at 4:19 PM, Pushpalanka Jayawardhana <la...@wso2.com>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 4:00 PM, Amila Suriarachchi <am...@wso2.com>wrote: > >> >> >> >> 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. >> > As I have understood, still we will have to re initialise all user stores, > unless we are adding or deleting a secondary user store at the very end of > the chain. This is because the order of the secondary user stores matters > and at deletion or insertion we need to update with the new order. Correct > me if I am wrong. > how you determine the order of the user stores? Current implementation logic may not support that. I am not sure how exactly you keep the users stores. even you keep it on a chain you should be able to change one without changing others. thanks, Amila. > >> 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 >> >> > -- *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
