Operating System: All
Platform: All

This blocks 8364.

After second installation of odl-restconf feature aaa is not initialized again.

Only on second installation of odl-restconf?

I suspect that this is basically that idmlight doesn't handle being reloaded well, and that Karaf 4's default lifecycle management is reloading when later features are installed because they include aaa (transitively?) and don't use dependency=true in the inclusion.

See: https://lists.opendaylight.org/pipermail/release/2017-May/010691.html

That being said, I don't have a great way to test it. I think Lori (now cc'ed on the bug) is also seeing this though.

I just encountered this bug yesterday. I built integration/distribution and started karaf. The container comes up with just the basic karaf features, no Opendaylight features, as expected. I loaded odl-lispflowmapping-msmr manually from the console. Things work well for southbound only operations. When I try to use RESTCONF, on the client side I get 401 unauthorized, and the karaf console throws this excpetion:

2017-05-04 06:37:04,085 | ERROR | rint Extender: 1 | BlueprintContainerImpl | 11 - org.apache.aries.blueprint.core - 1.7.1 | Unable to start blueprint container for bundle org.opendaylight.aaa.idmlight/0.5.0.SNAPSHOT due to unresolved dependencies [(objectClass=org.opendaylight.aaa.api.IIDMStore)]
java.util.concurrent.TimeoutException
at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:371)[11:org.apache.aries.blueprint.core:1.7.1]
at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[11:org.apache.aries.blueprint.core:1.7.1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_131]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_131]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_131]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_131]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]

I have also seen this error intermittently failing odl-vbd-distribution in Nitrogen. E.g: https://logs.opendaylight.org/releng/jenkins092/vbd-distribution-check-nitrogen/23/console.log.gz

"2017-05-02 17:06:42,391 | ERROR | rint Extender: 1 | BlueprintContainerImpl | 69 - org.apache.aries.blueprint.core - 1.7.1 | Unable to start blueprint container for bundle org.opendaylight.aaa.idmlight/0.6.0.SNAPSHOT due to unresolved dependencies [(objectClass=org.opendaylight.aaa.api.IIDMStore)]
java.util.concurrent.TimeoutException
at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:371)[69:org.apache.aries.blueprint.core:1.7.1]
at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[69:org.apache.aries.blueprint.core:1.7.1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]"

Not sure if this is correct solution, but we can set destroy method for blueprint container, which closes its resources.

https://git.opendaylight.org/gerrit/#/c/56543/

Not sure that fixes this issue, but I merged since it was definitely needed either way. Anyone still seeing this?

It looks to be fixed.

Awesome, thanks Ivan and Andrej. Please switch to "Verified" if this has been verified fixed.

I have verified that problem was fixed.