[Gluster-devel] Location of distaf tests

Wed Mar 23 16:26:27 UTC 2016

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.

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.

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/20160323/9a6e19b3/attachment-0001.html>