Re: [Gluster-devel] IMPORTANT - Adding further volume types to our smoke tests
Hi Pranith, On 11/13/2014 06:57 AM, Pranith Kumar Karampuri wrote: On 11/13/2014 03:23 AM, Justin Clift wrote: Hi all, At the moment, our smoke tests in Jenkins only run on a replicated volume. Extending that out to other volume types should (in theory :) help catch other simple gotchas. Xavi has put together a patch for doing just this, which I'd like to apply and get us running: https://forge.gluster.org/gluster-patch-acceptance-tests/gluster-patch-acceptance-tests/merge_requests/4 What are people's thoughts on the general idea, and on the above proposed patch? (The Forge isn't using Gerrit, so review/comments back here please :) This is good initiative. How about doing this tests with different backend filesystems as well? like ext4 and btrfs? That could be done, but we need to be sure that the number of combinations doesn't grow much or the total execution time will grow exponentially. Pranith Regards and best wishes, Justin Clift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] IMPORTANT - Adding further volume types to our smoke tests
On 11/13/2014 10:13 AM, Pranith Kumar Karampuri wrote: On 11/13/2014 03:51 AM, Jeff Darcy wrote: On the other hand, I'm not sure smoke is the place to do this. Smoke is supposed to be a *quick* test to catch *basic* errors (e.g. source fails to build) before we devote hours to a full regression test. How much does this change throughput on the smoke-test queue? Should we be doing this in regression instead, or in a third testing tier between the two we have? That makes sense. Should we have daily regression runs which will contain a lot more things that need to be tested on a regular basis? Running regressions per disk fs type is something that we need to do. We can improve them going forward with long running tests like disk replacement tests/ Rebalance, geo-rep tests etc. Let me know your thoughts on this. The problem I see with this approach is how to detect problems before merging them to the main branch. Is it possible to automatically merge multiple patches in a test branch, run the tests on it and don't allow merging each individual patch into master branch until these tests pass ? this could allow daily executions but a single buggy patch will delay the merge of many others. Xavi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] IMPORTANT - Adding further volume types to our smoke tests
Hi all, At the moment, our smoke tests in Jenkins only run on a replicated volume. Extending that out to other volume types should (in theory :) help catch other simple gotchas. Xavi has put together a patch for doing just this, which I'd like to apply and get us running: https://forge.gluster.org/gluster-patch-acceptance-tests/gluster-patch-acceptance-tests/merge_requests/4 What are people's thoughts on the general idea, and on the above proposed patch? (The Forge isn't using Gerrit, so review/comments back here please :) Regards and best wishes, Justin Clift -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] IMPORTANT - Adding further volume types to our smoke tests
\ At the moment, our smoke tests in Jenkins only run on a replicated volume. Extending that out to other volume types should (in theory :) help catch other simple gotchas. Xavi has put together a patch for doing just this, which I'd like to apply and get us running: https://forge.gluster.org/gluster-patch-acceptance-tests/gluster-patch-acceptance-tests/merge_requests/4 What are people's thoughts on the general idea, and on the above proposed patch? (The Forge isn't using Gerrit, so review/comments back here please :) I'm ambivalent. On the one hand, I think this is an important step in the right direction. Sometimes we need to be able to run *all* of our existing tests with some feature enabled, not just a few feature-specific tests. SSL is an example of this, and transport (or other forms of) multi-threading will be as well. On the other hand, I'm not sure smoke is the place to do this. Smoke is supposed to be a *quick* test to catch *basic* errors (e.g. source fails to build) before we devote hours to a full regression test. How much does this change throughput on the smoke-test queue? Should we be doing this in regression instead, or in a third testing tier between the two we have? My gut feel is that we need to think more about how to run a matrix of M tests across N configurations, instead of just putting feature/regression tests and configuration tests into one big bucket. Or maybe that's a longer-term thing. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] IMPORTANT - Adding further volume types to our smoke tests
On 11/13/2014 03:23 AM, Justin Clift wrote: Hi all, At the moment, our smoke tests in Jenkins only run on a replicated volume. Extending that out to other volume types should (in theory :) help catch other simple gotchas. Xavi has put together a patch for doing just this, which I'd like to apply and get us running: https://forge.gluster.org/gluster-patch-acceptance-tests/gluster-patch-acceptance-tests/merge_requests/4 What are people's thoughts on the general idea, and on the above proposed patch? (The Forge isn't using Gerrit, so review/comments back here please :) This is good initiative. How about doing this tests with different backend filesystems as well? like ext4 and btrfs? Pranith Regards and best wishes, Justin Clift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
