Comment 13 for bug 1860913

Reviewed: https://review.opendev.org/c/openstack/cinder/+/799843
Committed: https://opendev.org/openstack/cinder/commit/25eb0a7d76922e3a1a289d26c36b96a91c4059db
Submitter: "Zuul (22348)"
Branch: master

commit 25eb0a7d76922e3a1a289d26c36b96a91c4059db
Author: Gorka Eguileor <email address hidden>
Date: Tue Jul 6 13:35:44 2021 +0200

    NFS: Update connection info on online snap create

    The NFS snapshot creation for an attached volume requires interaction
    between Nova and Cinder, and a new qcow2 file is used after the
    attachment completes.

    This means that the connection properties stored in the Attachment is no
    longer valid, as it is pointing to the old qcow2 file, so if Nova tries
    to use that attachment it will start writing on the old qcow2 file.

    A flow showing this issue is:

    - Attach NFS volume
    - Create snapshot
    - Hard reboot

    After that the VM will start using the base image, breaking the qcow2
    chain.

    If we delete the snapshot in the meantime, then the VM will fail to
    reboot.

    This patch fixes this inconsistency by updating the connection info
    field inside the remotefs driver.

    We usually prefer that drivers don't to touch the DB, directly or
    indirectly (using OVOs), but in this case we are using OVOs methods
    instead of the usual model update on the volume manager because there
    are cases in the driver where a snapshot is created (cloning via
    snapshot) and we have to update the attachment without the manager, as
    it is unaware that a temporary snapshot is being created.

    Besides that main reason there are other less critical reasons to do the
    attachment update in the driver:

    - Smaller code change
    - Easier to backport
    - Limit change impact on other areas (better for backport)
    - The snapshot_create model update code in the manager does not support
      updating attachments.
    - There are cases in the cinder volume manager where the model update
      values returned by snapshot_create are not being applied.

    Snapshot deletion belonging to in-use volumes are not affected by this
    issue because we only do block commit when the snapshot file we are
    deleting is not the active file. In _delete_snapshot_online:

            if utils.paths_normcase_equal(info['active_file'],
                                          info['snapshot_file']):

    Closes-Bug: #1860913
    Change-Id: I62fcef3169dcb9f4363a5344af4b2711edfef632