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
