[automated-testing] What is the current state of the Glusto test framework in upstream?

Vijay Bhaskar Reddy Avuthu vavuthu at redhat.com
Mon Apr 1 05:55:49 UTC 2019


On Sun, Mar 31, 2019 at 6:30 PM Yaniv Kaul <ykaul at redhat.com> wrote:

>
>
> On Wed, Mar 13, 2019 at 4:14 PM Jonathan Holloway <jholloway at redhat.com>
> wrote:
>
>>
>>
>> On Wed, Mar 13, 2019 at 5:08 AM Sankarshan Mukhopadhyay <
>> sankarshan.mukhopadhyay at gmail.com> wrote:
>>
>>> On Wed, Mar 13, 2019 at 3:03 PM Yaniv Kaul <ykaul at redhat.com> wrote:
>>> > On Wed, Mar 13, 2019, 3:53 AM Sankarshan Mukhopadhyay <
>>> sankarshan.mukhopadhyay at gmail.com> wrote:
>>> >>
>>> >> What I am essentially looking to understand is whether there are
>>> >> regular Glusto runs and whether the tests receive refreshes. However,
>>> >> if there is no available Glusto service running upstream - that is a
>>> >> whole new conversation.
>>> >
>>> >
>>> > I'm* still trying to get it running properly on my simple
>>> Vagrant+Ansible setup[1].
>>> > Right now I'm installing Gluster + Glusto + creating bricks, pool and
>>> a volume in ~3m on my latop.
>>> >
>>>
>>> This is good. I think my original question was to the maintainer(s) of
>>> Glusto along with the individuals involved in the automated testing
>>> part of Gluster to understand the challenges in deploying this for the
>>> project.
>>>
>>> > Once I do get it fully working, we'll get to make it work faster,
>>> clean it up and and see how can we get code coverage.
>>> >
>>> > Unless there's an alternative to the whole framework that I'm not
>>> aware of?
>>>
>>> I haven't read anything to this effect on any list.
>>>
>>>
>> This is cool. I haven't had a chance to give it a run on my laptop, but
>> it looked good.
>> Are you running into issues with Glusto, glusterlibs, and/or Glusto-tests?
>>
>
> All of the above.
> - The client consumes at times 100% CPU, not sure why.
> - There are missing deps which I'm reverse engineering from Gluster CI
> (which by itself has some strange deps - why do we need python-docx ?)
> - I'm failing with the cvt test, with
> test_shrinking_volume_when_io_in_progress with the error:
> AssertionError: IO failed on some of the clients
>
> I had hoped it could give me a bit more hint:
> - which clients? (I happen to have one, so that's easy)
> - What IO workload?
> - What error?
>
> - I hope there's a mode that does NOT perform cleanup/teardown, so it's
> easier to look at the issue at hand.
>

python-docx needs to be installed as part of "glusto-tests dependencies".
file_dir_ops.py supports writing docx files.
IO failed on the client: 192.168.250.10. and it trying to write deep
directories with files.
Need to comment "tearDown" section if we want leave the cluster as it is in
the failed state.


>
- From glustomain.log, I can see:
> 2019-03-31 12:56:00,627 INFO (validate_io_procs) Validating IO on
> 192.168.250.10:/mnt/testvol_distributed-replicated_cifs
> 2019-03-31 12:56:00,627 INFO (_log_results) ESC[34;1mRETCODE (
> root at 192.168.250.10): 1ESC[0m
> 2019-03-31 12:56:00,628 INFO (_log_results) ESC[47;30;1mSTDOUT (
> root at 192.168.250.10)...
> Starting File/Dir Ops: 12:55:27:PM:Mar_31_2019
> Unable to create dir '/mnt/testvol_distributed-replicated_cifs/user6' :
> Invalid argument
> Unable to create dir '/mnt/testvol_distributed-replicated_cifs/user6/dir0'
> : Invalid argument
> Unable to create dir
> '/mnt/testvol_distributed-replicated_cifs/user6/dir0/dir0' : Invalid
> argument
> Unable to create dir
> '/mnt/testvol_distributed-replicated_cifs/user6/dir0/dir1' : Invalid
> argument
> Unable to create dir '/mnt/testvol_distributed-replicated_cifs/user6/dir1'
> : Invalid argument
> Unable to create dir
> '/mnt/testvol_distributed-replicated_cifs/user6/dir1/dir0' : Invalid
> argument
>
> I'm right now assuming something's wrong on my setup. Unclear what, yet.
>

+ vivek ; for the inputs regarding cifs issue

I had a conversation with vivek regarding the "Invalid argument" long time
back.


>
>> I was using the glusto-tests container to run tests locally and for BVT
>> in the lab.
>> I was running against lab VMs, so looking forward to giving the vagrant
>> piece a go.
>>
>> By upstream service are we talking about the Jenkins in the CentOS
>> environment, etc?
>>
>
> Yes.
> Y.
>
> @Vijay Bhaskar Reddy Avuthu <vavuthu at redhat.com> @Akarsha Rai
>> <akrai at redhat.com> any insight?
>>
>> Cheers,
>> Jonathan
>>
>> > Surely for most of the positive paths, we can (and perhaps should) use
>>> the the Gluster Ansible modules.
>>> > Y.
>>> >
>>> > [1] https://github.com/mykaul/vg
>>> > * with an intern's help.
>>> _______________________________________________
>>> automated-testing mailing list
>>> 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/20190401/0f73dfad/attachment-0001.html>


More information about the automated-testing mailing list