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 4908daed96)
f99f667a96