On 6/3/26 10:44, Peter Krempa wrote: > On Wed, Jun 03, 2026 at 10:24:09 +0200, Michal Prívozník wrote: >> On 6/2/26 23:07, Peter Krempa via Devel wrote: >>> From: Peter Krempa <[email protected]> >>> >>> qemu-11.1 will drop support for the 'gluster' block backend driver. We >>> want to keep the tests around to validate that nothing in the >>> parser/generator has changed but there's no point in wiring up QMP >>> schema validation against older versions. >>> >>> Skip the schema validation for gluster qemublocktests. >>> >>> Signed-off-by: Peter Krempa <[email protected]> >>> --- >>> tests/qemublocktest.c | 31 ++++++++++++++++++++----------- >>> 1 file changed, 20 insertions(+), 11 deletions(-) >>> >> >>> @@ -1230,10 +1237,12 @@ mymain(void) >>> TEST_IMAGE_CREATE("qcow2-backing-raw-slice", "raw-slice"); >>> TEST_IMAGE_CREATE("qcow2-backing-qcow2-slice", "qcow2-slice"); >>> >>> - /* 'gluster' is deprecated as of qemu-9.2, once removed this tests can >>> be dropped too */ >>> - imagecreatedata.deprecated = true; >>> + /* 'gluster' is deprecated as of qemu-9.2, removed as of qemu-11.1. >>> Schema >>> + * validation no longer happens on these tests, but we keep them since >>> + * older qemu versions are still supported */ >>> + imagecreatedata.removed = true; >>> TEST_IMAGE_CREATE("network-gluster-qcow2", NULL); >>> - imagecreatedata.deprecated = false; >>> + imagecreatedata.removed = false; >>> TEST_IMAGE_CREATE("network-rbd-qcow2", NULL); >>> TEST_IMAGE_CREATE("network-ssh-qcow2", NULL); >>> >> >> So 'deprecated' member is never set. Why have it at all then? > > So I've left it be, because it's plumbed in the 3 calls to > `testQEMUSchemaValidate` as an argument ... > >> Or is it because we do not have anything deprecated currently, so it's >> for future use? > > ... and thought that we could use it if something else gets deprecated > in the future, so that it doesn't then need to be un-reverted. > > The question is though, whether it makes sense to mark stuff as > deprecated, since anything deprecated will eventually get removed, so we > might as well directly set the 'removed' flag instead. > > A counter argument to the above could be that in this case it'll take > qemu 1.5+ years from deprecation to removal and we've got the coverate > for the whole time. Also if something doesn't get removed in the end we > don't lose the coverage. > > In case of qemublocktest, I think we could directly switch to 'removed' > mode because we have also the output JSON files to match against so > changes would get noticed. > > So it's fine with me if you want me to remove it, I wasn't persuaded > either way and in the end laziness won. >
Makes sense. Keep it then. Reviewed-by: Michal Privoznik <[email protected]> Michal
