Since the migration to new engine facade, some operations that shouldn't be executing within a txn, are logging a "session semantic violated" warning

Bug #1924789 reported by Rodolfo Alonso
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Confirmed
High
Unassigned

Bug Description

When Neutron moved to the new engine facade, some operations that could not be executed inside a running transaction, are allowed as an exception. Those commands are executed disabling first the transaction guard. Example:

    if context.session.is_active:
        context.GUARD_TRANSACTION = False

There are three occurrences in the code, all of them in the neutron.db.l3_db code, all of them creating/deleting a port from a router.

Snippet: paste.openstack.org/show/804570/

Log: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_798/786282/1/check/neutron-fullstack-with-uwsgi/7984131/controller/logs/dsvm-fullstack-logs/TestHAL3Agent.test_router_fip_qos_after_admin_state_down_up/neutron-server--2021-04-16--14-34-57-360223_log.txt

Revision history for this message
Bence Romsics (bence-romsics) wrote :

Hi Rodolfo,

As I read that code this does not break the relevant operations, it only prints noisy warnings. Both the operation exempting itself from the transaction guard and the noisy warning look completely intentional. Do you want to selectively suppress the warning where we had the transaction guard hack? To me that makes perfect sense.

Cheers,
Bence

Changed in neutron:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Rodolfo Alonso (rodolfo-alonso-hernandez) wrote :

Hello Bence:

The problem is not the warnings messages but what we skip if we hit them. Those warning messages are written when we use a AFTER_* callback method inside a transaction. Those events are supposed to be sent once the object transaction is finished [1].

Now we are sending them inside another one. This is happening with router and ports: we are handling ports inside the router creation/update txn. We should, somehow, fix that.

[1]https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/ovo_rpc.py#L51-L54

Changed in neutron:
importance: Medium → High
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.