| 2020-03-05 11:08:27 |
Luigi Toscano |
description |
When multiple volume backends are available, encryption tests may fail if encryption is not supported on some backends. This is the case for NFS right now (https://review.opendev.org/#/c/597148/)
As the environment as a whole supports encryption, It should be possible to run encryption tests but limit them on the supported backend(s).
I see various possible solutions:
1) make sure volume.storage_protocol is used when calling the volume type is create inside EncryptionScenarioTest.create_encrypted_volume
2) add a new configuration variable which will be used when calling EncryptionScenarioTest.create_encrypted_volume and then create_volume_type.
This has two possible variants:
2a) let this configuration key list a single backend. This may be limit the tested scenarios if more backend are capable of encryption;
2b) allow for a list of values, and choose one randomly. This may introduce too much randomness and it is not exactly the same as "allow cinder to choose any capable resource".
3) assume that the first backend in volume.backend_list work with encryption. This is a bit risky and potentially limits which scenarios can be tested. |
When multiple volume backends are available, encryption tests may fail if encryption is not supported on some backends. For example, whenever the NFS protocol is used, encryption does not work (proof: there is work in progress here https://review.opendev.org/#/c/597148/).
As the environment as a whole supports encryption, It should be possible to run encryption tests but limit them on the supported backend(s).
I see various possible solutions:
1) make sure volume.storage_protocol is used when calling the volume type is create inside EncryptionScenarioTest.create_encrypted_volume
2) add a new configuration variable which will be used when calling EncryptionScenarioTest.create_encrypted_volume and then create_volume_type.
This has two possible variants:
2a) let this configuration key list a single backend. This may be limit the tested scenarios if more backend are capable of encryption;
2b) allow for a list of values, and choose one randomly. This may introduce too much randomness and it is not exactly the same as "allow cinder to choose any capable resource".
3) assume that the first backend in volume.backend_list work with encryption. This is a bit risky and potentially limits which scenarios can be tested. |
|
