Re: [Gluster-infra] [Gluster-Maintainers] Request to provide PASS flags to a patch in gerrit
+1 regards Aravinda On Wednesday 31 August 2016 04:23 PM, Raghavendra Talur wrote: Hi All, We have a test [1] which is causing hangs in NetBSD. We have not been able to debug the issue yet. It could be because the bash script does not comply with posix guidelines or that there is a bug in the brick code. However, as we have 3.9 merge deadline tomorrow this is causing the test pipeline to grow a lot and needing manual intervention. I recommend we disable this test for now. I request Kaushal to provide pass flags to the patch [2] for faster merge. [1] ./tests/features/lock_revocation.t [2] http://review.gluster.org/#/c/15374/ Thanks, Raghavendra Talur ___ maintainers mailing list maintain...@gluster.org http://www.gluster.org/mailman/listinfo/maintainers ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] centos builds are not getting triggered
Hi, Looks like centos builds are not getting triggered. Please look into this https://build.gluster.org/job/rackspace-regression-2GB-triggered/ -- regards Aravinda ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Please install Golang in all build machines
Thanks. We can skip the package "golang-github-gorilla-handlers-devel" now. I will modify my patch not to use this package. regards Aravinda On 04/19/2016 03:47 PM, Michael Scherer wrote: Le mardi 19 avril 2016 à 12:05 +0200, Michael Scherer a écrit : Le mardi 19 avril 2016 à 15:08 +0530, Aravinda a écrit : Enclosed patch for installing required packages. Patch is good, but there is no golang-github-gorilla-handlers-devel in EPEL for now :/ Is this the same as golang-github-gorilla-handlers ? Ok so the package is in testing: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8108 IE, someone need to make it go to stable. (which is then missing in epel 7, so another issue coming later) regards Aravinda On 04/18/2016 02:27 PM, Michael Scherer wrote: Le mardi 12 avril 2016 à 16:00 +0530, Aravinda a écrit : Hi, REST API Server and Eventing implementation requires Golang to build. Added "BuildRequires: golang" in spec file but smoke tests are failing. # https://build.gluster.org/job/glusterfs-devrpms-el6/15169/console checking for go... no configure: error: pass --disable-restapi to build without golang. exiting.. + exit 1 Patch: http://review.gluster.org/#/c/13977/ Please install golang in build machines. So this raise a few questions: - any version of golang - build machine for all arch/os ? Also, people can also send patch on https://github.com/gluster/gluster.org_ansible_configuration/blob/master/roles/jenkins_builder/tasks/pkgs.yml (patch by mail on this list, no PR on github) ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Please install Golang in all build machines
Enclosed patch for installing required packages. regards Aravinda On 04/18/2016 02:27 PM, Michael Scherer wrote: Le mardi 12 avril 2016 à 16:00 +0530, Aravinda a écrit : Hi, REST API Server and Eventing implementation requires Golang to build. Added "BuildRequires: golang" in spec file but smoke tests are failing. # https://build.gluster.org/job/glusterfs-devrpms-el6/15169/console checking for go... no configure: error: pass --disable-restapi to build without golang. exiting.. + exit 1 Patch: http://review.gluster.org/#/c/13977/ Please install golang in build machines. So this raise a few questions: - any version of golang - build machine for all arch/os ? Also, people can also send patch on https://github.com/gluster/gluster.org_ansible_configuration/blob/master/roles/jenkins_builder/tasks/pkgs.yml (patch by mail on this list, no PR on github) >From 42c015c5cdeaa4368381cb95cde432f60d2e4fb8 Mon Sep 17 00:00:00 2001 From: Aravinda VK Date: Tue, 19 Apr 2016 15:05:54 +0530 Subject: [PATCH] New dependent packages for REST APIs and Eventing Project Following packages added to Linux - golang - golang-github-gorilla-mux-devel - golang-github-gorilla-handlers-devel - golang-github-gorilla-websocket-devel - golang-github-dgrijalva-jwt-go-devel - golang-github-Sirupsen-logrus-devel Signed-off-by: Aravinda VK --- roles/jenkins_builder/tasks/pkgs.yml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/roles/jenkins_builder/tasks/pkgs.yml b/roles/jenkins_builder/tasks/pkgs.yml index 73ce302..db9f9be 100644 --- a/roles/jenkins_builder/tasks/pkgs.yml +++ b/roles/jenkins_builder/tasks/pkgs.yml @@ -33,6 +33,13 @@ - librdmacm-devel - libaio-devel - clang-analyzer + # needed for REST APIs and Eventing + - golang + - golang-github-gorilla-mux-devel + - golang-github-gorilla-handlers-devel + - golang-github-gorilla-websocket-devel + - golang-github-dgrijalva-jwt-go-devel + - golang-github-Sirupsen-logrus-devel - package: state=present name={{ item }} name: Install jenkins builder FreeBSD packages -- 2.5.5 ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Please install Golang in all build machines
Hi, REST API Server and Eventing implementation requires Golang to build. Added "BuildRequires: golang" in spec file but smoke tests are failing. # https://build.gluster.org/job/glusterfs-devrpms-el6/15169/console checking for go... no configure: error: pass --disable-restapi to build without golang. exiting.. + exit 1 Patch: http://review.gluster.org/#/c/13977/ Please install golang in build machines. -- regards Aravinda ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Request for project creation under Gluster organization(github)
regards Aravinda On 02/11/2016 02:04 PM, Michael Scherer wrote: Le jeudi 11 février 2016 à 14:02 +0530, Aravinda a écrit : Hi, Please create following projects under Gluster organization in github.com glustertool - Tools infrastructure for adding more tools for Gluster https://github.com/aravindavk/glustertool glusterrest - REST API server for Gluster Management and Events. Design: http://review.gluster.org/13214 and http://review.gluster.org/13115 Let me know if I need to provide any additional details. Thanks. We usually need to know who should be allowed to commit. My github account aravindavk (https://github.com/aravindavk) We still have IMHO too much team on github :/ ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Request for project creation under Gluster organization(github)
Hi, Please create following projects under Gluster organization in github.com glustertool - Tools infrastructure for adding more tools for Gluster https://github.com/aravindavk/glustertool glusterrest - REST API server for Gluster Management and Events. Design: http://review.gluster.org/13214 and http://review.gluster.org/13115 Let me know if I need to provide any additional details. Thanks. -- regards Aravinda ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-devel] Code-Review+2 and Verified+1 cause multiple retriggers on Jenkins
How about "AuthorVerified+1" instead of any "Verified+1"? regards Aravinda On 02/04/2016 03:34 PM, Raghavendra Talur wrote: Hi, We recently changed the jenkins builds to be triggered on the following triggers. 1. Verified+1 2. Code-review+2 3. recheck (netbsd|centos|smoke) There is a bug in 1 and 2. Multiple triggers of 1 or 2 would result in re-runs even when not intended. I would like to replace 1 and 2 with a comment "run-all-regression" or something like that. Thoughts? Thanks Raghavendra Talur ___ Gluster-devel mailing list gluster-de...@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-devel] Reduce regression runs wait time - New gerrit/review work flow
+1 for running regressions on need basis. Also we need to make the tests more intelligent so that same tests runs differently when triggered nightly/regular. function test_some_functionality { if env.NIGHTLY { # run nightly tests # time consuming tests # test with more data run_nightly_tests(); } # Regular basic tests run_basic_tests(); } TEST test_some_functionality; This way we can maintain all tests in single place. Set env/config variable as NIGHTLY whenever we need to run nightly tests. -- regards Aravinda On 06/15/2015 06:49 AM, Kaushal M wrote: Hi all, The recent rush of reviews being sent due to the release of 3.7 was a cause of frustration for many of us because of the regression tests (gerrit troubles themselves are another thing). W.R.T regression 3 main sources of frustration were, 1. Spurious test failures 2. Long wait times 3. Regression slave troubles We've already tackled the spurious failure issue and are quite stable now. The trouble with the slave vms is related to the gerrit issues, and is mainly due to the network issues we are having between the data-centers hosting the slaves and gerrit/jenkins. People have been looking into this, but we haven't had much success. This leaves the issue of the long wait times. The long wait times are because of the long queues of pending jobs, some of which take days to get scheduled. Two things cause the long queues, 1. Automatic regression job triggering for all submissions to gerrit 2. Long run time for regression (~2h) The long queues coupled with the spurious failure and network problems, meant that jobs would fail for no reason after a long wait, and would have to be added to the back of the queue to be re-run. This meant that developers would have to wait days for their changes to get merged, and was one of the causes for the delay in the release of 3.7. The solution reduce wait times for regression runs. To reduce wait times we should, 1. Trigger runs only when required 2. Reduce regression run time. Raghavendra Talur (rtalur/RaSTar) will soon send out a mail with his findings on the regression run times, and we can continue discussion on it on that thread. Earlier, the regression runs used to be manually triggered by the maintainers once they had determined that a change was ready for submission. But as there were only two maintainers before (Vijay and Avati) auto triggering was brought in to reduce their load. Auto triggering worked fine when we had a lower volume of changes being submitted to gerrit. But now, with the large volumes we see during the release freeze dates, auto triggering just adds to problems. I propose that we move back to the old model of starting regression runs only once the maintainers are ready to merge. But instead of the maintainers manually tiggering the runs, we could automate it. We can model our new workflow on those of OpenStack[1] and Wikimedia[2]. The existing Gerrit plugin for Jenkins doesn't provide the features necessary to enable selective triggering based on Gerrit flags. Both OpenStack and Wikimedia use a project gating tool called Zuul[3], which provides a much better integration with Jenkins and Gerrit and more features on top. I propose the following work flow, - Developer pushes change to Gerrit. - Zuul is notified by Gerrit of new change - Zuul runs pre-review checks on Jenkins. This will be the current smoke tests. - Zuul reports back status of the checks to Gerrit. - If checks fail, developer will need to resend the change after the required fixes. The process starts once more. - If the checks pass, the change is now ready for review - The change is now reviewed by other developers and maintainers. Non-maintainers will be able to give only a +1 review. - On a negative review, the developer will need to rework the change and resend it. The process starts once more. - The maintainer give a +2 review once he/she is satisfied. The maintainers work is done here. - Zuul is notified of the +2 review - Zuul runs the regression runs and reports back the status. - If the regression runs fail, the process starts over again. - If the runs pass, the change is ready for acceptance. - Zuul will pick the change into the repository. - If the pick fails, Zuul will report back the failure, and the process starts once again. Following this flow should, 1. Reduce regression wait time 2. Improve change acceptance time 3. Reduce unnecessary wastage of infra resources 4. Improve infra stability. It also brings in drawbacks that we need to maintain one other piece of infra (Zuul). This would be an additional maintenance overhead on top of Gerrit, Jenkins and the current slaves. But I feel the reduction in the upkeep efforts of the slaves would be enough to offset this. tl;dr Current auto-triggering of regression runs is stupid and a waste of time and resources. Bring in a project gating system, Zuul,
Re: [Gluster-infra] [Gluster-devel] Gerrit and Jenkins likely unavailable most of Sunday
Is it not possible to view the patches if not logged in? I think public access(read only) need to be enabled. ~aravinda On 04/20/2015 08:35 AM, Vijay Bellur wrote: On 04/20/2015 04:25 AM, Justin Clift wrote: The good news: 1) Gerrit is kind of :/ updated. The very very latest versions (released friday) don't work properly for us. So, we're running on the slightly older v2.9.4 release of Gerrit. It's a lot newer than what we were running though. ;) 2) The GitHub integration seems to be working. When you next to to http://review.gluster.org, it'll get you to authenticate via GitHub. The bad news: 1) The first time you authenticate to GitHub it will create a brand new account for you, that doesn't have many useful permissions. You will need to email Vijay, Humble, or myself with the account number it creates for you + with your GitHub username. Your account number will probably be something like 10006xx. Mine was 1000668. This new account id needs to be merged into your existing one manually by a Gerrit admin. It's not hard, and only needs to be done once. :) The procedure for migration from an admin perspective is quite involved and account migrations are better done in batches. Instead of mailing any of us directly, can you please update the gerrit migration etherpad [1] once you have signed in using github? This might be a slightly more optimal way of doing this migration :). We will pick up details from the etherpad at a regular frequency. Thanks for taking the trouble & apologies for any inconvenience caused in advance! Regards, Vijay [1] https://public.pad.fsfe.org/p/gluster-gerrit-migration ___ Gluster-devel mailing list gluster-de...@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra