qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.8] iotests: Do not rely on un


From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH for-2.8] iotests: Do not rely on unavailable domains in 162
Date: Tue, 23 Aug 2016 11:19:07 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 2016-08-23 at 10:17, Sascha Silbe wrote:
Dear Max,

Max Reitz <address@hidden> writes:

On 2016-08-23 at 07:44, Sascha Silbe wrote:
Max Reitz <address@hidden> writes:
[tests/qemu-iotests/162]
Using a fixed port number means multiple users won't be able to run this
in parallel. That it's only open for a short time actually makes the
issue a bit worse as it's hard to understand just why the test failed
intermittently.

Is there a way to have qemu-nbd use a random port and print the port
number?

Good idea. We can just let the script generate a random port;
$(($RANDOM+32768)) should do the trick.

Which will fail just the same as the original version if anything (not
just qemu-nbd) is already occupying the port you happened to
choose.

But I think figuring that out from the error log will be rather trivial:

> +Failed to bind socket: Address already in use

Maybe we should just fix this part:

+# (We need to set up a server here, because the error message for "Connection
+#  refused" does not contain the destination port)

Including the port number in the "Connection refused" error message is a
useful diagnostic, especially if it's a non-default port.

This would need to be included in the socket code itself, because it wouldn't make sense to do this for NBD alone. However, doing that is not trivial, because at the point where the error message is generated we only have a generic addrinfo structure which I'm not really inclined to add unparsing code for, just so this test (for developers) does not fail with a very low probability.

While I do agree that it would be useful diagnostics in principle, in practice this is kind of rendered obsolete by the fact that we generally do print the URL (the "file name") anyway. The same applies for any other protocol: When raw-posix cannot open some file, its Error object will not contain the file name but just "No such file or directory" or something like that. The file name is supplied by the caller, e.g. qemu-img.

The thing is just that this test tests whether we can trust NBD to correctly interpret that file name. So we can't trust this information, but a normal user usually can (if they can't, it's a bug).

So adding this information would in my opinion only really be useful for this very test, and I'm not so sure whether the effort is really worth it.

If you think this test failing is really an issue that we should fix, then I'd rather put the qemu-nbd launch inside of a loop, retrying until it succeeds with some random port.

Max



reply via email to

[Prev in Thread] Current Thread [Next in Thread]