Re: CI fails

OK, But if we move to use git server instead of gerrit server (only for post merge), we won't use the Gerrit trigger plugin, so I don't see how its still relevant. Instead of using the gerrit trigger to run post merge jobs, we'll use the SCM plugin instead like a normal git. =20 Will this approach have any issues?

=20 On Wed, Apr 20, 2016 at 10:41 AM, David Caro <dcaro(a)redhat.com&gt; wrote: =20 > On 04/20 09:40, David Caro wrote: > > On 04/20 10:25, Eyal Edri wrote: > > > On Wed, Apr 20, 2016 at 10:20 AM, Barak Korren <bkorren(a)redhat.com&gt; > wrote: > > > > > > > On 20 April 2016 at 10:16, Eyal Edri <eedri(a)redhat.com&gt; wrote: > > > > > > > > > > > > > > > On Wed, Apr 20, 2016 at 9:28 AM, Barak Korren <bkorren(a)redhat.c=

> > > > wrote: > > > > >> > > > > >> > I'd try that approach first, though the mirror is a good idea > that > > > > will > > > > >> > probably have to be implemented anyhow once we start adding > slaves, > > > > >> > having real > > > > >> > info on the network usage/errors will give us insight to > actually > > > > >> > determine > > > > >> > what's the issue, and thus, what's the best solution. > > > > >> > > > > > >> > @infra what do you think? > > > > >> > > > > > >> > > > > >> The issue with mirroring is how can you make sure that you mir=

> fast > > > > >> enough to enable CI. Even if Gerrit can push to the mirror on > patch > > > > >> submission, there will still be some time delta between the > submission > > > > >> happening (and the patch event showing up in Jenins) and the > mirror > > > > >> being synced. This looks like a nasty race condition. > > > > >> What the mirror essentially does is make sure that bits are co=

> > > > >> from Amazom to PHX just once. I wonder if we can get the same > benefit > > > > >> with a simple HTTP proxy, how proxy-able is the Git HTTP proto=

> > > > >> > > > > > > > > > > I think we should prioritize mirroring the GIT (not gerrit) rep=

> to PHX, > > > > > this will help: > > > > > > > > > > Speed up all post merge jobs and reduce potential of errors from > git > > > > clone > > > > > (they will be in the same network) > > > > > Reduce load (?) from the gerrit server and perhaps reduce errors > of the > > > > per > > > > > patch jobs that will still run from gerrit.ovirt.org (AMAZON) > > > > > A longer goal will be either to migrate the gerrit server to PHX > or to > > > > find > > > > > away to properly mirror the gerrit server (but then i fear there > might be > > > > > race/problem as mentioned) > > > > > > > > > > > > > Please look at my comment about possible race conditions caused by > > > > mirroring. Simple mirroring may cause more trouble then its worth=

> > > > need to consider proxying instead. > > > > > > > > > > I don't see how a race condition can occur with a merge commit, > > > Can you elaborate? > > > > > > From the gerrit config on jenkins: > > > > > > Replication cache expiration time in minutes > > > > If one of the server supports replication events, these events are > cached in memory because they can be received before the build is trigg=

> and this plugin gets called to evaluate if the build can run. Cache all=

> the plugin to look if the replication events were already received when=

> gets called to evaluate if the build can run. If the time elapsed betwe=

> this plugin gets called and the time the build entered the queue is gre=

> than the cache expiration time, the plugin will assume that replication > events were received and will let the build run. > > > > Changing this value will only take effect when Jenkins is restarted > > > > > And from the specific server options: > > Block builds in the queue until the replication events for the configur=

> Gerrit slave(s) are received. > > > > > > > > > > > > > > > > > > -- > > > Eyal Edri > > > Associate Manager > > > RHEV DevOps > > > EMEA ENG Virtualization R&D > > > Red Hat Israel > > > > > > phone: +972-9-7692018 > > > irc: eedri (on #tlv #rhev-dev #rhev-integ) > > > > -- > > David Caro > > > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > Tel.: +420 532 294 605 > > Email: dcaro(a)redhat.com > > IRC: dcaro|dcaroest@{freenode|oftc|redhat} > > Web: www.redhat.com > > RHT Global #: 82-62605 > > > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dcaro(a)redhat.com > IRC: dcaro|dcaroest@{freenode|oftc|redhat} > Web: www.redhat.com > RHT Global #: 82-62605 > =20 =20 =20 --=20 Eyal Edri Associate Manager RHEV DevOps EMEA ENG Virtualization R&D Red Hat Israel =20 phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXFzQWAAoJEEBxx+HSYmnDLfgH/0pyqs6y6NTN2YsfCWstUHq9 o6ZC/plSAkF1sLKwtqvlaut3hw4b1Z1nc1USTH6GSRTrLqS0vXADQZTZDhKO6FEp 0PzD9wpAFw7InQbSTzBQKu/SD+mVyErw12aoVwLBoNrEsUaSU+k2GCD8a6/HcDvB rkmjMPOMdnl3Z4XmzZCdGPQmpQA8ivllrV3XHc75hXqLeqBuVEkEAGGgk0jRE6Hf 7dnAhmp/TUtI/oUysz/A1+zVUVjubGBH41mxf+SbvXB1cYW8T+cpEyDvqsvGfUq2 TQBVyhg8tQ0bxpOviqoOqOQhj/9YGarHSKK6jAht5F2nEyft/CYjHYVKU6U5rLw= =sciK -----END PGP SIGNATURE-----