Plugin API was silently changed for subnetpool dict extension functions

[Ihar Hrachyshka]

Some Newton changes that were part of blueprint adopt-oslo-versioned-objects-for-db mistakenly changed plugin API for registered dict extension functions by passing objects instead of db models into those functions. We should not have done it, and should revert to passing models before Newton final release.

Note: there is also another resource affected by the same issue: allowed address pairs.

[Ihar Hrachyshka (ihar-hrachyshka)]

The patch that should fix the issue: https://review.openstack.org/#/c/348279/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/348279
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=10ada71486db33c6cb69f35811d0ca3dc547eff0
Submitter: Jenkins
Branch: master

commit 10ada71486db33c6cb69f35811d0ca3dc547eff0
Author: Ihar Hrachyshka <email address hidden>
Date: Thu Jul 28 14:21:02 2016 +0200

    objects: expose database model for NeutronDbObject instances

    Sometimes object users need access to corresponding models that are used
    to persist object data. While it's not encouraged, and object consumers
    should try to rely solely on object API and fields, we should fulfill
    this special need, at least for now.

    One of use cases to access the corresponding database model are
    functions registered by plugins to extend core resources. Those
    functions are passed into register_dict_extend_funcs and expect the
    model as one of its arguments.

    Later, when more objects are adopted in base plugin code, and we are
    ready to switch extensions to objects, we can pass to those functions
    some wrappers that would trigger deprecation warnings on attempts to
    access attributes that are not available on objects; and then after a
    while finally switch to passing objects directly instead of those
    wrappers. Of course, that would not happen overnight, and the path would
    take several cycles.

    To avoid the stored reference to the model to influence other code
    fetching from the session, we detach (expunge) the model from the active
    database session on every fetch. We also refresh the model before
    detaching it when the corresponding object had synthetic fields changed,
    because that's usually an indication that some relationships may be
    stale on the model.

    Since we now consistently detach the model from the active session on
    each fetch, we cannot reuse it. So every time we hit update, we now need
    to refetch the model from the session, otherwise we will hit an error
    trying to refresh and/or detach an already detached model. Hence the
    change in NeutronDbObject.update to always trigger update_object
    irrespective to whether any persistent fields were changed. This makes
    test_update_no_changes test case incorrect, hence its removal.

    Due to the way RBAC metaclass works, it may trigger cls.get_object in
    the middle of object creation (to validate newly created RBAC entry
    against the object). It results in duplicate expunge calls for the same
    object model (one during object creation, another when fetching the same
    object to validate it for RBAC). To avoid that, switched RBAC code from
    objects API to direct objects.db_api.get_object calls that will avoid
    triggering the whole model expunge/refresh machinery.

    Now that we have models stored on objects, the patch switched back
    plugin code to passing models in places where we previously, by mistake,
    were passing objects into extensions.

    Specifically, the switch for allowed address pairs occurred with
    I3c937267ce789ed510373616713b3fa9517c18ac. For subnetpools, it happened
    in I1415c7a29af86d377ed31cce40888631a34d...

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 9.0.0.0rc1 release candidate.