So as a follow up of this, the fault is in "7fb39bdfbd8a7a668c7db53923836ac42cd640ec" that removed --nojournal from " github.com/juju/testing" 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)
On Wed, Jun 8, 2016 at 1:20 PM, Christian Muirhead < christian.muirh...@canonical.com> wrote: > Hi Torsten - > > 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). > > 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: > https://bugs.launchpad.net/juju-core/+bug/1588784 > https://bugs.launchpad.net/juju-core/+bug/1573286 > > Cheers, > Christian > > > On Wed, 8 Jun 2016, 16:06 Torsten Baumann, <torsten.baum...@canonical.com> > wrote: > >> Hi David, >> >> Thanks for raising the inefficiency. >> >> From what I understand there was a change introduced in and around June >> 1st for https://bugs.launchpad.net/juju-core/+bug/1573294 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. >> >> >> 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. >> >> 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? >> >> 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. >> >> thanks everyone, >> >> Torsten >> >> >> >> ---------- Forwarded message ---------- >> From: David Cheney <david.che...@canonical.com> >> Date: Thu, Jun 2, 2016 at 9:49 PM >> Subject: The CI build time continue to rise alarmingly >> To: "juju-dev@lists.ubuntu.com" <Juju-dev@lists.ubuntu.com> >> >> >> CI build times are now an average of 36 minutes. That means in a >> typical 8 hour work day, assuming doing nothing other than landing >> branches, less than 16 commits can be landed. >> >> While bugs can be worked on and reviewed in parallel, landing is a >> sequential action that blocks everyone, and given the landing bot is >> batting less than 0.500, this limits the practical number of changes >> that can be landed in a day, a sprint, a iteration, or a development >> cycle. >> >> I cannot make it any clearer than this, the speed of CI limits the >> velocity of this team. >> >> Dave >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
