[SFC-194] Problem with the installation of sfc, groupbasedpolicy, vbd related to vpp features Created: 18/May/17  Updated: 24/May/18

Status: Confirmed
Project: sfc
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Dimitrios Markou Assignee: Tomas Cechvala
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: Text File error_case_2.txt    
External issue ID: 8501

 Description   

I experienced some weird errors in Carbon RC1:

1. When I install first the odl-sfc-vpp-renderer feature and then the odl-groupbasedpolicy-neutron-vpp-mapper odl-netconf-all odl-vbd-ui odl-groupbasedpolicy-vpp odl-groupbasedpolicy-ui features I get this error [1]

2. When I install first the the odl-groupbasedpolicy-neutron-vpp-mapper odl-netconf-all odl-vbd-ui odl-groupbasedpolicy-vpp odl-groupbasedpolicy-ui features and then the the odl-sfc-vpp-renderer feature the JVM crashes big time and I get this error [2]

3. When I install all the aforementioned features together (odl-groupbasedpolicy-neutron-vpp-mapper odl-netconf-all odl-vbd-ui odl-groupbasedpolicy-vpp odl-groupbasedpolicy-ui odl-sfc-vpp-renderer ) I get the same error with case 2 (attached file)

Hint: Maybe this is a problem with the yang versions that sfc uses and are related to vpp

[1] Error executing command: Can't install feature odl-groupbasedpolicy-neutron-vpp-mapper/0.0.0: Could not start bundle mvn:org.opendaylight.honeycomb.vbd/vbd-impl/1.1.0-Carbon in feature(s)
odl-vbd-1.1 .0-Carbon: The bundle "org.opendaylight.honeycomb.vbd.impl_1.1.0.Carbon [331]" could not be resolved. Reason: Missing Constraint: Import-Package: org.opendaylight.yang.gen.v1.urn.ieee.params.xml.ns.yang.dot1q.t ypes.rev150626; version="[1.1.0,2.0.0)"

[2] attached file (error_case_2.txt)

 Comments   
Comment by Dimitrios Markou [ 18/May/17 ]

Attachment error_case_2.txt has been added with description: JVM error

Comment by Michal Cmarada [ 19/May/17 ]

replicated with GBP.
Those features are independent and they both pull yangs from different locations. GBP pulls yang models for HC/VPP from VBD project and we support version 1704 for both VPP and HC. SFC has a local copy of these models too but with a different revision. I think that SFC supports 1609 version of HC/VPP. We would have to depend on same versions of HC/VPP models and pull them from a common location. I think that it will not be possible to use both features at once because they will need to use different versions of HC/VPP. If the same models will be used for both projects I think that it would be possible to use them simultaneously.

Comment by A H [ 19/May/17 ]

To better assess the impact of this bug and fix, could someone from your team please help us identify the following:

Regression: Is this bug a regression of functionality/performance/feature compared to Boron?

Severity: Could you elaborate on the severity of this bug? Is this a BLOCKER such that we cannot release Carbon without it?

Is there a workaround such that we can write a release note?

Testing: Could you also elaborate on the testing of this patch? How extensively has this patch been tested? Is it covered by any unit tests or system tests?

Impact: Does this fix impact any dependent projects?

Comment by Robert Varga [ 19/May/17 ]

There is definitely some versioning mismatch going on. Can you post karaf.log?

Comment by Robert Varga [ 19/May/17 ]

Vratko has a patch: https://git.opendaylight.org/gerrit/#/c/50683/

From overall architecture we have a circular dependency: fd.io HC depends on us and we depend on hc2vpp models. I think hc2vpp is on Boron, so it is not an issue right now, but we need to think about testing RCs (both ways).

Ed: would it be possible to get fd.io to export their models with YANG bindings from the ODL release fd.io is consuming? Like in maven central or some place we can get to...

Maybe ODL's settings.xml needs to include fd.io release repositories?

Comment by Colin Dixon [ 21/May/17 ]

(In reply to Robert Varga from comment #4)
> I think hc2vpp is on Boron, so it is not
> an issue right now, but we need to think about testing RCs (both ways).

Is this to say it is not a blocker in Carbon?

Comment by Robert Varga [ 21/May/17 ]

No. That is to say we do not have a circular dependency right now, because hc2vpp consumes our Boron release and our Carbon codebase can therefore consume latest hc2vpp release without introducing a cycle.

Model consistency across our components needs to be resolved, though.

Comment by A H [ 21/May/17 ]

We are looking to build Carbon RC2 tonight at 23:59 UTC 5/21/2017 assuming there are no blocker bugs. Is there an ETA for when a fix can be merged and this bug resolved for stable/carbon branch?

Comment by A H [ 22/May/17 ]

As per this email thread [1], this blocker is being retargeted for Carbon SR1 or later.

[1] https://lists.opendaylight.org/pipermail/vbd-dev/2017-May/000118.html

Comment by Tomas Cechvala [ 04/Jul/17 ]

Retargeted for SR2, downgraded from blocker to critical

https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2017-July/003780.html

Comment by OpenDaylight Release [ 03/May/18 ]

Tomas, moving it to you for now.

Please decide to who this should be assigned.  

Generated at Wed Feb 07 20:38:53 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.