Wrong OVO classes registered in some cases

Bug #1731948 reported by Slawek Kaplonski
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
High
Slawek Kaplonski
oslo.versionedobjects
Incomplete
Wishlist
Unassigned

Bug Description

When patch https://review.openstack.org/#/c/321001 was merged some UT in projects like networking-midonet started failing. It is reported on https://bugs.launchpad.net/networking-midonet/+bug/1731623

It looks that reason of this problem is that wrong OVO classes are registered in case when e.g. 2 different projects uses same names of OVO objects.

I checked it little bit and it looks that neutron.objects.subnet.Subnet has got registered os_vif.objects.route.Route object instead of neutron.objects.subnet.Route, see my logs from one exampled test: http://paste.openstack.org/show/626170/

affects: networking-midonet → neutron
Changed in neutron:
importance: Undecided → Medium
Revision history for this message
Brian Haley (brian-haley) wrote :

Looks like https://review.openstack.org/#/c/321001 was reverted, is this still a bug?

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

IMO it is a bug because https://review.openstack.org/#/c/321001 was more like a trigger for this issue than reason of if. I think that we should fix somehow this problem and then merge again https://review.openstack.org/#/c/321001

Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

the UT failures seen on networking-midonet was probably UT-only issue, ie. lack of fixtures,
because in real deployments there is no process which uses both of neutron objects and os-vif objects. (at least for midonet deployments)

it would be still nice for neutron to use a separate registry to avoid potential issues though.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/519622

Changed in neutron:
assignee: nobody → Slawek Kaplonski (slaweq)
status: New → In Progress
Revision history for this message
Ihar Hrachyshka (ihar-hrachyshka) wrote :

Added oslo.versionedobjects to the list of affected projects so that it allows to use custom registries for consuming projects.

Changed in oslo.versionedobjects:
importance: Undecided → Wishlist
tags: added: gate-failure unittest
Changed in neutron:
importance: Medium → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on oslo.versionedobjects (master)

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.openstack.org/521245
Reason: as discussed with Ihar, it will not be necessary

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/519622
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=5e08a9b0e7d4f99d217ca73c6aa37e52a13c5d5a
Submitter: Zuul
Branch: master

commit 5e08a9b0e7d4f99d217ca73c6aa37e52a13c5d5a
Author: Sławek Kapłoński <email address hidden>
Date: Tue Nov 14 20:36:39 2017 +0000

    [OVO] Switch to use own registry

    Neutron will now use own registry for versionedobjects.
    It avoids problems with loading wrong OVO objects from
    different projects (like os_vif) when names are the same.

    Change-Id: I9d4fab591fbe52271c613251321a6d03078976f7
    Closes-Bug: #1731948

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 12.0.0.0b2

This issue was fixed in the openstack/neutron 12.0.0.0b2 development milestone.

tags: added: neutron-proactive-backport-potential
Revision history for this message
Ben Nemec (bnemec) wrote :

I see the OVO patch was abandoned. Is there anything left to do there?

Changed in oslo.versionedobjects:
status: New → Incomplete
tags: removed: neutron-proactive-backport-potential
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.