Cellar groups usage

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Cellar groups usage

Thomas Draier
Hi,

We have been trying to use cellar groups for our cluster deployments. The
idea was to be able to deploy one bundle to only a subset of nodes, but
actually we did not manage to make it work.

We created one single group, say groupA that contains 2 nodes, in addition
to the default group, which contain all nodes. Both groups use the
"cluster" configuration (pull / push), bundles can be handled by any group
(no whitelist/blacklist), and no local listener is configured.

Basically, when we deploy a module on groupA, the module is correctly
installed on all nodes of this group, and everything goes fine. However, if
a sync is done on the default group, the bundle will be immediately
uninstalled, as the "pull" operation will see this bundle as local only
(it's not in default group) and will uninstall it.

On the other hand, if we deploy a module on default group, it's correctly
installed everywhere, but the next sync of groupA will uninstall the bundle
from the 2 nodes that it owns.

Since sync are done automatically quite often, including at startup, some
bundles can get unexpectedly uninstalled at any time. At startup, since all
groups are syncing in a random order - the last group to sync will "win",
so will reinstall bundles that were just uninstalled by the previous sync -
but bundles only installed on other groups will be removed.

We were thinking of different possible fixes for handling that ( maybe
changing the sync, checking that the bundle is not part of any cluster
group before uninstalling it or changing its state ), but it's actually not
quite clear what is the expected behaviour and how it is supposed to work.
Is there anything wrong in the way we are using groups ?

Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Cellar groups usage

jbonofre
Hi Thomas,

did you move the nodes to default to groupA ?

If nodes belong to multiple groups, it's the expected behavior.

Union of groups is not a good setup as you can have slight difference.
That's why you have the cluster:group-move/set.

Regards
JB

On 01/25/2018 10:21 AM, Thomas Draier wrote:

> Hi,
>
> We have been trying to use cellar groups for our cluster deployments. The
> idea was to be able to deploy one bundle to only a subset of nodes, but
> actually we did not manage to make it work.
>
> We created one single group, say groupA that contains 2 nodes, in addition
> to the default group, which contain all nodes. Both groups use the
> "cluster" configuration (pull / push), bundles can be handled by any group
> (no whitelist/blacklist), and no local listener is configured.
>
> Basically, when we deploy a module on groupA, the module is correctly
> installed on all nodes of this group, and everything goes fine. However, if
> a sync is done on the default group, the bundle will be immediately
> uninstalled, as the "pull" operation will see this bundle as local only
> (it's not in default group) and will uninstall it.
>
> On the other hand, if we deploy a module on default group, it's correctly
> installed everywhere, but the next sync of groupA will uninstall the bundle
> from the 2 nodes that it owns.
>
> Since sync are done automatically quite often, including at startup, some
> bundles can get unexpectedly uninstalled at any time. At startup, since all
> groups are syncing in a random order - the last group to sync will "win",
> so will reinstall bundles that were just uninstalled by the previous sync -
> but bundles only installed on other groups will be removed.
>
> We were thinking of different possible fixes for handling that ( maybe
> changing the sync, checking that the bundle is not part of any cluster
> group before uninstalling it or changing its state ), but it's actually not
> quite clear what is the expected behaviour and how it is supposed to work.
> Is there anything wrong in the way we are using groups ?
>
> Thomas
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Cellar groups usage

jbonofre
By the way, which Cellar version are you using ?

I did changes in the way the sync is done.

Especially, detected if the node is the last/only one in a group to prevent this.

Regards
JB

On 01/25/2018 10:30 AM, Jean-Baptiste Onofré wrote:

> Hi Thomas,
>
> did you move the nodes to default to groupA ?
>
> If nodes belong to multiple groups, it's the expected behavior.
>
> Union of groups is not a good setup as you can have slight difference.
> That's why you have the cluster:group-move/set.
>
> Regards
> JB
>
> On 01/25/2018 10:21 AM, Thomas Draier wrote:
>> Hi,
>>
>> We have been trying to use cellar groups for our cluster deployments. The
>> idea was to be able to deploy one bundle to only a subset of nodes, but
>> actually we did not manage to make it work.
>>
>> We created one single group, say groupA that contains 2 nodes, in addition
>> to the default group, which contain all nodes. Both groups use the
>> "cluster" configuration (pull / push), bundles can be handled by any group
>> (no whitelist/blacklist), and no local listener is configured.
>>
>> Basically, when we deploy a module on groupA, the module is correctly
>> installed on all nodes of this group, and everything goes fine. However, if
>> a sync is done on the default group, the bundle will be immediately
>> uninstalled, as the "pull" operation will see this bundle as local only
>> (it's not in default group) and will uninstall it.
>>
>> On the other hand, if we deploy a module on default group, it's correctly
>> installed everywhere, but the next sync of groupA will uninstall the bundle
>> from the 2 nodes that it owns.
>>
>> Since sync are done automatically quite often, including at startup, some
>> bundles can get unexpectedly uninstalled at any time. At startup, since all
>> groups are syncing in a random order - the last group to sync will "win",
>> so will reinstall bundles that were just uninstalled by the previous sync -
>> but bundles only installed on other groups will be removed.
>>
>> We were thinking of different possible fixes for handling that ( maybe
>> changing the sync, checking that the bundle is not part of any cluster
>> group before uninstalling it or changing its state ), but it's actually not
>> quite clear what is the expected behaviour and how it is supposed to work.
>> Is there anything wrong in the way we are using groups ?
>>
>> Thomas
>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Cellar groups usage

Thomas Draier
In reply to this post by jbonofre
Hi JB,

I did not move the node to groupA, as all groups always belong to default
and we cannot "leave" default group (or should they not ? maybe I broke
this in https://github.com/apache/karaf-cellar/pull/44 ? ). In our case we
need to have nodes belong to multiple groups - we have a "limited" group
for deploying bundles only on a sub set of nodes, but deployment on default
should still deploy on all nodes.

We are on a quite old version of cellar ( karaf 4.0.7 / cellar 4.0.2 ), can
you point me to the changes on sync you are talking ? We can probably
upgrade cellar but upgrading karaf will be more difficult, is is possible
to cellar 4.1.x on karaf 4.0.7 ?

Thanks !

On Thu, Jan 25, 2018 at 10:30 AM Jean-Baptiste Onofré <[hidden email]>
wrote:

> Hi Thomas,
>
> did you move the nodes to default to groupA ?
>
> If nodes belong to multiple groups, it's the expected behavior.
>
> Union of groups is not a good setup as you can have slight difference.
> That's why you have the cluster:group-move/set.
>
> Regards
> JB
>
> On 01/25/2018 10:21 AM, Thomas Draier wrote:
> > Hi,
> >
> > We have been trying to use cellar groups for our cluster deployments. The
> > idea was to be able to deploy one bundle to only a subset of nodes, but
> > actually we did not manage to make it work.
> >
> > We created one single group, say groupA that contains 2 nodes, in
> addition
> > to the default group, which contain all nodes. Both groups use the
> > "cluster" configuration (pull / push), bundles can be handled by any
> group
> > (no whitelist/blacklist), and no local listener is configured.
> >
> > Basically, when we deploy a module on groupA, the module is correctly
> > installed on all nodes of this group, and everything goes fine. However,
> if
> > a sync is done on the default group, the bundle will be immediately
> > uninstalled, as the "pull" operation will see this bundle as local only
> > (it's not in default group) and will uninstall it.
> >
> > On the other hand, if we deploy a module on default group, it's correctly
> > installed everywhere, but the next sync of groupA will uninstall the
> bundle
> > from the 2 nodes that it owns.
> >
> > Since sync are done automatically quite often, including at startup, some
> > bundles can get unexpectedly uninstalled at any time. At startup, since
> all
> > groups are syncing in a random order - the last group to sync will "win",
> > so will reinstall bundles that were just uninstalled by the previous
> sync -
> > but bundles only installed on other groups will be removed.
> >
> > We were thinking of different possible fixes for handling that ( maybe
> > changing the sync, checking that the bundle is not part of any cluster
> > group before uninstalling it or changing its state ), but it's actually
> not
> > quite clear what is the expected behaviour and how it is supposed to
> work.
> > Is there anything wrong in the way we are using groups ?
> >
> > Thomas
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Cellar groups usage

jbonofre
That's bad: a node can leave the default group.

I didn't approve https://github.com/apache/karaf-cellar/pull/44 yet, especially
because it changes the group management. That's why I would like to do a deep
review ;)
I guess you are using a fork on Cellar with your changes, right ?

Let me check the sync change I did.

Regards
JB

On 01/25/2018 10:57 AM, Thomas Draier wrote:

> Hi JB,
>
> I did not move the node to groupA, as all groups always belong to default
> and we cannot "leave" default group (or should they not ? maybe I broke
> this in https://github.com/apache/karaf-cellar/pull/44 ? ). In our case we
> need to have nodes belong to multiple groups - we have a "limited" group
> for deploying bundles only on a sub set of nodes, but deployment on default
> should still deploy on all nodes.
>
> We are on a quite old version of cellar ( karaf 4.0.7 / cellar 4.0.2 ), can
> you point me to the changes on sync you are talking ? We can probably
> upgrade cellar but upgrading karaf will be more difficult, is is possible
> to cellar 4.1.x on karaf 4.0.7 ?
>
> Thanks !
>
> On Thu, Jan 25, 2018 at 10:30 AM Jean-Baptiste Onofré <[hidden email]>
> wrote:
>
>> Hi Thomas,
>>
>> did you move the nodes to default to groupA ?
>>
>> If nodes belong to multiple groups, it's the expected behavior.
>>
>> Union of groups is not a good setup as you can have slight difference.
>> That's why you have the cluster:group-move/set.
>>
>> Regards
>> JB
>>
>> On 01/25/2018 10:21 AM, Thomas Draier wrote:
>>> Hi,
>>>
>>> We have been trying to use cellar groups for our cluster deployments. The
>>> idea was to be able to deploy one bundle to only a subset of nodes, but
>>> actually we did not manage to make it work.
>>>
>>> We created one single group, say groupA that contains 2 nodes, in
>> addition
>>> to the default group, which contain all nodes. Both groups use the
>>> "cluster" configuration (pull / push), bundles can be handled by any
>> group
>>> (no whitelist/blacklist), and no local listener is configured.
>>>
>>> Basically, when we deploy a module on groupA, the module is correctly
>>> installed on all nodes of this group, and everything goes fine. However,
>> if
>>> a sync is done on the default group, the bundle will be immediately
>>> uninstalled, as the "pull" operation will see this bundle as local only
>>> (it's not in default group) and will uninstall it.
>>>
>>> On the other hand, if we deploy a module on default group, it's correctly
>>> installed everywhere, but the next sync of groupA will uninstall the
>> bundle
>>> from the 2 nodes that it owns.
>>>
>>> Since sync are done automatically quite often, including at startup, some
>>> bundles can get unexpectedly uninstalled at any time. At startup, since
>> all
>>> groups are syncing in a random order - the last group to sync will "win",
>>> so will reinstall bundles that were just uninstalled by the previous
>> sync -
>>> but bundles only installed on other groups will be removed.
>>>
>>> We were thinking of different possible fixes for handling that ( maybe
>>> changing the sync, checking that the bundle is not part of any cluster
>>> group before uninstalling it or changing its state ), but it's actually
>> not
>>> quite clear what is the expected behaviour and how it is supposed to
>> work.
>>> Is there anything wrong in the way we are using groups ?
>>>
>>> Thomas
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Cellar groups usage

Thomas Draier
I will go back to #44 then :-)

Yes, we are using a fork with changes from #44. And also some other changes
in the synchronizers - we are currently reviewing if there are still things
we may need to push to the master or if they have already been fixed.

thomas

On Thu, Jan 25, 2018 at 11:02 AM Jean-Baptiste Onofré <[hidden email]>
wrote:

> That's bad: a node can leave the default group.
>
> I didn't approve https://github.com/apache/karaf-cellar/pull/44 yet,
> especially
> because it changes the group management. That's why I would like to do a
> deep
> review ;)
> I guess you are using a fork on Cellar with your changes, right ?
>
> Let me check the sync change I did.
>
> Regards
> JB
>
> On 01/25/2018 10:57 AM, Thomas Draier wrote:
> > Hi JB,
> >
> > I did not move the node to groupA, as all groups always belong to default
> > and we cannot "leave" default group (or should they not ? maybe I broke
> > this in https://github.com/apache/karaf-cellar/pull/44 ? ). In our case
> we
> > need to have nodes belong to multiple groups - we have a "limited" group
> > for deploying bundles only on a sub set of nodes, but deployment on
> default
> > should still deploy on all nodes.
> >
> > We are on a quite old version of cellar ( karaf 4.0.7 / cellar 4.0.2 ),
> can
> > you point me to the changes on sync you are talking ? We can probably
> > upgrade cellar but upgrading karaf will be more difficult, is is possible
> > to cellar 4.1.x on karaf 4.0.7 ?
> >
> > Thanks !
> >
> > On Thu, Jan 25, 2018 at 10:30 AM Jean-Baptiste Onofré <[hidden email]>
> > wrote:
> >
> >> Hi Thomas,
> >>
> >> did you move the nodes to default to groupA ?
> >>
> >> If nodes belong to multiple groups, it's the expected behavior.
> >>
> >> Union of groups is not a good setup as you can have slight difference.
> >> That's why you have the cluster:group-move/set.
> >>
> >> Regards
> >> JB
> >>
> >> On 01/25/2018 10:21 AM, Thomas Draier wrote:
> >>> Hi,
> >>>
> >>> We have been trying to use cellar groups for our cluster deployments.
> The
> >>> idea was to be able to deploy one bundle to only a subset of nodes, but
> >>> actually we did not manage to make it work.
> >>>
> >>> We created one single group, say groupA that contains 2 nodes, in
> >> addition
> >>> to the default group, which contain all nodes. Both groups use the
> >>> "cluster" configuration (pull / push), bundles can be handled by any
> >> group
> >>> (no whitelist/blacklist), and no local listener is configured.
> >>>
> >>> Basically, when we deploy a module on groupA, the module is correctly
> >>> installed on all nodes of this group, and everything goes fine.
> However,
> >> if
> >>> a sync is done on the default group, the bundle will be immediately
> >>> uninstalled, as the "pull" operation will see this bundle as local only
> >>> (it's not in default group) and will uninstall it.
> >>>
> >>> On the other hand, if we deploy a module on default group, it's
> correctly
> >>> installed everywhere, but the next sync of groupA will uninstall the
> >> bundle
> >>> from the 2 nodes that it owns.
> >>>
> >>> Since sync are done automatically quite often, including at startup,
> some
> >>> bundles can get unexpectedly uninstalled at any time. At startup, since
> >> all
> >>> groups are syncing in a random order - the last group to sync will
> "win",
> >>> so will reinstall bundles that were just uninstalled by the previous
> >> sync -
> >>> but bundles only installed on other groups will be removed.
> >>>
> >>> We were thinking of different possible fixes for handling that ( maybe
> >>> changing the sync, checking that the bundle is not part of any cluster
> >>> group before uninstalling it or changing its state ), but it's actually
> >> not
> >>> quite clear what is the expected behaviour and how it is supposed to
> >> work.
> >>> Is there anything wrong in the way we are using groups ?
> >>>
> >>> Thomas
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> [hidden email]
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Cellar groups usage

jbonofre
Great, I'm proposing to review the change in early stage with you.

Don't hesitate to ping me then.

Thanks !
Regards
JB

On 01/25/2018 11:10 AM, Thomas Draier wrote:

> I will go back to #44 then :-)
>
> Yes, we are using a fork with changes from #44. And also some other changes
> in the synchronizers - we are currently reviewing if there are still things
> we may need to push to the master or if they have already been fixed.
>
> thomas
>
> On Thu, Jan 25, 2018 at 11:02 AM Jean-Baptiste Onofré <[hidden email]>
> wrote:
>
>> That's bad: a node can leave the default group.
>>
>> I didn't approve https://github.com/apache/karaf-cellar/pull/44 yet,
>> especially
>> because it changes the group management. That's why I would like to do a
>> deep
>> review ;)
>> I guess you are using a fork on Cellar with your changes, right ?
>>
>> Let me check the sync change I did.
>>
>> Regards
>> JB
>>
>> On 01/25/2018 10:57 AM, Thomas Draier wrote:
>>> Hi JB,
>>>
>>> I did not move the node to groupA, as all groups always belong to default
>>> and we cannot "leave" default group (or should they not ? maybe I broke
>>> this in https://github.com/apache/karaf-cellar/pull/44 ? ). In our case
>> we
>>> need to have nodes belong to multiple groups - we have a "limited" group
>>> for deploying bundles only on a sub set of nodes, but deployment on
>> default
>>> should still deploy on all nodes.
>>>
>>> We are on a quite old version of cellar ( karaf 4.0.7 / cellar 4.0.2 ),
>> can
>>> you point me to the changes on sync you are talking ? We can probably
>>> upgrade cellar but upgrading karaf will be more difficult, is is possible
>>> to cellar 4.1.x on karaf 4.0.7 ?
>>>
>>> Thanks !
>>>
>>> On Thu, Jan 25, 2018 at 10:30 AM Jean-Baptiste Onofré <[hidden email]>
>>> wrote:
>>>
>>>> Hi Thomas,
>>>>
>>>> did you move the nodes to default to groupA ?
>>>>
>>>> If nodes belong to multiple groups, it's the expected behavior.
>>>>
>>>> Union of groups is not a good setup as you can have slight difference.
>>>> That's why you have the cluster:group-move/set.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 01/25/2018 10:21 AM, Thomas Draier wrote:
>>>>> Hi,
>>>>>
>>>>> We have been trying to use cellar groups for our cluster deployments.
>> The
>>>>> idea was to be able to deploy one bundle to only a subset of nodes, but
>>>>> actually we did not manage to make it work.
>>>>>
>>>>> We created one single group, say groupA that contains 2 nodes, in
>>>> addition
>>>>> to the default group, which contain all nodes. Both groups use the
>>>>> "cluster" configuration (pull / push), bundles can be handled by any
>>>> group
>>>>> (no whitelist/blacklist), and no local listener is configured.
>>>>>
>>>>> Basically, when we deploy a module on groupA, the module is correctly
>>>>> installed on all nodes of this group, and everything goes fine.
>> However,
>>>> if
>>>>> a sync is done on the default group, the bundle will be immediately
>>>>> uninstalled, as the "pull" operation will see this bundle as local only
>>>>> (it's not in default group) and will uninstall it.
>>>>>
>>>>> On the other hand, if we deploy a module on default group, it's
>> correctly
>>>>> installed everywhere, but the next sync of groupA will uninstall the
>>>> bundle
>>>>> from the 2 nodes that it owns.
>>>>>
>>>>> Since sync are done automatically quite often, including at startup,
>> some
>>>>> bundles can get unexpectedly uninstalled at any time. At startup, since
>>>> all
>>>>> groups are syncing in a random order - the last group to sync will
>> "win",
>>>>> so will reinstall bundles that were just uninstalled by the previous
>>>> sync -
>>>>> but bundles only installed on other groups will be removed.
>>>>>
>>>>> We were thinking of different possible fixes for handling that ( maybe
>>>>> changing the sync, checking that the bundle is not part of any cluster
>>>>> group before uninstalling it or changing its state ), but it's actually
>>>> not
>>>>> quite clear what is the expected behaviour and how it is supposed to
>>>> work.
>>>>> Is there anything wrong in the way we are using groups ?
>>>>>
>>>>> Thomas
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> [hidden email]
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Cellar groups usage

Thomas Draier
Ok, sorry, I just tested and checked the code, and yes we can still leave
the default group :-) The thing you cannot do is delete the default group
.. but leaving/joining is still possible. Tell me when you want to review
the code, if you have any question about it.



On Thu, Jan 25, 2018 at 11:13 AM Jean-Baptiste Onofré <[hidden email]>
wrote:

> Great, I'm proposing to review the change in early stage with you.
>
> Don't hesitate to ping me then.
>
> Thanks !
> Regards
> JB
>
> On 01/25/2018 11:10 AM, Thomas Draier wrote:
> > I will go back to #44 then :-)
> >
> > Yes, we are using a fork with changes from #44. And also some other
> changes
> > in the synchronizers - we are currently reviewing if there are still
> things
> > we may need to push to the master or if they have already been fixed.
> >
> > thomas
> >
> > On Thu, Jan 25, 2018 at 11:02 AM Jean-Baptiste Onofré <[hidden email]>
> > wrote:
> >
> >> That's bad: a node can leave the default group.
> >>
> >> I didn't approve https://github.com/apache/karaf-cellar/pull/44 yet,
> >> especially
> >> because it changes the group management. That's why I would like to do a
> >> deep
> >> review ;)
> >> I guess you are using a fork on Cellar with your changes, right ?
> >>
> >> Let me check the sync change I did.
> >>
> >> Regards
> >> JB
> >>
> >> On 01/25/2018 10:57 AM, Thomas Draier wrote:
> >>> Hi JB,
> >>>
> >>> I did not move the node to groupA, as all groups always belong to
> default
> >>> and we cannot "leave" default group (or should they not ? maybe I broke
> >>> this in https://github.com/apache/karaf-cellar/pull/44 ? ). In our
> case
> >> we
> >>> need to have nodes belong to multiple groups - we have a "limited"
> group
> >>> for deploying bundles only on a sub set of nodes, but deployment on
> >> default
> >>> should still deploy on all nodes.
> >>>
> >>> We are on a quite old version of cellar ( karaf 4.0.7 / cellar 4.0.2 ),
> >> can
> >>> you point me to the changes on sync you are talking ? We can probably
> >>> upgrade cellar but upgrading karaf will be more difficult, is is
> possible
> >>> to cellar 4.1.x on karaf 4.0.7 ?
> >>>
> >>> Thanks !
> >>>
> >>> On Thu, Jan 25, 2018 at 10:30 AM Jean-Baptiste Onofré <[hidden email]
> >
> >>> wrote:
> >>>
> >>>> Hi Thomas,
> >>>>
> >>>> did you move the nodes to default to groupA ?
> >>>>
> >>>> If nodes belong to multiple groups, it's the expected behavior.
> >>>>
> >>>> Union of groups is not a good setup as you can have slight difference.
> >>>> That's why you have the cluster:group-move/set.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 01/25/2018 10:21 AM, Thomas Draier wrote:
> >>>>> Hi,
> >>>>>
> >>>>> We have been trying to use cellar groups for our cluster deployments.
> >> The
> >>>>> idea was to be able to deploy one bundle to only a subset of nodes,
> but
> >>>>> actually we did not manage to make it work.
> >>>>>
> >>>>> We created one single group, say groupA that contains 2 nodes, in
> >>>> addition
> >>>>> to the default group, which contain all nodes. Both groups use the
> >>>>> "cluster" configuration (pull / push), bundles can be handled by any
> >>>> group
> >>>>> (no whitelist/blacklist), and no local listener is configured.
> >>>>>
> >>>>> Basically, when we deploy a module on groupA, the module is correctly
> >>>>> installed on all nodes of this group, and everything goes fine.
> >> However,
> >>>> if
> >>>>> a sync is done on the default group, the bundle will be immediately
> >>>>> uninstalled, as the "pull" operation will see this bundle as local
> only
> >>>>> (it's not in default group) and will uninstall it.
> >>>>>
> >>>>> On the other hand, if we deploy a module on default group, it's
> >> correctly
> >>>>> installed everywhere, but the next sync of groupA will uninstall the
> >>>> bundle
> >>>>> from the 2 nodes that it owns.
> >>>>>
> >>>>> Since sync are done automatically quite often, including at startup,
> >> some
> >>>>> bundles can get unexpectedly uninstalled at any time. At startup,
> since
> >>>> all
> >>>>> groups are syncing in a random order - the last group to sync will
> >> "win",
> >>>>> so will reinstall bundles that were just uninstalled by the previous
> >>>> sync -
> >>>>> but bundles only installed on other groups will be removed.
> >>>>>
> >>>>> We were thinking of different possible fixes for handling that (
> maybe
> >>>>> changing the sync, checking that the bundle is not part of any
> cluster
> >>>>> group before uninstalling it or changing its state ), but it's
> actually
> >>>> not
> >>>>> quite clear what is the expected behaviour and how it is supposed to
> >>>> work.
> >>>>> Is there anything wrong in the way we are using groups ?
> >>>>>
> >>>>> Thomas
> >>>>>
> >>>>
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> [hidden email]
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> [hidden email]
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>