Just an FYI.

    We have added a new feature called “odl-genius-tools”, and have started 
migrating some of the datastore related utils to a new module called 
genius/tools [0].
    This is just to make a light weight feature for use by applications who 
just need datastore related utils. Please use this new feature, so that you 
won’t have to add dependency on a heavier genius feature, just to use datastore 
related utilities.
    Also make sure to use the utils from the new module for any of the upcoming 
patches, as the older ones are deprecated and the migration to the new utils in 
the existing code is in progress.

Thanks,
Faseela

[0] https://git.opendaylight.org/gerrit/#/c/69755/

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Thursday, March 15, 2018 3:14 PM
To: Faseela K <faseel...@ericsson.com>
Cc: genius-...@lists.opendaylight.org
Subject: Re: [genius-dev] Move datastoreutils and other infra utilities outside 
mdsalutil?

Hello,

On Thu, Mar 15, 2018 at 8:24 AM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi,
  Recently there was a requirement from openflowplugin, that they need an “srm” 
only feature.
  And they don’t want any dependency on mdsalutil as mdsalutil inturn depends 
on openflowplugin.
  Currently srm depends on mdsalutil, as some of the utilities(like 
AbstractClusteredSyncDataTreeChangeListener, FutureRpcResults etc) are within 
mdsautil-api.
  Was wondering whether we should have a separate module (“genius-infra” ??) so 
that we can separate out the openflow utilities and other infra utilities?

mdsalutil-api truly has grown into a bit of too much, and the package names in 
it are a mess, so I'm totally in favour of doing such a split. In addition to 
resolving your specific short term problem re. genius' SRM use by 
openflowplugin, I think by clearly separating and offering a few of the general 
purpose utilities which have grown in genius in a separate bundle and Karaf 
feature, we can perhaps make them more of interest to other projects than just 
genius itself and netvirt as well; I'm specifically thinking e.g. 
openflowplugin perhaps having an interest to later use some of them even 
directly, not indirectly via SRM, or e.g. for upcoming work in neutron.

The "scope" of this new bundle IMHO should include MD SAL DataBroker related 
utilities (which we cannot host in the only lower-level infrautils; where they 
should continue to go if appropriate), but without any YANG models (just 
because those are typically always already "higher-level functionalities" which 
should better be placed elsewhere). For example, a specific functionality such 
as SRM should remain in its own bundle, that's just fine, and lets us have good 
modularity boundaries. As such, I would expect this new bundle to only ever 
have dependencies to infrautils, controller & mdsal but never to 
openflowplugin, ovsdb or any other genius bundles, nor the binding-parent. 
Makes sense?

Specifically which existing classes shall we start that bundle with? Here's my 
initial proposal, for discussion:

* org.opendaylight.genius.datastoreutils.listeners (incl. the 
AbstractClusteredSyncDataTreeChangeListener)
* org.opendaylight.genius.infra (incl. the FutureRpcResults you need; also 
ManagedNewTransactionRunner stuff)
* org.opendaylight.genius.mdsalutil.cache
* org.opendaylight.genius.utils.metrics.DataStoreMetrics only as a non-public 
package local class in the new listeners package
* NOT the SingleTransactionDataBroker - I think we should discourage its use, 
in favour of the ManagedNewTransactionRunner
* NOT org.opendaylight.genius.datastoreutils's @Deprecated Listener helpers, 
BUT MAYBE the Chainable* stuff, IFF (when) we make the new 
genius.datastoreutils.listeners use them for testability
* NOT IMdsalApiManager and org.opendaylight.genius.mdsalutil, 
mdsalutil.actions, mdsalutil.instructions, mdsalutil.[nx]matches (obviously)
* NOT org.opendaylight.genius.mdsalutil.packet
* NOT org.opendaylight.genius.utils.batching (at least not in its current form)
* NOT org.opendaylight.genius.utils
* NOT anything Hwvtep related

We can do this with a few steps, of course; don't have to move everything in 
one big Gerrit change. And we obviously need to keep backwards compatibility at 
least for a while. This should be possible by making mdsalutil-api dependant on 
this new bundle, and delegating. We should very much avoid to simply copy/paste 
ANY code, IMHO.

Could I suggest that we use the opportunity of a new bundle as the occassion to 
set a high bar for code quality? Beyond CS (that's old news), and FB (that's so 
2017), we should mandate also that all code in this new bundle complies with 
findbugs-slf4j (which we're just about to enforce accross all of genius 
anyway), Google's Error-Prone, enforces no copy/paste, has a 100% clean 
classpath without duplicates? This is easy by using the infrautils:parent for 
this new bundle, see 
https://github.com/opendaylight/infrautils/blob/master/common/parent/pom.xml. 
There will be further code quality checks added there in the coming months 
(incl. e.g. https://git.opendaylight.org/gerrit/#/c/67838/, and more null 
analysis related stuff).

What do you guys want to call this new bundle? How about genius[-\.]tools? 
That's perhaps better than genius-infra, just because there is already an 
org.opendaylight.genius.infra package in mdsalutil-api, and that could be very 
confusing. Also genius.infra could possibly create confusion with infrautils.

Who's going to do it? Or at least make a start?

Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com<mailto:vorbur...@redhat.com> | IRC: vorburger @freenode | 
~ = http://vorburger.ch<http://vorburger.ch/>

Thanks,
Faseela

_______________________________________________
genius-dev mailing list
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/genius-dev

_______________________________________________
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Reply via email to