--K3Y3NTg/qyuIFs24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/20 10:25, Eyal Edri wrote:
On Wed, Apr 20, 2016 at 10:20 AM, Barak Korren <bkorren@redhat.com> wrote: =20
On 20 April 2016 at 10:16, Eyal Edri <eedri@redhat.com> wrote:
On Wed, Apr 20, 2016 at 9:28 AM, Barak Korren <bkorren@redhat.com>
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 mirror fa= st enough to enable CI. Even if Gerrit can push to the mirror on patch submission, there will still be some time delta between the submissi= on 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 copied 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 protocol?
I think we should prioritize mirroring the GIT (not gerrit) repos 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 t= he
wrote: 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 migh= t 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. We need to consider proxying instead.
=20 I don't see how a race condition can occur with a merge commit, Can you elaborate?
=46rom the gerrit config on jenkins: Replication cache expiration time in minutes If one of the server supports replication events, these events are cached i= n memory because they can be received before the build is triggered and thi= s plugin gets called to evaluate if the build can run. Cache allows the plu= gin to look if the replication events were already received when it gets ca= lled to evaluate if the build can run. If the time elapsed between this plu= gin gets called and the time the build entered the queue is greated than th= e cache expiration time, the plugin will assume that replication events wer= e received and will let the build run. Changing this value will only take effect when Jenkins is restarted=20
=20 =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)
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605 --K3Y3NTg/qyuIFs24 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXFzJTAAoJEEBxx+HSYmnD/doH/2nMykApAnpG1ZtTSSXsl7xJ ZQYd4eEiiJ/7UaAi9Ig7GA5MorOET6yVPzP6S7tQNing7DtYpv2nyTZLSv9rSCpC jkmms2iZfbzeC4AJtkAAKL/qo7Co75Y+GCDcsGCO4pnaRzu4eOMg8N4veL7Fw4ie WU4jTls0SSnXqOZWNp5586/iafbOcfGDcDwt+Wzf9J+cr94a4RWNvDkhO275HwYK rHRE6C5aIiZF1hrS2T8gVyHUr9AwH+lRzY2sVJ87aFQ78S1tk3RrfEAnobu/emol LBeta3OYqETAKJRI561bxiGtdX4X7gB52jCHxQasErXdgxHs2YklYcU7ab0MsF4= =r8hk -----END PGP SIGNATURE----- --K3Y3NTg/qyuIFs24--