e770c868f8
This adds a check to each of the core methods that other callers (e.g. service plugins) may use to manipulate core resources. This check prevents them from passing in a context that is already part of an ongoing DB session because we do not want DB rollbacks to be allowed after the ML2 plugin calls postcommit methods on drivers. All of the core methods are protected except for create_port and update_port. This was left out because of a few particularily deeply nested calls to the port methods from the L3 code that will be addressed in change I5aa099c2264636336ab0b76c0826b506e2dc44b6. For more details, read the devref added by this patch. Partial-Bug: #1540844 Change-Id: I9924600c57648f7eccaa5abb6979419d9547a2ff
2.0 KiB
Calling the ML2 Plugin
When writing code for an extension, service plugin, or any other part of Neutron you must not call core plugin methods that mutate state while you have a transaction open on the session that you pass into the core plugin method.
The create and update methods for ports, networks, and subnets in ML2 all have a precommit phase and postcommit phase. During the postcommit phase, the data is expected to be fully persisted to the database and ML2 drivers will use this time to relay information to a backend outside of Neutron. Calling the ML2 plugin within a transaction would violate this semantic because the data would not be persisted to the DB; and, were a failure to occur that caused the whole transaction to be rolled back, the backend would become inconsistent with the state in Neutron's DB.
To prevent this, these methods are protected with a decorator that will raise a RuntimeError if they are called with context that has a session in an active transaction. The decorator can be found at neutron.common.utils.transaction_guard and may be used in other places in Neutron to protect functions that are expected to be called outside of a transaction.