Note that fabric does the provisioning too. Kinda like ace, but more specific to karaf as it uses karaf features.
On Fri, Apr 15, 2011 at 09:56, Christian Schneider <ch...@die-schneider.net> wrote: > Hi All, > > what I like in the Fabric case is that it seems to concentrate on > distribution of configuration. So it has a narrow scope which may be a good > thing. > > There are more solutions to be considered like for example Ace. I think we > should try to come up with some use cases and see how the current efforts > fit into each and > what should be included. > > So for example I see at least two very different use cases: > > - High performance computing: Here you will have many quite similar nodes > that need to have synchronized configuration. The processing should be > distributed between the nodes. As the network has to scale quite dynamically > automatic discovery of nodes will probably be important here > - Management of a network of Karaf servers. Here the focus will be on > distribution of configuration to the nodes and centralized remote > deployment. Still there will be nodes that want to have some kind of load > balancing or failover capability > > In any case I think it could make sense to separate things like > configuration management and deployment from workload distribution as some > people may need only one of them. > > Christian > > > Am 15.04.2011 08:38, schrieb Guillaume Nodet: >> >> So I have another proposal to put on the table. >> >> I've been working since a few weeks on this very subject as part of my >> day job at FuseSource, and we've just open sourced some components: >> http://fabric.fusesource.org/ >> >> A *very * rough overview is available at >> http://fabric.fusesource.org/documentation/user-guide.html >> and a getting started guide at >> http://fabric.fusesource.org/documentation/getting-started.html >> >> Feedback welcome. >> >> On Thu, Apr 14, 2011 at 10:48, Jean-Baptiste Onofré<j...@nanthrax.net> >> wrote: >>> >>> I'm totally agree with Chris. >>> >>> Ioannis and I are aware that the solution is not the killer one, that we >>> can >>> do a lot of things better. >>> >>> However, the solution has the main advantage to exist and work. >>> People (Karaf contributors and community) can play with this cluster >>> implementation and enhance it. >>> >>> So here's my +1 also. >>> >>> Regards >>> JB >>> >>> On 04/13/2011 05:32 PM, Chris Custine wrote: >>>> >>>> +1 for bringing this code to Karaf. >>>> >>>> I haven't tested this out thoroughly or even looked deeply at the >>>> code, but in general I like this idea. I certainly agree with some of >>>> Guillaume's points, however unless there is a suitable alternative I >>>> think this will provide a good starting point for the community to get >>>> involved and improve it. >>>> >>>> Chris >>>> -- >>>> Chris Custine >>>> My Blog :: http://blog.organicelement.com >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Apr 13, 2011 at 09:06, Ioannis Canellos<ioca...@gmail.com> >>>> wrote: >>>>> >>>>> Guillaume, I haven't seen all your points, so here are some comments >>>>> for >>>>> the >>>>> rest: >>>>> >>>>> *Automatic discovery is really a myth imho. Such protocols have to use >>>>>> >>>>>> multicast and multicast is really forbidden in a lot of places. So >>>>>> *relying* on multicast would be a mistake I think. I've seen >>>>>> hazelcast can be configured using static ips which sounds better >>>>>> (though multicast is nice for demos, no problem with that).* >>>>>> >>>>> In places like EC2 or other Cloud platforms, indeed multicast is >>>>> forbidden, >>>>> but in a private cluster, multicast is great. >>>>> So I would say that automatic discovery is not panacea, but its still a >>>>> very >>>>> strong feature. >>>>> >>>>> >>>>>> *That's really my problem. Maybe it's a misunderstanding, but when >>>>>> you* >>>>>> * say "replication", I hear same thing everywhere, which I have a >>>>>> problem with. >>>>>> I think that definitely solve some problems, but it looks too >>>>>> limited.* >>>>>> >>>>> Let's don't stick to the "term" replication. Let's just say that it >>>>> provides >>>>> means to configure a group of nodes instead of a single one. And note >>>>> that >>>>> not all nodes are in total synch. You can configure what you want to >>>>> sync. >>>>> The configuration means can be extended and become more granular in >>>>> order >>>>> to >>>>> fit all needs. >>>>> >>>>> >>>>> -- >>>>> *Ioannis Canellos* >>>>> * >>>>> http://iocanel.blogspot.com >>>>> >>>>> Apache Karaf<http://karaf.apache.org/> Committer& PMC >>>>> Apache ServiceMix<http://servicemix.apache.org/> Committer >>>>> * >>>>> >> >> > > -- > ---- > http://www.liquid-reality.de > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com Connect at CamelOne May 24-26 The Open Source Integration Conference http://camelone.com/
