Is anyone looking at this? this is currently blocking netvirt and other 
projects relying in ofp.

BR/Luis

> On Jan 16, 2018, at 7:43 PM, Vishal Thapar <[email protected]> wrote:
> 
> Hi Luis,
>  
> There is already a Jira [4], and patch [5] from Robert in works. OFPlugin 
> could do a similar workaround to one I did for OVSDB while waiting for 
> Robert’s patch to land.
>  
> Regards,
> Vishal.
>  
> [4] https://jira.opendaylight.org/browse/NETCONF-496 
> <https://jira.opendaylight.org/browse/NETCONF-496>
> [5] https://git.opendaylight.org/gerrit/67212 
> <https://git.opendaylight.org/gerrit/67212>
>  
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Luis 
> Gomez
> Sent: 17 January 2018 08:58
> To: openflowplugin-dev <[email protected]>
> Subject: [openflowplugin-dev] Fwd: [opendaylight-dev] [release] odlparent + 
> yangtools bump
>  
> FYI the topology issue described by Vishal below also happens in 
> openflowplugin, so the proposed workarounds should also work here. Should we 
> open a ticket for this?
>  
> BR/Luis
> 
> 
> Begin forwarded message:
>  
> From: Vishal Thapar <[email protected] 
> <mailto:[email protected]>>
> Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump
> Date: January 16, 2018 at 6:08:46 AM PST
> To: Tom Pantelis <[email protected] <mailto:[email protected]>>
> Cc: Stephen Kitt <[email protected] <mailto:[email protected]>>, odl-dev-list 
> <[email protected] <mailto:[email protected]>>, 
> "[email protected] 
> <mailto:[email protected]>" 
> <[email protected] 
> <mailto:[email protected]>>, Release 
> <[email protected] <mailto:[email protected]>>
>  
> Hi Tom,
>  
> Yeah, this is another workaround. In case of OVSDB I know which version I 
> want to use. But it is still not a proper fix. Something like 
> restconf/apidocs can’t know the correct version. If latest is correct one, 
> should probably move older ones to differently named bundles.
>  
> Regards,
> Vishal.
>  
> From: Tom Pantelis [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: 16 January 2018 19:13
> To: Vishal Thapar <[email protected] 
> <mailto:[email protected]>>
> Cc: Robert Varga <[email protected] <mailto:[email protected]>>; Stephen Kitt 
> <[email protected] <mailto:[email protected]>>; odl-dev-list 
> <[email protected] <mailto:[email protected]>>; Release 
> <[email protected] <mailto:[email protected]>>; 
> [email protected] 
> <mailto:[email protected]>
> Subject: Re: [release] [opendaylight-dev] odlparent + yangtools bump
>  
>  
>  
> On Tue, Jan 16, 2018 at 1:57 AM, Vishal Thapar <[email protected] 
> <mailto:[email protected]>> wrote:
> Thanks for the lead Tom.
>  
> I’m not subscribed to yangtools-dev so they may not get this mail.
>  
> I followed it to new yangtools unable to figure out which version to pick 
> when 2 versions of same model are loaded. Network-topology happens to be one 
> of 8 such instances I saw that have two different versions under same yang 
> file and both are loaded [1]. I think this is more of an existing bad design 
> or oversight being exposed by new yangtools, your opinion may wary.
>  
> I was able to workaround part of OVSDB issue by hardcoding the revision when 
> deserializing [2]. I am now able to use OVSDB plugin to configure OVS, but 
> restconf is still failing as well as odl-mdsal-apidocsc gives 500 error. IMO, 
> there are two ways to take care of this:
>  
> Publish and modify all test scripts etc. to specify revision in rest calls 
> too [if possible].
> Eliminate duplicate models by moving older models to appropriately named 
> folders, something similar to ietf-yang-types [3] only moving older one to 
> use the revision in folder name, to avoid changes to all consumers.
> ‘Fix’ in yangtools to pick the newer version.
>  
> Note that I mention yangtools but this could likely be an mdsal or restconf 
> issue too, am not familiar enough with any of these to make a definitive 
> statement on where the ‘bug’ is. Also, without rest allOVSDB/Genius/Netvirt 
> CSIT will be broken, even if rest of bump activity goes through smoothly.
>  
>  
> This sounds familiar - I ran into it in another project and worked around it: 
> https://git.opendaylight.org/gerrit/#/c/66536/2/impl/src/main/java/org/opendaylight/jsonrpc/impl/Util.java
>  
> <https://git.opendaylight.org/gerrit/#/c/66536/2/impl/src/main/java/org/opendaylight/jsonrpc/impl/Util.java>
>  - the comments in the findModuleWithLatestRevision method sum it up.
>  
>  
> Thanks and Regards,
> Vishal.
>  
> [1] 
> https://github.com/opendaylight/mdsal/tree/master/model/ietf/ietf-topology/src/main/yang
>  
> <https://github.com/opendaylight/mdsal/tree/master/model/ietf/ietf-topology/src/main/yang>
> [2] https://git.opendaylight.org/gerrit/67191 
> <https://git.opendaylight.org/gerrit/67191>
> [3] https://github.com/opendaylight/mdsal/tree/master/model/ietf 
> <https://github.com/opendaylight/mdsal/tree/master/model/ietf>
>  
>  
> From: Tom Pantelis [mailto:[email protected] 
> <mailto:[email protected]>] 
> Sent: 15 January 2018 19:34
> To: Vishal Thapar <[email protected] 
> <mailto:[email protected]>>
> Cc: Stephen Kitt <[email protected] <mailto:[email protected]>>; odl-dev-list 
> <[email protected] <mailto:[email protected]>>; Release 
> <[email protected] <mailto:[email protected]>>
> Subject: Re: [release] [opendaylight-dev] odlparent + yangtools bump
>  
> org.opendaylight.ovsdb.southbound.InstanceIdentifierCodec.prefixForNamespace 
> returned null:
>  
>     @Override
>     protected String prefixForNamespace(final URI namespace) {
>         return context.findModule(namespace, 
> Optional.empty()).map(Module::getName).orElse(null);
>     }
>  
>  
>  
>  
> On Mon, Jan 15, 2018 at 8:27 AM, Vishal Thapar <[email protected] 
> <mailto:[email protected]>> wrote:
> Hi all,
> 
> I know bump is still in progress but I've seen basic functionality issues in 
> OVSDB which means all projects depending on OVSDB are also broken. Main issue 
> I've seen:
> 
> 1. The issue is at startup, OVSDB plugin creates default topology for ovsdb:1 
> and hwvtep:1 in network-topology config and operational. They both don't show 
> up when I make a restconf GET call. It was working earlier.
> 
> 2. I have genius code to write to network-topology config. It triggers Data 
> change notification and I can see entry in logs showing so, but it throws up 
> this error:
> 
> 2018-01-15T17:56:42,977 | ERROR | 
> opendaylight-cluster-data-notification-dispatcher-176 | 
> DataTreeChangeListenerActor      | 137 - 
> org.opendaylight.controller.sal-clustering-commons - 1.7.0.SNAPSHOT | 
> member-1-shard-topology-config: Error notifying 
> listenerorg.opendaylight.ovsdb.southbound.OvsdbDataTreeChangeListener@3eeb42f 
> <mailto:org.opendaylight.ovsdb.southbound.OvsdbDataTreeChangeListener@3eeb42f>
>  java.lang.IllegalArgumentException: Failed to map QName {} 
> [(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology]
>   at 
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:210) 
> [62:com.google.guava:23.3.0.jre]
>   at 
> org.opendaylight.yangtools.yang.data.util.AbstractNamespaceCodec.appendQName(AbstractNamespaceCodec.java:47)
>  [294:org.opendaylight.yangtools.yang-data-util:2.0.0]
>   at 
> org.opendaylight.yangtools.yang.data.util.AbstractStringInstanceIdentifierCodec.serialize(AbstractStringInstanceIdentifierCodec.java:53)
>  [294:org.opendaylight.yangtools.yang-data-util:2.0.0]
>   at 
> org.opendaylight.ovsdb.southbound.InstanceIdentifierCodec.serialize(InstanceIdentifierCodec.java:65)
>  [270:org.opendaylight.ovsdb.southbound-impl:1.6.0.SNAPSHOT]
>   at 
> org.opendaylight.ovsdb.southbound.ovsdb.transact.TransactUtils.stampInstanceIdentifierMutation(TransactUtils.java:440)
>  [270:org.opendaylight.ovsdb.southbound-impl:1.6.0.SNAPSHOT]
>   at 
> org.opendaylight.ovsdb.southbound.ovsdb.transact.TerminationPointCreateCommand.stampInstanceIdentifier(TerminationPointCreateCommand.java:372)
> 
> So looks like model is loaded correctly, data is also written/read correctly, 
> but something going wrong with the Codec or base model making it fail some 
> checks.
> 
> 
> -----Original Message-----
> From: [email protected] 
> <mailto:[email protected]> 
> [mailto:[email protected] 
> <mailto:[email protected]>] On Behalf Of Stephen Kitt
> Sent: 12 January 2018 22:03
> To: odl-dev-list <[email protected] 
> <mailto:[email protected]>>; Release 
> <[email protected] <mailto:[email protected]>>
> Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump
> 
> On Fri, 12 Jan 2018 11:05:01 +0100
> Michael Vorburger <[email protected] <mailto:[email protected]>> wrote:
> > FYI for anyone else looking at the published meeting minutes from
> > yesterday's TSC call which decided doing this so late in the game for
> > Oxygen:
> >
> > https://meetings.opendaylight.org/opendaylight-meeting/2018/tsc/openda 
> > <https://meetings.opendaylight.org/opendaylight-meeting/2018/tsc/openda>
> > ylight-meeting-tsc.2018-01-11-18 <tel:2018-01-11-18>.00.html
> > https://meetings.opendaylight.org/opendaylight-meeting/2018/tsc/openda 
> > <https://meetings.opendaylight.org/opendaylight-meeting/2018/tsc/openda>
> > ylight-meeting-tsc.2018-01-11-18 <tel:2018-01-11-18>.00.txt
> > https://meetings.opendaylight.org/opendaylight-meeting/2018/tsc/openda 
> > <https://meetings.opendaylight.org/opendaylight-meeting/2018/tsc/openda>
> > ylight-meeting-tsc.2018-01-11-18 <tel:2018-01-11-18>.00.log.html
> >
> > Question: was there a succesful CSIT run of the netvirt project, as
> > discussed as a pre-requisite during the kernel project calls on
> > Tuesday?
> 
> No, we ran into various issues with the jobs on Jenkins and the patches which 
> meant I couldn’t get a CSIT run before the TSC call. We decided, instead of 
> spending more time trying to get a CSIT run *before* the merge, to go ahead 
> with a time-boxed merge and run CSIT then — the time-box is that we want CSIT 
> on Monday at the latest.
> 
> It would no doubt have taken me longer than that to get CSIT working on the 
> basis of the multi-patch jobs, so apart from the disruption caused to 
> projects today, this seems like the less intrusive approach...
> (Well, still more intrusive than just dropping the patches, but the TSC wants 
> the migration to happen if at all possible anyway.)
> 
> Regards,
> 
> Stephen
> _______________________________________________
> release mailing list
> [email protected] <mailto:[email protected]>
> https://lists.opendaylight.org/mailman/listinfo/release 
> <https://lists.opendaylight.org/mailman/listinfo/release>
>  
>  
> _______________________________________________
> dev mailing list
> [email protected] <mailto:[email protected]>
> https://lists.opendaylight.org/mailman/listinfo/dev 
> <https://lists.opendaylight.org/mailman/listinfo/dev>
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to