[01:40] Bug #1647897 opened: Juju bootstrap proxy support === iatrou_ is now known as iatrou === Tribaal_ is now known as Tribaal === frankban|afk is now known as frankban [09:56] hello folks. We have about 120 nodes constantly being deployed and redeployed by juju in a CI [09:56] this environment has been online for a while now [09:56] as a result, some collections have grown quite a bit [09:56] one of them is: presence.beings [09:56] juju:PRIMARY> db.presence.beings.count() [09:56] 1646080 [09:57] the other was logs.logs (which had about 14.000.000 entries) [09:57] gsamfira: hey [09:57] hey perrito666 [09:57] gsamfira: logs should be rotated, something is wrong there [09:57] I don;t think juju got a chance to rotate [09:58] the db was under huge load [09:58] gsamfira: but the rotation is done by juju [09:58] and by rotation I mean just deletion [09:58] mostly because of a bunch of queries against precence.being [09:58] which had no index on model-uuid [09:58] and did a COLLSCAN for every query [09:59] gsamfira: this is 2.x? [09:59] I can imagine. But juju kind of stopped working, erroring out with i/o error while talking to mongo [09:59] 2.0.1 [09:59] i/o error and i/o timeout [10:00] I had to drop all connections to the state machine port, go into the database and create an index in presence.beings [10:00] db.presence.beings.createIndex({"model-uuid": 1}) [10:00] also on txns [10:00] db.txns.createIndex({"s": 1}) [10:00] just to get rid of a lot of spam in syslog about COLLSCANs [10:01] thumper: babbageclunk any of you might be interested in this? [10:01] also dropped all logs and saved 1.3 GB of disk space [10:01] gsamfira: lol [10:01] o/ [10:01] so, for how long has this been running? [10:01] the state machine is a 16 CPU core, 32 GB of RAM VM hosted on RAID10 10kRPM SAS disks [10:01] gsamfira: logs is a capped collection so size bound [10:02] presence is bollocks [10:02] Bug #1647897 changed: Juju bootstrap proxy support [10:02] and grows forever [10:02] also might be worth mentioning we have enabled HA on this particular setup [10:02] thumper: ouch [10:02] 2 low hanging fruit we can implement is simply creating indexes on stuff we query [10:03] especially if we query those frequently [10:03] the environment has been up for a couple of months I think [10:03] lemme check [10:05] since october. Rougly 2 months [10:05] perrito666: ^ [10:06] gsamfira: tx that is a nice point of data [10:06] http://paste.ubuntu.com/23592735/ <-- this might also be of interest [10:06] this is a CI environment, a lot of units get torn down and spun up again [10:06] so there is a lot of traffic [10:08] perrito666: juju:PRIMARY> db.statuseshistory.count() [10:08] 1810513 [10:08] so you get an idea [10:08] :) [10:09] gsamfira: that is quite a reasonable size for status :) because its also capped but that one seems to be working [10:10] yup. The environment seems stable again after creating the indexes and cleaning the logs [10:11] gsamfira: that is good to know :) a quick workaround and low hanging fruit all together [10:12] I'll create a patch for the indexes later this week [10:17] voidspace: http://streams.canonical.com/juju/tools/agent/2.0.2/ [10:20] Bug #1357760 changed: ensure-availability (aka HA) should work with manual provider [10:20] Bug #1493058 changed: ensure-availability fails on GCE [10:20] Bug #1512569 changed: UniterSuite.TestRebootNowKillsHook fails with: uniter still alive [10:20] alexisb: can you backport your fix for bug 1631369 for 2.0 branch as well? [10:20] Bug #1631369: ExpireSuite.TestClaim_ExpiryInFuture_TimePasses took way too long [10:21] mgz, sure [10:44] perrito666: I've created https://github.com/juju/juju/tree/feature-persistent-storage [10:44] axw_: ack [10:44] axw_: we should propose against that I presume [10:45] perrito666: yup, so we don't mess up 2.1 [10:45] we dont mess up things, we awesome-ize them [10:47] Bug #1557726 changed: Restore fails on some openstacks like prodstack === akhavr1 is now known as akhavr [12:46] thumper: https://bugs.launchpad.net/juju/+bug/1648063 [12:47] Bug #1648063: kill-controller removes machines from migrated model === freyes__ is now known as freyes [12:56] jam: from within a hook context (debug-hooks) is there a way to get a list of all the bindings defined for the charm? [12:57] frobware: ^^^ do you know? [13:00] voidspace: generally it will be the things listed under "provides" or "requires" in charm-metadata.yaml [13:00] voidspace: https://github.com/frobware/testcharms [13:01] jam: referring to the charm is what I was hoping to avoid [13:01] jam: but thanks [13:01] :-) [13:15] voidspace: :/ had hoped but nothing here of use https://jujucharms.com/docs/2.0/authors-hook-environment [13:16] rick_h: it would be a nice tool to have [13:16] rick_h: however... [13:16] rick_h: I have now torn down that environment and frobware has a test charm that I can deploy locally [13:16] rick_h: that defines useful stuff explicitly for playing with bindings [13:17] voidspace: yea, all good. Just noting that I can't find anything useful for what you were asking [13:17] rick_h: thanks for lookinh [13:17] rick_h: *looking [13:17] rick_h: but frobware has useful tools for playing with network-get [13:25] Review me? 2 line change: https://github.com/juju/juju/pull/6670 [13:56] babbageclunk: https://github.com/juju/juju/pull/6669 === jamespag` is now known as jamespage [15:59] perrito666: http://reports.vapour.ws/releases/4631/job/functional-backup-restore/attempt/4900 [16:50] Bug #1625624 changed: juju 2 doesn't remove openstack security groups === frankban is now known as frankban|afk