Comment 2 for bug 1917619

Reviewed: https://review.opendev.org/c/openstack/nova/+/785577
Committed: https://opendev.org/openstack/nova/commit/f99f667a96a357adc0070d75b5940e76726f9664
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit f99f667a96a357adc0070d75b5940e76726f9664
Author: Lee Yarwood <email address hidden>
Date: Wed Mar 3 12:33:49 2021 +0000

    libvirt: Simplify device_path check in _detach_encryptor

    Introduced by Id670f13a7f197e71c77dc91276fc2fba2fc5f314 to resolve bug
     #1821696 this check was put in place to ensure _detach_encryptor did not
    attempt to use the os-brick encryptors with an unsupported volume type
    after libvirt secrets had been removed outside the control of Nova.

    With the introduction of the [workarounds]disable_native_luksv1 via
    Ia500eb614cf575ab846f64f4b69c9068274c8c1f however the use of
    _allow_native_luksv1 as part of this check is no longer valid. As this
    helper was updated to return False when the workaround is enabled,
    regardless of the underlying volume being attached natively or not.

    If an admin had enabled the workaround after users had launched
    instances with natively attached encrypted volumes *and* the libvirt
    secrets had gone missing _detach_encryptor would attempt to use the
    os-brick encryptors. This would fail when the underlying volume type is
    unsupported, for example rbd. See bug #1917619 for an example.

    This change resolves this corner case by dropping the use of
    _allow_native_luksv1 from the check and just asserting that a
    device_path is present for an encrypted volume before allowing the use
    of the os-brick encryptors. As noted this is safe as calls to the
    encryptors are idempotent, ignoring failures to detach when the
    underlying volume type is supported.

    Closes-Bug: #1917619
    Change-Id: Iba40c2df72228b461767d5734d5a62403d9f2cfa
    (cherry picked from commit 4908daed96ddda492ced6cbb084abe8f33a8b1f7)