Bug 1564115

Summary: need option 'run brick-mux-tests' in reviews
Product: [Community] GlusterFS Reporter: Amar Tumballi <atumball>
Component: project-infrastructureAssignee: bugs <bugs>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: mainlineCC: amukherj, bugs, gluster-infra, jeff, nigelb, srangana
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: Process-Automation
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-05 06:18:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Amar Tumballi 2018-04-05 12:21:32 UTC 
# Description of problem:

Today, if there is a concern in patch related to brick-mux, we ask the submitter to run the test with another patch which enables brick-mux and then run regression there to validate the concerns.

The best is, same patchset gets tested with brick-mux, and all the votes are captured in same patchset.

I prefer command 'run brick-mux regression" to get the tests started. But it is fine if someone else has some other string for this. All expected out of resolving bug is announcing which string to add for running brick-mux regression in ML. 


# Additional info:

Have some more bugs in series. Lets plan to prioritize them properly.
Comment 1 Niels de Vos 2018-04-05 13:22:46 UTC 
We now have a "Verified" label in Gerrit. I think it should be possible to add an other label "Test w/ brick-mux' or similar that triggers this special test. It will be used more than when a magic comment is required.
Comment 2 Amar Tumballi 2018-04-05 13:33:25 UTC 
I personally feel lesser tick-boxes, but more commands, and documenting them. It would get closer to github flow, so it will reduce the overall dependency to understand gerrit for someone who comes from github workflow.

Initially, I am fine with 'a option' to trigger this, so whichever is faster for infra team. Later we can discuss, how part of it.
Comment 3 Nigel Babu 2018-04-06 05:50:53 UTC 
Should this job vote at all? I can have a job that does on-demand running easily. But having it vote is slightly more challenging (but not impossible).
Comment 4 Amar Tumballi 2018-04-06 05:53:57 UTC 
No serious need of 'Vote' at present. This can be 'SUCCESS', 'FAILURE', ABORT or whatever.. as the person triggering the run, I would look up the result before voting.

Lets get the basic trigger infra to work first as MVP, then VOTE privilege can come as much later solution.
Comment 5 Nigel Babu 2018-04-17 06:36:02 UTC 
WIP: https://review.gluster.org/#/c/19885/