[15:07:13] <flaviof> vishnoianil: qq.
[15:07:23] <vishnoianil> flaviof, sure
[15:07:23] <flaviof> vishnoianil: If Isee this: https://gist.github.com/f000be830e77bcb20c43
[15:07:54] <flaviof> vishnoianil: is that begign enough, so I can continue, or is that reason to start over?
[15:08:17] <vishnoianil> flaviof, for me that means stop the controller, delete the data directory and restart it
[15:08:19] <vishnoianil> 
[15:08:26] <vishnoianil> flaviof, no it's not benign
[15:08:38] <flaviof> vishnoianil: I'm glad I asked. 
[15:08:47] <flaviof> thanks!
[15:09:00] <vishnoianil> flaviof, i didn't get a chance to dig into that, because we have something more critical on plate
Partly duplicate of CONTROLLER-1278
but providing reference to topology model in initial config
for topology provider will prevent app starting before models are loaded.
Initial config contains capabilities section, where topology model and flow capable model should be listed.
This will prevent it from starting before models are loaded.
(In reply to Tony Tkacik from comment #2)
> Partly duplicate of CONTROLLER-1278
> but providing reference to topology model in initial config
> for topology provider will prevent app starting before models are loaded.
>
> Initial config contains capabilities section, where topology model and flow
> capable model should be listed.
>
> This will prevent it from starting before models are loaded.
thanks for the update, Tony!
(In reply to Tony Tkacik from comment #2)
> Partly duplicate of CONTROLLER-1278
> but providing reference to topology model in initial config
> for topology provider will prevent app starting before models are loaded.
>
> Initial config contains capabilities section, where topology model and flow
> capable model should be listed.
>
> This will prevent it from starting before models are loaded.
Tony,
does this mean out ovsdb netvirt app needs to be using config? Currently netvirt is activator based and does not use config. Changing to config has been difficult because there is a lot of dependency injection and callback code that we ahve not been able to convert.
Thanks, Sam
Hi, there is patch for controller which adds blocking behaviour for users
Which uses different activation,
That means if we detect situation such as class is present and schema
Not available yet, we will block user thread and unblock
It when schema is available or after 5sec.
Tony
Tony,
could you post the gerrit for the patch?
How does config determine that a schema is not loaded if the application does not use config to set a capability for the model?
Thanks, Sam
Flavio,
I am tracking on this issue too. Looks like the bug that was noted as partly duplicate https://bugs.opendaylight.org/show_bug.cgi?id=3067 had it's patch merged today https://git.opendaylight.org/gerrit/#/c/19607/ . It didn't seem to fix my case though. Has it fixed your case? if so, I'll open a new bug to track it on my side.
Thanks,
JamO
(In reply to Jamo Luhrsen from comment #7)
> Flavio,
>
> I am tracking on this issue too. Looks like the bug that was noted as
> partly duplicate https://bugs.opendaylight.org/show_bug.cgi?id=3067 had it's
> patch merged today https://git.opendaylight.org/gerrit/#/c/19607/ . It
> didn't seem to fix my case though. Has it fixed your case? if so, I'll
> open a new bug to track it on my side.
>
> Thanks,
> JamO
Hi JamO!
I have not seen this issue for a while. I'd say it's best if you
open a new bug to track it on your side.
– flavio
https://git.opendaylight.org/gerrit/#/c/22804/1 - improves reporting of this type of error in yangtools - which will result in md-sal waiting till schema for inventory augmentations is loaded.
No longer an issue.
Hi,
why do I get this exception?
..
IncorrectNestingException: Child interface org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.xxxxxxxxxxAugment is not valid child.
at org.opendaylight.yangtools.binding.data.codec.impl.IncorrectNestingException.create(IncorrectNestingException.java:28)
at org.opendaylight.yangtools.binding.data.codec.impl.DataContainerCodecContext.childNonNull(DataContainerCodecContext.java:180)[66:org.opendaylight.mdsal.binding-dom-codec:0.8.1.Beryllium-SR1]
at org.opendaylight.yangtools.binding.data.codec.impl.DataObjectCodecContext.streamChild(DataObjectCodecContext.java:149)[66:org.opendaylight.mdsal.binding-dom-codec:0.8.1.Beryllium-SR1]
at org.opendaylight.yangtools.binding.data...
(In reply to Harinath Mallepally from comment #11)
> Hi,
>
> why do I get this exception?
> ..
>
> IncorrectNestingException: Child interface
> org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.xxxxxxxxxxAugment
> is not valid child.
> at
> org.opendaylight.yangtools.binding.data.codec.impl.IncorrectNestingException.
> create(IncorrectNestingException.java:28)
> at
> org.opendaylight.yangtools.binding.data.codec.impl.DataContainerCodecContext.
> childNonNull(DataContainerCodecContext.java:180)[66:org.opendaylight.mdsal.
> binding-dom-codec:0.8.1.Beryllium-SR1]
> at
> org.opendaylight.yangtools.binding.data.codec.impl.DataObjectCodecContext.
> streamChild(DataObjectCodecContext.java:149)[66:org.opendaylight.mdsal.
> binding-dom-codec:0.8.1.Beryllium-SR1]
> at org.opendaylight.yangtools.binding.data...
Harinath,
not sure if it is the same as in this bug here, but the cause was because certain models were not loaded when they were used. The solution was to add methods to ensure all models were loaded before using them. in the config.xml file you can add required-capabilities for your module to indicate what models to wait for. The patch mentioned below by Tony is for modules that don't use config.
Sam