On 2 Apr 2015, at 05:18, Emmanuel Dreyfus wrote:
> Hi
>
> I am now convinced the solution to our multiple regression problem is to
> introduce more "Gluster Build System" users: one for CentOS regression,
> another one for NetBSD regression (and one for each smoke test, as
> exaplained below).
>
> I just tested it on http://review.gluster.org/10052, and here is what
> gerrit display in the verified column
> - if there are neither verified=+1 or verified=-1 cast: nothing
> - if there is at least one verified=+1 and no verified=-1: verified
> - if there is at least one verified=-1: failed
>
> Therefore if CentOS regression uses bu...@review.gluster.org to report
> results and NetBSD regression uses nb7bu...@review.gluster.org (later
> user should be created), we acheive this outcome:
> - gerrit will display a change as verified if one regression reported it
> as verified and the other either also succeeded or failed to report
> - gerrit will display a change as failed if one regression reported it
> at failed, regardless of what the other reported.
>
> There is still one minor problem: if one regression does not report, or
> report late, we can have the feeling that a change is verified while it
> should not, and its status can change later. But this is a minor issue
> compaed to curent status.
>
> Other ideas:
> - smoke builds should also report as different gerrit users, so that a
> verified=+1 regression result does not override verified=-1 smoke build
> result
> - when we get a regression failure, we could cast the verified vote to
> gerrit and immediatly schedule another regression run. That way we could
> automatically workaround spurious failures without the need for
> retrigger in Jenkins.
You're probably right. :)
I'll set up test / sandbox VM's today using last night's backup of our
Gerrit setup, then we can try stuff out on it to make sure.
Give me a few hours though. ;)
It needs to be able to communicate with stuff on the internet for
OpenID to work, but unable to affect our Jenkins box, Forge/GitHub/etc.
Best way I've thought of for doing that (so far) is adding static routes
to bogus IP addresses in /etc/hosts for the things we don't want it
communicating with. The other option might be to just use the built in
IP tables firewall to disallow all communications except for whitelisted
addresses. Will figure it out in a few hours. ;)
+ 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://www.gluster.org/mailman/listinfo/gluster-devel
