[Discovery] missing features and 3rd party implementation of discovery.api

[Stefan Egli <eg...@adobe.com>]

Hi,

I've created SLING-2939 [0] to track an additional, 3rd party based implementation of the discovery.api. The idea is to complement the discovery.impl (which is ootb, entirely sling-based) with a more mature, specialized, scalable implementation based on a clustering library. I've summarized some pros/cons of possible candidates, including some already received feedback in the ticket. I would appreciated further feedback!

It looks like Zookeeper/Curator would be a very good fit, requirement-wise – but there was also an argument for using JGroups (or something like Infinispan ontop of it), although that's LGPL at the moment.

At the same time, it might be a good time to discuss if there's any need for api changes, like 'topology-wide leader' or 'grouping/spliting/organizing topologies'. In discussions surrounding topologies, other more consensus-like topics came up (things which zookeeper/curator would cover nicely). The question here is though if that fits into the discovery api itself or if that's not something completely different and out-of-scope of discovery.

Thanks,
Cheers,
Stefan
--
[0] - https://issues.apache.org/jira/browse/SLING-2939

Re: [Discovery] missing features and 3rd party implementation of discovery.api

[Stefan Egli <eg...@adobe.com>]

or we just use Hazelcast.. :)

On 7/5/13 12:44 PM, "Robert Munteanu" <ro...@apache.org> wrote:

>On Fri, Jul 5, 2013 at 1:29 PM, Carsten Ziegeler <cz...@apache.org>
>wrote:
>> Yep, it's a blocker - so we should use something else or wait and
>>increase
>> the pressure to make them switch :)
>
>
>I found out today that the switch is complete in the master branch
>[1], so we can start using it right now if we want to.
>
>However, there still isn't an official release. According to the
>project lead, there isn't a definite date for JGroups 3.4 ( first
>APL-licensed version), but it should be before Infinispan 6.0 is out.
>
>Robert
>
>
>[1]: https://issues.jboss.org/browse/JGRP-1643
>
>>
>>
>> Carsten
>>
>>
>> 2013/7/5 Robert Munteanu <ro...@lmn.ro>
>>
>>> On Fri, Jul 5, 2013 at 12:18 PM, Stefan Egli <eg...@adobe.com> wrote:
>>> > Does the fact that JGroups uses LGPL at the moment (they plan to
>>>switch
>>> to
>>> > APL 'soon') prevent it from being used in Sling?
>>>
>>> AFAIK LGPL is a blocker, see [1]
>>>
>>> Robert
>>>
>>> [1]: http://www.apache.org/legal/resolved.html#category-x
>>>
>>> >
>>> > Cheers,
>>> > Stefan
>>> >
>>> > On 7/3/13 3:05 PM, "Carsten Ziegeler" <cz...@apache.org> wrote:
>>> >
>>> >>Thanks for taking this up, Stefan.
>>> >>
>>> >>I think we should also try to close down the first version of the
>>> >>discovery
>>> >>api and release this, so other parts of our code can really rely on
>>>this
>>> >>api.
>>> >>
>>> >>Apart from that, I don't have a strong preference, although it would
>>>be
>>> >>nice to just use Apache stuff :)
>>> >>
>>> >>Regards
>>> >>Carsten
>>> >>
>>> >>
>>> >>2013/7/1 Stefan Egli <eg...@adobe.com>
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>> I've created SLING-2939 [0] to track an additional, 3rd party based
>>> >>> implementation of the discovery.api. The idea is to complement the
>>> >>> discovery.impl (which is ootb, entirely sling-based) with a more
>>> mature,
>>> >>> specialized, scalable implementation based on a clustering library.
>>> I've
>>> >>> summarized some pros/cons of possible candidates, including some
>>> already
>>> >>> received feedback in the ticket. I would appreciated further
>>>feedback!
>>> >>>
>>> >>> It looks like Zookeeper/Curator would be a very good fit,
>>> >>>requirement-wise
>>> >>> ­ but there was also an argument for using JGroups (or something
>>>like
>>> >>> Infinispan ontop of it), although that's LGPL at the moment.
>>> >>>
>>> >>> At the same time, it might be a good time to discuss if there's any
>>> need
>>> >>> for api changes, like 'topology-wide leader' or
>>> >>> 'grouping/spliting/organizing topologies'. In discussions
>>>surrounding
>>> >>> topologies, other more consensus-like topics came up (things which
>>> >>> zookeeper/curator would cover nicely). The question here is though
>>>if
>>> >>>that
>>> >>> fits into the discovery api itself or if that's not something
>>> completely
>>> >>> different and out-of-scope of discovery.
>>> >>>
>>> >>> Thanks,
>>> >>> Cheers,
>>> >>> Stefan
>>> >>> --
>>> >>> [0] - https://issues.apache.org/jira/browse/SLING-2939
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>--
>>> >>Carsten Ziegeler
>>> >>cziegeler@apache.org
>>> >
>>>
>>>
>>>
>>> --
>>> Sent from my (old) computer
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org

Re: [Discovery] missing features and 3rd party implementation of discovery.api

[Robert Munteanu <ro...@apache.org>]

On Fri, Jul 5, 2013 at 1:29 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Yep, it's a blocker - so we should use something else or wait and increase
> the pressure to make them switch :)


I found out today that the switch is complete in the master branch
[1], so we can start using it right now if we want to.

However, there still isn't an official release. According to the
project lead, there isn't a definite date for JGroups 3.4 ( first
APL-licensed version), but it should be before Infinispan 6.0 is out.

Robert


[1]: https://issues.jboss.org/browse/JGRP-1643

>
>
> Carsten
>
>
> 2013/7/5 Robert Munteanu <ro...@lmn.ro>
>
>> On Fri, Jul 5, 2013 at 12:18 PM, Stefan Egli <eg...@adobe.com> wrote:
>> > Does the fact that JGroups uses LGPL at the moment (they plan to switch
>> to
>> > APL 'soon') prevent it from being used in Sling?
>>
>> AFAIK LGPL is a blocker, see [1]
>>
>> Robert
>>
>> [1]: http://www.apache.org/legal/resolved.html#category-x
>>
>> >
>> > Cheers,
>> > Stefan
>> >
>> > On 7/3/13 3:05 PM, "Carsten Ziegeler" <cz...@apache.org> wrote:
>> >
>> >>Thanks for taking this up, Stefan.
>> >>
>> >>I think we should also try to close down the first version of the
>> >>discovery
>> >>api and release this, so other parts of our code can really rely on this
>> >>api.
>> >>
>> >>Apart from that, I don't have a strong preference, although it would be
>> >>nice to just use Apache stuff :)
>> >>
>> >>Regards
>> >>Carsten
>> >>
>> >>
>> >>2013/7/1 Stefan Egli <eg...@adobe.com>
>> >>
>> >>> Hi,
>> >>>
>> >>> I've created SLING-2939 [0] to track an additional, 3rd party based
>> >>> implementation of the discovery.api. The idea is to complement the
>> >>> discovery.impl (which is ootb, entirely sling-based) with a more
>> mature,
>> >>> specialized, scalable implementation based on a clustering library.
>> I've
>> >>> summarized some pros/cons of possible candidates, including some
>> already
>> >>> received feedback in the ticket. I would appreciated further feedback!
>> >>>
>> >>> It looks like Zookeeper/Curator would be a very good fit,
>> >>>requirement-wise
>> >>> ­ but there was also an argument for using JGroups (or something like
>> >>> Infinispan ontop of it), although that's LGPL at the moment.
>> >>>
>> >>> At the same time, it might be a good time to discuss if there's any
>> need
>> >>> for api changes, like 'topology-wide leader' or
>> >>> 'grouping/spliting/organizing topologies'. In discussions surrounding
>> >>> topologies, other more consensus-like topics came up (things which
>> >>> zookeeper/curator would cover nicely). The question here is though if
>> >>>that
>> >>> fits into the discovery api itself or if that's not something
>> completely
>> >>> different and out-of-scope of discovery.
>> >>>
>> >>> Thanks,
>> >>> Cheers,
>> >>> Stefan
>> >>> --
>> >>> [0] - https://issues.apache.org/jira/browse/SLING-2939
>> >>>
>> >>>
>> >>
>> >>
>> >>--
>> >>Carsten Ziegeler
>> >>cziegeler@apache.org
>> >
>>
>>
>>
>> --
>> Sent from my (old) computer
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org

Re: [Discovery] missing features and 3rd party implementation of discovery.api

[Carsten Ziegeler <cz...@apache.org>]

Yep, it's a blocker - so we should use something else or wait and increase
the pressure to make them switch :)


Carsten


2013/7/5 Robert Munteanu <ro...@lmn.ro>

> On Fri, Jul 5, 2013 at 12:18 PM, Stefan Egli <eg...@adobe.com> wrote:
> > Does the fact that JGroups uses LGPL at the moment (they plan to switch
> to
> > APL 'soon') prevent it from being used in Sling?
>
> AFAIK LGPL is a blocker, see [1]
>
> Robert
>
> [1]: http://www.apache.org/legal/resolved.html#category-x
>
> >
> > Cheers,
> > Stefan
> >
> > On 7/3/13 3:05 PM, "Carsten Ziegeler" <cz...@apache.org> wrote:
> >
> >>Thanks for taking this up, Stefan.
> >>
> >>I think we should also try to close down the first version of the
> >>discovery
> >>api and release this, so other parts of our code can really rely on this
> >>api.
> >>
> >>Apart from that, I don't have a strong preference, although it would be
> >>nice to just use Apache stuff :)
> >>
> >>Regards
> >>Carsten
> >>
> >>
> >>2013/7/1 Stefan Egli <eg...@adobe.com>
> >>
> >>> Hi,
> >>>
> >>> I've created SLING-2939 [0] to track an additional, 3rd party based
> >>> implementation of the discovery.api. The idea is to complement the
> >>> discovery.impl (which is ootb, entirely sling-based) with a more
> mature,
> >>> specialized, scalable implementation based on a clustering library.
> I've
> >>> summarized some pros/cons of possible candidates, including some
> already
> >>> received feedback in the ticket. I would appreciated further feedback!
> >>>
> >>> It looks like Zookeeper/Curator would be a very good fit,
> >>>requirement-wise
> >>> ­ but there was also an argument for using JGroups (or something like
> >>> Infinispan ontop of it), although that's LGPL at the moment.
> >>>
> >>> At the same time, it might be a good time to discuss if there's any
> need
> >>> for api changes, like 'topology-wide leader' or
> >>> 'grouping/spliting/organizing topologies'. In discussions surrounding
> >>> topologies, other more consensus-like topics came up (things which
> >>> zookeeper/curator would cover nicely). The question here is though if
> >>>that
> >>> fits into the discovery api itself or if that's not something
> completely
> >>> different and out-of-scope of discovery.
> >>>
> >>> Thanks,
> >>> Cheers,
> >>> Stefan
> >>> --
> >>> [0] - https://issues.apache.org/jira/browse/SLING-2939
> >>>
> >>>
> >>
> >>
> >>--
> >>Carsten Ziegeler
> >>cziegeler@apache.org
> >
>
>
>
> --
> Sent from my (old) computer
>



-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [Discovery] missing features and 3rd party implementation of discovery.api

[Robert Munteanu <ro...@lmn.ro>]

On Fri, Jul 5, 2013 at 12:18 PM, Stefan Egli <eg...@adobe.com> wrote:
> Does the fact that JGroups uses LGPL at the moment (they plan to switch to
> APL 'soon') prevent it from being used in Sling?

AFAIK LGPL is a blocker, see [1]

Robert

[1]: http://www.apache.org/legal/resolved.html#category-x

>
> Cheers,
> Stefan
>
> On 7/3/13 3:05 PM, "Carsten Ziegeler" <cz...@apache.org> wrote:
>
>>Thanks for taking this up, Stefan.
>>
>>I think we should also try to close down the first version of the
>>discovery
>>api and release this, so other parts of our code can really rely on this
>>api.
>>
>>Apart from that, I don't have a strong preference, although it would be
>>nice to just use Apache stuff :)
>>
>>Regards
>>Carsten
>>
>>
>>2013/7/1 Stefan Egli <eg...@adobe.com>
>>
>>> Hi,
>>>
>>> I've created SLING-2939 [0] to track an additional, 3rd party based
>>> implementation of the discovery.api. The idea is to complement the
>>> discovery.impl (which is ootb, entirely sling-based) with a more mature,
>>> specialized, scalable implementation based on a clustering library. I've
>>> summarized some pros/cons of possible candidates, including some already
>>> received feedback in the ticket. I would appreciated further feedback!
>>>
>>> It looks like Zookeeper/Curator would be a very good fit,
>>>requirement-wise
>>> ­ but there was also an argument for using JGroups (or something like
>>> Infinispan ontop of it), although that's LGPL at the moment.
>>>
>>> At the same time, it might be a good time to discuss if there's any need
>>> for api changes, like 'topology-wide leader' or
>>> 'grouping/spliting/organizing topologies'. In discussions surrounding
>>> topologies, other more consensus-like topics came up (things which
>>> zookeeper/curator would cover nicely). The question here is though if
>>>that
>>> fits into the discovery api itself or if that's not something completely
>>> different and out-of-scope of discovery.
>>>
>>> Thanks,
>>> Cheers,
>>> Stefan
>>> --
>>> [0] - https://issues.apache.org/jira/browse/SLING-2939
>>>
>>>
>>
>>
>>--
>>Carsten Ziegeler
>>cziegeler@apache.org
>



--
Sent from my (old) computer

Re: [Discovery] missing features and 3rd party implementation of discovery.api

[Stefan Egli <eg...@adobe.com>]

Does the fact that JGroups uses LGPL at the moment (they plan to switch to
APL 'soon') prevent it from being used in Sling?

Cheers,
Stefan

On 7/3/13 3:05 PM, "Carsten Ziegeler" <cz...@apache.org> wrote:

>Thanks for taking this up, Stefan.
>
>I think we should also try to close down the first version of the
>discovery
>api and release this, so other parts of our code can really rely on this
>api.
>
>Apart from that, I don't have a strong preference, although it would be
>nice to just use Apache stuff :)
>
>Regards
>Carsten
>
>
>2013/7/1 Stefan Egli <eg...@adobe.com>
>
>> Hi,
>>
>> I've created SLING-2939 [0] to track an additional, 3rd party based
>> implementation of the discovery.api. The idea is to complement the
>> discovery.impl (which is ootb, entirely sling-based) with a more mature,
>> specialized, scalable implementation based on a clustering library. I've
>> summarized some pros/cons of possible candidates, including some already
>> received feedback in the ticket. I would appreciated further feedback!
>>
>> It looks like Zookeeper/Curator would be a very good fit,
>>requirement-wise
>> ­ but there was also an argument for using JGroups (or something like
>> Infinispan ontop of it), although that's LGPL at the moment.
>>
>> At the same time, it might be a good time to discuss if there's any need
>> for api changes, like 'topology-wide leader' or
>> 'grouping/spliting/organizing topologies'. In discussions surrounding
>> topologies, other more consensus-like topics came up (things which
>> zookeeper/curator would cover nicely). The question here is though if
>>that
>> fits into the discovery api itself or if that's not something completely
>> different and out-of-scope of discovery.
>>
>> Thanks,
>> Cheers,
>> Stefan
>> --
>> [0] - https://issues.apache.org/jira/browse/SLING-2939
>>
>>
>
>
>-- 
>Carsten Ziegeler
>cziegeler@apache.org

Re: [Discovery] missing features and 3rd party implementation of discovery.api

[Carsten Ziegeler <cz...@apache.org>]

Thanks for taking this up, Stefan.

I think we should also try to close down the first version of the discovery
api and release this, so other parts of our code can really rely on this
api.

Apart from that, I don't have a strong preference, although it would be
nice to just use Apache stuff :)

Regards
Carsten


2013/7/1 Stefan Egli <eg...@adobe.com>

> Hi,
>
> I've created SLING-2939 [0] to track an additional, 3rd party based
> implementation of the discovery.api. The idea is to complement the
> discovery.impl (which is ootb, entirely sling-based) with a more mature,
> specialized, scalable implementation based on a clustering library. I've
> summarized some pros/cons of possible candidates, including some already
> received feedback in the ticket. I would appreciated further feedback!
>
> It looks like Zookeeper/Curator would be a very good fit, requirement-wise
> – but there was also an argument for using JGroups (or something like
> Infinispan ontop of it), although that's LGPL at the moment.
>
> At the same time, it might be a good time to discuss if there's any need
> for api changes, like 'topology-wide leader' or
> 'grouping/spliting/organizing topologies'. In discussions surrounding
> topologies, other more consensus-like topics came up (things which
> zookeeper/curator would cover nicely). The question here is though if that
> fits into the discovery api itself or if that's not something completely
> different and out-of-scope of discovery.
>
> Thanks,
> Cheers,
> Stefan
> --
> [0] - https://issues.apache.org/jira/browse/SLING-2939
>
>


-- 
Carsten Ziegeler
cziegeler@apache.org