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