Hi Arun, Take a look at [6] In case of OVSDB we only use one version and one model, most recent, so we used this fix.
You may want to look at Tom’s patch [7] as OFP uses network-topology and inventory both and [6] may not work. Once Robert’s patch lands you can revert yours. Regards, Vishal. [6] https://git.opendaylight.org/gerrit/67191 [7] https://git.opendaylight.org/gerrit/#/c/66536/2/impl/src/main/java/org/opendaylight/jsonrpc/impl/Util.java From: D Arunprakash Sent: 18 January 2018 08:46 To: Luis Gomez <[email protected]>; Vishal Thapar <[email protected]>; openflowplugin-dev <[email protected]> Subject: RE: [openflowplugin-dev] [opendaylight-dev] [release] odlparent + yangtools bump Hi Luis, We haven’t started anything on this, let me check with Vishal and comeback on this. Regards, Arun From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Luis Gomez Sent: Thursday, January 18, 2018 12:45 AM To: Vishal Thapar <[email protected]<mailto:[email protected]>>; openflowplugin-dev <[email protected]<mailto:[email protected]>> Subject: Re: [openflowplugin-dev] [opendaylight-dev] [release] odlparent + yangtools bump 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]<mailto:[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 [5] https://git.opendaylight.org/gerrit/67212 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Luis Gomez Sent: 17 January 2018 08:58 To: openflowplugin-dev <[email protected]<mailto:[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]] 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: 1. Publish and modify all test scripts etc. to specify revision in rest calls too [if possible]. 2. 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. 3. ‘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 - 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 [2] https://git.opendaylight.org/gerrit/67191 [3] 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 > ylight-meeting-tsc.2018-01-11-18<tel:2018-01-11-18>.00.html > 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 > 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 _______________________________________________ dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/dev
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
