On 12/10/2018 13:58, Sam Hague wrote:
> Thanks Robert for finding that. min-element/max-elements are used in
> multiple other other models. Would they also have the same issue?
> 
> What do you think about the yangtools patch going in? Should we push to
> get than in rather than trying other workarounds?
> 
> In this case, odl-interface-service-bindings is in genius
> interfacemanager. That particular yang is core to everything so I am not
> sure if we could simply remove the min/max-element. Will ping the genius
> folks to see what they think.

yangtools-2.1.2/mdsal-3.0.1 are propagated to all patches.
https://jenkins.opendaylight.org/releng/view/integration/job/integration-multipatch-test-neon/87/
is currently running.

I took a look at
https://jenkins.opendaylight.org/releng/view/integration/job/netvirt-csit-1node-1cmb-0ctl-0cmp-openstack-queens-upstream-stateful-neon/31/
and the failures are NPEs from iterating lists, which are presumably
empty (and hence have disappeared). One example for all:

org/opendaylight/netvirt/fibmanager/VrfEntryListener:1798, where we read
the VRF table and iterate over the list -- which is null because it is
empty (as per YANGTOOLS-585).

The question is what are we going to do about this?

One option is to implement https://jira.opendaylight.org/browse/MDSAL-18
for LazyDataObjects where the list is not restricted by min-elements > 0.

Another is to have a utility method which turns nulls to empty lists.

Regards,
Robert

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to