[RFE] ml2: needs a way for MD to pass data from precommit to postcommit

[YAMAMOTO Takashi]

it would be nice to have a proper mechanism to pass some MD specific data
from precommit to postcommit.

use case: https://review.openstack.org/#/c/293376/41/dragonflow/neutron/ml2/mech_driver.py@168

[Li Ma (nick-ma-z)]

The simplest way is to add a driver_data dict into MechanismDriverContext, as far as I know.

[OpenStack Infra (hudson-openstack)]

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

[Robert Kukura (rkukura)]

Adding a dict to the abstract Context classes in driver_api.py would be fine. The current patch adds them to the context implementation, but not to the driver API definition.

I'm also wondering if this is necessary at all, since all python classes are essentially dictionaries anyway, and a mechanism driver can store anything it needs during precommit as an attribute on the context class and it will be available during postcommit. But I do prefer adding a dictionary attribute explicitly for this purpose, since this would allow ML2 to save the state if it needs to instantiate a new Context instance. This might apply during port binding, or if postcommit processing is eventually make more asynchronous.

[Armando Migliaccio (armando-migliaccio)]

Passthrough information between pre and post phases through method calling leads to tight coupling by design and I think we should refrain from doing so, especially if there are no guarantees that the state is not becoming stale between method invocations. The thing is, if you need to do such a thing, maybe the two method should really be one, but I can see in the use case above why require the split.

I think you're better off retrieving state in some other fashion, for instance by looking data up passed on what is given to you from the context.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Li Ma (<email address hidden>) on branch: master
Review: https://review.openstack.org/329797

[Robert Kukura (rkukura)]

Armando, I don't see why you characterize this as "tight coupling" when the intent is, as I understand it, for the same MD to both supply (in precommit) and consume (in postcommit) the driver-specific data. And precommit and postcommit cannot generally be combined into one method, since precommit is guaranteed to be inside the transaction and postcommit is guaranteed to be outside it. It is very common for MDs to implement both these methods since they need to do certain things within the transaction and other things outside it after it has committed.

I agree state can often be retrieved or recreated in some other fashion, so this may not be a critical requirement. But I would hate to see MDs resort to just adding random properties to the Context class and then breaking when ML2 changes internally.