[Gluster-devel] Location of distaf tests

Thu Mar 24 06:35:29 UTC 2016

On Wed, Mar 23, 2016 at 9:56 PM, M S Vishwanath Bhat <msvbhat at gmail.com>
wrote:

>
>
> On 18 March 2016 at 02:47, Jonathan Holloway <jholloway at redhat.com> wrote:
>
>>
>>
>> ------------------------------
>>
>> *From: *"M S Vishwanath Bhat" <msvbhat at gmail.com>
>> *To: *"Niels de Vos" <ndevos at redhat.com>
>> *Cc: *"Gluster Devel" <gluster-devel at gluster.org>
>> *Sent: *Thursday, March 17, 2016 8:18:23 AM
>> *Subject: *Re: [Gluster-devel] Location of distaf tests
>>
>>
>>
>>
>> On 17 March 2016 at 10:50, Niels de Vos <ndevos at redhat.com> wrote:
>>
>>> On Wed, Mar 09, 2016 at 08:26:44PM +0530, M S Vishwanath Bhat wrote:
>>> > On 9 March 2016 at 19:39, Kaushal M <kshlmster at gmail.com> wrote:
>>> >
>>> > > On Wed, Mar 9, 2016 at 7:02 PM, M S Vishwanath Bhat <
>>> msvbhat at gmail.com>
>>> > > wrote:
>>> > > > Hi,
>>> > > >
>>> > > > When we were discussing about the readiness of distaf for upstream
>>> test
>>> > > > automation, this question came up, That we should have a process or
>>> > > workflow
>>> > > > for proposing, reviewing and including the tests somewhere.
>>> > > >
>>> > > > Right now the tests are part of distaf repository
>>> > > > (github.com/gluster/distaf) itself. And contributing to distaf is
>>> by
>>> > > sending
>>> > > > a PR. But we want this to be included in gerrit so that review and
>>> > > > contributing process becomes much easier. But the question still
>>> > > remains...
>>> > > > where? Right now I can think of below options.
>>> > > >
>>> > > > * Use the same distaf repo in github for tests as well.
>>> > > > * Create a separate repo distaf_gluster_tests (or something
>>> similar) and
>>> > > > have all the tests there.
>>> > > > * Or have a tests/distaf/ directory inside glusterfs repository.
>>> And this
>>> > > > tests can be bundled in a rpm and distributed. This directory will
>>> have
>>> > > both
>>> > > > the test cases and related library functions.
>>> > >
>>> > > I prefer this approach. It makes it easier for developers to submit
>>> > > tests along with their changes, as is the case with our regression
>>> > > tests now.
>>> > >
>>> > > By library functions, I'm assuming you mean helper libraries related
>>> > > to gluster, which will be used in the tests which will be written.
>>> > >
>>> >
>>> > Yes, I mean helper functions which are related to gluster. The
>>> framework
>>> > itself will be  made a python package. At least that's the plan.
>>>
>>> +1 for the tests in tests/distaf/ . I think I would like the libs to be
>>> part of the main distaf project. That would make it easier to run distaf
>>> for other projects that integrate with Gluster (like Samba,
>>> NFS-Ganesha and the like). The upstream projects can that use distaf for
>>> their integration with Gluster if they choose so.
>>>
>>
>> My concern with having libs in main distaf project is that, libs and test
>> cases are very much tied together. So when someone writes a testcase, they
>> write and/or modify the related gluster libs along with it. And the one
>> needs to go back and forth between the testcase and gluster libs while
>> writing and debugging the case. If they are in separate repo/package, it
>> makes it bit difficult (not impossible) for test case writer.
>>
>> If everyone is of the same opinion that gluster libs should be part of
>> main distaf repo, I can still do it when I package it next week.
>>
>>
>> I'm now thinking we should go ahead and keep it three distinct projects:
>> - Gluster: testcase--and supporting functions that are not a good fit for
>> the libs
>> - distaf-libs-gluster: core libarary and utility functions
>> - distaf: framework only
>>
>
> But that (having more than one repo) kind of  defeats the purpose of
> developers having to concern themselves with only single repo
> (glusterfs.git). Since I couldn't discuss this in weekly gluster meeting in
> #gluster-meeting, let me propose my solution here.
>

This proposal from Jonathan of 3 repos is what I like the best for long
term.

>
> Library functions and test cases both go into a subdirectory inside
> glusterfs.git. This helps for devs and people writing test case for
> gluster. And we find a way to sync the libraries to distaf.git, so that
> each time a package is made, it is available for integrating projects to
> make use of. I know this is not very elegant way of dealing with the
> problem, but I couldn't think of anything which would fit all requirements.
>

If you think distaf-libs-gluster can have more improvements and it makes
sense to have them with tests for now; we can have 2 repos temporarily
1. Gluster git has tests + distaf-libs-gluster ( We can even avoid
packaging these two for now. Just let them be part of Gluster repo. )
2. distaf repo has distaf framework only

>
> Jonathan, Niels, Kaushal, Raghavendra Talur - Your thoughts?
>
> Best Regards,
> Vishwanath
>
>
>> Here's some of my reasoning...
>> - We're already talking about not putting the libs in the Gluster repo as
>> an option, so from a convenience perspective it's not as relevant which
>> repo is being used (distaf or distaf-gluster-libs).
>> - And if we're already talking about the possibility of a refactor to
>> split the libs out down the road, it's not much different to talk refactor
>> to roll the libs into the distaf project should they become a problem to
>> maintain.
>> - With that said, if looking to have distaf adopted by a wider
>> non-Gluster audience, we'll want to split the libs out down the road
>> anyway. It would also lay the foundation for others
>> (distaf-libs-<your-project-here>).
>> - The Maintainer/Reviewer/Contributor demographic isn't necessarily the
>> same across all three and the Maintainer/Reviewer will most likely play a
>> larger role initially as we build out the libs and figure out what goes
>> where, what works, etc.
>>         I'm just thinking it would be easier to manage that separately in
>> the beginning.
>> - If we are including the libs in the distaf project, how will the libs
>> be consumed? Roll them in the distaf package? Separate package? Git clone
>> and setup.py?
>>         I like the concept of separate distaf and distaf-libs-gluster
>> packages that can be versioned and maintained separately. It keeps them
>> flexible and clean/clear of each other, and any framework changes that are
>> required by a library change can be managed through the packaging.
>>         We can still do that if the libs are in the same repo, but in my
>> opinion it's not as clean and the value add in having them combined is
>> minimal.
>> - It shouldn't take that long to create the new project and may save us
>> some inevitable headache down the road.
>>
>> Either way, I agree with Niels that the sooner the better--so if a
>> separate repo for distaf-libs-gluster would create an unacceptable delay,
>> rolling libs into the distaf project works for me.
>>
>> Cheers,
>> Jonathan
>>
>> Best Regards,
>> Vishwanath
>>
>>>
>>> > > I'm also in favor of including them here as well. This will help keep
>>> > > DiSTAF free of an Gluster specific cruft and allow it to be
>>> (possibly)
>>> > > reusable by others.
>>> > >
>>> >
>>> > The recent changes makes it specific to gluster, but very easy to make
>>> it
>>> > generic.
>>>
>>> Starting Gluster specific is fine, later on when things are in use and
>>> working the way we need it should be trivial to make it more generic.
>>> Just keep a generic way for adding new functionalities for now, and file
>>> issues in GitHub for the parts that need to get refactored.
>>>
>>> The sooner we can start using distaf and gain (more) real world
>>> experience the better.
>>>
>>> Thanks,
>>> Niels
>>>
>>>
>>> > Best Regards,
>>> > Vishwanath
>>> >
>>> >
>>> > >
>>> > > >
>>> > > > Please let us know what your preferred option is. If you have any
>>> other
>>> > > > ideas, please let us know as well.
>>> > > >
>>> > > > Best Regards,
>>> > > > Vishwanath
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > Gluster-devel mailing list
>>> > > > Gluster-devel at gluster.org
>>> > > > http://www.gluster.org/mailman/listinfo/gluster-devel
>>> > >
>>>
>>> > _______________________________________________
>>> > Gluster-devel mailing list
>>> > Gluster-devel at gluster.org
>>> > http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160324/f6051753/attachment-0001.html>