[Gluster-devel] Jenkins success/failure with *BSD thought
Interestingly, we'll probably need to do something a bit smarter with the regression testing SUCCESS/FAILURE status, for cases like this: http://review.gluster.org/#/c/8380/ For that CR, the FreeBSD smoke test failed, but the later running regression test passed and marked the whole thing as SUCCESS. I'm thinking the regression test pass failure logic (at the end of the testing scripting), should probably query the result of the smoke tests, and if they failed then not reset that. Anyone have better ideas/suggestions? :) + Justin -- 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] NetBSD and FreeBSD smoke tests are enabled
On 28/07/2014, at 1:34 PM, Emmanuel Dreyfus wrote: On Mon, Jul 28, 2014 at 01:13:42PM +0100, Justin Clift wrote: Just a heads up. The NetBSD and FreeBSD smoke tests have been enabled for (at least) the release-3.6 and master branches. FreeBSD does not seems to be ready for prime time. I get build errors completely unrelated to my changes: http://build.gluster.org/job/freebsd-smoke/25/console Thanks for the heads up. I've disabled voting for it now. It'll still run (and fail) on Gerrit submittions, but won't affect pass/failure results. Hopefully Harsha has time to investigate this tonight. :) NetBSD builds master, but I am not sure NetBSD build release-3.6 right now, as I have not yet pulled up the latest fixes for it. I will give it a try and report, but in the meantime I will disable it for release-3.6 Cool. :) + Justin -- 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] Jenkins success/failure with *BSD thought
On 07/28/2014 08:33 AM, Justin Clift wrote: Interestingly, we'll probably need to do something a bit smarter with the regression testing SUCCESS/FAILURE status, for cases like this: http://review.gluster.org/#/c/8380/ For that CR, the FreeBSD smoke test failed, but the later running regression test passed and marked the whole thing as SUCCESS. I'm thinking the regression test pass failure logic (at the end of the testing scripting), should probably query the result of the smoke tests, and if they failed then not reset that. Anyone have better ideas/suggestions? :) I've been meaning to ask (or suggest) this for some time To me a smoke test should be a simple compile and run the executable(s) to make sure they don't crash with the most basic configuration. I think the posix tests that are in smoke.sh today should really be part of the regression test, e.g. .../basic/posix.t For one thing it'd make the smoke.sh run faster. -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD and FreeBSD smoke tests are enabled
On Mon, Jul 28, 2014 at 01:38:04PM +0100, Justin Clift wrote: FreeBSD does not seems to be ready for prime time. I get build errors completely unrelated to my changes: http://build.gluster.org/job/freebsd-smoke/25/console Thanks for the heads up. I've disabled voting for it now. It'll still run (and fail) on Gerrit submittions, but won't affect pass/failure results. It would be nice to restart anyone that failed for it inthe meantime. (Am I alone?) NetBSD builds master, but I am not sure NetBSD build release-3.6 right now, as I have not yet pulled up the latest fixes for it. I will give it a try and report, but in the meantime I will disable it for release-3.6 I confirm it is broken for branch-3.6, and I do not find how to disable it for reelase-3.6 but not master. -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD and FreeBSD smoke tests are enabled
On 28/07/2014, at 1:40 PM, Emmanuel Dreyfus wrote: On Mon, Jul 28, 2014 at 01:38:04PM +0100, Justin Clift wrote: FreeBSD does not seems to be ready for prime time. I get build errors completely unrelated to my changes: http://build.gluster.org/job/freebsd-smoke/25/console Thanks for the heads up. I've disabled voting for it now. It'll still run (and fail) on Gerrit submittions, but won't affect pass/failure results. It would be nice to restart anyone that failed for it inthe meantime. (Am I alone?) I'm actually not sure how to do this. I _think_ it'll need the affected CR's to have a new patch revision uploaded, or have their commit message changed, so things get triggered again. NetBSD builds master, but I am not sure NetBSD build release-3.6 right now, as I have not yet pulled up the latest fixes for it. I will give it a try and report, but in the meantime I will disable it for release-3.6 I confirm it is broken for branch-3.6, and I do not find how to disable it for reelase-3.6 but not master. Emailed you the details. :) + Justin -- 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] NetBSD and FreeBSD smoke tests are enabled
On Mon, Jul 28, 2014 at 12:34:50PM +, Emmanuel Dreyfus wrote: NetBSD builds master, but I am not sure NetBSD build release-3.6 right now, as I have not yet pulled up the latest fixes for it. I will give it a try and report, but in the meantime I will disable it for release-3.6 release-3.6 build for NetBSD with this: http://review.gluster.com/8381 Once it is merged, we can re-enable NetBSD/rlease-3.6 release-3.5 builds for NetBSD fine. -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] NetBSD and FreeBSD smoke tests are enabled
On Mon, Jul 28, 2014 at 8:15 AM, Emmanuel Dreyfus m...@netbsd.org wrote: On Mon, Jul 28, 2014 at 01:13:42PM +0100, Justin Clift wrote: Just a heads up. The NetBSD and FreeBSD smoke tests have been enabled for (at least) the release-3.6 and master branches. release-3.6 did not build for NetBSD. Someone please merge that one so that we can enable NetBSD voltiing for release-3.6: http://review.gluster.com/8381 FreeBSD can only be enabled after we merge - http://review.gluster.com/#/c/8246/ -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Jenkins success/failure with *BSD thought
I've been meaning to ask (or suggest) this for some time To me a smoke test should be a simple compile and run the executable(s) to make sure they don't crash with the most basic configuration. I think the posix tests that are in smoke.sh today should really be part of the regression test, e.g. .../basic/posix.t This is an issue only now since regression testing was automated, we could move all the tests together. All of them are done simultaneously - failures among any of them gets NACK on jenkins. We have to test it though, do not know how much we can configure Jenkins this way. -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Reuse of frame?
Is it true that different fops will always have a different frame (i.e. different frame pointer) as seen in the translator stack? I've always thought this to be true, but it seems that with the release-3.6.0 branch the two quick getxattr syscalls that the getfattr cli command calls share the same frame pointer. This is causing havoc with a translator of mine, and I was wondering if this was a bug, or expected behaviour. Thanks, Matt -- Matthew McKeen matt...@mmckeen.net ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Reuse of frame?
call frames and stacks are re-used from a mem-pool. So pointers might repeat. Can you describe your use case a little more in detail, just to be sure? On Mon, Jul 28, 2014 at 11:27 AM, Matthew McKeen matt...@mmckeen.net wrote: Is it true that different fops will always have a different frame (i.e. different frame pointer) as seen in the translator stack? I've always thought this to be true, but it seems that with the release-3.6.0 branch the two quick getxattr syscalls that the getfattr cli command calls share the same frame pointer. This is causing havoc with a translator of mine, and I was wondering if this was a bug, or expected behaviour. Thanks, Matt -- Matthew McKeen matt...@mmckeen.net ___ 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] Reuse of frame?
Does your code wait for both clients to unwind so that it merges the two replies before it unwinds itself? You typically would need to keep a call count (# of winds) and wait for that many _cbk invocations before calling STACK_UNWIND yourself. If you are not waiting for both replies, it is possible that the frame pointer got re-used for second call before second callback of first call arrived. On Mon, Jul 28, 2014 at 12:32 PM, Matthew McKeen matt...@mmckeen.net wrote: I have a translator on the client stack. For a particular getxattr I wind the stack to call two client translator getxattr fops. The callback for these fops is the same function in the original translator. The getfattr cli command calls two getxattr syscalls in rapid succession so that I see the callback being hit 4 times, and the original getxattr forward fop 2 times. For both the 4 callbacks and 2 forward fops the frame pointer for the translator is the same. Therefore, when I try and store a pointer to a dict in frame-local, the dict pointer points to the same dict for both fops and data set into the dict with the same keys ends up overwriting the values from the previous fop. On Mon, Jul 28, 2014 at 12:19 PM, Anand Avati av...@gluster.org wrote: call frames and stacks are re-used from a mem-pool. So pointers might repeat. Can you describe your use case a little more in detail, just to be sure? On Mon, Jul 28, 2014 at 11:27 AM, Matthew McKeen matt...@mmckeen.net wrote: Is it true that different fops will always have a different frame (i.e. different frame pointer) as seen in the translator stack? I've always thought this to be true, but it seems that with the release-3.6.0 branch the two quick getxattr syscalls that the getfattr cli command calls share the same frame pointer. This is causing havoc with a translator of mine, and I was wondering if this was a bug, or expected behaviour. Thanks, Matt -- Matthew McKeen matt...@mmckeen.net ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel -- Matthew McKeen matt...@mmckeen.net -- Matthew McKeen matt...@mmckeen.net ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
