[automated-testing] Tear down - shouldn't it unmount client?

Yaniv Kaul ykaul at redhat.com
Fri Mar 29 06:53:38 UTC 2019


On Fri, Mar 29, 2019 at 9:24 AM Vijay Bhaskar Reddy <vavuthu at redhat.com>
wrote:

>
>
> On 03/29/2019 12:25 AM, Yaniv Kaul wrote:
>
>
>
> On Thu, Mar 28, 2019 at 7:21 PM Jonathan Holloway <jholloway at redhat.com>
> wrote:
>
>> Only where a mount is exec'd in setUp. In some cases, tests are grouped
>> by Class with the volume created in setUp without a mount. Any tests
>> requiring a mount handle the mount and subsequent umount before tearDown
>> gets run.
>>
>> e.g.,
>> test_volume_create_start_stop_start() is only testing the volume and
>> doesn't require the mount, whereas...
>> test_file_dir_create_ops_on_volume() is creating ops on the mounted
>> volume and does it's own mount/umount.
>>
>
> (It's also taking 100% CPU during execution, need to find out why...)
>
>>
>> This file could be broken into a volume only class and a mounted volume
>> class to handle the mount/umount in tearDown, or even allow the super
>> GlusterBaseClass.tearDownClass() method do it automatically.
>>
>
> Ok, so since for some reason test_volume_sanity() is failing for me[2], it
> doesn't unmount.
> Unmount before making the check, so it'll clean well, even if it fails
> seem to help[3].
>
>>
>> On another note, this test_vvt.py test can probably be eliminated with
>> the code covered in another volume test suite (or suites) and the volume
>> verification test step in BVT run using pytest markers against
>> @pytest.mark.bvt_vvt decorator as I'd originally intended.
>> The idea there was to create a BVT test from a sample of existing
>> testcases written in the full test suites--eliminating duplication of code.
>>
>
> This is what is running today (I think) in upstream[1], so if it needs to
> / can be, that'd be great, but has to be coordinated.
> Y.
>
> [1]
> https://github.com/gluster/glusterfs-patch-acceptance-tests/blob/b9e7dbc57bc96c8a538593f7a5ff0f03fc38e335/centos-ci/scripts/run-glusto.sh
> [2] Donno what it means:
> E       AssertionError: Lists are not equal.
> E        Before creating file:
> ['00\nchangelogs\nindices\nlandfill\nunlink\n',
> '00\nchangelogs\nindices\nlandfill\nunlink\n',
> '00\nchangelogs\nindices\nlandfill\nunlink\n',
> '00\nchangelogs\nindices\nlandfill\nunlink\n']
> E        After deleting file:
> ['00\nchangelogs\nindices\nlandfill\nunlink\n',
> '00\nchangelogs\nindices\nlandfill\nunlink\n',
> '00\n25\nchangelogs\nindices\nlandfill\nunlink\n',
> '00\n25\n2d\nchangelogs\nindices\nlandfill\nunlink\n']
>
>
> I remember this test cases was created as part of Closed Gap and later bug
> turned to WONTFIX. I think we need to skip or remove the test cases. Since
> test cases is asserting out before unmount, it
> leaves the mount point as it is.
>

The latter part I've fixed. the former one, do we need to simply depracate
this test?
(which makes me wonder who's running those tests at all, if they are
broken...)
Y.

>
>
> [3] https://review.gluster.org/#/c/glusto-tests/+/22440/
>
>>
>> Cheers,
>> Jonathan
>>
>> On Thu, Mar 28, 2019 at 9:02 AM Yaniv Kaul <ykaul at redhat.com> wrote:
>>
>>> Teardown (at least where I'm looking at, test_vvt.py) is cleaning up the
>>> volume.
>>> Shouldn't it also unmount the client?
>>>
>>> TIA,
>>> Y.
>>> _______________________________________________
>>> automated-testing mailing list
>>> automated-testing at gluster.org
>>> https://lists.gluster.org/mailman/listinfo/automated-testing
>>>
>>
>
> _______________________________________________
> automated-testing mailing listautomated-testing at gluster.orghttps://lists.gluster.org/mailman/listinfo/automated-testing
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/automated-testing/attachments/20190329/4f44cd93/attachment-0001.html>


More information about the automated-testing mailing list