<div dir="ltr">So as a follow up of this, the fault is in "7fb39bdfbd8a7a668c7db53923836ac42cd640ec" that removed --nojournal from "<a href="http://github.com/juju/testing">github.com/juju/testing</a>" mgo.go file, which is good for mongo 3.2 but kills 2.4, this needs to check what version of mongo is running and use flags accordingly, its EOD for me but if no one tackled this by tomorrow ill fix it (hint, our code has this in main in the mongo package iirc)</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 8, 2016 at 1:20 PM, Christian Muirhead <span dir="ltr"><<a href="mailto:christian.muirhead@canonical.com" target="_blank">christian.muirhead@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Torsten - <div><br>That fix shouldn't have increased build times unless we also changed the test run to be against Mongo 3.2. If builds are still against 2.4 then the change will have made them slightly faster (because we only drop and recreate the database at the suite level). </div><div><br></div><div>I don't think we've switched runs to be against 3.2 because there were other problems that were unrelated to the slow state tests - these two that I know about:</div><div><a href="https://bugs.launchpad.net/juju-core/+bug/1588784" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1588784</a></div><div><a href="https://bugs.launchpad.net/juju-core/+bug/1573286" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1573286</a></div><div>  </div><div><div>Cheers,</div><div>Christian</div><div><div class="h5"><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, 8 Jun 2016, 16:06 Torsten Baumann, <<a href="mailto:torsten.baumann@canonical.com" target="_blank">torsten.baumann@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi David,<div><br></div><div>Thanks for raising the inefficiency.</div><div><br></div><div>From what I understand there was a change introduced in and around June 1st for<span style="font-size:12.8px"> </span><a href="https://bugs.launchpad.net/juju-core/+bug/1573294" style="font-size:12.8px" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1573294</a> that may have increased the time again. :-( As regrettable as this is we did review this with the tech board and it was accepted as part of the fix.</div><div><br></div><div><br></div><div>I discussed with a few people and there is some time we can shave off on the tarball assembly (2-4 minutes) if we spent a few days work there.</div><div><br></div><div>I also believe we can save time if we ran the tests in LXC containers but there may be some reliability issues there. we can always switch the jobs to use lxc and see what happens?<br></div><div><br></div><div>Other than that I am open to seeing who else on this list has ideas as to what we can do to reduce the time? I would rather we go after the most important ones first if we can identify them.</div><div><br></div><div>thanks everyone,</div><div><br></div><div>Torsten</div></div><div dir="ltr"><div><br></div><div><br></div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">David Cheney</b> <span dir="ltr"><<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>></span><br>Date: Thu, Jun 2, 2016 at 9:49 PM<br>Subject: The CI build time continue to rise alarmingly<br>To: "<a href="mailto:juju-dev@lists.ubuntu.com" target="_blank">juju-dev@lists.ubuntu.com</a>" <<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a>><br><br><br>CI build times are now an average of 36 minutes. That means in a<br>
typical 8 hour work day, assuming doing nothing other than landing<br>
branches, less than 16 commits can be landed.<br>
<br>
While bugs can be worked on and reviewed in parallel, landing is a<br>
sequential action that blocks everyone, and given the landing bot is<br>
batting less than 0.500, this limits the practical number of changes<br>
that can be landed in a day, a sprint, a iteration, or a development<br>
cycle.<br>
<br>
I cannot make it any clearer than this, the speed of CI limits the<br>
velocity of this team.<br>
<br>
Dave<br>
<span><font color="#888888"><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</font></span></div><br></div></div>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div></div></div></div></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>