You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2011/04/13 10:19:23 UTC
[PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Hi all,
Ioannis made a great work by using Hazelcast to create a cluster of
Karaf nodes.
He has already blogged around:
http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
I like the design and I think it could be very interesting to embed this
feature in Karaf 3.0.0.
Ioannnis has kindly accepted to donate this work to Karaf.
The next steps are:
- think about an assemblies extension to provide cluster ready distribution
- document Karaf clustering in manual (mostly based on the Ioannis' blog)
- add an example of Karaf cluster usage.
I propose to work with Ioannis around these steps.
WDYT ?
Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
Do you think that we need a kind of "agnostic" layer around clustering
(especially if some of us already started to work around a different
kind of Karaf clusters) ?
Thanks
Regards
JB
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by jb...@nanthrax.net.
Thanks for this news Guillaume.
Let me take a look on the doc to have a better overview.
Regards
JB
-----Original Message-----
From: Guillaume Nodet <gn...@gmail.com>
Date: Fri, 15 Apr 2011 08:38:19
To: <de...@karaf.apache.org>
Reply-To: dev@karaf.apache.org
Subject: Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
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é <jb...@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<io...@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
>>> *
>>>
>
--
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/
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
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é<jb...@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<io...@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/
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Christian Schneider <ch...@die-schneider.net>.
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é<jb...@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<io...@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
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
I've fixed the users guide (forgot to upload the updated version).
And yeah, I'll write more asap.
On Fri, Apr 15, 2011 at 08:58, Charles Moulliard <cm...@gmail.com> wrote:
> Hi Guillaume,
>
> It could be interesting to provide more info about the different
> profiles that we can use and what a profile is supposed to do (deploy
> features + config files related to a domain, ....).
>
> BTW : the user guide does not contain anything except an empty link : features.
>
> Regards,
>
> Charles Moulliard
>
> Sr. Principal Solution Architect - FuseSource
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
>
>
>
> On Fri, Apr 15, 2011 at 8:38 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>> 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é <jb...@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<io...@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
>>>>> *
>>>>>
>>>
>>
>>
>>
>> --
>> 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/
>>
>
--
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/
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Charles Moulliard <cm...@gmail.com>.
Hi Guillaume,
It could be interesting to provide more info about the different
profiles that we can use and what a profile is supposed to do (deploy
features + config files related to a domain, ....).
BTW : the user guide does not contain anything except an empty link : features.
Regards,
Charles Moulliard
Sr. Principal Solution Architect - FuseSource
Apache Committer
Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard
On Fri, Apr 15, 2011 at 8:38 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> 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é <jb...@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<io...@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
>>>> *
>>>>
>>
>
>
>
> --
> 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/
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
The criticality is a really subjective. Karaf and before ServiceMix
Kernel has been created 3 years ago and the features we're talking
about have not been considered critical until recently. We have lots
of people using Karaf for simple deployments and they don't
necessarily need any clustering features.
Another example is the provisioning side which could be done using
Ace, but Ace isn't part of Karaf.
I'm not arguing about the value here, but I disagree we *need* to put
that in the karaf trunk. I'd much rather a separate subproject
somewhere as I don't expect all karaf users to need that, and I think
keeping the clustering part separate will ensure a better independence
of trunk. In addition, I think the clustering solution could provide
more than just Karaf (think about Camel, ActiveMQ and ServiceMix as
we're supporting in Fabric as described in
http://fabric.fusesource.org/documentation/user-guide.html).
Such a project is bound to grow in scope and considering that, I
really don't think trunk is a good location (unless we strictly limit
the scope).
As for the locating that in the ASF, that's a different story, you
absolutely have the right to start something in the ASF or outside.
The same has happened already, such as with Archiva / Nexus for
example.
On Fri, Apr 15, 2011 at 10:48, Ioannis Canellos <io...@gmail.com> wrote:
>>
>> it and it makes no sense to create a schism within Karaf project.
>>
>
> Charles,
>
> I do not wish my statement to be taken as "schismatic". I do not wish a
> split community and I don't think that anyone does.
> Voting is not about splinting. Voting is about uniting different views under
> the banner of "majority".
>
> I am sure Guillaume did a great work. What I don't like about it is that it
> comes as a fuse project (don't have an issue with fuse I respect and admire
> your work), but imho a critical feature like this should be 100% part of the
> karaf trunk.
>
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> *
>
--
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/
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by "Jamie G." <ja...@gmail.com>.
I believe that Karaf clustering is a first level feature for Karaf
3.0, as such perhaps it can be made available as a user selectable
choice - same as one can choose felix, equinox, or another OSGi
container.
As the default solution I have to give it a -1, as I think we really
need to be able to support it directly in Karaf.
Jamie
On Fri, Apr 15, 2011 at 7:00 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I am absolutely positive to reuse existing solutions and to not redo efforts
> that have been done elsewhere. That is why I did not insist on the
> clustering solution being an apache project.
> Though as you for sure know there are two kinds of open source projects. One
> kind is driven and "owned" by a community and the other kind by a company.
> The difference is in freedom for users as well as for contributors.
>
> For example in the case of config management and deployment Talend will also
> like to help drive the solution. In case of a community driven project this
> will be possible. In case of a fuse product it may or may not be possible
> depending on the current position of the Fuse management. So while in open
> source it is always possible to fork a project only community driven and
> owned projects allow collaboration of several vendors in the same project in
> the long run.
>
> So for this reason I think that strategic dependencies of apache projects
> should be community driven if possible.
>
> Just to name one case where this is not the case is spring. While the
> product is great and helps the apache projects a lot it is not possible to
> really take part in the spring development. So while we would sur elike to
> fix or change many things in spring we could only do this by creating a fork
> which would be a baad choice. So it iss no wonder that many projects try to
> be more independent of spring.
>
> Christian
>
>
> Am 15.04.2011 11:11, schrieb Rob Davies:
>>
>> We use other open source projects all the time in our apache projects -
>> even core functionality. What should matter is the right solution - I hate
>> to think any apache project suffers from not invented here syndrome.
>> On 15 Apr 2011, at 09:57, Christian Schneider wrote:
>>
>
> --
> ----
> http://www.liquid-reality.de
>
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Achim Nierbeck <bc...@googlemail.com>.
I have to say I'm with Christian her right now.
I really appreciate the work Ioannis has done, and I also appreciate
the work Guillaume has done. So we do end up in
a quite comfortable situation. There is a open solution waiting and
also a fully funded solution which can be bought with
proper support.
Now I think as this is a community driven project, where lots of
people do invest personal time we should
honor that also and give a +1 for Ioannis solution as the default one
and a +1 for making it exchangeable so
the fabric solution can step in if it is needed.
Just my 2 cents here :)
regards, Achim
2011/4/15 Christian Schneider <ch...@die-schneider.net>:
> There is no problem in offering fabric as an easy to install choice for
> users. But a product that is driven by one company should not be a default
> strategic dependency for an apache project.
> Talend of course also has their own open source products that are not
> community driven. I would oppose against using them by default in apache
> projects in the same way.
>
> Of course I fully acknowledge that a company should carefully decide which
> projects to have driven by the community as there is also much risk in this
> for a company.
>
> Christian
>
>
> Am 15.04.2011 13:08, schrieb Rob Davies:
>>
>> is this is answer to my statement ?? I also think choice is good - I'm
>> just saying that we shouldn't fall into the trap of re-inventing everything
>> because its not apache. If talend wants to donate stuff to apache - awesome!
>> - its all good!
>>
>> On 15 Apr 2011, at 10:30, Christian Schneider wrote:
>>
>
> --
> ----
> http://www.liquid-reality.de
>
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Christian Schneider <ch...@die-schneider.net>.
There is no problem in offering fabric as an easy to install choice for
users. But a product that is driven by one company should not be a
default strategic dependency for an apache project.
Talend of course also has their own open source products that are not
community driven. I would oppose against using them by default in apache
projects in the same way.
Of course I fully acknowledge that a company should carefully decide
which projects to have driven by the community as there is also much
risk in this for a company.
Christian
Am 15.04.2011 13:08, schrieb Rob Davies:
> is this is answer to my statement ?? I also think choice is good - I'm just saying that we shouldn't fall into the trap of re-inventing everything because its not apache. If talend wants to donate stuff to apache - awesome! - its all good!
>
> On 15 Apr 2011, at 10:30, Christian Schneider wrote:
>
--
----
http://www.liquid-reality.de
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
Rob, Choosing a community driven solution is not "re-inventing" the wheel,
its just choosing the "free" wheel.
Cheers!
On Fri, Apr 15, 2011 at 2:08 PM, Rob Davies <ra...@gmail.com> wrote:
> is this is answer to my statement ?? I also think choice is good - I'm
> just saying that we shouldn't fall into the trap of re-inventing everything
> because its not apache. If talend wants to donate stuff to apache - awesome!
> - its all good!
>
> On 15 Apr 2011, at 10:30, Christian Schneider wrote:
>
> > I am absolutely positive to reuse existing solutions and to not redo
> efforts that have been done elsewhere. That is why I did not insist on the
> clustering solution being an apache project.
> > Though as you for sure know there are two kinds of open source projects.
> One kind is driven and "owned" by a community and the other kind by a
> company. The difference is in freedom for users as well as for contributors.
> >
> > For example in the case of config management and deployment Talend will
> also like to help drive the solution. In case of a community driven project
> this will be possible. In case of a fuse product it may or may not be
> possible depending on the current position of the Fuse management. So while
> in open source it is always possible to fork a project only community driven
> and owned projects allow collaboration of several vendors in the same
> project in the long run.
> >
> > So for this reason I think that strategic dependencies of apache projects
> should be community driven if possible.
> >
> > Just to name one case where this is not the case is spring. While the
> product is great and helps the apache projects a lot it is not possible to
> really take part in the spring development. So while we would sur elike to
> fix or change many things in spring we could only do this by creating a fork
> which would be a baad choice. So it iss no wonder that many projects try to
> be more independent of spring.
> >
> > Christian
> >
> >
> > Am 15.04.2011 11:11, schrieb Rob Davies:
> >> We use other open source projects all the time in our apache projects -
> even core functionality. What should matter is the right solution - I hate
> to think any apache project suffers from not invented here syndrome.
> >> On 15 Apr 2011, at 09:57, Christian Schneider wrote:
> >>
> >
> > --
> > ----
> > http://www.liquid-reality.de
> >
>
>
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Rob Davies <ra...@gmail.com>.
is this is answer to my statement ?? I also think choice is good - I'm just saying that we shouldn't fall into the trap of re-inventing everything because its not apache. If talend wants to donate stuff to apache - awesome! - its all good!
On 15 Apr 2011, at 10:30, Christian Schneider wrote:
> I am absolutely positive to reuse existing solutions and to not redo efforts that have been done elsewhere. That is why I did not insist on the clustering solution being an apache project.
> Though as you for sure know there are two kinds of open source projects. One kind is driven and "owned" by a community and the other kind by a company. The difference is in freedom for users as well as for contributors.
>
> For example in the case of config management and deployment Talend will also like to help drive the solution. In case of a community driven project this will be possible. In case of a fuse product it may or may not be possible depending on the current position of the Fuse management. So while in open source it is always possible to fork a project only community driven and owned projects allow collaboration of several vendors in the same project in the long run.
>
> So for this reason I think that strategic dependencies of apache projects should be community driven if possible.
>
> Just to name one case where this is not the case is spring. While the product is great and helps the apache projects a lot it is not possible to really take part in the spring development. So while we would sur elike to fix or change many things in spring we could only do this by creating a fork which would be a baad choice. So it iss no wonder that many projects try to be more independent of spring.
>
> Christian
>
>
> Am 15.04.2011 11:11, schrieb Rob Davies:
>> We use other open source projects all the time in our apache projects - even core functionality. What should matter is the right solution - I hate to think any apache project suffers from not invented here syndrome.
>> On 15 Apr 2011, at 09:57, Christian Schneider wrote:
>>
>
> --
> ----
> http://www.liquid-reality.de
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Christian Schneider <ch...@die-schneider.net>.
I am absolutely positive to reuse existing solutions and to not redo
efforts that have been done elsewhere. That is why I did not insist on
the clustering solution being an apache project.
Though as you for sure know there are two kinds of open source projects.
One kind is driven and "owned" by a community and the other kind by a
company. The difference is in freedom for users as well as for
contributors.
For example in the case of config management and deployment Talend will
also like to help drive the solution. In case of a community driven
project this will be possible. In case of a fuse product it may or may
not be possible depending on the current position of the Fuse
management. So while in open source it is always possible to fork a
project only community driven and owned projects allow collaboration of
several vendors in the same project in the long run.
So for this reason I think that strategic dependencies of apache
projects should be community driven if possible.
Just to name one case where this is not the case is spring. While the
product is great and helps the apache projects a lot it is not possible
to really take part in the spring development. So while we would sur
elike to fix or change many things in spring we could only do this by
creating a fork which would be a baad choice. So it iss no wonder that
many projects try to be more independent of spring.
Christian
Am 15.04.2011 11:11, schrieb Rob Davies:
> We use other open source projects all the time in our apache projects - even core functionality. What should matter is the right solution - I hate to think any apache project suffers from not invented here syndrome.
> On 15 Apr 2011, at 09:57, Christian Schneider wrote:
>
--
----
http://www.liquid-reality.de
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Rob Davies <ra...@gmail.com>.
We use other open source projects all the time in our apache projects - even core functionality. What should matter is the right solution - I hate to think any apache project suffers from not invented here syndrome.
On 15 Apr 2011, at 09:57, Christian Schneider wrote:
> I absolutely agree with Ioannis. The default configuration management or clustering support for karaf should be part of the Karaf project - or alternatively be a separate project at Apache or a similar community.
>
> Christian
>
> Am 15.04.2011 10:48, schrieb Ioannis Canellos:
>>> it and it makes no sense to create a schism within Karaf project.
>>>
>> Charles,
>>
>> I do not wish my statement to be taken as "schismatic". I do not wish a
>> split community and I don't think that anyone does.
>> Voting is not about splinting. Voting is about uniting different views under
>> the banner of "majority".
>>
>> I am sure Guillaume did a great work. What I don't like about it is that it
>> comes as a fuse project (don't have an issue with fuse I respect and admire
>> your work), but imho a critical feature like this should be 100% part of the
>> karaf trunk.
>>
>> *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
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Christian Schneider <ch...@die-schneider.net>.
I absolutely agree with Ioannis. The default configuration management or
clustering support for karaf should be part of the Karaf project - or
alternatively be a separate project at Apache or a similar community.
Christian
Am 15.04.2011 10:48, schrieb Ioannis Canellos:
>> it and it makes no sense to create a schism within Karaf project.
>>
> Charles,
>
> I do not wish my statement to be taken as "schismatic". I do not wish a
> split community and I don't think that anyone does.
> Voting is not about splinting. Voting is about uniting different views under
> the banner of "majority".
>
> I am sure Guillaume did a great work. What I don't like about it is that it
> comes as a fuse project (don't have an issue with fuse I respect and admire
> your work), but imho a critical feature like this should be 100% part of the
> karaf trunk.
>
> *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
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
>
> it and it makes no sense to create a schism within Karaf project.
>
Charles,
I do not wish my statement to be taken as "schismatic". I do not wish a
split community and I don't think that anyone does.
Voting is not about splinting. Voting is about uniting different views under
the banner of "majority".
I am sure Guillaume did a great work. What I don't like about it is that it
comes as a fuse project (don't have an issue with fuse I respect and admire
your work), but imho a critical feature like this should be 100% part of the
karaf trunk.
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Charles Moulliard <cm...@gmail.com>.
Ioannis,
Before considering to resolve something through Apache Way, I think that
it is interesting that we take the time to discuss, to review what
Guillaume suggest and confront this with the idea introduced by
Jean-Baptiste, you and the others. Karaf 3.0 and our communities of
users deserve it and it makes no sense to create a schism within Karaf
project.
Regards,
Charles
On 15/04/11 09:01, Ioannis Canellos wrote:
> I consider clustering to be a first class feature of karaf 3.x and I
> would like to see it as part of the karaf trunk and not as part of 3rd
> library which is partially open sourced. In any case since there are a
> lot of different views, let's resolve this "the apache way" and vote
> on which solution we want to add to the karaf trunk.
>
> On Friday, April 15, 2011, Guillaume Nodet<gn...@gmail.com> wrote:
>> 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é<jb...@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<io...@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
>>>>> *
>>>>>
>>
>>
>> --
>> 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/
>>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
I consider clustering to be a first class feature of karaf 3.x and I
would like to see it as part of the karaf trunk and not as part of 3rd
library which is partially open sourced. In any case since there are a
lot of different views, let's resolve this "the apache way" and vote
on which solution we want to add to the karaf trunk.
On Friday, April 15, 2011, Guillaume Nodet <gn...@gmail.com> wrote:
> 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é <jb...@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<io...@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
>>>> *
>>>>
>>
>
>
>
> --
> 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/
>
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
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é <jb...@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<io...@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
>>> *
>>>
>
--
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/
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<io...@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
>> *
>>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Chris Custine <ch...@gmail.com>.
+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 <io...@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
> *
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
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
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
Cellar can leverage its own feature to broadcast configuration changes
across nodes, so there is no need to go and configure each
node separately ;-)
Moreover, it provides some shell commands that allow you to broadcast
commands to all or specific nodes.
So for instance if you wish to add a new feature to a specific node and not
to all nodes, all you have to do is to add it to the feature blacklist PID.
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Apr 13, 2011 at 14:59, Ioannis Canellos <io...@gmail.com> wrote:
> @Guillaume: Don't worry there is nothing to take personally.
> +1 On creating a thread and start a discussion about the features we want
> our clustering engine to have, In fact I will create one asap.
>
> I will disagree with Guillaume on that its not usable in real life, as I
> initially implemented that to solve some "real life" problems of mine and to
> be more exact:
> a) Automatic Discovery of nodes
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).
> b) Configuration replication
> c) Feature repository & feature state replication. etc.
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.
> imho these are "real" problems, they do cover the needs that have been
> discussed and that have been around the last months (at least as expressed
> via https://issues.apache.org/jira/browse/KARAF-376).
> Any feedback and/or additional requirements/features are more than welcome
> and I would gladly work on them.
>
> Also note, that the statement "all nodes are roughly the same" is not very
> accurate, as each node can be configured to have different role inside the
> cluster.
> a) A node can be set to be just a receiver of events
> b) A node can be set to be just a transmitter of events
> c) A node can set a white list/black list by type of event and/or event id
> (e.g. a node could disable config replication, or even exclude a specifc PID
> from the list of replicated PIDs)
>
How / where is that configured ? If you have to be explicit on what you block,
doesn't that mean that each time you add something to your cluster, you need
to go to all nodes to tell them to not include that new stuff.
>
> On Wed, Apr 13, 2011 at 3:22 PM, Jamie G. <ja...@gmail.com> wrote:
>
>> Would not all nodes involved in a particular cluster be roughly the
>> same? Yes, a separate thread should be started to discuss the
>> technical issues.
>>
>> Jamie
>>
>> On Wed, Apr 13, 2011 at 9:44 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>> > (Ioannis, please don't take that personally)
>> >
>> > We can start a discussion around clustering, but I strongly disagree
>> > with several design
>> > decisions that have been made by Ioannis while working on cellar.
>> > Mainly the assumption
>> > that all nodes are roughly the same.
>> >
>> > I think the cellar is a nice experiment, but I'm not so sure it's
>> > really so useful in real life.
>> > So, if this is to be imported in Karaf, I'd like that not to be in
>> > trunk for now until we can
>> > start a real discussion on what problems we want to solve and what's
>> > the best way to
>> > solve them.
>> >
>> >
>> > On Wed, Apr 13, 2011 at 10:19, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>> >> Hi all,
>> >>
>> >> Ioannis made a great work by using Hazelcast to create a cluster of
>> Karaf
>> >> nodes.
>> >>
>> >> He has already blogged around:
>> >>
>> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>> >>
>> >> I like the design and I think it could be very interesting to embed this
>> >> feature in Karaf 3.0.0.
>> >>
>> >> Ioannnis has kindly accepted to donate this work to Karaf.
>> >>
>> >> The next steps are:
>> >> - think about an assemblies extension to provide cluster ready
>> distribution
>> >> - document Karaf clustering in manual (mostly based on the Ioannis'
>> blog)
>> >> - add an example of Karaf cluster usage.
>> >> I propose to work with Ioannis around these steps.
>> >>
>> >> WDYT ?
>> >> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
>> >> Do you think that we need a kind of "agnostic" layer around clustering
>> >> (especially if some of us already started to work around a different
>> kind of
>> >> Karaf clusters) ?
>> >>
>> >> Thanks
>> >> Regards
>> >> JB
>> >>
>> >
>> >
>> >
>> > --
>> > 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
> *
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
@Guillaume: Don't worry there is nothing to take personally.
+1 On creating a thread and start a discussion about the features we want
our clustering engine to have, In fact I will create one asap.
I will disagree with Guillaume on that its not usable in real life, as I
initially implemented that to solve some "real life" problems of mine and to
be more exact:
a) Automatic Discovery of nodes
b) Configuration replication
c) Feature repository & feature state replication. etc.
imho these are "real" problems, they do cover the needs that have been
discussed and that have been around the last months (at least as expressed
via https://issues.apache.org/jira/browse/KARAF-376).
Any feedback and/or additional requirements/features are more than welcome
and I would gladly work on them.
Also note, that the statement "all nodes are roughly the same" is not very
accurate, as each node can be configured to have different role inside the
cluster.
a) A node can be set to be just a receiver of events
b) A node can be set to be just a transmitter of events
c) A node can set a white list/black list by type of event and/or event id
(e.g. a node could disable config replication, or even exclude a specifc PID
from the list of replicated PIDs)
On Wed, Apr 13, 2011 at 3:22 PM, Jamie G. <ja...@gmail.com> wrote:
> Would not all nodes involved in a particular cluster be roughly the
> same? Yes, a separate thread should be started to discuss the
> technical issues.
>
> Jamie
>
> On Wed, Apr 13, 2011 at 9:44 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> > (Ioannis, please don't take that personally)
> >
> > We can start a discussion around clustering, but I strongly disagree
> > with several design
> > decisions that have been made by Ioannis while working on cellar.
> > Mainly the assumption
> > that all nodes are roughly the same.
> >
> > I think the cellar is a nice experiment, but I'm not so sure it's
> > really so useful in real life.
> > So, if this is to be imported in Karaf, I'd like that not to be in
> > trunk for now until we can
> > start a real discussion on what problems we want to solve and what's
> > the best way to
> > solve them.
> >
> >
> > On Wed, Apr 13, 2011 at 10:19, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >> Hi all,
> >>
> >> Ioannis made a great work by using Hazelcast to create a cluster of
> Karaf
> >> nodes.
> >>
> >> He has already blogged around:
> >>
> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
> >>
> >> I like the design and I think it could be very interesting to embed this
> >> feature in Karaf 3.0.0.
> >>
> >> Ioannnis has kindly accepted to donate this work to Karaf.
> >>
> >> The next steps are:
> >> - think about an assemblies extension to provide cluster ready
> distribution
> >> - document Karaf clustering in manual (mostly based on the Ioannis'
> blog)
> >> - add an example of Karaf cluster usage.
> >> I propose to work with Ioannis around these steps.
> >>
> >> WDYT ?
> >> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
> >> Do you think that we need a kind of "agnostic" layer around clustering
> >> (especially if some of us already started to work around a different
> kind of
> >> Karaf clusters) ?
> >>
> >> Thanks
> >> Regards
> >> JB
> >>
> >
> >
> >
> > --
> > 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
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by "Jamie G." <ja...@gmail.com>.
Would not all nodes involved in a particular cluster be roughly the
same? Yes, a separate thread should be started to discuss the
technical issues.
Jamie
On Wed, Apr 13, 2011 at 9:44 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> (Ioannis, please don't take that personally)
>
> We can start a discussion around clustering, but I strongly disagree
> with several design
> decisions that have been made by Ioannis while working on cellar.
> Mainly the assumption
> that all nodes are roughly the same.
>
> I think the cellar is a nice experiment, but I'm not so sure it's
> really so useful in real life.
> So, if this is to be imported in Karaf, I'd like that not to be in
> trunk for now until we can
> start a real discussion on what problems we want to solve and what's
> the best way to
> solve them.
>
>
> On Wed, Apr 13, 2011 at 10:19, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi all,
>>
>> Ioannis made a great work by using Hazelcast to create a cluster of Karaf
>> nodes.
>>
>> He has already blogged around:
>> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>>
>> I like the design and I think it could be very interesting to embed this
>> feature in Karaf 3.0.0.
>>
>> Ioannnis has kindly accepted to donate this work to Karaf.
>>
>> The next steps are:
>> - think about an assemblies extension to provide cluster ready distribution
>> - document Karaf clustering in manual (mostly based on the Ioannis' blog)
>> - add an example of Karaf cluster usage.
>> I propose to work with Ioannis around these steps.
>>
>> WDYT ?
>> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
>> Do you think that we need a kind of "agnostic" layer around clustering
>> (especially if some of us already started to work around a different kind of
>> Karaf clusters) ?
>>
>> Thanks
>> Regards
>> JB
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
(Ioannis, please don't take that personally)
We can start a discussion around clustering, but I strongly disagree
with several design
decisions that have been made by Ioannis while working on cellar.
Mainly the assumption
that all nodes are roughly the same.
I think the cellar is a nice experiment, but I'm not so sure it's
really so useful in real life.
So, if this is to be imported in Karaf, I'd like that not to be in
trunk for now until we can
start a real discussion on what problems we want to solve and what's
the best way to
solve them.
On Wed, Apr 13, 2011 at 10:19, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi all,
>
> Ioannis made a great work by using Hazelcast to create a cluster of Karaf
> nodes.
>
> He has already blogged around:
> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>
> I like the design and I think it could be very interesting to embed this
> feature in Karaf 3.0.0.
>
> Ioannnis has kindly accepted to donate this work to Karaf.
>
> The next steps are:
> - think about an assemblies extension to provide cluster ready distribution
> - document Karaf clustering in manual (mostly based on the Ioannis' blog)
> - add an example of Karaf cluster usage.
> I propose to work with Ioannis around these steps.
>
> WDYT ?
> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
> Do you think that we need a kind of "agnostic" layer around clustering
> (especially if some of us already started to work around a different kind of
> Karaf clusters) ?
>
> Thanks
> Regards
> JB
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Christian Schneider <ch...@die-schneider.net>.
Much of the thread till now was about which solution should be included
as default and what non technical properties it should have. An
important question here was who controls the solution (community vs
company). While this is an important question I think we have discussed
this quite good already.
So I would like to come back to the more technical requirements of the
clustering support. The problem here is that we each have very different
ideas what we need in the clustering which is very valid but needs to be
understood to avoid that we misunderstand each other.
So to get ahead with this I added some scenarios to the clustering wiki
page. I propose that we first gather some scenarios from all the people
involved and then discuss how to achieve these sceanrios and how they
map to the proposed solutions.
https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
Christian
Am 16.04.2011 09:29, schrieb Jean-Baptiste Onofré:
> What a thread !! :)
>
> I was with a customer yesterday and I just now browse the thread.
>
> Before dealing with Apache and Karaf inclusion of Guillaume work, I
> think that we need to compare and discuss from a technology point of
> view.
> My initial e-mail was exactly to start to discuss about different ways
> to achieve clustering (existing ones, planned ones, etc) and compare
> our point of view.
>
> That's why we need to consider and compare Ioannis and Guillaume works
> and maybe conclude that it's a kind of merge of both, or pick up some
> implementations of each.
>
> I have an absolute and total trust in Guillaume, especially about his
> Apache fiber (keep in mind that Guillaume is a ASF member). If he
> proposed his cluster implementation, he knows that we can use it in
> Karaf.
>
> So, before discussing about the "source" of the implementation, I
> think that we need to focus on the technical layer and discuss the
> different way to see the cluster.
> I don't care where the implementation comes from (Fuse, Talend,
> others), if the implementation is a good one, and if the community
> accepts this implementation, I can't see any problem.
> We are all Apache commiters after all :)
>
> My 2 cents
>
> Regards
> JB
>
> On 04/13/2011 10:19 AM, Jean-Baptiste Onofré wrote:
>> Hi all,
>>
>> Ioannis made a great work by using Hazelcast to create a cluster of
>> Karaf nodes.
>>
>> He has already blogged around:
>> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>>
>>
>> I like the design and I think it could be very interesting to embed this
>> feature in Karaf 3.0.0.
>>
>> Ioannnis has kindly accepted to donate this work to Karaf.
>>
>> The next steps are:
>> - think about an assemblies extension to provide cluster ready
>> distribution
>> - document Karaf clustering in manual (mostly based on the Ioannis'
>> blog)
>> - add an example of Karaf cluster usage.
>> I propose to work with Ioannis around these steps.
>>
>> WDYT ?
>> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
>> Do you think that we need a kind of "agnostic" layer around clustering
>> (especially if some of us already started to work around a different
>> kind of Karaf clusters) ?
>>
>> Thanks
>> Regards
>> JB
>
--
----
http://www.liquid-reality.de
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Andreas Pieber <an...@gmail.com>.
+1 to start the vote
Kind regards,
Andreas
On Tue, May 3, 2011 at 2:21 PM, Jamie G. <ja...@gmail.com> wrote:
> +1 for the vote
>
> J
>
> On Tue, May 3, 2011 at 4:21 AM, Achim Nierbeck <bc...@googlemail.com> wrote:
>> Hi JB,
>>
>> +1 for the vote
>>
>> 2011/5/3 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>> Hi all,
>>>
>>> I've deeper tested Cellar tonight, especially the group usage and it works
>>> like a charm. I began to make some enhancements (commands output, sync flag,
>>> etc).
>>>
>>> In the mean time, I launched a thread on ACE about the role of Karaf and ACE
>>> in a cluster environment. In ACE, we support clouding environment using
>>> jclouds. To avoid overlap between project, I launched the discussion.
>>>
>>> I think it's the right time to launch a vote about to include Cellar on
>>> Karaf trunk.
>>> WDYT ?
>>>
>>> Regards
>>> JB
>>>
>>> On 05/02/2011 08:45 PM, Achim Nierbeck wrote:
>>>>
>>>> This looks really great Ioannis, nothing more I can add :)
>>>>
>>>> Regards, Achim
>>>>
>>>> Am 02.05.2011 03:59, schrieb Andreas Pieber:
>>>>>
>>>>> This looks really cool Ioannis! Thank you very much for your effort!
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>> On Sun, May 1, 2011 at 7:58 PM, Jamie G.<ja...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> That's awesome Ioannis, thanks for the Cellar update :)
>>>>>>
>>>>>> J
>>>>>>
>>>>>> On Sun, May 1, 2011 at 3:00 PM, Ioannis Canellos<io...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I would like to inform you the Cellar has been re-factored, in order to
>>>>>>> satisfy all the requirements as they have been documented so far in our
>>>>>>> wiki
>>>>>>> page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
>>>>>>>
>>>>>>> Refactoring highlights:
>>>>>>>
>>>>>>> 1. Cellar now provides support for hierarchical groups.
>>>>>>> 2. Each node can be assigned one or more groups.
>>>>>>> 3. Syncing is the default but "optional" behavior and only occurs
>>>>>>> among
>>>>>>> members of the same group.
>>>>>>> 4. On each group a feature/configuration list can be assigned if
>>>>>>> syncing
>>>>>>> is not the desired behaviour.
>>>>>>> 5. Each group registers its own communication channels.
>>>>>>> 6. Rich command set (group management, remote feature/configuration
>>>>>>> management).
>>>>>>> 7. Added a Scala / Wicket webconsole (however its currently very
>>>>>>> limited).
>>>>>>>
>>>>>>> If you would like a more detailed overview you can check these 2
>>>>>>> videos,
>>>>>>> which demonstrate building,installation, usage of cellar:
>>>>>>> *Building& Installing Cellar*:
>>>>>>> http://www.youtube.com/watch?v=EM_5fh6XA1M
>>>>>>> *Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
>>>>>>>
>>>>>>> Additional requirements, ideas for new features, feedback and of course
>>>>>>> contributions are more than welcome.
>>>>>>>
>>>>>>> --
>>>>>>> *Ioannis Canellos*
>>>>>>> *
>>>>>>> http://iocanel.blogspot.com
>>>>>>>
>>>>>>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>>>>>>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>>>>>>> *
>>>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> --
>> *Achim Nierbeck*
>>
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer & Project Lead
>>
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by "Jamie G." <ja...@gmail.com>.
+1 for the vote
J
On Tue, May 3, 2011 at 4:21 AM, Achim Nierbeck <bc...@googlemail.com> wrote:
> Hi JB,
>
> +1 for the vote
>
> 2011/5/3 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> Hi all,
>>
>> I've deeper tested Cellar tonight, especially the group usage and it works
>> like a charm. I began to make some enhancements (commands output, sync flag,
>> etc).
>>
>> In the mean time, I launched a thread on ACE about the role of Karaf and ACE
>> in a cluster environment. In ACE, we support clouding environment using
>> jclouds. To avoid overlap between project, I launched the discussion.
>>
>> I think it's the right time to launch a vote about to include Cellar on
>> Karaf trunk.
>> WDYT ?
>>
>> Regards
>> JB
>>
>> On 05/02/2011 08:45 PM, Achim Nierbeck wrote:
>>>
>>> This looks really great Ioannis, nothing more I can add :)
>>>
>>> Regards, Achim
>>>
>>> Am 02.05.2011 03:59, schrieb Andreas Pieber:
>>>>
>>>> This looks really cool Ioannis! Thank you very much for your effort!
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>> On Sun, May 1, 2011 at 7:58 PM, Jamie G.<ja...@gmail.com>
>>>> wrote:
>>>>>
>>>>> That's awesome Ioannis, thanks for the Cellar update :)
>>>>>
>>>>> J
>>>>>
>>>>> On Sun, May 1, 2011 at 3:00 PM, Ioannis Canellos<io...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I would like to inform you the Cellar has been re-factored, in order to
>>>>>> satisfy all the requirements as they have been documented so far in our
>>>>>> wiki
>>>>>> page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
>>>>>>
>>>>>> Refactoring highlights:
>>>>>>
>>>>>> 1. Cellar now provides support for hierarchical groups.
>>>>>> 2. Each node can be assigned one or more groups.
>>>>>> 3. Syncing is the default but "optional" behavior and only occurs
>>>>>> among
>>>>>> members of the same group.
>>>>>> 4. On each group a feature/configuration list can be assigned if
>>>>>> syncing
>>>>>> is not the desired behaviour.
>>>>>> 5. Each group registers its own communication channels.
>>>>>> 6. Rich command set (group management, remote feature/configuration
>>>>>> management).
>>>>>> 7. Added a Scala / Wicket webconsole (however its currently very
>>>>>> limited).
>>>>>>
>>>>>> If you would like a more detailed overview you can check these 2
>>>>>> videos,
>>>>>> which demonstrate building,installation, usage of cellar:
>>>>>> *Building& Installing Cellar*:
>>>>>> http://www.youtube.com/watch?v=EM_5fh6XA1M
>>>>>> *Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
>>>>>>
>>>>>> Additional requirements, ideas for new features, feedback and of course
>>>>>> contributions are more than welcome.
>>>>>>
>>>>>> --
>>>>>> *Ioannis Canellos*
>>>>>> *
>>>>>> http://iocanel.blogspot.com
>>>>>>
>>>>>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>>>>>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>>>>>> *
>>>>>>
>>>
>>
>
>
>
> --
> --
> *Achim Nierbeck*
>
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi JB,
+1 for the vote
2011/5/3 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi all,
>
> I've deeper tested Cellar tonight, especially the group usage and it works
> like a charm. I began to make some enhancements (commands output, sync flag,
> etc).
>
> In the mean time, I launched a thread on ACE about the role of Karaf and ACE
> in a cluster environment. In ACE, we support clouding environment using
> jclouds. To avoid overlap between project, I launched the discussion.
>
> I think it's the right time to launch a vote about to include Cellar on
> Karaf trunk.
> WDYT ?
>
> Regards
> JB
>
> On 05/02/2011 08:45 PM, Achim Nierbeck wrote:
>>
>> This looks really great Ioannis, nothing more I can add :)
>>
>> Regards, Achim
>>
>> Am 02.05.2011 03:59, schrieb Andreas Pieber:
>>>
>>> This looks really cool Ioannis! Thank you very much for your effort!
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> On Sun, May 1, 2011 at 7:58 PM, Jamie G.<ja...@gmail.com>
>>> wrote:
>>>>
>>>> That's awesome Ioannis, thanks for the Cellar update :)
>>>>
>>>> J
>>>>
>>>> On Sun, May 1, 2011 at 3:00 PM, Ioannis Canellos<io...@gmail.com>
>>>> wrote:
>>>>>
>>>>> I would like to inform you the Cellar has been re-factored, in order to
>>>>> satisfy all the requirements as they have been documented so far in our
>>>>> wiki
>>>>> page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
>>>>>
>>>>> Refactoring highlights:
>>>>>
>>>>> 1. Cellar now provides support for hierarchical groups.
>>>>> 2. Each node can be assigned one or more groups.
>>>>> 3. Syncing is the default but "optional" behavior and only occurs
>>>>> among
>>>>> members of the same group.
>>>>> 4. On each group a feature/configuration list can be assigned if
>>>>> syncing
>>>>> is not the desired behaviour.
>>>>> 5. Each group registers its own communication channels.
>>>>> 6. Rich command set (group management, remote feature/configuration
>>>>> management).
>>>>> 7. Added a Scala / Wicket webconsole (however its currently very
>>>>> limited).
>>>>>
>>>>> If you would like a more detailed overview you can check these 2
>>>>> videos,
>>>>> which demonstrate building,installation, usage of cellar:
>>>>> *Building& Installing Cellar*:
>>>>> http://www.youtube.com/watch?v=EM_5fh6XA1M
>>>>> *Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
>>>>>
>>>>> Additional requirements, ideas for new features, feedback and of course
>>>>> contributions are more than welcome.
>>>>>
>>>>> --
>>>>> *Ioannis Canellos*
>>>>> *
>>>>> http://iocanel.blogspot.com
>>>>>
>>>>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>>>>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>>>>> *
>>>>>
>>
>
--
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi all,
I've deeper tested Cellar tonight, especially the group usage and it
works like a charm. I began to make some enhancements (commands output,
sync flag, etc).
In the mean time, I launched a thread on ACE about the role of Karaf and
ACE in a cluster environment. In ACE, we support clouding environment
using jclouds. To avoid overlap between project, I launched the discussion.
I think it's the right time to launch a vote about to include Cellar on
Karaf trunk.
WDYT ?
Regards
JB
On 05/02/2011 08:45 PM, Achim Nierbeck wrote:
> This looks really great Ioannis, nothing more I can add :)
>
> Regards, Achim
>
> Am 02.05.2011 03:59, schrieb Andreas Pieber:
>> This looks really cool Ioannis! Thank you very much for your effort!
>>
>> Kind regards,
>> Andreas
>>
>> On Sun, May 1, 2011 at 7:58 PM, Jamie G.<ja...@gmail.com> wrote:
>>> That's awesome Ioannis, thanks for the Cellar update :)
>>>
>>> J
>>>
>>> On Sun, May 1, 2011 at 3:00 PM, Ioannis Canellos<io...@gmail.com> wrote:
>>>> I would like to inform you the Cellar has been re-factored, in order to
>>>> satisfy all the requirements as they have been documented so far in our wiki
>>>> page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
>>>>
>>>> Refactoring highlights:
>>>>
>>>> 1. Cellar now provides support for hierarchical groups.
>>>> 2. Each node can be assigned one or more groups.
>>>> 3. Syncing is the default but "optional" behavior and only occurs among
>>>> members of the same group.
>>>> 4. On each group a feature/configuration list can be assigned if syncing
>>>> is not the desired behaviour.
>>>> 5. Each group registers its own communication channels.
>>>> 6. Rich command set (group management, remote feature/configuration
>>>> management).
>>>> 7. Added a Scala / Wicket webconsole (however its currently very
>>>> limited).
>>>>
>>>> If you would like a more detailed overview you can check these 2 videos,
>>>> which demonstrate building,installation, usage of cellar:
>>>> *Building& Installing Cellar*: http://www.youtube.com/watch?v=EM_5fh6XA1M
>>>> *Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
>>>>
>>>> Additional requirements, ideas for new features, feedback and of course
>>>> contributions are more than welcome.
>>>>
>>>> --
>>>> *Ioannis Canellos*
>>>> *
>>>> http://iocanel.blogspot.com
>>>>
>>>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>>>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>>>> *
>>>>
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Achim Nierbeck <bc...@googlemail.com>.
This looks really great Ioannis, nothing more I can add :)
Regards, Achim
Am 02.05.2011 03:59, schrieb Andreas Pieber:
> This looks really cool Ioannis! Thank you very much for your effort!
>
> Kind regards,
> Andreas
>
> On Sun, May 1, 2011 at 7:58 PM, Jamie G. <ja...@gmail.com> wrote:
>> That's awesome Ioannis, thanks for the Cellar update :)
>>
>> J
>>
>> On Sun, May 1, 2011 at 3:00 PM, Ioannis Canellos <io...@gmail.com> wrote:
>>> I would like to inform you the Cellar has been re-factored, in order to
>>> satisfy all the requirements as they have been documented so far in our wiki
>>> page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
>>>
>>> Refactoring highlights:
>>>
>>> 1. Cellar now provides support for hierarchical groups.
>>> 2. Each node can be assigned one or more groups.
>>> 3. Syncing is the default but "optional" behavior and only occurs among
>>> members of the same group.
>>> 4. On each group a feature/configuration list can be assigned if syncing
>>> is not the desired behaviour.
>>> 5. Each group registers its own communication channels.
>>> 6. Rich command set (group management, remote feature/configuration
>>> management).
>>> 7. Added a Scala / Wicket webconsole (however its currently very
>>> limited).
>>>
>>> If you would like a more detailed overview you can check these 2 videos,
>>> which demonstrate building,installation, usage of cellar:
>>> *Building & Installing Cellar*: http://www.youtube.com/watch?v=EM_5fh6XA1M
>>> *Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
>>>
>>> Additional requirements, ideas for new features, feedback and of course
>>> contributions are more than welcome.
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> http://iocanel.blogspot.com
>>>
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> Apache ServiceMix <http://servicemix.apache.org/> Committer
>>> *
>>>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Andreas Pieber <an...@gmail.com>.
This looks really cool Ioannis! Thank you very much for your effort!
Kind regards,
Andreas
On Sun, May 1, 2011 at 7:58 PM, Jamie G. <ja...@gmail.com> wrote:
> That's awesome Ioannis, thanks for the Cellar update :)
>
> J
>
> On Sun, May 1, 2011 at 3:00 PM, Ioannis Canellos <io...@gmail.com> wrote:
>> I would like to inform you the Cellar has been re-factored, in order to
>> satisfy all the requirements as they have been documented so far in our wiki
>> page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
>>
>> Refactoring highlights:
>>
>> 1. Cellar now provides support for hierarchical groups.
>> 2. Each node can be assigned one or more groups.
>> 3. Syncing is the default but "optional" behavior and only occurs among
>> members of the same group.
>> 4. On each group a feature/configuration list can be assigned if syncing
>> is not the desired behaviour.
>> 5. Each group registers its own communication channels.
>> 6. Rich command set (group management, remote feature/configuration
>> management).
>> 7. Added a Scala / Wicket webconsole (however its currently very
>> limited).
>>
>> If you would like a more detailed overview you can check these 2 videos,
>> which demonstrate building,installation, usage of cellar:
>> *Building & Installing Cellar*: http://www.youtube.com/watch?v=EM_5fh6XA1M
>> *Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
>>
>> Additional requirements, ideas for new features, feedback and of course
>> contributions are more than welcome.
>>
>> --
>> *Ioannis Canellos*
>> *
>> http://iocanel.blogspot.com
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> Apache ServiceMix <http://servicemix.apache.org/> Committer
>> *
>>
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by "Jamie G." <ja...@gmail.com>.
That's awesome Ioannis, thanks for the Cellar update :)
J
On Sun, May 1, 2011 at 3:00 PM, Ioannis Canellos <io...@gmail.com> wrote:
> I would like to inform you the Cellar has been re-factored, in order to
> satisfy all the requirements as they have been documented so far in our wiki
> page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
>
> Refactoring highlights:
>
> 1. Cellar now provides support for hierarchical groups.
> 2. Each node can be assigned one or more groups.
> 3. Syncing is the default but "optional" behavior and only occurs among
> members of the same group.
> 4. On each group a feature/configuration list can be assigned if syncing
> is not the desired behaviour.
> 5. Each group registers its own communication channels.
> 6. Rich command set (group management, remote feature/configuration
> management).
> 7. Added a Scala / Wicket webconsole (however its currently very
> limited).
>
> If you would like a more detailed overview you can check these 2 videos,
> which demonstrate building,installation, usage of cellar:
> *Building & Installing Cellar*: http://www.youtube.com/watch?v=EM_5fh6XA1M
> *Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
>
> Additional requirements, ideas for new features, feedback and of course
> contributions are more than welcome.
>
> --
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> *
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Awesome Ioannis.
Thanks
Regards
JB
On 05/01/2011 07:30 PM, Ioannis Canellos wrote:
> I would like to inform you the Cellar has been re-factored, in order to
> satisfy all the requirements as they have been documented so far in our wiki
> page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
>
> Refactoring highlights:
>
> 1. Cellar now provides support for hierarchical groups.
> 2. Each node can be assigned one or more groups.
> 3. Syncing is the default but "optional" behavior and only occurs among
> members of the same group.
> 4. On each group a feature/configuration list can be assigned if syncing
> is not the desired behaviour.
> 5. Each group registers its own communication channels.
> 6. Rich command set (group management, remote feature/configuration
> management).
> 7. Added a Scala / Wicket webconsole (however its currently very
> limited).
>
> If you would like a more detailed overview you can check these 2 videos,
> which demonstrate building,installation, usage of cellar:
> *Building& Installing Cellar*: http://www.youtube.com/watch?v=EM_5fh6XA1M
> *Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
>
> Additional requirements, ideas for new features, feedback and of course
> contributions are more than welcome.
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
I would like to inform you the Cellar has been re-factored, in order to
satisfy all the requirements as they have been documented so far in our wiki
page https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
Refactoring highlights:
1. Cellar now provides support for hierarchical groups.
2. Each node can be assigned one or more groups.
3. Syncing is the default but "optional" behavior and only occurs among
members of the same group.
4. On each group a feature/configuration list can be assigned if syncing
is not the desired behaviour.
5. Each group registers its own communication channels.
6. Rich command set (group management, remote feature/configuration
management).
7. Added a Scala / Wicket webconsole (however its currently very
limited).
If you would like a more detailed overview you can check these 2 videos,
which demonstrate building,installation, usage of cellar:
*Building & Installing Cellar*: http://www.youtube.com/watch?v=EM_5fh6XA1M
*Basic Feature Overview*: http://www.youtube.com/watch?v=HfNrTp371LA
Additional requirements, ideas for new features, feedback and of course
contributions are more than welcome.
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Guillaume Nodet <gn...@gmail.com>.
Let me try to explain a bit more what I had in mind.
Some of you may know I've been working on this stuff over the past
weeks. When this thread came up, I thought some of you (as users of
Karaf) might be interested in what I had worked on, so I actually
pushed really hard to be able to open source bits (which is now
available as Fabric). I think that would be helpful for some of us
to be able to use those bits.
Now, my original idea was not really to embed Fabric in Karaf.
Fabric has a broader goal than Karaf and has bits that are targeted
for ServiceMix, Camel or ActiveMQ (see the Fabric extensions described
at http://fabric.fusesource.org/documentation/user-guide.html#Fabric_Extensions).
As such, it would not make sense to actually dump the code into
Karaf. I sincerely think (but maybe I'm wrong), that the clustering
thing we're talking about is a big project in itself, that it is more
tied to OSGi than to Karaf itself (by that I mean, that it could be
useful for people that use OSGi but not Karaf to some extent).
I also think the notion of clustering is also really dependant on what
you cluster. Clustering web applications has nothing to do with
clustering activemq brokers. What does a Karaf clustering solution
really mean ? Clustering activemq brokers is not simply deploying the
same bundle in multiple nodes. For example, I see in
https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering
some thoughts about statefull / stateless: I think that in order to
provide a generic way to cluster applications you need to control
things. JEE defines a programming model using EJB, WebServices,
etc... and everything can be controlled. At the end, you kinda have
to enforce some things.
Karaf is really designed to be a general purpose server side
container. ServiceMix and Geronimo are using it already, maybe in the
future other Apache projects may want to leverage it too. However,
most of those I'm thinking about would not be interested in a
clustering solution such as a generic one described at
https://cwiki.apache.org/confluence/display/KARAF/Karaf+clustering.
I think what we're discussing here is a different thing: some kind of
environment based on OSGi which is highly distributed, with some kind
of automatic provisioning. And I think if you want to actually have a
reliable system, a provisioning agent need to be in full control of
the provisioning. It seems to me very hard to imagine a reliable
agent that can cope with any user interaction: you can't really
support a user uninstalling a bundle, can you ? So you need to lock
things down. And at the end, I think such a solution is not Karaf.
It can reuse Karaf, but it's not Karaf.
Now, for Fabric itself, I'm not sure if FuseFource will be willing to
donate it to Apache. I can understand some of you (mostly the talend
guys because they try to get into the same business as FuseSource)
would rather start a new project than reusing Fabric. But for people
that don't have a business closely related to Karaf, things are
certainly a bit different. The ASL is not the only open source
license in the world and being fanatic on anything is usually not
good. I'm not aware of any ASL compatible OS, so I'm quite confident
none of us is religious on those things. Each license has a purpose
and one need to respect the will of the licensor.
Last, if several people are willing to work on an OSGi based
clustering (need a better term) and/or provisioning solution at the
ASF, maybe a better way would be to go and start a project in the
incubator. FWIW, the Ace project could definitely be interested in
such an effort. I've seen a demo a few weeks ago of creating ec2
instances on the fly and provisioning them with Ace and that looked
quite cool.
On Sat, Apr 16, 2011 at 19:52, Ioannis Canellos <io...@gmail.com> wrote:
> If I have misunderstood, then I apologize! Guillaume, could you please
> sched some light to it? Do you intend to bring the source in, or you
> intend to have fabric hosted to fuse source and used as a dependency,
> like jansi?
>
> On Saturday, April 16, 2011, <jb...@nanthrax.net> wrote:
>> Hi Ioannis,
>>
>> Don't get me wrong: I assume that Guillaume talked about his implementation cause he can donate to Karaf.
>> If cluster implementations can't be included in Karaf, there is no discussion ;)
>>
>> Regards
>> JB
>> -----Original Message-----
>> From: Ioannis Canellos <io...@gmail.com>
>> Date: Sat, 16 Apr 2011 11:37:59
>> To: <de...@karaf.apache.org>
>> Reply-To: dev@karaf.apache.org
>> Subject: Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
>>
>>>
>>> I have an absolute and total trust in Guillaume, especially about his
>>> Apache fiber (keep in mind that Guillaume is a ASF member). If he proposed
>>> his cluster implementation, he knows that we can use it in Karaf
>>>
>>
>> We all do JB! I can't imagine there is anyone among us, that doesn't trust
>> him and highly respect his work.
>>
>> My objection with Guillaume's proposal has nothing to do with Guillaume
>> himself or Fuse (I respect Fuse and I've even proposed to my day work
>> purchasing Fuse support :-)).
>>
>>
>>> I don't care where the implementation comes from (Fuse, Talend, others), if
>>> the implementation is a good one, and if the community accepts this
>>> implementation.
>>
>>
>> No ones cares about the origination of the solution.
>>
>> The only objection is that I believe that the default clustering solution
>> should be part of karaf and not a third party dependency.
>> If Guillaume proposed to brings his "source" in, none would object (at least
>> I would step back).
>>
>>
>> --
>> *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
> *
>
--
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/
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
If I have misunderstood, then I apologize! Guillaume, could you please
sched some light to it? Do you intend to bring the source in, or you
intend to have fabric hosted to fuse source and used as a dependency,
like jansi?
On Saturday, April 16, 2011, <jb...@nanthrax.net> wrote:
> Hi Ioannis,
>
> Don't get me wrong: I assume that Guillaume talked about his implementation cause he can donate to Karaf.
> If cluster implementations can't be included in Karaf, there is no discussion ;)
>
> Regards
> JB
> -----Original Message-----
> From: Ioannis Canellos <io...@gmail.com>
> Date: Sat, 16 Apr 2011 11:37:59
> To: <de...@karaf.apache.org>
> Reply-To: dev@karaf.apache.org
> Subject: Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
>
>>
>> I have an absolute and total trust in Guillaume, especially about his
>> Apache fiber (keep in mind that Guillaume is a ASF member). If he proposed
>> his cluster implementation, he knows that we can use it in Karaf
>>
>
> We all do JB! I can't imagine there is anyone among us, that doesn't trust
> him and highly respect his work.
>
> My objection with Guillaume's proposal has nothing to do with Guillaume
> himself or Fuse (I respect Fuse and I've even proposed to my day work
> purchasing Fuse support :-)).
>
>
>> I don't care where the implementation comes from (Fuse, Talend, others), if
>> the implementation is a good one, and if the community accepts this
>> implementation.
>
>
> No ones cares about the origination of the solution.
>
> The only objection is that I believe that the default clustering solution
> should be part of karaf and not a third party dependency.
> If Guillaume proposed to brings his "source" in, none would object (at least
> I would step back).
>
>
> --
> *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
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by jb...@nanthrax.net.
Hi Ioannis,
Don't get me wrong: I assume that Guillaume talked about his implementation cause he can donate to Karaf.
If cluster implementations can't be included in Karaf, there is no discussion ;)
Regards
JB
-----Original Message-----
From: Ioannis Canellos <io...@gmail.com>
Date: Sat, 16 Apr 2011 11:37:59
To: <de...@karaf.apache.org>
Reply-To: dev@karaf.apache.org
Subject: Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
>
> I have an absolute and total trust in Guillaume, especially about his
> Apache fiber (keep in mind that Guillaume is a ASF member). If he proposed
> his cluster implementation, he knows that we can use it in Karaf
>
We all do JB! I can't imagine there is anyone among us, that doesn't trust
him and highly respect his work.
My objection with Guillaume's proposal has nothing to do with Guillaume
himself or Fuse (I respect Fuse and I've even proposed to my day work
purchasing Fuse support :-)).
> I don't care where the implementation comes from (Fuse, Talend, others), if
> the implementation is a good one, and if the community accepts this
> implementation.
No ones cares about the origination of the solution.
The only objection is that I believe that the default clustering solution
should be part of karaf and not a third party dependency.
If Guillaume proposed to brings his "source" in, none would object (at least
I would step back).
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
>
> I have an absolute and total trust in Guillaume, especially about his
> Apache fiber (keep in mind that Guillaume is a ASF member). If he proposed
> his cluster implementation, he knows that we can use it in Karaf
>
We all do JB! I can't imagine there is anyone among us, that doesn't trust
him and highly respect his work.
My objection with Guillaume's proposal has nothing to do with Guillaume
himself or Fuse (I respect Fuse and I've even proposed to my day work
purchasing Fuse support :-)).
> I don't care where the implementation comes from (Fuse, Talend, others), if
> the implementation is a good one, and if the community accepts this
> implementation.
No ones cares about the origination of the solution.
The only objection is that I believe that the default clustering solution
should be part of karaf and not a third party dependency.
If Guillaume proposed to brings his "source" in, none would object (at least
I would step back).
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
What a thread !! :)
I was with a customer yesterday and I just now browse the thread.
Before dealing with Apache and Karaf inclusion of Guillaume work, I
think that we need to compare and discuss from a technology point of view.
My initial e-mail was exactly to start to discuss about different ways
to achieve clustering (existing ones, planned ones, etc) and compare our
point of view.
That's why we need to consider and compare Ioannis and Guillaume works
and maybe conclude that it's a kind of merge of both, or pick up some
implementations of each.
I have an absolute and total trust in Guillaume, especially about his
Apache fiber (keep in mind that Guillaume is a ASF member). If he
proposed his cluster implementation, he knows that we can use it in Karaf.
So, before discussing about the "source" of the implementation, I think
that we need to focus on the technical layer and discuss the different
way to see the cluster.
I don't care where the implementation comes from (Fuse, Talend, others),
if the implementation is a good one, and if the community accepts this
implementation, I can't see any problem.
We are all Apache commiters after all :)
My 2 cents
Regards
JB
On 04/13/2011 10:19 AM, Jean-Baptiste Onofré wrote:
> Hi all,
>
> Ioannis made a great work by using Hazelcast to create a cluster of
> Karaf nodes.
>
> He has already blogged around:
> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>
> I like the design and I think it could be very interesting to embed this
> feature in Karaf 3.0.0.
>
> Ioannnis has kindly accepted to donate this work to Karaf.
>
> The next steps are:
> - think about an assemblies extension to provide cluster ready distribution
> - document Karaf clustering in manual (mostly based on the Ioannis' blog)
> - add an example of Karaf cluster usage.
> I propose to work with Ioannis around these steps.
>
> WDYT ?
> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
> Do you think that we need a kind of "agnostic" layer around clustering
> (especially if some of us already started to work around a different
> kind of Karaf clusters) ?
>
> Thanks
> Regards
> JB
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Andreas Pieber <an...@gmail.com>.
Simply a big thanks and +1 :)
Kind regards,
Andreas
On Wed, Apr 13, 2011 at 10:39 AM, Ioannis Canellos <io...@gmail.com> wrote:
> Please note the current work provides such abstraction layer (through
> the ClusterManager) and Hazelcast only provides the implementation. So we
> are not "bound" to Hazelcast. If we decide to switch to an other
> cluster/grid implementation that provides similar functionality *(discovery
> mechanism, grid etc)*, we could just do it.
>
>
>
> On Wed, Apr 13, 2011 at 11:27 AM, Achim Nierbeck <bc...@googlemail.com>wrote:
>
>> Hi JB, Ioannis,
>>
>> I think this is a great contribution to Karaf, so a +1 from me :)
>> Thank you Ioannis.
>>
>> About the agnostic layer, this sounds reasonable since I guess there
>> are a ton of other possible solutions out there.
>> +1 on that then I guess :)
>>
>> Regards, Achim
>>
>>
>> 2011/4/13 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> > Hi all,
>> >
>> > Ioannis made a great work by using Hazelcast to create a cluster of Karaf
>> > nodes.
>> >
>> > He has already blogged around:
>> >
>> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>> >
>> > I like the design and I think it could be very interesting to embed this
>> > feature in Karaf 3.0.0.
>> >
>> > Ioannnis has kindly accepted to donate this work to Karaf.
>> >
>> > The next steps are:
>> > - think about an assemblies extension to provide cluster ready
>> distribution
>> > - document Karaf clustering in manual (mostly based on the Ioannis' blog)
>> > - add an example of Karaf cluster usage.
>> > I propose to work with Ioannis around these steps.
>> >
>> > WDYT ?
>> > Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
>> > Do you think that we need a kind of "agnostic" layer around clustering
>> > (especially if some of us already started to work around a different kind
>> of
>> > Karaf clusters) ?
>> >
>> > Thanks
>> > Regards
>> > JB
>> >
>>
>
>
>
> --
> *Ioannis Canellos*
> *
> http://iocanel.blogspot.com
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> *
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Ioannis Canellos <io...@gmail.com>.
Please note the current work provides such abstraction layer (through
the ClusterManager) and Hazelcast only provides the implementation. So we
are not "bound" to Hazelcast. If we decide to switch to an other
cluster/grid implementation that provides similar functionality *(discovery
mechanism, grid etc)*, we could just do it.
On Wed, Apr 13, 2011 at 11:27 AM, Achim Nierbeck <bc...@googlemail.com>wrote:
> Hi JB, Ioannis,
>
> I think this is a great contribution to Karaf, so a +1 from me :)
> Thank you Ioannis.
>
> About the agnostic layer, this sounds reasonable since I guess there
> are a ton of other possible solutions out there.
> +1 on that then I guess :)
>
> Regards, Achim
>
>
> 2011/4/13 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> > Hi all,
> >
> > Ioannis made a great work by using Hazelcast to create a cluster of Karaf
> > nodes.
> >
> > He has already blogged around:
> >
> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
> >
> > I like the design and I think it could be very interesting to embed this
> > feature in Karaf 3.0.0.
> >
> > Ioannnis has kindly accepted to donate this work to Karaf.
> >
> > The next steps are:
> > - think about an assemblies extension to provide cluster ready
> distribution
> > - document Karaf clustering in manual (mostly based on the Ioannis' blog)
> > - add an example of Karaf cluster usage.
> > I propose to work with Ioannis around these steps.
> >
> > WDYT ?
> > Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
> > Do you think that we need a kind of "agnostic" layer around clustering
> > (especially if some of us already started to work around a different kind
> of
> > Karaf clusters) ?
> >
> > Thanks
> > Regards
> > JB
> >
>
--
*Ioannis Canellos*
*
http://iocanel.blogspot.com
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
*
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi JB, Ioannis,
I think this is a great contribution to Karaf, so a +1 from me :)
Thank you Ioannis.
About the agnostic layer, this sounds reasonable since I guess there
are a ton of other possible solutions out there.
+1 on that then I guess :)
Regards, Achim
2011/4/13 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi all,
>
> Ioannis made a great work by using Hazelcast to create a cluster of Karaf
> nodes.
>
> He has already blogged around:
> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>
> I like the design and I think it could be very interesting to embed this
> feature in Karaf 3.0.0.
>
> Ioannnis has kindly accepted to donate this work to Karaf.
>
> The next steps are:
> - think about an assemblies extension to provide cluster ready distribution
> - document Karaf clustering in manual (mostly based on the Ioannis' blog)
> - add an example of Karaf cluster usage.
> I propose to work with Ioannis around these steps.
>
> WDYT ?
> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
> Do you think that we need a kind of "agnostic" layer around clustering
> (especially if some of us already started to work around a different kind of
> Karaf clusters) ?
>
> Thanks
> Regards
> JB
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by "Jamie G." <ja...@gmail.com>.
+1 Thanks Ioannis.
Jamie
On Wed, Apr 13, 2011 at 7:37 AM, Charles Moulliard <cm...@gmail.com> wrote:
> Hi JB,
>
> As we have already discussed this idea through chat, I confirm that I
> like this idea and the benefits that we will capitalize for Karaf,
> ServiceMix, Camel, ... projects.
>
> The most critical question will be now to define what will be part of
> the clustering info :
> - configs defined through config admin,
> - cache created by projects,
> - messages that we would like to pass from camel routes into another
> karaf instances,
> - endpoints defintion
> - ...
>
> +1
>
> Regards,
>
> Charles
>
>
>
>
> On Wed, Apr 13, 2011 at 10:19 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi all,
>>
>> Ioannis made a great work by using Hazelcast to create a cluster of Karaf
>> nodes.
>>
>> He has already blogged around:
>> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>>
>> I like the design and I think it could be very interesting to embed this
>> feature in Karaf 3.0.0.
>>
>> Ioannnis has kindly accepted to donate this work to Karaf.
>>
>> The next steps are:
>> - think about an assemblies extension to provide cluster ready distribution
>> - document Karaf clustering in manual (mostly based on the Ioannis' blog)
>> - add an example of Karaf cluster usage.
>> I propose to work with Ioannis around these steps.
>>
>> WDYT ?
>> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
>> Do you think that we need a kind of "agnostic" layer around clustering
>> (especially if some of us already started to work around a different kind of
>> Karaf clusters) ?
>>
>> Thanks
>> Regards
>> JB
>>
>
Re: [PROPOSAL] Karaf clustering feature in Karaf 3.0.0
Posted by Charles Moulliard <cm...@gmail.com>.
Hi JB,
As we have already discussed this idea through chat, I confirm that I
like this idea and the benefits that we will capitalize for Karaf,
ServiceMix, Camel, ... projects.
The most critical question will be now to define what will be part of
the clustering info :
- configs defined through config admin,
- cache created by projects,
- messages that we would like to pass from camel routes into another
karaf instances,
- endpoints defintion
- ...
+1
Regards,
Charles
On Wed, Apr 13, 2011 at 10:19 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi all,
>
> Ioannis made a great work by using Hazelcast to create a cluster of Karaf
> nodes.
>
> He has already blogged around:
> http://iocanel.blogspot.com/2011/03/karaf-clustering-using-hazelcast.html
>
> I like the design and I think it could be very interesting to embed this
> feature in Karaf 3.0.0.
>
> Ioannnis has kindly accepted to donate this work to Karaf.
>
> The next steps are:
> - think about an assemblies extension to provide cluster ready distribution
> - document Karaf clustering in manual (mostly based on the Ioannis' blog)
> - add an example of Karaf cluster usage.
> I propose to work with Ioannis around these steps.
>
> WDYT ?
> Are you OK to ship Karaf clustering using Hazelcast in Karaf ?
> Do you think that we need a kind of "agnostic" layer around clustering
> (especially if some of us already started to work around a different kind of
> Karaf clusters) ?
>
> Thanks
> Regards
> JB
>