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 " } ] } }
toggle quoted message
Show quoted text
On Jan 16, 2018, at 7:43 PM, Vishal Thapar <vishal.thapar@...> 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: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Luis Gomez Sent: 17 January 2018 08:58 To: openflowplugin-dev <openflowplugin-dev@...> 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 <vishal.thapar@...> Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump Date: January 16, 2018 at 6:08:46 AM PST To: Tom Pantelis <tompantelis@...> Cc: Stephen Kitt <skitt@...>, odl-dev-list <dev@...>, "yangtools-dev@..." <yangtools-dev@...>, Release <release@...> 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:tompantelis@...] Sent: 16 January 2018 19:13 To: Vishal Thapar <vishal.thapar@...> Cc: Robert Varga <nite@...>; Stephen Kitt <skitt@...>; odl-dev-list <dev@...>; Release <release@...>; yangtools-dev@... Subject: Re: [release] [opendaylight-dev] odlparent + yangtools bump On Tue, Jan 16, 2018 at 1:57 AM, Vishal Thapar <vishal.thapar@...> 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:tompantelis@...] Sent: 15 January 2018 19:34 To: Vishal Thapar <vishal.thapar@...> Cc: Stephen Kitt <skitt@...>; odl-dev-list <dev@...>; Release <release@...> 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 <vishal.thapar@...> 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: dev-bounces@... [mailto:dev-bounces@...] On Behalf Of Stephen Kitt Sent: 12 January 2018 22:03 To: odl-dev-list <dev@...>; Release <release@...> Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump
On Fri, 12 Jan 2018 11:05:01 +0100 Michael Vorburger <vorburger@...> 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 release@... https://lists.opendaylight.org/mailman/listinfo/release _______________________________________________ dev mailing list dev@... https://lists.opendaylight.org/mailman/listinfo/dev
|