In order to have a clean view of the requirements I have created a wiki page and moved there a summary of the discussion so far. Fell free to view / edit the wiki page here https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering.
We can continue the discussion in this thread and I will update the wiki if more requirements, features occur. On Wed, Apr 13, 2011 at 6:54 PM, Ioannis Canellos <ioca...@gmail.com> wrote: > >> I definitely agree with those requirements. And I think this notion >> of group is really a key point here. >> I think we should be able to describe some kind of profile (maybe as >> simply as a list >> of features with the related configuration) and associate a profile to a >> node. >> >> I think we should have a description of those profiles available >> somewhere so that nodes >> can update themselves according to the profile associated to them. >> This way, changing the >> profile would affect all associated nodes. > > > I like the idea of the profile. If I may suggest that we could provide a > default profile and provisioning tools (shell commands, and configuration > files) that would allow the cluster admin to partition the nodes to profiles > and build various topologies. > > > I think having each node >> pulling the configuration is safer >> than pulling changes to it. For example, if one node is stopped in >> your group, you want the changes >> to be applied when it will come back up, so the description of the >> wanted state need to be available. > > > A would prefer a mixed mode. By mixed mode I mean broadcast changes and > pull configuration "on cluster join". This way you > avoid unnecessary polling, without the danger of staying out of sync. > > >> I don't see many reasons for stopping a single bundle unless you want >> to stop the feature it belongs too. >> > > As a user I agree on that. As a karaf developer I disagree, because since > the features concept is optional, it would be best to provide the means even > to those that don't use features. > > >> > Something like DOSGi but with more tools and options like >> > provisioning, loadbalance etc. >> >> I'm slightly unsure about that one. I would tend to defer it, as I >> don't want to step on camel or servicemix toes. >> The CXF DOSGi could server the purpose and I think things like >> loadbalanding looks way too much like what camel / servicemix provide. > > > I don't see how we are stepping toes with ServiceMix or Camel. Now > regarding CXF DOSGi you are right, howeverI never felt that it fits nice > inside Karaf, but that's more like a personal taste than a requirement. > > > >> -- >> >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > *Ioannis Canellos* > * > http://iocanel.blogspot.com > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > Apache ServiceMix <http://servicemix.apache.org/> Committer > * > -- *Ioannis Canellos* * http://iocanel.blogspot.com Apache Karaf <http://karaf.apache.org/> Committer & PMC Apache ServiceMix <http://servicemix.apache.org/> Committer *
