2017-06-13 10:35 GMT+02:00 Stephen Kitt <sk...@redhat.com>:
> 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
>
That's wrong. There's no relationship between how a feature is defined and
the bundle being refreshed when the feature is installed.
A bundle will be refreshed if:
* it has been updated
* it has been uninstalled
* one of its dependencies is refreshed
* a new optional dependency has been installed
When installing feature, you can use the --verbose flag which will print
why bundles are being refreshed.
>
> 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
>
--
------------------------
Guillaume Nodet
