On 18 March 2016 at 02:47, Jonathan Holloway <[email protected]> wrote:
> > > ------------------------------ > > *From: *"M S Vishwanath Bhat" <[email protected]> > *To: *"Niels de Vos" <[email protected]> > *Cc: *"Gluster Devel" <[email protected]> > *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 <[email protected]> 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 <[email protected]> wrote: >> > >> > > On Wed, Mar 9, 2016 at 7:02 PM, M S Vishwanath Bhat < >> [email protected]> >> > > 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 >> > > > [email protected] >> > > > http://www.gluster.org/mailman/listinfo/gluster-devel >> > > >> >> > _______________________________________________ >> > Gluster-devel mailing list >> > [email protected] >> > http://www.gluster.org/mailman/listinfo/gluster-devel >> >> > > _______________________________________________ > Gluster-devel mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-devel > > >
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
