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
signature.asc
Description: PGP signature
_______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
