Re: Three CI builds in the last 48 hours have failed because launchpad had a lie down

[Nate Finch]

 I agree.  We should snapshot a known-good starting point and start from
there.  It's a huge waste of time to do apt update / upgrade / install git,
bzr, mercurial, etc every single time we run CI.  That's like 1/3rd the
time it takes to run the unit test CI job.

On Wed, May 18, 2016 at 10:35 PM David Cheney 
wrote:

> This is a huge waste of wall time and bandwidth, and increases the
> chance of failure significantly. This is something I would like to see
> changed.
>
> On Thu, May 19, 2016 at 12:06 PM, John Meinel 
> wrote:
> > CI does a build from scratch in a pristine VM. There is some discussion
> > about changing that in a variety of ways (in a container in a long
> running
> > VM, etc), but it doesn't have a local copy to work from so it has to
> pull it
> > from upstream each time.
> >
> > John
> > =:->
> >
> >
> > On Wed, May 18, 2016 at 8:05 PM, David Cheney <
> david.che...@canonical.com>
> > wrote:
> >>
> >> We already have godeps which can take a set of vcs repos and flick
> >> them to the right revisions.
> >>
> >> Why does CI check out every single dependency from upstream every
> >> single time we do a build ? That introduces wc -l dependencies.tsv
> >> points of failure to every single CI run -- not to mention the several
> >> minutes it spends laboriously checking out the code.
> >>
> >> Thanks
> >>
> >> 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

Re: Three CI builds in the last 48 hours have failed because launchpad had a lie down

[David Cheney]

This is a huge waste of wall time and bandwidth, and increases the
chance of failure significantly. This is something I would like to see
changed.

On Thu, May 19, 2016 at 12:06 PM, John Meinel  wrote:
> CI does a build from scratch in a pristine VM. There is some discussion
> about changing that in a variety of ways (in a container in a long running
> VM, etc), but it doesn't have a local copy to work from so it has to pull it
> from upstream each time.
>
> John
> =:->
>
>
> On Wed, May 18, 2016 at 8:05 PM, David Cheney 
> wrote:
>>
>> We already have godeps which can take a set of vcs repos and flick
>> them to the right revisions.
>>
>> Why does CI check out every single dependency from upstream every
>> single time we do a build ? That introduces wc -l dependencies.tsv
>> points of failure to every single CI run -- not to mention the several
>> minutes it spends laboriously checking out the code.
>>
>> Thanks
>>
>> 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

Re: Three CI builds in the last 48 hours have failed because launchpad had a lie down

[John Meinel]

CI does a build from scratch in a pristine VM. There is some discussion
about changing that in a variety of ways (in a container in a long running
VM, etc), but it doesn't have a local copy to work from so it has to pull
it from upstream each time.

John
=:->


On Wed, May 18, 2016 at 8:05 PM, David Cheney 
wrote:

> We already have godeps which can take a set of vcs repos and flick
> them to the right revisions.
>
> Why does CI check out every single dependency from upstream every
> single time we do a build ? That introduces wc -l dependencies.tsv
> points of failure to every single CI run -- not to mention the several
> minutes it spends laboriously checking out the code.
>
> Thanks
>
> 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

Three CI builds in the last 48 hours have failed because launchpad had a lie down

[David Cheney]

We already have godeps which can take a set of vcs repos and flick
them to the right revisions.

Why does CI check out every single dependency from upstream every
single time we do a build ? That introduces wc -l dependencies.tsv
points of failure to every single CI run -- not to mention the several
minutes it spends laboriously checking out the code.

Thanks

Dave

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: The mean time for a CI run has risen to 33 minutes

[Katherine Cox-Buday]

Not sure if this is the isolation problem you're speaking of, but if so, it's 
been fixed.

https://launchpad.net/bugs/1564511

Martin Packman  writes:

> On 16/05/2016, David Cheney  wrote:
>> This got significantly worse in the last 6 weeks. What happened ?
>
> Either the juju tests are slower, or trusty on aws is slower. It's a
> fresh cloud instance each run, and still trusty because we switched to
> xenial and the lxd tests failed due to lack of isolation. Could change
> back to xenial now Curtis added some lxd setup support the the
> makefile I think, but that is unlikely to help speed at all.
>
> Martin

-- 
Katherine

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

[Christian Muirhead]

Yeah, I think so too - it seems like one of those performance bugs where
the fix would be obvious to someone familiar with the codebase. But the
response to Gustavo's bug (from October!) didn't give me much hope of it
being fixed very soon.

On Wed, May 18, 2016 at 11:36 AM David Cheney 
wrote:

> This feels like a bug in mongodb. We store approximately zero data in
> mongodb during test runs -- seriously, one machine, a charm at most,
> that's it. It mongodb has such amazingly high overheads just start to
> store data that sounds like a serious problem that is being ignored.
>
> On Wed, May 18, 2016 at 7:32 PM, Christian Muirhead
>  wrote:
> > WiredTiger is *much* slower at creating and dropping indexes and
> > collections. I haven't worked out why that is, other than doing some
> > stracing and seeing that a lot of time is spent in fdatasync - I haven't
> dug
> > into the mongo source code.
> > There's a bit more detail in these bugs:
> > https://bugs.launchpad.net/juju-core/+bug/1573294
> > https://jira.mongodb.org/browse/SERVER-21198
> >
> > I've changed the tests so that instead of dropping and recreating
> databases
> > in teardown and setup we clear out all of the collections (except the
> > transaction collections) between tests. Obviously that's worse from the
> > perspective of test isolation, but it seems to work well - better than I
> was
> > expecting, to be honest.
> >
> > Cheers,
> > Christian
> >
> > On Wed, May 18, 2016 at 9:58 AM roger peppe 
> > wrote:
> >>
> >> Out of interest, what's causing the 3.2 slowdown and what's the hack to
> >> speed it up again?
> >>
> >> On 18 May 2016 09:51, "Christian Muirhead"
> >>  wrote:
> >>>
> >>>
> >>>
> >>> On Wed, May 18, 2016 at 2:04 AM David Cheney <
> david.che...@canonical.com>
> >>> wrote:
> 
>  100x more webscale
> >>>
> >>> Ha!
> >>>
> >>> I'm *just about* finished the hack to make the state tests on 3.2 run
> in
> >>> about the same time as on 2.4. On my machine the state tests take
> 6m24s on
> >>> 3.2 and the old version took 4m56s. Which is still worse,
> unfortunately, but
> >>> at least it isn't 100x worse. So if there are stability benefits to
> running
> >>> the tests on 3.2 it's still a win, I guess?
> >>>
> >>>
> 
> 
>  On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
>   wrote:
>  > For now we are trying to go around mongo issues that make the tests
>  > 100x
>  > slower (yes one hundred) once this is fixed we should start using
>  > mongo 3.2
>  > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
>  > storage
>  > engine, which we could skip if mmapv1 ( the old one) wasn't also
>  > nearing EOL
>  > I am currently on the phone but if You want more details I can dig
> up
>  > the
>  > bug with details of what I am talking about.
>  >
>  >
>  > On Tuesday, 17 May 2016, David Cheney 
>  > wrote:
>  >>
>  >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
>  >> versions for the foreseeable future, or is there a possibility to
>  >> make
>  >> it a build or run time failure if mongo < 3.2 is installed on the
>  >> host
>  >> ?
>  >>
>  >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
>  >>  wrote:
>  >> > On 17/05/2016, Curtis Hovey-Canonical 
> wrote:
>  >> >>
>  >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
>  >> >> xenial
>  >> >> and without other changes, 2.4 will be used by all other 1.25
>  >> >> series.
>  >> >
>  >> > This isn't yet true, there's a bug open for it:
>  >> >
>  >> > "Use juju-mongodb2.6 for 1.25 on xenial"
>  >> > <
> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1570650>
>  >> >
>  >> > I had made the packaging change, but without juju code changes as
>  >> > well
>  >> > it just went and installed the old (2.4) juju-mongodb anyway when
>  >> > setting up a state server.
>  >> >
>  >> > Martin
>  >> >
>  >> > --
>  >> > 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:
> >>> 

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

[David Cheney]

This feels like a bug in mongodb. We store approximately zero data in
mongodb during test runs -- seriously, one machine, a charm at most,
that's it. It mongodb has such amazingly high overheads just start to
store data that sounds like a serious problem that is being ignored.

On Wed, May 18, 2016 at 7:32 PM, Christian Muirhead
 wrote:
> WiredTiger is *much* slower at creating and dropping indexes and
> collections. I haven't worked out why that is, other than doing some
> stracing and seeing that a lot of time is spent in fdatasync - I haven't dug
> into the mongo source code.
> There's a bit more detail in these bugs:
> https://bugs.launchpad.net/juju-core/+bug/1573294
> https://jira.mongodb.org/browse/SERVER-21198
>
> I've changed the tests so that instead of dropping and recreating databases
> in teardown and setup we clear out all of the collections (except the
> transaction collections) between tests. Obviously that's worse from the
> perspective of test isolation, but it seems to work well - better than I was
> expecting, to be honest.
>
> Cheers,
> Christian
>
> On Wed, May 18, 2016 at 9:58 AM roger peppe 
> wrote:
>>
>> Out of interest, what's causing the 3.2 slowdown and what's the hack to
>> speed it up again?
>>
>> On 18 May 2016 09:51, "Christian Muirhead"
>>  wrote:
>>>
>>>
>>>
>>> On Wed, May 18, 2016 at 2:04 AM David Cheney 
>>> wrote:

 100x more webscale
>>>
>>> Ha!
>>>
>>> I'm *just about* finished the hack to make the state tests on 3.2 run in
>>> about the same time as on 2.4. On my machine the state tests take 6m24s on
>>> 3.2 and the old version took 4m56s. Which is still worse, unfortunately, but
>>> at least it isn't 100x worse. So if there are stability benefits to running
>>> the tests on 3.2 it's still a win, I guess?
>>>
>>>


 On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
  wrote:
 > For now we are trying to go around mongo issues that make the tests
 > 100x
 > slower (yes one hundred) once this is fixed we should start using
 > mongo 3.2
 > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
 > storage
 > engine, which we could skip if mmapv1 ( the old one) wasn't also
 > nearing EOL
 > I am currently on the phone but if You want more details I can dig up
 > the
 > bug with details of what I am talking about.
 >
 >
 > On Tuesday, 17 May 2016, David Cheney 
 > wrote:
 >>
 >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
 >> versions for the foreseeable future, or is there a possibility to
 >> make
 >> it a build or run time failure if mongo < 3.2 is installed on the
 >> host
 >> ?
 >>
 >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
 >>  wrote:
 >> > On 17/05/2016, Curtis Hovey-Canonical  wrote:
 >> >>
 >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
 >> >> xenial
 >> >> and without other changes, 2.4 will be used by all other 1.25
 >> >> series.
 >> >
 >> > This isn't yet true, there's a bug open for it:
 >> >
 >> > "Use juju-mongodb2.6 for 1.25 on xenial"
 >> > 
 >> >
 >> > I had made the packaging change, but without juju code changes as
 >> > well
 >> > it just went and installed the old (2.4) juju-mongodb anyway when
 >> > setting up a state server.
 >> >
 >> > Martin
 >> >
 >> > --
 >> > 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
>>>
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

[Christian Muirhead]

Michael, thanks for all the clear info in the bugs by the way!

I also got good results from running the tests under tmpfs - the 3.2 run
was almost acceptably fast. But obviously it's not practical to require
every machine running the tests to have a tmpfs mounted (or somehow mount
one in the test run).

On Wed, May 18, 2016 at 10:36 AM Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

> On 18 May 2016 at 21:32, Christian Muirhead
>  wrote:
> > WiredTiger is *much* slower at creating and dropping indexes and
> > collections. I haven't worked out why that is, other than doing some
> > stracing and seeing that a lot of time is spent in fdatasync - I haven't
> dug
> > into the mongo source code.
>
> Yeah, this is what I concluded too. I tried running mongo under
> eatmydata but it didn't work for reasons I didn't get around to
> understanding. I even built a mongo with the fdatasync call commented
> out but then I moved onto other things...
>
> Cheers,
> mwh
>
> > There's a bit more detail in these bugs:
> > https://bugs.launchpad.net/juju-core/+bug/1573294
> > https://jira.mongodb.org/browse/SERVER-21198
> >
> > I've changed the tests so that instead of dropping and recreating
> databases
> > in teardown and setup we clear out all of the collections (except the
> > transaction collections) between tests. Obviously that's worse from the
> > perspective of test isolation, but it seems to work well - better than I
> was
> > expecting, to be honest.
> >
> > Cheers,
> > Christian
> >
> > On Wed, May 18, 2016 at 9:58 AM roger peppe 
> > wrote:
> >>
> >> Out of interest, what's causing the 3.2 slowdown and what's the hack to
> >> speed it up again?
> >>
> >> On 18 May 2016 09:51, "Christian Muirhead"
> >>  wrote:
> >>>
> >>>
> >>>
> >>> On Wed, May 18, 2016 at 2:04 AM David Cheney <
> david.che...@canonical.com>
> >>> wrote:
> 
>  100x more webscale
> >>>
> >>> Ha!
> >>>
> >>> I'm *just about* finished the hack to make the state tests on 3.2 run
> in
> >>> about the same time as on 2.4. On my machine the state tests take
> 6m24s on
> >>> 3.2 and the old version took 4m56s. Which is still worse,
> unfortunately, but
> >>> at least it isn't 100x worse. So if there are stability benefits to
> running
> >>> the tests on 3.2 it's still a win, I guess?
> >>>
> >>>
> 
> 
>  On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
>   wrote:
>  > For now we are trying to go around mongo issues that make the tests
>  > 100x
>  > slower (yes one hundred) once this is fixed we should start using
>  > mongo 3.2
>  > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
>  > storage
>  > engine, which we could skip if mmapv1 ( the old one) wasn't also
>  > nearing EOL
>  > I am currently on the phone but if You want more details I can dig
> up
>  > the
>  > bug with details of what I am talking about.
>  >
>  >
>  > On Tuesday, 17 May 2016, David Cheney 
>  > wrote:
>  >>
>  >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
>  >> versions for the foreseeable future, or is there a possibility to
>  >> make
>  >> it a build or run time failure if mongo < 3.2 is installed on the
>  >> host
>  >> ?
>  >>
>  >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
>  >>  wrote:
>  >> > On 17/05/2016, Curtis Hovey-Canonical 
> wrote:
>  >> >>
>  >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
>  >> >> xenial
>  >> >> and without other changes, 2.4 will be used by all other 1.25
>  >> >> series.
>  >> >
>  >> > This isn't yet true, there's a bug open for it:
>  >> >
>  >> > "Use juju-mongodb2.6 for 1.25 on xenial"
>  >> > <
> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1570650>
>  >> >
>  >> > I had made the packaging change, but without juju code changes as
>  >> > well
>  >> > it just went and installed the old (2.4) juju-mongodb anyway when
>  >> > setting up a state server.
>  >> >
>  >> > Martin
>  >> >
>  >> > --
>  >> > 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 

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

[Christian Muirhead]

WiredTiger is *much* slower at creating and dropping indexes and
collections. I haven't worked out why that is, other than doing some
stracing and seeing that a lot of time is spent in fdatasync - I haven't
dug into the mongo source code.
There's a bit more detail in these bugs:
https://bugs.launchpad.net/juju-core/+bug/1573294
https://jira.mongodb.org/browse/SERVER-21198

I've changed the tests so that instead of dropping and recreating databases
in teardown and setup we clear out all of the collections (except the
transaction collections) between tests. Obviously that's worse from the
perspective of test isolation, but it seems to work well - better than I
was expecting, to be honest.

Cheers,
Christian

On Wed, May 18, 2016 at 9:58 AM roger peppe 
wrote:

> Out of interest, what's causing the 3.2 slowdown and what's the hack to
> speed it up again?
> On 18 May 2016 09:51, "Christian Muirhead" <
> christian.muirh...@canonical.com> wrote:
>
>>
>>
>> On Wed, May 18, 2016 at 2:04 AM David Cheney 
>> wrote:
>>
>>> 100x more webscale
>>>
>> Ha!
>>
>> I'm *just about* finished the hack to make the state tests on 3.2 run in
>> about the same time as on 2.4. On my machine the state tests take 6m24s on
>> 3.2 and the old version took 4m56s. Which is still worse, unfortunately,
>> but at least it isn't 100x worse. So if there are stability benefits to
>> running the tests on 3.2 it's still a win, I guess?
>>
>>
>>
>>>
>>> On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
>>>  wrote:
>>> > For now we are trying to go around mongo issues that make the tests
>>> 100x
>>> > slower (yes one hundred) once this is fixed we should start using
>>> mongo 3.2
>>> > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
>>> storage
>>> > engine, which we could skip if mmapv1 ( the old one) wasn't also
>>> nearing EOL
>>> > I am currently on the phone but if You want more details I can dig up
>>> the
>>> > bug with details of what I am talking about.
>>> >
>>> >
>>> > On Tuesday, 17 May 2016, David Cheney 
>>> wrote:
>>> >>
>>> >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
>>> >> versions for the foreseeable future, or is there a possibility to make
>>> >> it a build or run time failure if mongo < 3.2 is installed on the host
>>> >> ?
>>> >>
>>> >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
>>> >>  wrote:
>>> >> > On 17/05/2016, Curtis Hovey-Canonical  wrote:
>>> >> >>
>>> >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
>>> xenial
>>> >> >> and without other changes, 2.4 will be used by all other 1.25
>>> series.
>>> >> >
>>> >> > This isn't yet true, there's a bug open for it:
>>> >> >
>>> >> > "Use juju-mongodb2.6 for 1.25 on xenial"
>>> >> > 
>>> >> >
>>> >> > I had made the packaging change, but without juju code changes as
>>> well
>>> >> > it just went and installed the old (2.4) juju-mongodb anyway when
>>> >> > setting up a state server.
>>> >> >
>>> >> > Martin
>>> >> >
>>> >> > --
>>> >> > 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
>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

[roger peppe]

Out of interest, what's causing the 3.2 slowdown and what's the hack to
speed it up again?
On 18 May 2016 09:51, "Christian Muirhead" 
wrote:

>
>
> On Wed, May 18, 2016 at 2:04 AM David Cheney 
> wrote:
>
>> 100x more webscale
>>
> Ha!
>
> I'm *just about* finished the hack to make the state tests on 3.2 run in
> about the same time as on 2.4. On my machine the state tests take 6m24s on
> 3.2 and the old version took 4m56s. Which is still worse, unfortunately,
> but at least it isn't 100x worse. So if there are stability benefits to
> running the tests on 3.2 it's still a win, I guess?
>
>
>
>>
>> On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
>>  wrote:
>> > For now we are trying to go around mongo issues that make the tests 100x
>> > slower (yes one hundred) once this is fixed we should start using mongo
>> 3.2
>> > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
>> storage
>> > engine, which we could skip if mmapv1 ( the old one) wasn't also
>> nearing EOL
>> > I am currently on the phone but if You want more details I can dig up
>> the
>> > bug with details of what I am talking about.
>> >
>> >
>> > On Tuesday, 17 May 2016, David Cheney 
>> wrote:
>> >>
>> >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
>> >> versions for the foreseeable future, or is there a possibility to make
>> >> it a build or run time failure if mongo < 3.2 is installed on the host
>> >> ?
>> >>
>> >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
>> >>  wrote:
>> >> > On 17/05/2016, Curtis Hovey-Canonical  wrote:
>> >> >>
>> >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
>> xenial
>> >> >> and without other changes, 2.4 will be used by all other 1.25
>> series.
>> >> >
>> >> > This isn't yet true, there's a bug open for it:
>> >> >
>> >> > "Use juju-mongodb2.6 for 1.25 on xenial"
>> >> > 
>> >> >
>> >> > I had made the packaging change, but without juju code changes as
>> well
>> >> > it just went and installed the old (2.4) juju-mongodb anyway when
>> >> > setting up a state server.
>> >> >
>> >> > Martin
>> >> >
>> >> > --
>> >> > 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
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev