Vishal (cc-ing ovsdb devs), FYI I still see problems with topology not accessible on latest int/dist distribution:
https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-1node-upstream-southbound-all-oxygen/115/ This is also reproducible locally by installing odl-ovsdb-southbound-impl-rest and checking topology API is not available: { "errors": { "error": [ { "error-type": "application", "error-tag": "data-missing", "error-message": "Request could not be completed because the relevant data model content does not exist " } ] } } > 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 > [5] 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]> > Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump > Date: January 16, 2018 at 6:08:46 AM PST > To: Tom Pantelis <[email protected]> > Cc: Stephen Kitt <[email protected]>, odl-dev-list > <[email protected]>, "[email protected]" > <[email protected]>, Release > <[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]> > Cc: Robert Varga <[email protected]>; Stephen Kitt <[email protected]>; odl-dev-list > <[email protected]>; Release <[email protected]>; > [email protected] > Subject: Re: [release] [opendaylight-dev] odlparent + yangtools bump > > > > On Tue, Jan 16, 2018 at 1:57 AM, Vishal Thapar <[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 > - 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]] > Sent: 15 January 2018 19:34 > To: Vishal Thapar <[email protected]> > Cc: Stephen Kitt <[email protected]>; odl-dev-list > <[email protected]>; Release <[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]> > 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 > 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]] On Behalf Of Stephen Kitt > Sent: 12 January 2018 22:03 > To: odl-dev-list <[email protected]>; Release > <[email protected]> > Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump > > On Fri, 12 Jan 2018 11:05:01 +0100 > Michael Vorburger <[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.00.html > > https://meetings.opendaylight.org/opendaylight-meeting/2018/tsc/openda > > ylight-meeting-tsc.2018-01-11-18.00.txt > > https://meetings.opendaylight.org/opendaylight-meeting/2018/tsc/openda > > ylight-meeting-tsc.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] > https://lists.opendaylight.org/mailman/listinfo/release > > > _______________________________________________ > dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/dev _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
