[automated-testing] gluster-block: Discussion regarding glusto tests

[Nigel Babu]

I've already tried to redirect this thread once. Please use the upstream
automated-testing@ list rather than CCing half the world. This is a
discussion that needs to happen and be decided in the open.

Pranith/Prasanna: At the moment your problem is that you want to write
tests in conjunction with your pull request and splitting into multiple
repos do not give you this ability. Is that the compelling reason why you
want this to happen in the gluster-block repo directly rather than
glusto-tests?


On Mon, Jul 2, 2018 at 5:40 PM Pranith Kumar Karampuri <pkarampu at redhat.com>
wrote:

>
>
> On Mon, 2 Jul 2018, 4:02 pm Rahul Hinduja, <rhinduja at redhat.com> wrote:
>
>>
>>
>> On Mon, Jul 2, 2018 at 3:54 PM, Prasanna Kalever <pkalever at redhat.com>
>> wrote:
>>
>>> On Mon, Jul 2, 2018 at 3:41 PM, Vijay Bhaskar Reddy Avuthu
>>> <vavuthu at redhat.com> wrote:
>>> > + Rahul
>>> >
>>> > Currently all the components of Gluster are under "gluster-tests"
>>> repo, I
>>> > would recommend the same for block. Another reason is its easy for QE
>>> to
>>> > track and trigger runs whenever is needed.
>>>
>>> +Vijay Bellur, +Amar
>>>
>>> The block dev is keeping the continuous effort here to catch the
>>> regression that might be introduced at each PR level, it will be easy
>>> for the contributes to run the tests locally, if they are part of the
>>> same repository. Downloading a different repository just to test the
>>> code that goes in guster-block repository doesn't make any sense to
>>> me. I'm not aware of any opensource project which would like their
>>> tests to maintained as part of a separate repository. At-least I
>>> wouldn't encourage this with gluster-block.
>>>
>>
>> Thats not true, if we go with this path than whats blocking us from
>> having multiple repositories like "ganesha", "geo-rep", "smb", "afr" etc.
>>
> Even though currently gluster dev worked on gluster block libs and cases
>> but we worked as a team in sprint-2 to achieve this. QE has contributed
>> maximum across glusto and will continue to invest time and resources in
>> glusto project [1] including block.
>>
>
> Our work of integration with glusto which started even before stop-gap
> work was to enable development team to write test cases along with the
> feature/bug-fix and send them in same PR. This way, the behaviour of the
> project at that HEAD will be tested correctly at that HEAD. If
> functionality changes then tests will change automatically.
> Asking contributors to send two separate patches to two different repos to
> get a change in the long run leads either to stale tests or stale code.
> It is a head ache better to avoid for both the teams.
>
>
>> All the cases irrespective of features must go to a common glusto-tests
>> repository. This would also help in central-CI and polarion reporting.
>>
>
> This is definitely something we should get right. Otherwise it will again
> become the same story as glusterfs where ongoing development and QE will
> have to duplicate efforts in automating the test cases.
>
> If we get this right by the time QE cycle starts there would be good
> amount of work already done by development team for automation and only the
> missing parts need to be automated by QE.
>
> Is there a way to get central-CI/polarion reporting to pull in tests from
> another repo and run them?
>
>
>> [1]: https://review.gluster.org/#/q/project:glusto-tests
>>
>
>
>
>
>>
>>
>>>
>>> Thanks,
>>> --
>>> Prasanna
>>>
>>>
>>> >
>>> > Regards,
>>> > Vijay A
>>> >
>>> > On Mon, Jul 2, 2018 at 2:05 PM, Prasanna Kalever <pkalever at redhat.com>
>>> > wrote:
>>> >>
>>> >> This was the plan long back, which Shwetha and myself had discussed,
>>> >> before even start work on the glusto tests for gluster-block, let me
>>> >> try to put the summary here:
>>> >>
>>> >> Plan 1:
>>> >> Create a 'glusto/libs/' folder under gluster-block repo and start
>>> >> adding libraries there and then keep the tests at 'glusto/tests/'
>>> >> folder under gluster-block repo.
>>> >>
>>> >> Plan 2:
>>> >> Push the libraries to glusto-tests repo and maintain the tests under
>>> >> gluster-block repo.
>>> >>
>>> >> I'm okay with any of the above approaches.
>>> >>
>>> >> Thanks!
>>> >> --
>>> >> Prasanna
>>> >>
>>> >>
>>> >> On Mon, Jul 2, 2018 at 11:46 AM, Bhumika Goyal <bgoyal at redhat.com>
>>> wrote:
>>> >> > Hi all,
>>> >> >
>>> >> > During stop-gap, we wrote some libraries(patch on gerrit) and test
>>> >> > cases(PR on gluster-block repo currently) for gluster-block using
>>> glusto.
>>> >> > Some of us think that having the glusto based test cases in the
>>> >> > gluster-block repo instead of glusto-tests repo would be easier for
>>> >> > developers to test their changes locally. In this way, we don't
>>> have to deal
>>> >> > with two repos for testing the changes every time.
>>> >> > What are your suggestions and is it okay to go with this approach?
>>> >> >
>>> >> > Thanks,
>>> >> > Bhumika
>>> >
>>> >
>>>
>>
>>

-- 
nigelb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/automated-testing/attachments/20180702/196981ec/attachment.html>