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

Vijay Bhaskar Reddy vavuthu at redhat.com
Fri Mar 29 06:24:22 UTC 2019



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 <mailto: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.

>
> [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
>     <mailto: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
>         <mailto:automated-testing at gluster.org>
>         https://lists.gluster.org/mailman/listinfo/automated-testing
>
>
>
> _______________________________________________
> automated-testing mailing list
> automated-testing at gluster.org
> https://lists.gluster.org/mailman/listinfo/automated-testing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/automated-testing/attachments/20190329/53a506d7/attachment-0001.html>


More information about the automated-testing mailing list