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 >
