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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
