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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to