Hi, As we continue to try to migrate OpenDaylight to Karaf 4, it’s become very clear that we need to understand exactly what feature dependencies entail. (And yes, I’ll submit documentation patches once we’ve done so.)
OpenDaylight (ODL) defines lots and lots of features, some of which
contain bundles which survive refreshes, many of which don’t. In
real-world deployments, the Karaf distributions which are built tend to
use boot features to start the features they’re interested in. We make
extensive use of feature dependencies of course, e.g.
<feature name='odl-ttp-model-rest' version='${project.version}'>
<feature version='${project.version}'>odl-ttp-model</feature>
<feature version='${restconf.version}'>odl-mdsal-apidocs</feature>
<feature version='${restconf.version}'>odl-restconf</feature>
<feature version='${controller.version}'>odl-mdsal-broker</feature>
</feature>
In Karaf 3 all this works fine.
In Karaf 4 we’re having lots of issues related to bundle refreshes, so
we’ve been trying to figure out how to avoid them. Of course,
“feature:install --no-auto-refresh” works, but that’s not ideal (at
least, I don’t think it is). We thought perhaps using the dependency or
prerequisite attributes might help.
As we understand things (and this is the main point I would like to
clarify), in Karaf 4, based on the feature declaration above:
* (re)starting odl-ttp-model-rest would restart odl-ttp-model,
odl-mdsal-apidocs etc. (which is a problem because e.g.
odl-mdsal-broker is very likely to already be running when we install
another feature)
* adding “dependency="true"” would disable this
* adding “prerequisite="true"” would also disable this, and ensure that
the corresponding feature is started before odl-ttp-model-rest
We hoped the second option would solve our problems, but in our
experimentation it seems that declaring features in this way means they
aren’t necessarily installed. (I’m hoping I can still dig up examples.)
As in,
<feature name="a">
<feature name="b" dependency="true"/>
</feature>
results in a distribution where
feature:install a
doesn’t necessarily install b. Is that supposed to be the case?
We also thought that declaring prerequisites would work too, especially
since our feature dependencies are acyclic and so it is actually
possible to initialise all our features in a given order. But when we
tried this we ran into stack overflows. (I’ll do it again and file
bugs.)
Does this make any sense at all?
Regards,
Stephen
pgp7CK5uvRtYj.pgp
Description: OpenPGP digital signature
