[CONTROLLER-812] Loading of YangFiles dependent on bundle order in features.xml Created: 11/Sep/14  Updated: 19/Oct/17  Resolved: 01/Dec/14

Status: Resolved
Project: controller
Component/s: config
Affects Version/s: Helium
Fix Version/s: None

Type: Bug
Reporter: Devin Avery Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: PC

External issue ID: 1820
Priority: Normal

 Description   

It appears that the order of bundles in the feature.xml matters in terms of how the yang files are loaded by the config subsystem.

When I do a feature:install odl-restconf I see the below exception:

**(NOTE: CONTROLLER-811 fixes this particular instance, but you can recreate the problem following the below instructions in reverse ).***

2014-09-11 12:34:29,218 | INFO | Local user karaf | SharedSchemaContextFactory | 96 - org.opendaylight.yangtools.yang-parser-impl - 0.6.2.SNAPSHOT | Failed to assemble sources
SchemaResolutionException{unsatisfiedImports={SourceIdentifier [name=sal-remote-augment@2014-7-8]=[ModuleImportImpl [name=sal-remote, revision=2014-01-14]]}}
at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory$2.apply(SharedSchemaContextFactory.java:77)
at

== Full Exception @ end ===

When I modify the odl-restconf feature and move the

<bundle>mvn:org.opendaylight.controller/sal-remote/${mdsal.version}</bundle>

above

<bundle>mvn:org.opendaylight.controller/sal-rest-connector/${mdsal.version}</bundle>

the exception goes away.

Unknown what affects this have.

==== Possible Resolution ====

Move the bundle for now, and long term we should look at removing the order dependency.

==== FULL EXCEPTION ====

2014-09-11 12:34:29,218 | INFO | Local user karaf | SharedSchemaContextFactory | 96 - org.opendaylight.yangtools.yang-parser-impl - 0.6.2.SNAPSHOT | Failed to assemble sources
SchemaResolutionException{unsatisfiedImports={SourceIdentifier [name=sal-remote-augment@2014-7-8]=[ModuleImportImpl [name=sal-remote, revision=2014-01-14]]}}
at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory$2.apply(SharedSchemaContextFactory.java:77)
at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory$2.apply(SharedSchemaContextFactory.java:61)
at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:859)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293)
at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:150)
at com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:106)
at com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
at com.google.common.util.concurrent.Futures.transform(Futures.java:613)
at com.google.common.util.concurrent.Futures.transform(Futures.java:565)
at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory.createSchemaContext(SharedSchemaContextFactory.java:126)
at org.opendaylight.yangtools.yang.parser.repo.URLSchemaContextResolver.getSchemaContext(URLSchemaContextResolver.java:165)
at org.opendaylight.controller.sal.dom.broker.GlobalBundleScanningSchemaServiceImpl.tryToUpdateSchemaContext(GlobalBundleScanningSchemaServiceImpl.java:236)
at org.opendaylight.controller.sal.dom.broker.GlobalBundleScanningSchemaServiceImpl$BundleScanner.addingBundle(GlobalBundleScanningSchemaServiceImpl.java:191)
at org.opendaylight.controller.sal.dom.broker.GlobalBundleScanningSchemaServiceImpl$BundleScanner.addingBundle(GlobalBundleScanningSchemaServiceImpl.java:165)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)[karaf-org.osgi.core.jar:]
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:847)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
...

 Comments   
Comment by Devin Avery [ 11/Sep/14 ]

Note: This is a lower priority bug and should be used to fix the config system so that order of the bundles in the feature.xml does NOT matter.

Comment by Tony Tkacik [ 16/Sep/14 ]

Thrown exception is innocent, MD-SAL only detected incorrect start order report and will reattemt to parse models after another bundle started (another models are available).

Model will be parsed once all its dependencies are satisfied.

See https://bugs.opendaylight.org/show_bug.cgi?id=1774 for more details about this error report.

Comment by Devin Avery [ 16/Sep/14 ]

Tony - I am setting this back to a Normal priority because the error message is really misleading and is confusing for people combing the logs. For example in my case I was trying to figure out why my controller's restconf was not starting and I saw a number of these exceptions, which indicated to me that there was a problem. As you state it turns out not to be the case, BUT we need to squelch that message somehow and only show it when there is truely a problem.

I realize that in an OSGi environment that may be difficult to tell, so a few possibilities may be:

1) track the bundles that are loading and if there are bundles still pending then hold onto the error message until all bundles currently defined are active, then print out an error for any files still running.

2) Batch the messages - say hold all messages and only print out after 30 seconds or something.

3) Don't print the entire exception stack since it is a "known error". Instead print the detailed message "Can't find this yang - It may be added later if another bundle starts" etc. Then when that other bundle starts and resolves the dependency print a statement saying that we found it.

4) This could be done in addition to all above - print a detailed report of what yangs you tried to compile and what yangs you have successfully compiled - that way each time a bundle starts people can see the current status of the yang files

etc etc. The main idea is to not leave people guessing as much as they are now.

Comment by Tony Tkacik [ 11/Nov/14 ]

Offending message was decreased to DEBUG.

Problem with your approach is:

> 1) track the bundles that are loading and if there are bundles still
> pending then hold onto the error message until all bundles currently defined are > active, then print out an error for any files still running.

Fileinstall (used by Karaf) dynamicly loads bundles and install them in its own order - so if feature is "incorrectly" ordered, list of bundles will not contain missing bundle
we printout message and after that missing bundle was added to system.

> 2) Batch the messages - say hold all messages and only print out after 30
> seconds or something.

This will complicate logic of component only because of logging. Personally I do not like any "time-based" constraints on code / reporting.

> 3) Don't print the entire exception stack since it is a "known error".

This could be done by log appender configuration.

>Instead print the detailed message "Can't find this yang - It may be added later if another bundle starts" etc.
>Then when that other bundle starts and resolves the dependency print a
> statement saying that we found it.

This will again complicate logic of component since it requires additional state tracking (was not found & we reported it -> found).

Generated at Wed Feb 07 19:53:56 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.