One approach to handle the situation as below is to use a level of indirection using components which are very fundamental to Karaf and/or JVM so that hard dependencies are totally avoided. These approaches make the API semantics of SRM more event-based than explicit register-callback
Option 1 in this specific context : SRM and OFP can communicate via EventAdmin wherein whenever SRM wants OFP to take an action, it just publishes a ‘notification’ to a pub-sub topic. So, SRM becomes eventadmin publisher and OFP becomes eventadmin subscriber Option 2 in this specific context : A bit compromised solution - using JMX. Following notify-react mechanism SRM fires a JMX notification and OFP listens and reacts Pros : 1) Across API boundary there is no explicit dependency 2) Version management would not be an issue because both Option 1 and Option 2 utilize more fundamental (more fundamental than Offset-0) services of Karaf and/or JVM Cons : 1) We can use only simplet types as notification payloads and not rich structured objects which should be acceptable for most of usecases Regards Muthu From: [email protected] [mailto:[email protected]] On Behalf Of Michael Vorburger Sent: Monday, May 14, 2018 10:35 PM To: Luis Gomez <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: Re: [openflowplugin-dev] [genius-dev] Autorelease build failing while adding dependency on genius-srm from openflowplugin On Mon, May 14, 2018 at 6:59 PM, Luis Gomez <[email protected]<mailto:[email protected]>> wrote: afaik we do not allow cycles between projects so this code may require new project (if this has different scope than original) or new repo to resolve the conflict. Can you tell us more about the "new repo" option? If we could have a 2nd repo, which from a governance perspective is part of the existing genius project, to host the code that is currently in genius/tools and genius/srm, and build that before openflowplugin, and then openflowplugin and then after that the "main" genius, then that is probably a good solution to this problem. How would we get that? On May 14, 2018, at 8:05 AM, Michael Vorburger <[email protected]<mailto:[email protected]>> wrote: On Mon, May 14, 2018 at 1:52 PM, D Arunprakash <[email protected]<mailto:[email protected]>> wrote: Hello, We are trying to use the genius service recovery framework(srm-api) from openflowplugin. https://git.opendaylight.org/gerrit/#/c/68998/ Since, odl-genius-srm was exposed as an independent feature and srm-api doesn’t dependent on ofp, we didn’t find any issues during compiling or feature install. But the autorelease validate jenkin build always failing with the below error. https://jenkins.opendaylight.org/releng/job/openflowplugin-validate-autorelease-fluorine/81/console 09:17:41 + ./scripts/determine-merge-order.py 09:17:42 Traceback (most recent call last): 09:17:42 File "./scripts/determine-merge-order.py", line 80, in <module> 09:17:42 determine_merge_order() 09:17:42 File "./scripts/determine-merge-order.py", line 68, in determine_merge_order 09:17:42 for d in deps_order: 09:17:42 File "/w/workspace/openflowplugin-validate-autorelease-fluorine/venv/lib/python2.7/site-packages/networkx/algorithms/dag.py", line 197, in topological_sort 09:17:42 raise nx.NetworkXUnfeasible("Graph contains a cycle or graph changed " 09:17:42 networkx.exception.Ne<http://networkx.exception.Ne>tworkXUnfeasible: Graph contains a cycle or graph changed during iteration 09:17:42 Build step 'Execute shell' marked build as failure 09:17:42 $ ssh-agent -k Could you please let us know if the feature exposed from genius is proper or jenkin autorelease script detect the circular dependency, even though the odl-genius-srm doesn’t dependent on ofp. Arun, yeah you (OFP) should be able to depend on odl-genius-srm now, that's what all the effort of Moving datastore related utils from mdsalutil to new "genius.tools" was all about... I just had a look (on latest master) through genius/srm and genius/features/odl-genius-srm to make sure we didn't forget anything obvious, but all seems right to me... integration-dev: could any of you shed light on exactly what the failure above is trying to tell us - what cycle in the graph has this found? One thought: Are we allowed to have cycles between projects as long as artifacts themselves don't have cycles? Because that is what we are doing here - ofp wants genius.srm which needs genius.tools, which is independant of the rest of all of genius. genius.mdsalutils and the rest of genius is dependant on ofp. Or is that ^^^ is a problem for integration/autorelease? But why? there isn't really a cycle; and you can build this in a Maven reactor from sources without requiring binaries. Otherwise we have a bigger problem. Resolving that would require an entire new ODL project. OMG the paperwork... :-( Tx, M. -- Michael Vorburger, Red Hat [email protected]<mailto:[email protected]> | IRC: vorburger @freenode | ~ = http://vorburger.ch<http://vorburger.ch/> Regards, Arun _______________________________________________ genius-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/genius-dev _______________________________________________ openflowplugin-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
