[openflowplugin-dev] [opendaylight-dev] [release] odlparent + yangtools bump


Luis Gomez
 

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 <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