CI fails

Wed Apr 20 11:11:40 UTC 2016

On Wed, Apr 20, 2016 at 10:47 AM, David Caro <dcaro at redhat.com> wrote:

> 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.
> >
> > Will this approach have any issues?
>
> Well, no feedback on gerrit, no link to the gerrit change that caused it,
> and
> only triggering on merges.
>

On second thought,
Can't we keep using the Gerrit Trigger plugin for events, but use the
mirror URL for cloning instead of gerrit.ovirt.org,
IMO it will work and worth a try.

Also, about the cloning, What if we won't create the target GIT REPO of the
'private' repos we want to avoid cloning,
That will fail replication and won't clone the repo we want to keep.

>
> Though we already do that on some projects due to the high time they take
> to
> run.
>
> >
> > 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)
>
> --
> 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/96151c9c/attachment.html>