You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by lb <lb...@gmail.com> on 2015/12/30 13:53:41 UTC
karaf/cellar generic discovery service
Hi all,
I'm wondering if it would make sense to extend current discovery service to
make it more generic and shareable among other services that need discovery
capabilities.
This may be achieved by adding some filtering capability to discoverMembers
i.e.
Collection<DiscoveredMember> discoverMembers(String domain)
How domain is used is implementation dependant (labels for kubernetes, path
for etcd, etc). Domain used by karaf clustering may be then defined in
hazelcast's service configuration file or wherever it make sense.
It would also be useful to have additional info about the discovery
services like all the kubernetes label or any additional attribute
associated with the discovered service.
What do you think ?
Re: karaf/cellar generic discovery service
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Luca,
Discovery comes from cloud and we extended later to kubernetes. It makes
sense to extend the API to support domains/filters.
As it could be backward compatible, it's something that we can include
in next minor release.
Can you create a Jira about that, I will do it ?
Thanks,
Regards
JB
On 12/30/2015 01:53 PM, lb wrote:
> Hi all,
>
> I'm wondering if it would make sense to extend current discovery service to
> make it more generic and shareable among other services that need discovery
> capabilities.
>
> This may be achieved by adding some filtering capability to discoverMembers
> i.e.
>
> Collection<DiscoveredMember> discoverMembers(String domain)
>
> How domain is used is implementation dependant (labels for kubernetes, path
> for etcd, etc). Domain used by karaf clustering may be then defined in
> hazelcast's service configuration file or wherever it make sense.
>
> It would also be useful to have additional info about the discovery
> services like all the kubernetes label or any additional attribute
> associated with the discovered service.
>
> What do you think ?
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: karaf/cellar generic discovery service
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thx
On 12/30/2015 10:20 PM, lb wrote:
> KARAF-4245
>
> On Wednesday, 30 December 2015, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Please Luca, create the Jira for domain/filtering. I will tackle the ECF
>> one.
>>
>> Regards
>> JB
>>
>> On 12/30/2015 06:44 PM, lb wrote:
>>
>>> Should I open the Jira for domain/filtering ? Or the one for ecf would
>>> include both ?
>>>
>>> On Wednesday, 30 December 2015, Scott Lewis <sl...@composent.com> wrote:
>>>
>>> On 12/30/2015 8:56 AM, Jean-Baptiste Onofré wrote:
>>>>
>>>> Hi Scott,
>>>>>
>>>>> good idea, as said early, we could provide Cellar ECF for both discovery
>>>>> and remote service (as an alternative to DOSGi).
>>>>>
>>>>>
>>>> That would be splendid. I would certainly contribute to the creation of
>>>> both a Cellar discovery and/or distribution provider.
>>>>
>>>>
>>>> Let me create a Jira and work on a PoC about that.
>>>>>
>>>>>
>>>> Please feel free to add me to the Jira and/or contact me directly. Just
>>>> FYI, ECF has github repos [1] in addition to the EF-hosted repos [2]...so
>>>> we can be flexible about where things are developed.
>>>>
>>>> Scott
>>>>
>>>> [1] https://github.com/ECF
>>>> [2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/
>>>>
>>>>
>>>> Regards
>>>>> JB
>>>>>
>>>>> On 12/30/2015 05:08 PM, Scott Lewis wrote:
>>>>>
>>>>> ECF [0] has a stable network discovery API [1] and a number of providers
>>>>>> based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd,
>>>>>> custom). We would welcome cooperative creation of other providers
>>>>>> (e.g.
>>>>>> based upon cellar).
>>>>>>
>>>>>> The discovery API is used by ECF's implementation of OSGi Remote
>>>>>> Services, allowing any discovery provider to be used to discover remote
>>>>>> services.
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> [0] https://wiki.eclipse.org/ECF
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>> http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html
>>>>>>
>>>>>> [2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
>>>>>>
>>>>>> On 12/30/2015 4:53 AM, lb wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm wondering if it would make sense to extend current discovery
>>>>>>> service to
>>>>>>> make it more generic and shareable among other services that need
>>>>>>> discovery
>>>>>>> capabilities.
>>>>>>>
>>>>>>> This may be achieved by adding some filtering capability to
>>>>>>> discoverMembers
>>>>>>> i.e.
>>>>>>>
>>>>>>> Collection<DiscoveredMember> discoverMembers(String domain)
>>>>>>>
>>>>>>> How domain is used is implementation dependant (labels for kubernetes,
>>>>>>> path
>>>>>>> for etcd, etc). Domain used by karaf clustering may be then defined in
>>>>>>> hazelcast's service configuration file or wherever it make sense.
>>>>>>>
>>>>>>> It would also be useful to have additional info about the discovery
>>>>>>> services like all the kubernetes label or any additional attribute
>>>>>>> associated with the discovered service.
>>>>>>>
>>>>>>> What do you think ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: karaf/cellar generic discovery service
Posted by lb <lb...@gmail.com>.
KARAF-4245
On Wednesday, 30 December 2015, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Please Luca, create the Jira for domain/filtering. I will tackle the ECF
> one.
>
> Regards
> JB
>
> On 12/30/2015 06:44 PM, lb wrote:
>
>> Should I open the Jira for domain/filtering ? Or the one for ecf would
>> include both ?
>>
>> On Wednesday, 30 December 2015, Scott Lewis <sl...@composent.com> wrote:
>>
>> On 12/30/2015 8:56 AM, Jean-Baptiste Onofré wrote:
>>>
>>> Hi Scott,
>>>>
>>>> good idea, as said early, we could provide Cellar ECF for both discovery
>>>> and remote service (as an alternative to DOSGi).
>>>>
>>>>
>>> That would be splendid. I would certainly contribute to the creation of
>>> both a Cellar discovery and/or distribution provider.
>>>
>>>
>>> Let me create a Jira and work on a PoC about that.
>>>>
>>>>
>>> Please feel free to add me to the Jira and/or contact me directly. Just
>>> FYI, ECF has github repos [1] in addition to the EF-hosted repos [2]...so
>>> we can be flexible about where things are developed.
>>>
>>> Scott
>>>
>>> [1] https://github.com/ECF
>>> [2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/
>>>
>>>
>>> Regards
>>>> JB
>>>>
>>>> On 12/30/2015 05:08 PM, Scott Lewis wrote:
>>>>
>>>> ECF [0] has a stable network discovery API [1] and a number of providers
>>>>> based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd,
>>>>> custom). We would welcome cooperative creation of other providers
>>>>> (e.g.
>>>>> based upon cellar).
>>>>>
>>>>> The discovery API is used by ECF's implementation of OSGi Remote
>>>>> Services, allowing any discovery provider to be used to discover remote
>>>>> services.
>>>>>
>>>>> Scott
>>>>>
>>>>> [0] https://wiki.eclipse.org/ECF
>>>>> [1]
>>>>>
>>>>>
>>>>> http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html
>>>>>
>>>>> [2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
>>>>>
>>>>> On 12/30/2015 4:53 AM, lb wrote:
>>>>>
>>>>> Hi all,
>>>>>>
>>>>>> I'm wondering if it would make sense to extend current discovery
>>>>>> service to
>>>>>> make it more generic and shareable among other services that need
>>>>>> discovery
>>>>>> capabilities.
>>>>>>
>>>>>> This may be achieved by adding some filtering capability to
>>>>>> discoverMembers
>>>>>> i.e.
>>>>>>
>>>>>> Collection<DiscoveredMember> discoverMembers(String domain)
>>>>>>
>>>>>> How domain is used is implementation dependant (labels for kubernetes,
>>>>>> path
>>>>>> for etcd, etc). Domain used by karaf clustering may be then defined in
>>>>>> hazelcast's service configuration file or wherever it make sense.
>>>>>>
>>>>>> It would also be useful to have additional info about the discovery
>>>>>> services like all the kubernetes label or any additional attribute
>>>>>> associated with the discovered service.
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: karaf/cellar generic discovery service
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Please Luca, create the Jira for domain/filtering. I will tackle the ECF
one.
Regards
JB
On 12/30/2015 06:44 PM, lb wrote:
> Should I open the Jira for domain/filtering ? Or the one for ecf would
> include both ?
>
> On Wednesday, 30 December 2015, Scott Lewis <sl...@composent.com> wrote:
>
>> On 12/30/2015 8:56 AM, Jean-Baptiste Onofré wrote:
>>
>>> Hi Scott,
>>>
>>> good idea, as said early, we could provide Cellar ECF for both discovery
>>> and remote service (as an alternative to DOSGi).
>>>
>>
>> That would be splendid. I would certainly contribute to the creation of
>> both a Cellar discovery and/or distribution provider.
>>
>>
>>> Let me create a Jira and work on a PoC about that.
>>>
>>
>> Please feel free to add me to the Jira and/or contact me directly. Just
>> FYI, ECF has github repos [1] in addition to the EF-hosted repos [2]...so
>> we can be flexible about where things are developed.
>>
>> Scott
>>
>> [1] https://github.com/ECF
>> [2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/
>>
>>
>>> Regards
>>> JB
>>>
>>> On 12/30/2015 05:08 PM, Scott Lewis wrote:
>>>
>>>> ECF [0] has a stable network discovery API [1] and a number of providers
>>>> based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd,
>>>> custom). We would welcome cooperative creation of other providers (e.g.
>>>> based upon cellar).
>>>>
>>>> The discovery API is used by ECF's implementation of OSGi Remote
>>>> Services, allowing any discovery provider to be used to discover remote
>>>> services.
>>>>
>>>> Scott
>>>>
>>>> [0] https://wiki.eclipse.org/ECF
>>>> [1]
>>>>
>>>> http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html
>>>>
>>>> [2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
>>>>
>>>> On 12/30/2015 4:53 AM, lb wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm wondering if it would make sense to extend current discovery
>>>>> service to
>>>>> make it more generic and shareable among other services that need
>>>>> discovery
>>>>> capabilities.
>>>>>
>>>>> This may be achieved by adding some filtering capability to
>>>>> discoverMembers
>>>>> i.e.
>>>>>
>>>>> Collection<DiscoveredMember> discoverMembers(String domain)
>>>>>
>>>>> How domain is used is implementation dependant (labels for kubernetes,
>>>>> path
>>>>> for etcd, etc). Domain used by karaf clustering may be then defined in
>>>>> hazelcast's service configuration file or wherever it make sense.
>>>>>
>>>>> It would also be useful to have additional info about the discovery
>>>>> services like all the kubernetes label or any additional attribute
>>>>> associated with the discovered service.
>>>>>
>>>>> What do you think ?
>>>>>
>>>>>
>>>>
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: karaf/cellar generic discovery service
Posted by lb <lb...@gmail.com>.
Should I open the Jira for domain/filtering ? Or the one for ecf would
include both ?
On Wednesday, 30 December 2015, Scott Lewis <sl...@composent.com> wrote:
> On 12/30/2015 8:56 AM, Jean-Baptiste Onofré wrote:
>
>> Hi Scott,
>>
>> good idea, as said early, we could provide Cellar ECF for both discovery
>> and remote service (as an alternative to DOSGi).
>>
>
> That would be splendid. I would certainly contribute to the creation of
> both a Cellar discovery and/or distribution provider.
>
>
>> Let me create a Jira and work on a PoC about that.
>>
>
> Please feel free to add me to the Jira and/or contact me directly. Just
> FYI, ECF has github repos [1] in addition to the EF-hosted repos [2]...so
> we can be flexible about where things are developed.
>
> Scott
>
> [1] https://github.com/ECF
> [2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/
>
>
>> Regards
>> JB
>>
>> On 12/30/2015 05:08 PM, Scott Lewis wrote:
>>
>>> ECF [0] has a stable network discovery API [1] and a number of providers
>>> based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd,
>>> custom). We would welcome cooperative creation of other providers (e.g.
>>> based upon cellar).
>>>
>>> The discovery API is used by ECF's implementation of OSGi Remote
>>> Services, allowing any discovery provider to be used to discover remote
>>> services.
>>>
>>> Scott
>>>
>>> [0] https://wiki.eclipse.org/ECF
>>> [1]
>>>
>>> http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html
>>>
>>> [2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
>>>
>>> On 12/30/2015 4:53 AM, lb wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm wondering if it would make sense to extend current discovery
>>>> service to
>>>> make it more generic and shareable among other services that need
>>>> discovery
>>>> capabilities.
>>>>
>>>> This may be achieved by adding some filtering capability to
>>>> discoverMembers
>>>> i.e.
>>>>
>>>> Collection<DiscoveredMember> discoverMembers(String domain)
>>>>
>>>> How domain is used is implementation dependant (labels for kubernetes,
>>>> path
>>>> for etcd, etc). Domain used by karaf clustering may be then defined in
>>>> hazelcast's service configuration file or wherever it make sense.
>>>>
>>>> It would also be useful to have additional info about the discovery
>>>> services like all the kubernetes label or any additional attribute
>>>> associated with the discovered service.
>>>>
>>>> What do you think ?
>>>>
>>>>
>>>
>>
>
Re: karaf/cellar generic discovery service
Posted by Scott Lewis <sl...@composent.com>.
On 12/30/2015 8:56 AM, Jean-Baptiste Onofré wrote:
> Hi Scott,
>
> good idea, as said early, we could provide Cellar ECF for both
> discovery and remote service (as an alternative to DOSGi).
That would be splendid. I would certainly contribute to the creation of
both a Cellar discovery and/or distribution provider.
>
> Let me create a Jira and work on a PoC about that.
Please feel free to add me to the Jira and/or contact me directly. Just
FYI, ECF has github repos [1] in addition to the EF-hosted repos
[2]...so we can be flexible about where things are developed.
Scott
[1] https://github.com/ECF
[2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/
>
> Regards
> JB
>
> On 12/30/2015 05:08 PM, Scott Lewis wrote:
>> ECF [0] has a stable network discovery API [1] and a number of providers
>> based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd,
>> custom). We would welcome cooperative creation of other providers (e.g.
>> based upon cellar).
>>
>> The discovery API is used by ECF's implementation of OSGi Remote
>> Services, allowing any discovery provider to be used to discover remote
>> services.
>>
>> Scott
>>
>> [0] https://wiki.eclipse.org/ECF
>> [1]
>> http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html
>>
>>
>> [2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
>>
>> On 12/30/2015 4:53 AM, lb wrote:
>>> Hi all,
>>>
>>> I'm wondering if it would make sense to extend current discovery
>>> service to
>>> make it more generic and shareable among other services that need
>>> discovery
>>> capabilities.
>>>
>>> This may be achieved by adding some filtering capability to
>>> discoverMembers
>>> i.e.
>>>
>>> Collection<DiscoveredMember> discoverMembers(String domain)
>>>
>>> How domain is used is implementation dependant (labels for kubernetes,
>>> path
>>> for etcd, etc). Domain used by karaf clustering may be then defined in
>>> hazelcast's service configuration file or wherever it make sense.
>>>
>>> It would also be useful to have additional info about the discovery
>>> services like all the kubernetes label or any additional attribute
>>> associated with the discovered service.
>>>
>>> What do you think ?
>>>
>>
>
Re: karaf/cellar generic discovery service
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Scott,
good idea, as said early, we could provide Cellar ECF for both discovery
and remote service (as an alternative to DOSGi).
Let me create a Jira and work on a PoC about that.
Regards
JB
On 12/30/2015 05:08 PM, Scott Lewis wrote:
> ECF [0] has a stable network discovery API [1] and a number of providers
> based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd,
> custom). We would welcome cooperative creation of other providers (e.g.
> based upon cellar).
>
> The discovery API is used by ECF's implementation of OSGi Remote
> Services, allowing any discovery provider to be used to discover remote
> services.
>
> Scott
>
> [0] https://wiki.eclipse.org/ECF
> [1]
> http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html
>
> [2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
>
> On 12/30/2015 4:53 AM, lb wrote:
>> Hi all,
>>
>> I'm wondering if it would make sense to extend current discovery
>> service to
>> make it more generic and shareable among other services that need
>> discovery
>> capabilities.
>>
>> This may be achieved by adding some filtering capability to
>> discoverMembers
>> i.e.
>>
>> Collection<DiscoveredMember> discoverMembers(String domain)
>>
>> How domain is used is implementation dependant (labels for kubernetes,
>> path
>> for etcd, etc). Domain used by karaf clustering may be then defined in
>> hazelcast's service configuration file or wherever it make sense.
>>
>> It would also be useful to have additional info about the discovery
>> services like all the kubernetes label or any additional attribute
>> associated with the discovered service.
>>
>> What do you think ?
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: karaf/cellar generic discovery service
Posted by Scott Lewis <sl...@composent.com>.
ECF [0] has a stable network discovery API [1] and a number of providers
based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd,
custom). We would welcome cooperative creation of other providers (e.g.
based upon cellar).
The discovery API is used by ECF's implementation of OSGi Remote
Services, allowing any discovery provider to be used to discover remote
services.
Scott
[0] https://wiki.eclipse.org/ECF
[1]
http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html
[2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
On 12/30/2015 4:53 AM, lb wrote:
> Hi all,
>
> I'm wondering if it would make sense to extend current discovery service to
> make it more generic and shareable among other services that need discovery
> capabilities.
>
> This may be achieved by adding some filtering capability to discoverMembers
> i.e.
>
> Collection<DiscoveredMember> discoverMembers(String domain)
>
> How domain is used is implementation dependant (labels for kubernetes, path
> for etcd, etc). Domain used by karaf clustering may be then defined in
> hazelcast's service configuration file or wherever it make sense.
>
> It would also be useful to have additional info about the discovery
> services like all the kubernetes label or any additional attribute
> associated with the discovered service.
>
> What do you think ?
>