Muthu, thanks for chiming in, but I am fundamentally against using any sort of "weakly typed hacks" to "work around" and "hide" what in effect ARE strong dependencies... so while I understand what you are getting at below from a technical PoV, they are total No Go, to me.
Genius project commiters: Do we want to propose the creation of a new Git repo that is part of the Genius project governance and move genius/tools and genius/srm there so that OFP can consume it? On Tue, May 15, 2018 at 7:12 AM, Muthukumaran K <[email protected] > wrote: > 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]; openflowplugin-dev@lists. > opendaylight.org > *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]> 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]> > wrote: > > > > On Mon, May 14, 2018 at 1:52 PM, D Arunprakash <[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.NetworkXUnfeasible: 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] | IRC: vorburger @freenode | ~ = http://vorburger.ch > > > > Regards, > > Arun > > > _______________________________________________ > genius-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/genius-dev > > > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > > > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
