User1: User5 User8 User2 burton-aus: i'll be right back
User2: User1 aw man, I didn't see that you'd requested the review on GH - I guess that's close enough to voluntelling. I'll have a look this afternoon once I get charms uploading.
User1: User2 no worries, you are busy, totally understand
User3: FARK
User4: User3 ?
User3: just trying to look at how mongo counts records in a collection
User3: it is non-trivial
User2: User3 Can we use stats instead of counting? Might be accurate enough and much faster.
User3: what stats?
User3: I have a theory on the count
User2: db.<collection>.stats()
User3: but need access to a big controller to test
User2: https://docs.mongodb.com/manual/reference/method/db.collection.stats/
User3: User2 you would think that db.coll.find().count() would use that
User3: but perhaps it doesn't
User3: can we get access to the stats through mgo?
User2: not sure
User2: mmm, toasted sandwich for lunch
User1: User5 if you have a chance, here's a PR for review. sadly it doesn't reflect 2 file renames so counts the full contents towards the +/- count :-( https://github.com/juju/juju/pull/7808
User3: var stats bson.D
User3: session.DB("mydb").Run(bson.D{{"collStats", "mycollection"}}, &stats)
User3: fmt.Println("Stats:", stats)
User3: so... maybe
User5: User1 ok, looking
User1: ta
User5: User1 is relationnetworks.go otherwise unchanged?
User1: User5 sadly not - there's some tweaks to accommodate the egress stuff - same core structs but with a direction attribute - "ingress" or "egress"
User1: pita the renames aren't better handled
User1: reviewboard did it better
User5: User1 perhaps do the rename and change in separate commits next time. anyway, not too big, reviewing...
User1: that would have worked, yeah
User5: User1 looks good
User1: tyvm
User3: anyone know what needs to be done to be able to run the mgo tests?
User2: User3 I've never got them running locally, but I think I had them running in travis against my github fork
User2: User3 that was pretty straightforward to set up
User2: User1 approved
User1: User2 yay, ty
User2: User5 just realised I need something from 2.2.3 in the upgrade juju2 tree (client side of the machine sanity check) - do you think I should just spot patch that in from 2.2.3, or update the tree to get it?
User2: User5 While typing that up I think I decided, I'll just update that client.
User2: User5 thanks for the help!
User5: User2 hah :)  FWIW I was going to say the same
User2: ha, lucky!
User2: User5 Can you take a look at https://github.com/juju/1.25-upgrade/pull/20 please?
User5: User2 ok. just finishing up a PR, then will take a look
User2: User5 thanks - no rush, I'm close to end of day so I'll look at comments tomorrow.
User5: User2 okey dokey
User5: User6 when you're free, can you please take a look at https://github.com/juju/juju/pull/7803?
User1: User6 User7 you free now for a HO? or soon?
User6: User1 I was just about to make coffee and then I'm available, i'm not sure about wkp
User6: wpk
User1: ok, just ping whenever
User6: User1 is it worth just you and I meeting? I feel like we're mostly in sync
User1: User6 we are, we can do it again tomorrow with everyone
User6: I'm off tomorrow, but maybe I'll be around the house (local 'vacation')
User6: Its a national holiday, vs a planned vacation
User1: or it can wait. we just need to ensure we're fully synced up and plan the next most important bit to do for nextwork-get
User7: User1 User6 sorry, I am now if you're available
User1: i can be in 10
User7: k
User1: User7 User6 i am free now if you guys are
User6: User1 we're on the hangout that wpk linked on the other channel
User8: is there a way to get juju upgrade-juju âbuild-agent to work on a model other than controller?
User3: User8 no
User3: User8 you need to upgrade the controller first
User3: then specify the controller version for the hosted model
User3: the hosted model then gets the same version as the controller
User8: User3 how do i do the 2nd bit âspecify the controller version for the hosted modelâ?
User3: User8 ok, lets say you have upgraded the controller
User3: and do a status on the controller
User3: and it says version 91.69.162.6 say
User3: you then go
User3: juju upgrade-juju other-model --agent-version=91.69.162.6
User3: probably a -m in there too
User8: User3 okay, iâll give it a shot
User9: I'm experiencing some odd behavior using JAAS + AWS + network spaces
User3: User9 what sort of odd behaviour?
User9: at a high level, things work (charms deploy successfully) if deployed in the default vpc, with no juju spaces defined
User9: on the other hand, if I create a model in the non default vpc, add some spaces, and deploy the exact same bundle except to the defined space I get odd failures throughout
User9: grabbing some material to support this omp
User9: it might be specific to the charm, in this case, elasticsearch
User9: ok
User9: this is making me feel a bit crazy
User9: but its entirely reproducable
User9: so
User9: I don't know what to say .... I think it might be a charm specific thing though and not juju or network related ..... I just don't get it
User9: using upstream elasticsearch in the charmstore (cs:trusty/elasticsearch-19)
User9: what happens is elasticsearch will be deployed and running on the machine deployed to the default vpc, and when elasticsearch deployed with a spaces constraint, the process just doesn't exist
User9: all the dirs are there, the binary is ther
User9: this model https://pastebin.com/NaLcqBFy is configured to a default vpc, no spaces added, and no constraints used
User9: from that elasticsearch node, http://paste.ubuntu.com/25434884/
User9: <- `ps aux | grep elasticsearch`
User9: we can see that elasticsearch is running
User9: next, a model created with a non-default vpc and spaces added, and all the machines deployed to the spaces
User9: http://paste.ubuntu.com/25434893/
User9: http://paste.ubuntu.com/25434894/
User9: heres the full yaml status http://paste.ubuntu.com/25434903/
User9: and now, same as before, I'll ssh into elasticsearch box and ps aux
User9: http://paste.ubuntu.com/25434906/
User9: boom
User9: java process for elasticsearch exists
User9: odd because the machine has elasticsearch and all the deps (java) installed
User9: lol
User9: I've been ramming my head on this for days now .... just thinking my fork of elasticsearch is borked
User9: lol
User9: ^^ important correction s/java process for elasticsearch exists/java process for elasticsearch ceases to exist/
User9: its quite baffling, really
User9: User3 ^that kind
User2: User9 can you see logs for elasticsearch? It sounds like it might be trying to start and failing when you have space constraints.
User9: User2 I was just about to report back with that
User9: User2 the java process appears just for a second then disappears
User9: the logs are clean though
User9: because it looks as if it actually does start
User9: so there is no error being logged or anything
User9: I have this juju log for the failing instance http://paste.ubuntu.com/
User9: wow ... the logs are entirely different
User9: and this log for the working instance 2017-08-30 22:19:45 INFO juju.cmd supercommand.go:63 running jujud [2.2.2 gc go1.8]
User9: 2017-08-30 22:19:45 DEBUG juju.cmd supercommand.go:64   args: []string{"/var/lib/juju/tools/unit-elasticsearch-0/jujud", "unit", "--data-dir", "/var/lib/juju", "--unit-name", "elasticsearch/0", "--debug"}
User9: 2017-08-30 22:19:45 DEBUG juju.agent agent.go:543 read agent config, format "2.0"
User9: 2017-08-30 22:19:45 INFO juju.jujud unit.go:151 unit agent unit-elasticsearch-0 start (2.2.2 [gc])
User9: 2017-08-30 22:19:45 DEBUG juju.worker runner.go:319 start "api"
User9: oh no
User9: my bad - jeeze
User9: and this log for the working instance http://paste.ubuntu.com/25435003/
User3: weird
User9: possibly one of my models has different logging config
User9: geh
User9: yep
User9: logging-config was turned up on the model with spaces/non-working one
juju-dev
Ubuntu IRC