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... > > 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. > > 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
