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