https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3690 Lustre <p>We use gerrit differently than it expects by default. Most importantly, there are two conditions that signal that a patch is done code review and can be sent to the Gate Keeper for landing:</p> <ul> <li>A +2 CodeReview<br/> OR</li> <li>2 or more +1 CodeReviews</li> </ul> <p>Unfortunately, there is currently no way to create a reliable positive or negative pattern to match that second condition. That makes it inpossible to create good filters that provide the following useful lists of patches:</p> <ul> <li>Patches that are fully reviewed and waiting for landing</li> <li>Patches that are awaiting further review</li> </ul> <p>On the CDWG mailing list Denis Kondratenko provided a couple of great links that talk about possible solutions for this very problem:</p> <ul> <li><a href="http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review" class="external-link" target="_blank" rel="nofollow noopener">http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review</a> (A hook could - for instance - allow a project to install an automated gatekeeper to vote +2 'submit approved' when sufficient +1 votes 'looks good to me' have been received)</li> <li><a href="http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12_1_1_2_code_review" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/Documentation/prolog-cookbook.html#_example_12_1_1_2_code_review</a> (but I don't know if it will get right searches..)</li> </ul> LU-3690

Improve gerrit reporting of patch status

Task Minor Resolved Not a Bug Peter Jones Christopher Morrone Fri, 2 Aug 2013 22:21:15 +0000 Thu, 30 Oct 2014 14:34:46 +0000 Thu, 26 Jun 2014 23:29:15 +0000 0 11 <p>Thanks Chris.</p> <p>Actually building prolog rule will not give us possibility to search for the submittable reviews. It will just allow user with submittable right to submit without review.</p> <p>I have checked another way to build correct search for issues or check their stages automatically - REST API. It is supported now by Gerrit 2.5.4, but provides very few data to analyze (and couldn't be used for searches).</p> <p>With Gerrit 2.6 REST API was improved a lot and there even "submittable" field there, so with that we could build scripts that will provide right searches for us.<br/> More than that 2.6 provides huge number of other details, that possibly could be used to detect different stages of review to build scripts to gather stat - where we spend most of the time and where to improve. And maybe better tool to get some notification for people that are responsible for review now (ping developers that ball on their side for example).</p> <p><a href="http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html#_rest_api" class="external-link" target="_blank" rel="nofollow noopener">http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html#_rest_api</a></p> <p>So maybe just updating to 2.6 will give us API that could resolve a lot of our issues for now.</p> <p>Chris, Peter,</p> <p>there was sbj in our discussion about how simple script for gerrit could looks like and what it could do.</p> <p>In attachment there is example. It has some minor issues, but could give you overall idea.</p> <p>BTW, it would be cool to have Intel servers support <a href="https://en.wikipedia.org/wiki/Cross-origin_resource_sharing" class="external-link" target="_blank" rel="nofollow noopener">CORS </a>. I don't really understand where it should be supported (by apache or gerrit), but I think IT guys could know. That feature could do scripts like in attachment to be interactive instead of static.</p> <p>One possibility that I think would be easy to implement (and also avoids the need to upgrade) is to only have Hudson/Jenkins mark the patch Verified -1 if it fails to build, but NOT add a Verified +1 if the build succeeds.</p> <p>That leaves +1 open for Maloo test results and ensures that Gerrit queries for Verified = +1 only return patches that have actually passed testing instead of patches that have merely been built. </p> <p>This could also be done (inelegantly) via a script that leverages Gerrit's ssh API. Using say:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>ssh -p 29418 review.whamcloud.com gerrit query --all-approvals --format=JSON status:open limit:100 </pre> </div></div> <p>Or human readably:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>ssh -p 29418 review.whamcloud.com gerrit query --all-approvals status:open limit:100 ... change I6e2837953902520240e9ceb251c92329d328d715 project: fs/lustre-release branch: master id: I6e2837953902520240e9ceb251c92329d328d715 number: 7803 subject: LU-1345 cleanup: C89 and build cleanups owner: name: Alexey Lyashkov email: alexey_lyashkov@xyratex.com username: shadow url: http://review.whamcloud.com/7803 createdOn: 2013-09-30 10:48:59 UTC lastUpdated: 2013-10-17 22:39:35 UTC sortKey: 00287e8f00001e7b open: true status: NEW patchSets: number: 1 revision: 3e4dd4324536fbeaba06049a80ac131cd1fe2cd2 parents: [92b43047fdfd1a61e200726ec93150543a75d2ff] ref: refs/changes/03/7803/1 uploader: name: Alexey Lyashkov email: alexey_lyashkov@xyratex.com username: shadow createdOn: 2013-09-30 10:48:59 UTC approvals: type: VRIF description: Verified value: -1 grantedOn: 2013-09-30 11:45:13 UTC by: name: Hudson username: hudson patchSets: number: 2 revision: bc0ef1e16472cdae57fe68236e90aef66730b873 parents: [63e8a4f33dc85d2957a035fc7d4b040de35c08ce] ref: refs/changes/03/7803/2 uploader: name: Alexey Lyashkov email: alexey_lyashkov@xyratex.com username: shadow createdOn: 2013-10-01 08:02:17 UTC approvals: type: VRIF description: Verified value: 1 grantedOn: 2013-10-02 05:45:32 UTC by: name: Hudson username: hudson approvals: type: CRVW description: Code Review value: -1 grantedOn: 2013-10-04 17:16:19 UTC by: name: James Simmons email: uja.ornl@gmail.com username: jsimmons approvals: type: VRIF description: Verified value: -1 grantedOn: 2013-10-03 06:48:00 UTC by: name: Maloo email: whamcloud.maloo@gmail.com username: maloo approvals: type: CRVW description: Code Review value: -1 grantedOn: 2013-10-03 14:27:13 UTC by: name: Dmitry Eremin email: dmitry.eremin@intel.com username: dmiter patchSets: number: 3 revision: 5122ed9a2f38d462266152fa818c195501d7c199 parents: [780c49a765e6de0caeea5af7dce864f855570789] ref: refs/changes/03/7803/3 uploader: name: Alexey Lyashkov email: alexey_lyashkov@xyratex.com username: shadow createdOn: 2013-10-16 08:17:11 UTC approvals: type: VRIF description: Verified value: 1 grantedOn: 2013-10-16 09:03:40 UTC by: name: Hudson username: hudson approvals: type: CRVW description: Code Review value: -1 grantedOn: 2013-10-16 14:29:42 UTC by: name: James Simmons email: uja.ornl@gmail.com username: jsimmons approvals: type: VRIF description: Verified value: -1 grantedOn: 2013-10-17 04:08:38 UTC by: name: Maloo email: whamcloud.maloo@gmail.com username: maloo ... </pre> </div></div> <p>See <a href="http://review.whamcloud.com/Documentation/cmd-query.html" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/Documentation/cmd-query.html</a> for some details.</p> <p>.bq One possibility that I think would be easy to implement (and also avoids the need to upgrade) is to only have Hudson/Jenkins mark the patch Verified -1 if it fails to build, but NOT add a Verified +1 if the build succeeds.</p> <p>What problem are you trying to solve? Right now Maloo marks +1 and Jenkins marks +2, so those are already distinct and searchable states in gerrit. The discussion in this ticket has been more focused on the Code-Review column, not the Verified column.</p> <p>If we mess with the "Verified" column at all, I think what I would want to do is eliminate it altogether. Gerrit does not contrain us to just the two columns in the default configuration. We can configure it however we want to match our workflow. And I think that is the root of our problems so far: we try to shoehorn our workflow into gerrit's out-of-the-box defaults rather than changing gerrit's configuration to work with our workflow.</p> <p>Case in point, +1 and +2 in Code-Review column in the gerrit defaults have different meanings than +1 and +2 in Lustre's usage. But we haven't taught gerrit our rules, so there is no way to create searches against the Code-Review column to gather the information that we really want.</p> <p>John has implemented some reports by interfacing with Gerrit directly:</p> <p><a href="https://wiki.hpdd.intel.com/display/Releases/2.6+Patch+Status+Report" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.hpdd.intel.com/display/Releases/2.6+Patch+Status+Report</a><br/> <a href="https://wiki.hpdd.intel.com/display/~jhammond/Patch+Status" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.hpdd.intel.com/display/~jhammond/Patch+Status</a></p> <p>Chris, does this meet your requirements for improved reporting of pending patches?</p> <p>The first link didn't work for me but the second did. Very nice looking.</p> <p>There is also <a href="https://wiki.hpdd.intel.com/display/~jhammond/Patch+Status+2" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.hpdd.intel.com/display/~jhammond/Patch+Status+2</a> which shows the same changes but in a single table.</p> <p>Andreas, as James pointed out we can't see the Releases/2.6+Patch+Status+Report page.</p> <p>I do like what I see at ~jhammond/Patch+Status and <br/> ~jhammond/Patch+Status+2!</p> <p>But there might be some bugs to work out...or perhaps the Patch+Status page hasn't been updated in a while? For instance, change 1720/3 is listed under "Needs Verify or Review", but it looks fully verified and reviewed in gerrit. From the gerrit logs, it seems to have been that way since April, so my suspicion is a kink in the Patch+Status script that needs to be worked out.</p> <p>But even without that I am getting useful insight. It looks pretty clear to me that we have an autotest issue. Quite a few tests have been waiting well over a month for autotest to be run on them. It is nice to have that easy visibility.</p> <p>I think the scanning script may assume that "Test-Parameters:" can only be the first field at the end, or something like that. It is missing fortestonly patches like this one:</p> <p><a href="http://review.whamcloud.com/#/c/9167/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/9167/</a></p> <p>Are we going to get to see the scripts that generate this stuff?</p> <p>1720/3 was under needs verify or review since we do not count positive reviews by the author or the committer.</p> <p>The commit message for <a href="http://review.whamcloud.com/#/c/9167/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/9167/</a> uses 'Test-Requirements' instead of 'Test-Parameters'.</p> <p>Ah, right, fair enough. I gave it a -1 to solve that.</p> <p>I like the pages alot. This task is complete as far as I am concerned.</p> <p>Great - thanks Chris!</p> <p>What are the 'official' URLs for the pages or will they stay at ~jhammond? Once we confirm the publishable URLs, I'd like to add them to the OpenSFS LWG wiki.</p> <p>Hi Cory, we have decided that the ~jhammond URLs are the official ones.</p> Related Development Rank 1|hzvx3z: Rank (Obsolete) 9530