<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 10:47 AM, David Caro <span dir="ltr"><<a href="mailto:dcaro@redhat.com" target="_blank">dcaro@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/20 10:44, Eyal Edri wrote:<br>
> OK,<br>
> But if we move to use git server instead of gerrit server (only for post<br>
> merge), we won't use the Gerrit trigger plugin, so I don't see how its<br>
> still relevant.<br>
> Instead of using the gerrit trigger to run post merge jobs, we'll use the<br>
> SCM plugin instead like a normal git.<br>
><br>
> Will this approach have any issues?<br>
<br>
</span>Well, no feedback on gerrit, no link to the gerrit change that caused it, and<br>
only triggering on merges.<br></blockquote><div><br></div><div>On second thought,</div><div>Can't we keep using the Gerrit Trigger plugin for events, but use the mirror URL for cloning instead of <a href="http://gerrit.ovirt.org">gerrit.ovirt.org</a>,</div><div>IMO it will work and worth a try.</div><div><br></div><div>Also, about the cloning, What if we won't create the target GIT REPO of the 'private' repos we want to avoid cloning,</div><div>That will fail replication and won't clone the repo we want to keep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Though we already do that on some projects due to the high time they take to<br>
run.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Wed, Apr 20, 2016 at 10:41 AM, David Caro <<a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a>> wrote:<br>
><br>
> > On 04/20 09:40, David Caro wrote:<br>
> > > On 04/20 10:25, Eyal Edri wrote:<br>
> > > > On Wed, Apr 20, 2016 at 10:20 AM, Barak Korren <<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>><br>
> > wrote:<br>
> > > ><br>
> > > > > On 20 April 2016 at 10:16, Eyal Edri <<a href="mailto:eedri@redhat.com">eedri@redhat.com</a>> wrote:<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > On Wed, Apr 20, 2016 at 9:28 AM, Barak Korren <<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>><br>
> > > > > wrote:<br>
> > > > > >><br>
> > > > > >> > I'd try that approach first, though the mirror is a good idea<br>
> > that<br>
> > > > > will<br>
> > > > > >> > probably have to be implemented anyhow once we start adding<br>
> > slaves,<br>
> > > > > >> > having real<br>
> > > > > >> > info on the network usage/errors will give us insight to<br>
> > actually<br>
> > > > > >> > determine<br>
> > > > > >> > what's the issue, and thus, what's the best solution.<br>
> > > > > >> ><br>
> > > > > >> > @infra what do you think?<br>
> > > > > >> ><br>
> > > > > >><br>
> > > > > >> The issue with mirroring is how can you make sure that you mirror<br>
> > fast<br>
> > > > > >> enough to enable CI. Even if Gerrit can push to the mirror on<br>
> > patch<br>
> > > > > >> submission, there will still be some time delta between the<br>
> > submission<br>
> > > > > >> happening (and the patch event showing up in Jenins) and the<br>
> > mirror<br>
> > > > > >> being synced. This looks like a nasty race condition.<br>
> > > > > >> What the mirror essentially does is make sure that bits are copied<br>
> > > > > >> from Amazom to PHX just once. I wonder if we can get the same<br>
> > benefit<br>
> > > > > >> with a simple HTTP proxy, how proxy-able is the Git HTTP protocol?<br>
> > > > > >><br>
> > > > > ><br>
> > > > > > I think we should prioritize mirroring the GIT (not gerrit) repos<br>
> > to PHX,<br>
> > > > > > this will help:<br>
> > > > > ><br>
> > > > > > Speed up all post merge jobs and reduce potential of errors from<br>
> > git<br>
> > > > > clone<br>
> > > > > > (they will be in the same network)<br>
> > > > > > Reduce load (?) from the gerrit server and perhaps reduce errors<br>
> > of the<br>
> > > > > per<br>
> > > > > > patch jobs that will still run from <a href="http://gerrit.ovirt.org" rel="noreferrer" target="_blank">gerrit.ovirt.org</a> (AMAZON)<br>
> > > > > > A longer goal will be either to migrate the gerrit server to PHX<br>
> > or to<br>
> > > > > find<br>
> > > > > > away to properly mirror the gerrit server (but then i fear there<br>
> > might be<br>
> > > > > > race/problem as mentioned)<br>
> > > > > ><br>
> > > > ><br>
> > > > > Please look at my comment about possible race conditions caused by<br>
> > > > > mirroring. Simple mirroring may cause more trouble then its worth. We<br>
> > > > > need to consider proxying instead.<br>
> > > > ><br>
> > > ><br>
> > > > I don't see how a race condition can occur with a merge commit,<br>
> > > > Can you elaborate?<br>
> > ><br>
> > ><br>
> > > From the gerrit config on jenkins:<br>
> > ><br>
> > ><br>
> > > Replication cache expiration time in minutes<br>
> > ><br>
> > > If one of the server supports replication events, these events are<br>
> > cached in memory because they can be received before the build is triggered<br>
> > and this plugin gets called to evaluate if the build can run. Cache allows<br>
> > the plugin to look if the replication events were already received when it<br>
> > gets called to evaluate if the build can run. If the time elapsed between<br>
> > this plugin gets called and the time the build entered the queue is greated<br>
> > than the cache expiration time, the plugin will assume that replication<br>
> > events were received and will let the build run.<br>
> > ><br>
> > > Changing this value will only take effect when Jenkins is restarted<br>
> > ><br>
> ><br>
> ><br>
> > And from the specific server options:<br>
> ><br>
> > Block builds in the queue until the replication events for the configured<br>
> > Gerrit slave(s) are received.<br>
> ><br>
> > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > --<br>
> > > > Eyal Edri<br>
> > > > Associate Manager<br>
> > > > RHEV DevOps<br>
> > > > EMEA ENG Virtualization R&D<br>
> > > > Red Hat Israel<br>
> > > ><br>
> > > > phone: <a href="tel:%2B972-9-7692018" value="+97297692018">+972-9-7692018</a><br>
> > > > irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
> > ><br>
> > > --<br>
> > > David Caro<br>
> > ><br>
> > > Red Hat S.L.<br>
> > > Continuous Integration Engineer - EMEA ENG Virtualization R&D<br>
> > ><br>
> > > Tel.: <a href="tel:%2B420%20532%20294%20605" value="+420532294605">+420 532 294 605</a><br>
> > > Email: <a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a><br>
> > > IRC: dcaro|dcaroest@{freenode|oftc|redhat}<br>
> > > Web: <a href="http://www.redhat.com" rel="noreferrer" target="_blank">www.redhat.com</a><br>
> > > RHT Global #: 82-62605<br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > David Caro<br>
> ><br>
> > Red Hat S.L.<br>
> > Continuous Integration Engineer - EMEA ENG Virtualization R&D<br>
> ><br>
> > Tel.: <a href="tel:%2B420%20532%20294%20605" value="+420532294605">+420 532 294 605</a><br>
> > Email: <a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a><br>
> > IRC: dcaro|dcaroest@{freenode|oftc|redhat}<br>
> > Web: <a href="http://www.redhat.com" rel="noreferrer" target="_blank">www.redhat.com</a><br>
> > RHT Global #: 82-62605<br>
> ><br>
><br>
><br>
><br>
> --<br>
> Eyal Edri<br>
> Associate Manager<br>
> RHEV DevOps<br>
> EMEA ENG Virtualization R&D<br>
> Red Hat Israel<br>
><br>
> phone: <a href="tel:%2B972-9-7692018" value="+97297692018">+972-9-7692018</a><br>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
<br>
--<br>
David Caro<br>
<br>
Red Hat S.L.<br>
Continuous Integration Engineer - EMEA ENG Virtualization R&D<br>
<br>
Tel.: <a href="tel:%2B420%20532%20294%20605" value="+420532294605">+420 532 294 605</a><br>
Email: <a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a><br>
IRC: dcaro|dcaroest@{freenode|oftc|redhat}<br>
Web: <a href="http://www.redhat.com" rel="noreferrer" target="_blank">www.redhat.com</a><br>
RHT Global #: 82-62605<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHEV DevOps<br>EMEA ENG Virtualization R&D<br>Red Hat Israel<br><br>phone: +972-9-7692018<br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div>
</div></div>