Also be ready for some questions like can this code live in another project in ODL so we skip new repo?
> On May 14, 2018, at 7:16 PM, Luis Gomez <[email protected]> wrote: > > For the project extra repo you will have to make the case to the TSC, this is > explain in detail the issue you have today and how an extra repo would help > with the same. After that you can get approval (or rejection) from TSC. > >> On May 14, 2018, at 10:04 AM, Michael Vorburger <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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/ >>> <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 >>> >>> <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 >>> <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 >>> <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev> >> >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
