Comment 2 for bug 1621837

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 I1415c7a29af86d377ed31cce40888631a34d4811. Neither of those was
    released in Mitaka, so it did not break anyone using major releases.
    Also, we have not heard from any trunk chaser that would be affected by
    the mistake.

    There are not other objects used in database code where we would pass
    them into extensions, so we should be good.

    Closes-Bug: #1621837
    Change-Id: I130609194f15b89df89e5606fb8193849edd14d8
    Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db