CI fails

[Eyal Edri]

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 <dcaro at redhat.com> 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 <bkorren at redhat.com>
> wrote:
> > >
> > > > On 20 April 2016 at 10:16, Eyal Edri <eedri at redhat.com> wrote:
> > > > >
> > > > >
> > > > > On Wed, Apr 20, 2016 at 9:28 AM, Barak Korren <bkorren at redhat.com>
> > > > 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: dcaro at 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 at redhat.com
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160420/b7a41987/attachment.html>