Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Kevin Wolf <kwolf@redhat.com>]

Am 19.02.2019 um 12:06 hat Daniel P. Berrangé geschrieben:
> On Tue, Feb 19, 2019 at 10:37:16AM +0100, Kevin Wolf wrote:
> > Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> > > 
> > >  https://gitlab.com/huth/qemu/-/jobs/163680780
> > > 
> > > Some of them apparently need encryption to be enabled (as already
> > > mentioned by Cleber in his patch) - thus should they really be in the
> > > quick check, too? Or could they at least check whether QEMU has been
> > > built with encryption?
> > 
> > The correct solution would be that they detect the situation
> > automatically and skip the test by calling _notrun.
> > 
> > I'm not sure how to detect if a given QEMU binary supports encryption,
> > but Dan might know.
> 
> It isn't easy & depends which encryption feature you're trying to use.
> 
> For TLS related features you can do something gross like
> 
>     qemu-img info --object tls-creds-anon,id=dummy README 2>&1
>     test $? != 0 && exit 0
> 
> This relies on fact that 'tls-creds-anon' object type will report a
> runtime error during initialization if gnutls isn't enabled.
> 
> For more general ciphers you pretty much have to just try the higher level
> feature and see if it fails.

Actually, I think for test cases we should see 'qemu-img create' failing
and could just skip the test if it returns a non-zero exit code.

But then I looked at Thomas' output again:

    --- /builds/huth/qemu/tests/qemu-iotests/188.out	2019-02-19 08:23:54.000000000 +0000
    +++ /builds/huth/qemu/tests/qemu-iotests/188.out.bad	2019-02-19 08:34:54.000000000 +0000
    @@ -1,4 +1,5 @@
     QA output created by 188
    +qemu-img: TEST_DIR/t.IMGFMT: No crypto library supporting PBKDF in this build: Function not implemented
     Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10

     == reading whole image ==--- /builds/huth/qemu/tests/qemu-iotests/188.out	2019-02-19 08:23:54.000000000 +0000

What is it actually doing there? There's clearly an error message, but
it almost looks like it's creating some kind of image anyway? The
following I/O works fine (i.e. this created image can even be opened
again with the luks driver), except that you can also access the image
with the wrong password.

Is this a real bug in either qcow2 or luks?

Kevin