From vavuthu at redhat.com  Mon Apr  1 05:55:49 2019
From: vavuthu at redhat.com (Vijay Bhaskar Reddy Avuthu)
Date: Mon, 1 Apr 2019 11:25:49 +0530
Subject: [automated-testing] What is the current state of the Glusto
 test framework in upstream?
In-Reply-To: <CAJgorsay3BEJpVZ9_D7Nps145jnoqt6DifBRXX499uaFOB_gPg@mail.gmail.com>
References: <CAJWA-5a5ozRr8L84v9FXjogg8wNRPECAFM7umcjJYXsbN9V-HA@mail.gmail.com>
	<CAJgorsZ8rPoBeHJD430gAbNuE7Ap39x3U7VpxvqUUW_TzTuf2g@mail.gmail.com>
	<CAJWA-5Y30jsUWCAuhtAwfAaVjtjTFkLTGM2NLNbNR7r4dqYEHg@mail.gmail.com>
	<CAKt6spviMiKQ5WdU71prDCoKkuFBhCrJDZm8_B39xw0Z1E-Cpg@mail.gmail.com>
	<CAJgorsay3BEJpVZ9_D7Nps145jnoqt6DifBRXX499uaFOB_gPg@mail.gmail.com>
Message-ID: <CAJEb8_kwwJSvTufroLtr69HVPSmyk4LesCeFn1nj17qdW=hr0A@mail.gmail.com>

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>

From ykaul at redhat.com  Mon Apr  1 06:19:52 2019
From: ykaul at redhat.com (Yaniv Kaul)
Date: Mon, 1 Apr 2019 09:19:52 +0300
Subject: [automated-testing] What is the current state of the Glusto
 test framework in upstream?
In-Reply-To: <CAJEb8_kwwJSvTufroLtr69HVPSmyk4LesCeFn1nj17qdW=hr0A@mail.gmail.com>
References: <CAJWA-5a5ozRr8L84v9FXjogg8wNRPECAFM7umcjJYXsbN9V-HA@mail.gmail.com>
	<CAJgorsZ8rPoBeHJD430gAbNuE7Ap39x3U7VpxvqUUW_TzTuf2g@mail.gmail.com>
	<CAJWA-5Y30jsUWCAuhtAwfAaVjtjTFkLTGM2NLNbNR7r4dqYEHg@mail.gmail.com>
	<CAKt6spviMiKQ5WdU71prDCoKkuFBhCrJDZm8_B39xw0Z1E-Cpg@mail.gmail.com>
	<CAJgorsay3BEJpVZ9_D7Nps145jnoqt6DifBRXX499uaFOB_gPg@mail.gmail.com>
	<CAJEb8_kwwJSvTufroLtr69HVPSmyk4LesCeFn1nj17qdW=hr0A@mail.gmail.com>
Message-ID: <CAJgorsY-7wqVLqF5-tO29dCz4PzEWor0tY3dGHvNhNO7ZBOp4g@mail.gmail.com>

On Mon, Apr 1, 2019 at 8:56 AM Vijay Bhaskar Reddy Avuthu <
vavuthu at redhat.com> wrote:

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

Anything special about docx files that we need to test with it? Have we
ever had some corruption specifically there? I'd understand (sort-of) if we
were running some application on top.
Anyway, this is not it - I have it installed already.

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

I would say that in CI, we probably want to continue, and elsewhere, we
probably want to stop.

>
>
>>
> - 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/6d46b32f/attachment.html>

From vavuthu at redhat.com  Mon Apr  1 06:38:47 2019
From: vavuthu at redhat.com (Vijay Bhaskar Reddy Avuthu)
Date: Mon, 1 Apr 2019 12:08:47 +0530
Subject: [automated-testing] What is the current state of the Glusto
 test framework in upstream?
In-Reply-To: <CAJgorsY-7wqVLqF5-tO29dCz4PzEWor0tY3dGHvNhNO7ZBOp4g@mail.gmail.com>
References: <CAJWA-5a5ozRr8L84v9FXjogg8wNRPECAFM7umcjJYXsbN9V-HA@mail.gmail.com>
	<CAJgorsZ8rPoBeHJD430gAbNuE7Ap39x3U7VpxvqUUW_TzTuf2g@mail.gmail.com>
	<CAJWA-5Y30jsUWCAuhtAwfAaVjtjTFkLTGM2NLNbNR7r4dqYEHg@mail.gmail.com>
	<CAKt6spviMiKQ5WdU71prDCoKkuFBhCrJDZm8_B39xw0Z1E-Cpg@mail.gmail.com>
	<CAJgorsay3BEJpVZ9_D7Nps145jnoqt6DifBRXX499uaFOB_gPg@mail.gmail.com>
	<CAJEb8_kwwJSvTufroLtr69HVPSmyk4LesCeFn1nj17qdW=hr0A@mail.gmail.com>
	<CAJgorsY-7wqVLqF5-tO29dCz4PzEWor0tY3dGHvNhNO7ZBOp4g@mail.gmail.com>
Message-ID: <CAJEb8_kpVKsN=15hXpnhyRfbvGaFPW_Ov6p9jUtOQqKpOkJ4DQ@mail.gmail.com>

I an not aware of any corruption issues with docx and nowhere in test cases
docx is used. I think it was there as an option to use.
The only place where it used is "file_dir_ops.py".

Regards,
Vijay A

On Mon, Apr 1, 2019 at 11:50 AM Yaniv Kaul <ykaul at redhat.com> wrote:

>
>
> On Mon, Apr 1, 2019 at 8:56 AM Vijay Bhaskar Reddy Avuthu <
> vavuthu at redhat.com> wrote:
>
>>
>>
>> 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.
>>
>
> Anything special about docx files that we need to test with it? Have we
> ever had some corruption specifically there? I'd understand (sort-of) if we
> were running some application on top.
> Anyway, this is not it - I have it installed already.
>
>> 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.
>>
>
> I would say that in CI, we probably want to continue, and elsewhere, we
> probably want to stop.
>
>>
>>
>>>
>> - 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/86e53a81/attachment-0001.html>

From ykaul at redhat.com  Mon Apr  1 08:04:54 2019
From: ykaul at redhat.com (Yaniv Kaul)
Date: Mon, 1 Apr 2019 11:04:54 +0300
Subject: [automated-testing] What is the current state of the Glusto
 test framework in upstream?
In-Reply-To: <CAAoO_8gRUNBA7aQ4MMbud2Rv=OXKLOtF7VG5Qx1qw-fRrnEcXQ@mail.gmail.com>
References: <CAJWA-5a5ozRr8L84v9FXjogg8wNRPECAFM7umcjJYXsbN9V-HA@mail.gmail.com>
	<CAJgorsZ8rPoBeHJD430gAbNuE7Ap39x3U7VpxvqUUW_TzTuf2g@mail.gmail.com>
	<CAJWA-5Y30jsUWCAuhtAwfAaVjtjTFkLTGM2NLNbNR7r4dqYEHg@mail.gmail.com>
	<CAKt6spviMiKQ5WdU71prDCoKkuFBhCrJDZm8_B39xw0Z1E-Cpg@mail.gmail.com>
	<CAJgorsay3BEJpVZ9_D7Nps145jnoqt6DifBRXX499uaFOB_gPg@mail.gmail.com>
	<CAJEb8_kwwJSvTufroLtr69HVPSmyk4LesCeFn1nj17qdW=hr0A@mail.gmail.com>
	<CAAoO_8gRUNBA7aQ4MMbud2Rv=OXKLOtF7VG5Qx1qw-fRrnEcXQ@mail.gmail.com>
Message-ID: <CAJgorsZnVew90HvXbqYm+ptCOxBDTFY0xSH4yr2YCOejrnP+qQ@mail.gmail.com>

On Mon, Apr 1, 2019 at 9:20 AM Vivek Das <vdas at redhat.com> wrote:

> Comments inline
>
> On Mon, Apr 1, 2019 at 11:26 AM Vijay Bhaskar Reddy Avuthu <
> vavuthu at redhat.com> wrote:
>
>>
>>
>> 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
>>
>
> A subsequent bug was raised for the above issue.
> https://bugzilla.redhat.com/show_bug.cgi?id=1664618
>

- The bug is lacking severity classification.
- The bug is lacking AutomationBlocker keyword.
- Is it a regression?
- Why hasn't anyone from engineering looked at it?
- How does it pass in CI?

Y.


>
>
>
>>
>> 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/85cc5ac3/attachment.html>

From kiyer at redhat.com  Fri Apr  5 12:16:37 2019
From: kiyer at redhat.com (Kshithij Iyer)
Date: Fri, 5 Apr 2019 17:46:37 +0530
Subject: [automated-testing] CentOS-CI failing in initialization
Message-ID: <CACEviogoWWZ9FYNLJjXHY-V5QwNc-JCWZJek1OrA7db=FywfqQ@mail.gmail.com>

Hello,
I was trying to verify my patch[1] with CentOS-CI and have observed that
the machines are not reachable and I am getting the below given error:

*17:38:14* + RETURN_CODE=0*17:38:14* + '[' 0 -eq 0 ']'*17:38:14* +
break*17:38:14* + '[' -z '' ']'*17:38:14* + scp -o
UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
jobs/scripts/glusto/run-glusto.sh
root at 172.19.2.48:run-glusto.sh*17:38:14* Warning: Permanently added
'172.19.2.48' (ECDSA) to the list of known hosts.*17:38:14* + ssh -t
-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
root at 172.19.2.48 EXIT_ON_FAIL= ./run-glusto.sh -m ''*17:38:14*
Pseudo-terminal will not be allocated because stdin is not a
terminal.*17:38:14* Warning: Permanently added '172.19.2.48' (ECDSA)
to the list of known hosts.

can someone please fix this?

[1] https://review.gluster.org/#/c/glusto-tests/+/22518/

Thanks,

Kshithij Iyer

ASSOCIATE QUALITY ENGINEER

Red Hat India <https://www.redhat.com/>

kiyer at redhat.com <vpapnoi at gmail.com>    IM: kiyer
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs/>   @redhatjobs
<https://instagram.com/redhatjobs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/automated-testing/attachments/20190405/3337e6d2/attachment-0001.html>

From saraut at redhat.com  Tue Apr  9 07:38:24 2019
From: saraut at redhat.com (Sayalee Raut)
Date: Tue, 9 Apr 2019 13:08:24 +0530
Subject: [automated-testing] CentOS-CI failing in initialization
In-Reply-To: <CACEviogoWWZ9FYNLJjXHY-V5QwNc-JCWZJek1OrA7db=FywfqQ@mail.gmail.com>
References: <CACEviogoWWZ9FYNLJjXHY-V5QwNc-JCWZJek1OrA7db=FywfqQ@mail.gmail.com>
Message-ID: <CAEfhE7sGAgq0rNOERt64=JZM8eTtwtMsDGYfSO_uDsYvQZOC4w@mail.gmail.com>

Hello,

Even I am facing similar issues; for my patch [1], while verifying it with
CentOS CI; below are errors:

*17:05:11* + RETURN_CODE=0*17:05:11* + '[' 0 -eq 0 ']'*17:05:11* +
break*17:05:11* + '[' -z functional/dht/test_rename_directory.py
']'*17:05:11* + scp -o UserKnownHostsFile=/dev/null -o
StrictHostKeyChecking=no jobs/scripts/glusto/run-glusto-patch.sh
root at 172.19.2.119:run-glusto-patch.sh*17:05:11* Warning: Permanently
added '172.19.2.119' (ECDSA) to the list of known hosts.*17:05:11* +
ssh -t -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
root at 172.19.2.119 EXIT_ON_FAIL=True ./run-glusto-patch.sh -p
functional/dht/test_rename_directory.py*17:05:11* Pseudo-terminal will
not be allocated because stdin is not a terminal.*17:05:11* Warning:
Permanently added '172.19.2.119' (ECDSA) to the list of known hosts.

[1] https://review.gluster.org/#/c/glusto-tests/+/22140/

Thanks & Regards,

sayalee raut

ASSOCIATE QUALITY ENGINEER

Red Hat India <https://www.redhat.com/>

saraut at redhat.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs/>   @redhatjobs
<https://instagram.com/redhatjobs>


On Fri, Apr 5, 2019 at 5:54 PM Kshithij Iyer <kiyer at redhat.com> wrote:

> Hello,
> I was trying to verify my patch[1] with CentOS-CI and have observed that
> the machines are not reachable and I am getting the below given error:
>
> *17:38:14* + RETURN_CODE=0*17:38:14* + '[' 0 -eq 0 ']'*17:38:14* + break*17:38:14* + '[' -z '' ']'*17:38:14* + scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no jobs/scripts/glusto/run-glusto.sh root at 172.19.2.48:run-glusto.sh*17:38:14* Warning: Permanently added '172.19.2.48' (ECDSA) to the list of known hosts.*17:38:14* + ssh -t -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root at 172.19.2.48 EXIT_ON_FAIL= ./run-glusto.sh -m ''*17:38:14* Pseudo-terminal will not be allocated because stdin is not a terminal.*17:38:14* Warning: Permanently added '172.19.2.48' (ECDSA) to the list of known hosts.
>
> can someone please fix this?
>
> [1] https://review.gluster.org/#/c/glusto-tests/+/22518/
>
> Thanks,
>
> Kshithij Iyer
>
> ASSOCIATE QUALITY ENGINEER
>
> Red Hat India <https://www.redhat.com/>
>
> kiyer at redhat.com <vpapnoi at gmail.com>    IM: kiyer
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> <https://www.facebook.com/redhatjobs/>   @redhatjobs
> <https://instagram.com/redhatjobs>
>
>
> _______________________________________________
> 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/20190409/4ee7035d/attachment.html>

From sankarshan.mukhopadhyay at gmail.com  Mon Apr 29 05:13:41 2019
From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay)
Date: Mon, 29 Apr 2019 10:43:41 +0530
Subject: [automated-testing] how does glusto based testing handle logging?
Message-ID: <CAJWA-5Y15iGVEwNErWZnHBvfr1QKw7NTNi9ia3S=3OsZQdeZFw@mail.gmail.com>

This is practically a 2 part question:

+ negative scenarios in Glusto ie. where not-expected behavior happens
+ handling logging for such negative paths

In summary, does setting up Glusto also set up an ELK (or, similar
stack) for centralized logging?

From jholloway at redhat.com  Mon Apr 29 15:34:51 2019
From: jholloway at redhat.com (Jonathan Holloway)
Date: Mon, 29 Apr 2019 10:34:51 -0500
Subject: [automated-testing] how does glusto based testing handle
	logging?
In-Reply-To: <CAJWA-5Y15iGVEwNErWZnHBvfr1QKw7NTNi9ia3S=3OsZQdeZFw@mail.gmail.com>
References: <CAJWA-5Y15iGVEwNErWZnHBvfr1QKw7NTNi9ia3S=3OsZQdeZFw@mail.gmail.com>
Message-ID: <CAKt6sptebjdg22y0uYj8n0UjMFnX3sWK3hpAZztN=w9gxuYXrg@mail.gmail.com>

Hi Sankarshan,

In a nutshell, no. Glusto itself only sets up a main Python logger for the
Glusto library to write to, typically when a test is run via
/usr/bin/glusto.
Above that, the gluster libraries either write to the main Glusto log or
create their own logger for the tests themselves.
For collection of those and logs at the system layer (syslog, Gluster,
etc), the automation is handled at the Jenkins level.

A centralized solution for test and log analysis is on the CCIT roadmap in
QE, and I'm working with Data Hub for the Log File Analysis aspect using
their Elastic.
Framework (PyTest, Glusto, etc.) and test logs generated by the
gluster-specific libraries would be included in logs collected by the
system, but setup for collation of that log data would be a level higher.

Someone can correct me, but I think the closest we have right now is the
sosreport generated and stored after the test downstream.

Cheers,
Jonathan


On Mon, Apr 29, 2019 at 12:20 AM Sankarshan Mukhopadhyay <
sankarshan.mukhopadhyay at gmail.com> wrote:

> This is practically a 2 part question:
>
> + negative scenarios in Glusto ie. where not-expected behavior happens
> + handling logging for such negative paths
>
> In summary, does setting up Glusto also set up an ELK (or, similar
> stack) for centralized logging?
> _______________________________________________
> 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/20190429/45966d60/attachment.html>

From sankarshan.mukhopadhyay at gmail.com  Mon Apr 29 16:16:47 2019
From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay)
Date: Mon, 29 Apr 2019 21:46:47 +0530
Subject: [automated-testing] how does glusto based testing handle
	logging?
In-Reply-To: <CAKt6sptebjdg22y0uYj8n0UjMFnX3sWK3hpAZztN=w9gxuYXrg@mail.gmail.com>
References: <CAJWA-5Y15iGVEwNErWZnHBvfr1QKw7NTNi9ia3S=3OsZQdeZFw@mail.gmail.com>
	<CAKt6sptebjdg22y0uYj8n0UjMFnX3sWK3hpAZztN=w9gxuYXrg@mail.gmail.com>
Message-ID: <CAJWA-5b5L61=czew7xM1YXh0a-Z834ZvQ=vQ2HiwuwBTvT+RsA@mail.gmail.com>

On Mon, Apr 29, 2019 at 9:05 PM Jonathan Holloway <jholloway at redhat.com> wrote:

> In a nutshell, no. Glusto itself only sets up a main Python logger for the Glusto library to write to, typically when a test is run via /usr/bin/glusto.
> Above that, the gluster libraries either write to the main Glusto log or create their own logger for the tests themselves.
> For collection of those and logs at the system layer (syslog, Gluster, etc), the automation is handled at the Jenkins level.
>

I think this leads to a design decision around how a Glusto instance
for Gluster would need to have a centralized logging or, at the very
least, rsyslog configured. Logs resulting from failed tests are a good
place to start for patterns and identify remedial approaches.

> A centralized solution for test and log analysis is on the CCIT roadmap in QE, and I'm working with Data Hub for the Log File Analysis aspect using their Elastic.
> Framework (PyTest, Glusto, etc.) and test logs generated by the gluster-specific libraries would be included in logs collected by the system, but setup for collation of that log data would be a level higher.
>
> Someone can correct me, but I think the closest we have right now is the sosreport generated and stored after the test downstream.

I'm not sure who can respond to this.

From ykaul at redhat.com  Mon Apr 29 16:39:45 2019
From: ykaul at redhat.com (Yaniv Kaul)
Date: Mon, 29 Apr 2019 19:39:45 +0300
Subject: [automated-testing] how does glusto based testing handle
	logging?
In-Reply-To: <CAJWA-5b5L61=czew7xM1YXh0a-Z834ZvQ=vQ2HiwuwBTvT+RsA@mail.gmail.com>
References: <CAJWA-5Y15iGVEwNErWZnHBvfr1QKw7NTNi9ia3S=3OsZQdeZFw@mail.gmail.com>
	<CAKt6sptebjdg22y0uYj8n0UjMFnX3sWK3hpAZztN=w9gxuYXrg@mail.gmail.com>
	<CAJWA-5b5L61=czew7xM1YXh0a-Z834ZvQ=vQ2HiwuwBTvT+RsA@mail.gmail.com>
Message-ID: <CAJgorsbhGvx1fqimknd=3Vhs+xSyvV9J3G9UMwL_YaAamwo3Vw@mail.gmail.com>

On Mon, Apr 29, 2019 at 7:17 PM Sankarshan Mukhopadhyay <
sankarshan.mukhopadhyay at gmail.com> wrote:

> On Mon, Apr 29, 2019 at 9:05 PM Jonathan Holloway <jholloway at redhat.com>
> wrote:
>
> > In a nutshell, no. Glusto itself only sets up a main Python logger for
> the Glusto library to write to, typically when a test is run via
> /usr/bin/glusto.
> > Above that, the gluster libraries either write to the main Glusto log or
> create their own logger for the tests themselves.
> > For collection of those and logs at the system layer (syslog, Gluster,
> etc), the automation is handled at the Jenkins level.
> >
>
> I think this leads to a design decision around how a Glusto instance
> for Gluster would need to have a centralized logging or, at the very
> least, rsyslog configured. Logs resulting from failed tests are a good
> place to start for patterns and identify remedial approaches.
>

Is the question about Gluso logging or Gluster? I thought the latter...
It's also a feature of Gluster, to log to syslog, so would be good to add
the capability to test that.
I believe it should be easy(TM) to add to the client (1st client) such
configuration.
I'll add it to the queue.

>
> > A centralized solution for test and log analysis is on the CCIT roadmap
> in QE, and I'm working with Data Hub for the Log File Analysis aspect using
> their Elastic.
> > Framework (PyTest, Glusto, etc.) and test logs generated by the
> gluster-specific libraries would be included in logs collected by the
> system, but setup for collation of that log data would be a level higher.
> >
> > Someone can correct me, but I think the closest we have right now is the
> sosreport generated and stored after the test downstream.
>
> I'm not sure who can respond to this.
> _______________________________________________
> 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/20190429/9eecede2/attachment.html>

From vdas at redhat.com  Mon Apr  1 06:20:23 2019
From: vdas at redhat.com (Vivek Das)
Date: Mon, 01 Apr 2019 06:20:23 -0000
Subject: [automated-testing] What is the current state of the Glusto
 test framework in upstream?
In-Reply-To: <CAJEb8_kwwJSvTufroLtr69HVPSmyk4LesCeFn1nj17qdW=hr0A@mail.gmail.com>
References: <CAJWA-5a5ozRr8L84v9FXjogg8wNRPECAFM7umcjJYXsbN9V-HA@mail.gmail.com>
	<CAJgorsZ8rPoBeHJD430gAbNuE7Ap39x3U7VpxvqUUW_TzTuf2g@mail.gmail.com>
	<CAJWA-5Y30jsUWCAuhtAwfAaVjtjTFkLTGM2NLNbNR7r4dqYEHg@mail.gmail.com>
	<CAKt6spviMiKQ5WdU71prDCoKkuFBhCrJDZm8_B39xw0Z1E-Cpg@mail.gmail.com>
	<CAJgorsay3BEJpVZ9_D7Nps145jnoqt6DifBRXX499uaFOB_gPg@mail.gmail.com>
	<CAJEb8_kwwJSvTufroLtr69HVPSmyk4LesCeFn1nj17qdW=hr0A@mail.gmail.com>
Message-ID: <CAAoO_8gRUNBA7aQ4MMbud2Rv=OXKLOtF7VG5Qx1qw-fRrnEcXQ@mail.gmail.com>

Comments inline

On Mon, Apr 1, 2019 at 11:26 AM Vijay Bhaskar Reddy Avuthu <
vavuthu at redhat.com> wrote:

>
>
> 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
>

A subsequent bug was raised for the above issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1664618


>
> 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/ff5adefe/attachment.html>