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.
Will this approach have any issues? On Wed, Apr 20, 2016 at 10:41 AM, David Caro <[email protected]> wrote: > 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 <[email protected]> > wrote: > > > > > > > On 20 April 2016 at 10:16, Eyal Edri <[email protected]> wrote: > > > > > > > > > > > > > > > On Wed, Apr 20, 2016 at 9:28 AM, Barak Korren <[email protected]> > > > > 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 mirror > 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 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 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. 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 triggered > and this plugin gets called to evaluate if the build can run. Cache allows > 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 between > this plugin gets called and the time the build entered the queue is greated > 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 configured > 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: [email protected] > > 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: [email protected] > IRC: dcaro|dcaroest@{freenode|oftc|redhat} > Web: www.redhat.com > RHT Global #: 82-62605 > -- 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)
_______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
