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@xxxxxxxxx> wrote: > > > On Wed, Mar 9, 2016 at 7:02 PM, M S Vishwanath Bhat <msvbhat@xxxxxxxxx> > > 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. > > 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@xxxxxxxxxxx > > > http://www.gluster.org/mailman/listinfo/gluster-devel > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
