Re: Tests do not pass with go1.7

Given the error message, I think this is our "prevent us from contacting real websites in the test run" failing. This is one of those "global state is bad" cases because we had to patch global state during the run of the tests but prob 1.7 changes what global state we need to touch. John =:-> On

Tests do not pass with go1.7

Just FYI, in case anyone was like me and decided they wanted to jump on the faster compile times in 1.7... some of our tests do not pass in go 1.7: https://bugs.launchpad.net/juju-core/+bug/1589350 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: A cautionary tale - mgo asserts

On 8 June 2016 at 22:36, John Meinel wrote: > ... >> > > >> >> ops := []txn.Op{{ >> C: "collection", >> Id: ..., >> Assert: bson.M{ >> "some-field.A": "foo", >> "some-field.B": 99, >> }, >> Update: ... >> } >> >> ...

Re: A cautionary tale - mgo asserts

On 9 June 2016 at 03:44, Gustavo Niemeyer wrote: > Is it mgo/txn that is internally unmarahalling onto that? > > Let's get that fixed at its heart. > That would be ideal. The root of the problem is that the Assert, Insert and Update fields of txn.Op are of type

Re: The CI build time continue to rise alarmingly

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

Re: A cautionary tale - mgo asserts

On 8 June 2016 at 16:44, Gustavo Niemeyer wrote: > Is it mgo/txn that is internally unmarahalling onto that? > > Let's get that fixed at its heart. Yes, good plan. > On Jun 8, 2016 12:27 PM, "roger peppe" wrote: >> >> The Assert field

Re: A cautionary tale - mgo asserts

Is it mgo/txn that is internally unmarahalling onto that? Let's get that fixed at its heart. On Jun 8, 2016 12:27 PM, "roger peppe" wrote: > The Assert field in mgo/txn.Op is an interface{}, so > when it's marshaled and unmarshaled, the order > can change because

Re: A cautionary tale - mgo asserts

The Assert field in mgo/txn.Op is an interface{}, so when it's marshaled and unmarshaled, the order can change because unmarshaling unmarshals as bson.M which does not preserve key order. https://play.golang.org/p/_1ZPl7iMyn On 8 June 2016 at 15:55, Gustavo Niemeyer

Re: The CI build time continue to rise alarmingly

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

Re: A cautionary tale - mgo asserts

Is it mgo itself that is changing the order internally? It should not do that. On Wed, Jun 8, 2016 at 8:00 AM, roger peppe wrote: > OK, I understand now, I think. > > The underlying problem is that subdocument searches in MongoDB > are order-sensitive. > > For example, I

Re: Regarding Synnefo environment provider for Juju

Thodoris, Also feel free to join #juju-dev on freenode (IRC) for dynamic assistance. You can reach out to me directly (alexisb) and I will ensure someone provides some help. We look forward to working with you on getting a Juju provider for Synnefo! Alexis On Wed, Jun 8, 2016 at 4:28 AM,

Re: Regarding Synnefo environment provider for Juju

Hey Thodoris, Congratulations on beginning your provider! :) Do you have your code visible anywhere? It would help with diagnosing any issues. - Katherine Thodoris Sotiropoulos writes: > Hi all, > > You may remember previous e-mails sent by my partner Stavros >

Regarding Synnefo environment provider for Juju

Hi all, You may remember previous e-mails sent by my partner Stavros Sachtouris regarding the case of implementing a Juju environment provider for our open source IaaS called Synnefo. We have started implementation of the basics (configuration schema, instance creation, instance queries,

Re: A cautionary tale - mgo asserts

You had me at "ruins mongodb", actually just "ruins'. On Wed, Jun 8, 2016 at 9:04 PM, roger peppe wrote: > This is also relevant (but probably only for larger documents): > > https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/ > > Another reason to

Re: A cautionary tale - mgo asserts

This is also relevant (but probably only for larger documents): https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/ Another reason to avoid entire-subdocument matches. On 8 June 2016 at 10:42, Menno Smits wrote: > > > On 8 June 2016 at 21:05, Tim

Re: A cautionary tale - mgo asserts

OK, I understand now, I think. The underlying problem is that subdocument searches in MongoDB are order-sensitive. For example, I just tried this in a mongo shell: > db.foo.insert({_id: "one", x: {a: 1, b: 2}}) > db.foo.find({x: {a: 1, b: 2}}) { "_id" : "one", "x" : { "a" : 1, "b" : 2 } } >

Re: A cautionary tale - mgo asserts

OK, I understand now, I think. The underlying problem is that subdocument searches in MongoDB are order-sensitive. For example, I just tried this in a mongo shell: > db.foo.insert({_id: "one", x: {a: 1, b: 2}}) > db.foo.find({x: {a: 1, b: 2}}) { "_id" : "one", "x" : { "a" : 1, "b" : 2 } } >

Re: A cautionary tale - mgo asserts

> > ... > > > ops := []txn.Op{{ > C: "collection", > Id: ..., > Assert: bson.M{ > "some-field.A": "foo", > "some-field.B": 99, > }, > Update: ... > } > > ... > > > [1] If transaction operations are loaded and used from the DB (more likely >

Re: A cautionary tale - mgo asserts

On 8 June 2016 at 21:05, Tim Penhey wrote: > Hi folks, > > tl;dr: not use structs in transaction asserts > > ... > > The solution is to not use a field struct equality, even though it is easy > to write, but to use the dotted field notation to check the embedded field >

Re: A cautionary tale - mgo asserts

On 8 June 2016 at 10:05, Tim Penhey wrote: > Hi folks, > > tl;dr: not use structs in transaction asserts > > I have spent the last two days looking at this bug: > https://bugs.launchpad.net/juju-core/+bug/1537585 > > It was one where the instance poller got itself in a

Re: A cautionary tale - mgo asserts

On 8 June 2016 at 10:05, Tim Penhey wrote: > Hi folks, > > tl;dr: not use structs in transaction asserts > > I have spent the last two days looking at this bug: > https://bugs.launchpad.net/juju-core/+bug/1537585 > > It was one where the instance poller got itself in a