Vratko, I think we talked about this in the last integration call: if netconf 
project (or any other) has 2 or more features that are incompatible (e.g. 
produce SFT failures) but still required (e.g. for netconf device notifications 
xor netconf cluster use case), the project should select 1 as preferred and we 
should remove the non-preferred feature and any downstream project feature 
consuming this last from the distribution-check test. The workaround of 
allowing both incompatible features [1] has 2 issues imo:

- Extra distribution-check overhead to verify all compatible features twice.
- It sets a precedent for any project to create incompatible features and never 
move from that.

BR/Luis

[1] https://git.opendaylight.org/gerrit/#/c/64410/ 
<https://git.opendaylight.org/gerrit/#/c/64410/>
> On Oct 24, 2017, at 2:44 PM, Michael Vorburger <[email protected]> wrote:
> 
> +unimgr-dev:
> 
> On Mon, Oct 23, 2017 at 6:02 PM, Vratko Polak -X (vrpolak - PANTHEON 
> TECHNOLOGIES at Cisco) <[email protected] <mailto:[email protected]>> wrote:
> Previous story: [2].
> 
> 
> It's not that rare - just hit me again (on 
> https://git.opendaylight.org/gerrit/#/c/64674/ 
> <https://git.opendaylight.org/gerrit/#/c/64674/>), had to override once more 
> - and find this annoying..
>   
> > who would have to do what
> 
>  
> 
> Ideally, Netconf developers would unify their features,
> 
> which does not seem to get done anytime soon [3].
> 
> 
> If I understand [3] correctly, Tomas Cere doesn't even consider this a 
> netconf issue, but asks for "unimgr should move towards odl-netconf-topology" 
> (instead of odl-netconf-connector-ssh, because "There is no reason to pull in 
> odl-netconf-connector-ssh unless you are using config subsystem still"). Is 
> this something the unimgr project would be willing to do?
> 
> If not, or if unimgr-dev, assuming I understand things correctly, why don't 
> we just kick unimgr project out of distribution?! I'll raise a patch 
> proposing this when it next hits me, if it's not resolved by then.
>  
> 
> There is a workaround in Int/Dist [4] prepared,
> 
> but it keeps SFT unstable, this time due to
> 
> (lack of) Karaf 4 memory efficiency [5].
> 
>  
> 
> Current road to stability seem to be
> 
> fixing various ODL project features (like [6])
> 
> to be less taxing on Karaf 4 bundle resolver,
> 
> and then merging [4].
> 
>  
> 
> > It would be nice if the exception included some context like the path.
> 
>  
> 
> I have rebased my old [7].
> 
> In this case, it is multiple netconf features trying to update
> 
> operational topology status for "controller-config" device.
> 
>  
> 
> > How does SFT even pick this up to fail the test?
> 
>  
> 
> In general, a "caused by" thrown by featuresService.installFeature.
> 
> In this case there was an ISE (visible in surefire report [8]
> 
> at 12:27:25,742) coming from here [9] (at least in Nitrogen),
> 
> not sure which component gets to throw it.
> 
>  
> 
> Vratko.
> 
>  
> 
> [2] https://lists.opendaylight.org/pipermail/release/2017-October/012728.html 
> <https://lists.opendaylight.org/pipermail/release/2017-October/012728.html>
> [3] https://jira.opendaylight.org/browse/NETCONF-479 
> <https://jira.opendaylight.org/browse/NETCONF-479>
> [4] https://git.opendaylight.org/gerrit/64410 
> <https://git.opendaylight.org/gerrit/64410>
> [5] https://jira.opendaylight.org/browse/ODLPARENT-125 
> <https://jira.opendaylight.org/browse/ODLPARENT-125>
> [6] https://jira.opendaylight.org/browse/INTDIST-92 
> <https://jira.opendaylight.org/browse/INTDIST-92>
> [7] https://git.opendaylight.org/gerrit/48118 
> <https://git.opendaylight.org/gerrit/48118>
> [8] 
> https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/distribution/features/singles/odl-integration-compatible-with-all/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz
>  
> <https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/distribution/features/singles/odl-integration-compatible-with-all/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz>
> [9] 
> https://github.com/opendaylight/netconf/blob/release/nitrogen/netconf/sal-netconf-connector/src/main/java/org/opendaylight/netconf/sal/connect/netconf/sal/NetconfDeviceTopologyAdapter.java#L243
>  
> <https://github.com/opendaylight/netconf/blob/release/nitrogen/netconf/sal-netconf-connector/src/main/java/org/opendaylight/netconf/sal/connect/netconf/sal/NetconfDeviceTopologyAdapter.java#L243>
>  
> 
> From: [email protected] 
> <mailto:[email protected]> 
> [mailto:[email protected] 
> <mailto:[email protected]>] On Behalf Of Tom 
> Pantelis
> Sent: 23 October, 2017 15:24
> To: Michael Vorburger <[email protected] <mailto:[email protected]>>
> Cc: controller-dev <[email protected] 
> <mailto:[email protected]>>
> Subject: Re: [controller-dev] SingleFeatureTest (SFT) failure on 
> odl-integration-compatible-with-all due to 
> ConflictingModificationAppliedException: Node was created by other 
> transaction.
> 
>  
> 
>  
> 
>  
> 
> On Mon, Oct 23, 2017 at 8:41 AM, Michael Vorburger <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> Hello,
> 
>  
> 
> Any idea who would have to do what to precent SFT from (only occassionally?!) 
> failing on odl-integration-compatible-with-all due to 
> ConflictingModificationAppliedException: Node was created by other 
> transaction, as seen on 
> https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/console.log.gz
>  
> <https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/console.log.gz>
>  for https://git.opendaylight.org/gerrit/#/c/63466/ 
> <https://git.opendaylight.org/gerrit/#/c/63466/> ?
> 
>  
> 
> It would be nice if the exception included some context like the path. Does 
> this test install all netconf features? I've seen such sporadic issues with 
> the callhome feature when it's installed with all the other netconf features.
> 
>  
> 
> How does SFT even pick this up to fail the test? Log scraping?  Or was it a 
> "caused by" thrown on blueprint startup?
> 
>  
> 
> 
> Tx,
> 
> M.
> 
> --
> 
> Michael Vorburger, Red Hat
> [email protected] <mailto:[email protected]> | IRC: vorburger @freenode 
> | ~ = http://vorburger.ch <http://vorburger.ch/>
> 
> _______________________________________________
> controller-dev mailing list
> [email protected] 
> <mailto:[email protected]>
> https://lists.opendaylight.org/mailman/listinfo/controller-dev 
> <https://lists.opendaylight.org/mailman/listinfo/controller-dev>
>  
> 
> 
> _______________________________________________
> controller-dev mailing list
> [email protected]
> https://lists.opendaylight.org/mailman/listinfo/controller-dev

_______________________________________________
controller-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/controller-dev
  • [controller-dev... Michael Vorburger
    • Re: [contr... Tom Pantelis
      • Re: [c... Michael Vorburger
      • Re: [c... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
        • Re... Michael Vorburger
          • ... Luis Gomez
          • ... Michael Vorburger
            • ... Donald Hunter (donaldh)
              • ... Tom Pantelis
              • ... Michael Vorburger
                • ... Tom Pantelis
                • ... Donald Hunter (donaldh)
                • ... Tomas Cere -X (tcere - PANTHEON TECHNOLOGIES at Cisco)
                • ... Tomas Cere -X (tcere - PANTHEON TECHNOLOGIES at Cisco)
                • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
                • ... Tomas Cere -X (tcere - PANTHEON TECHNOLOGIES at Cisco)

Reply via email to