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.
