On Mon, Jul 1, 2013 at 3:08 PM, Prabath Siriwardena <[email protected]>wrote:
> Adding a user store is not as dynamic as adding a proxy or sequence.. > thinking both in the same way is not quite right.. There are two things. 1. Configurations required to start the server. eg. user-mgt.xml, carbon.xml registry.xml. Those things required at the server start up and hence can not be dep synch. We need to use a mechanism like puppet or some other thing which fetch those configurations from some location. 2. Configurations added at run time. Can be added through mgt-node and system will dep-sync that. thanks, Amila. > > Thanks & regards, > -Prabath > > > On Mon, Jul 1, 2013 at 2:54 PM, Amila Suriarachchi <[email protected]> wrote: > >> >> >> >> On Mon, Jul 1, 2013 at 2:38 PM, Prabath Siriwardena <[email protected]>wrote: >> >>> Not quite right.. >>> >>> A given user sore cannot just exist on its own.. it has to maintain the >>> order with others.. That needs to be maintain at the user-mgt.xml.. >>> >>> By breaking this in to separate user-store files only make things >>> complex.. >>> >> >> I think keeping dynamic things in user-mgt.xml is the complex one. >> >> For an example in order to start the server you need to have a user >> realm which is given at the user manager xml. Then if you want to add a >> additional user stores you can use a separate user store file. There is no >> requirement to replicate whole user manager xml and re initialise user >> realm for that. >> >> thanks, >> Amila. >> >> >>> >>> Thanks & regards, >>> -Prabath >>> >>> On Mon, Jul 1, 2013 at 2:27 PM, Pradeep Fernando <[email protected]>wrote: >>> >>>> Hi All, >>>> >>>> >>>> On Tue, Jun 25, 2013 at 4:00 PM, Amila Suriarachchi <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jun 25, 2013 at 3:05 PM, Pushpalanka Jayawardhana < >>>>> [email protected]> 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. >>>>> >>>> >>>> Azeez,Amila,me had a chat on the $subject. We have to follow the above >>>> approach it seems. >>>> >>>> Here the additional user-store configs are runtime artifacts and can be >>>> treated in the same way we do other runtime artifacts. User-mgt.xml is a >>>> static config file and it needs not to be dep-synched. >>>> >>>> @Prabath and Pushpalanka; >>>> >>>> Can we achieve the functionality using above method... >>>> >>>> >>>> On technical front, if we try to listen to more than one directory, >>>> things get bit complicated. Specially if you want to do dep-sync for those >>>> directories. Normally we maintain a one dep-sync thread per tenant. If we >>>> listen/dep-sync more than one directory - > two dep-sync thread per tenant. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> 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 < >>>>>> [email protected]> 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 <[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 >>>>>>>> >>>>>>> ^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 >>>>>>>> <[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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Amila Suriarachchi* >>>>> >>>>> Software Architect >>>>> >>>>> WSO2 Inc. ; http://wso2.com >>>>> lean . enterprise . middleware >>>>> >>>>> phone : +94 71 3082805 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Pradeep Fernando* >>>> Associate Technical Lead;WSO2 Inc.; http://wso2.com >>>> >>>> blog: http://pradeepfernando.blogspot.com >>>> m: +94776603662 >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >>> >> >> >> >> -- >> *Amila Suriarachchi* >> >> Software Architect >> WSO2 Inc. ; http://wso2.com >> lean . enterprise . middleware >> >> phone : +94 71 3082805 >> > > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
