--Q6Ii71d/u7QX3MLh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/20 10:44, Eyal Edri wrote:
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@redhat.com> wrote: =20
On 04/20 10:25, Eyal Edri wrote:
On Wed, Apr 20, 2016 at 10:20 AM, Barak Korren <bkorren@redhat.com> wrote:
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.c=
om> wrote:
> > > I'd try that approach first, though the mirror is a good idea
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= ror fast > enough to enable CI. Even if Gerrit can push to the mirror on
On 04/20 09:40, David Caro wrote: that 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=
Well, no feedback on gerrit, no link to the gerrit change that caused it, a= nd only triggering on merges. Though we already do that on some projects due to the high time they take to run. pied
> 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=
col? > > > > > >> > > > > > > > > > > > > I think we should prioritize mirroring the GIT (not gerrit) rep= os > > 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= =2E We > > > > > 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= ered > > and this plugin gets called to evaluate if the build can run. Cache all= ows > > the plugin to look if the replication events were already received when= it > > gets called to evaluate if the build can run. If the time elapsed betwe= en > > this plugin gets called and the time the build entered the queue is gre= ated > > 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= ed > > 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@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@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)
--=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 --Q6Ii71d/u7QX3MLh Content-Type: application/pgp-signature; name="signature.asc" -----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----- --Q6Ii71d/u7QX3MLh--