[Gluster-devel] Location of distaf tests

Thu Mar 17 21:17:35 UTC 2016

----- Original Message -----

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: 

<blockquote>

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. 

</blockquote>

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 

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 

<blockquote>

Best Regards, 
Vishwanath 

<blockquote>

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

</blockquote>

_______________________________________________ 
Gluster-devel mailing list 
Gluster-devel at gluster.org 
http://www.gluster.org/mailman/listinfo/gluster-devel 
</blockquote>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160317/fe220b8a/attachment.html>