We have added support for some addition IMGOPTS in python iotests like
in bash iotests. Similarly to bash iotests, we want a way to skip some
tests which can't work with specific IMGOPTS.

Globally for python iotests we now don't support things like
'data_file=$TEST_IMG.ext_data_file' in IMGOPTS, so, forbid this
globally in iotests.py.

Suggested-by: Hanna Reitz <hreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 tests/qemu-iotests/iotests.py | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 903686b402..2cbb13d67a 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -1238,6 +1238,17 @@ def _verify_virtio_scsi_pci_or_ccw() -> None:
         notrun('Missing virtio-scsi-pci or virtio-scsi-ccw in QEMU binary')
 
 
+def _verify_imgopts(unsupported: Sequence[str] = ()) -> None:
+    imgopts = os.environ.get('IMGOPTS')
+    # One of usage examples for IMGOPTS is "data_file=$TEST_IMG.ext_data_file"
+    # but it supported only for bash tests. We don't have a concept of global
+    # TEST_IMG in iotests.py, not saying about somehow parsing $variables.
+    # So, for simplicity let's just not support any IMGOPTS with '$' inside.
+    unsup = list(unsupported) + ['$']
+    if imgopts and any(x in imgopts for x in unsup):
+        notrun(f'not suitable for this imgopts: {imgopts}')
+
+
 def supports_quorum():
     return 'quorum' in qemu_img_pipe('--help')
 
@@ -1414,7 +1425,8 @@ def execute_setup_common(supported_fmts: Sequence[str] = (),
                          unsupported_fmts: Sequence[str] = (),
                          supported_protocols: Sequence[str] = (),
                          unsupported_protocols: Sequence[str] = (),
-                         required_fmts: Sequence[str] = ()) -> bool:
+                         required_fmts: Sequence[str] = (),
+                         unsupported_imgopts: Sequence[str] = ()) -> bool:
     """
     Perform necessary setup for either script-style or unittest-style tests.
 
@@ -1434,6 +1446,7 @@ def execute_setup_common(supported_fmts: Sequence[str] = (),
     _verify_aio_mode(supported_aio_modes)
     _verify_formats(required_fmts)
     _verify_virtio_blk()
+    _verify_imgopts(unsupported_imgopts)
 
     return debug
 
-- 
2.31.1

On 03.12.21 14:07, Vladimir Sementsov-Ogievskiy wrote:
> We have added support for some addition IMGOPTS in python iotests like
> in bash iotests. Similarly to bash iotests, we want a way to skip some
> tests which can't work with specific IMGOPTS.
>
> Globally for python iotests we now don't support things like
> 'data_file=$TEST_IMG.ext_data_file' in IMGOPTS, so, forbid this
> globally in iotests.py.
>
> Suggested-by: Hanna Reitz <hreitz@redhat.com>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>   tests/qemu-iotests/iotests.py | 15 ++++++++++++++-
>   1 file changed, 14 insertions(+), 1 deletion(-)

Reviewed-by: Hanna Reitz <hreitz@redhat.com>

Can we move this and the next patch before patch 2, though? Otherwise, 
the tests adjusted in the next patch will be broken after patch 2 (when 
given those unsupported options).  The move seems trivial, just 
wondering whether you know of anything that would prohibit this.

23.12.2021 15:41, Hanna Reitz wrote:
> On 03.12.21 14:07, Vladimir Sementsov-Ogievskiy wrote:
>> We have added support for some addition IMGOPTS in python iotests like
>> in bash iotests. Similarly to bash iotests, we want a way to skip some
>> tests which can't work with specific IMGOPTS.
>>
>> Globally for python iotests we now don't support things like
>> 'data_file=$TEST_IMG.ext_data_file' in IMGOPTS, so, forbid this
>> globally in iotests.py.
>>
>> Suggested-by: Hanna Reitz <hreitz@redhat.com>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> ---
>>   tests/qemu-iotests/iotests.py | 15 ++++++++++++++-
>>   1 file changed, 14 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Hanna Reitz <hreitz@redhat.com>
> 
> Can we move this and the next patch before patch 2, though? Otherwise, the tests adjusted in the next patch will be broken after patch 2 (when given those unsupported options).  The move seems trivial, just wondering whether you know of anything that would prohibit this.
> 

OK

-- 
Best regards,
Vladimir