Hi Srinath, All, +1 for the idea. This make life easy when you want to manually configure the extended nodes in a cluster. Also autoscaling will be benefited.
As I see most of the configs needs only synching at the startup of the instance/ initial startup. But some may require dynamic update in runtime. How are we going to handle this (with depsync or any other mechanism)? thanks, On Thu, May 30, 2013 at 3:45 PM, Srinath Perera <[email protected]> wrote: > Sorry wrong topic. it should be "Synching Configurations across nodes in a > cluster" > > > 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 >> > > > > -- > ============================ > 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 > > -- Supun Malinga, Senior Software Engineer, WSO2 Inc. http://wso2.com http://wso2.org email - [email protected] <[email protected]> mobile - 071 56 91 321
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
