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
_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
