[00:00] <hml> anastasiamac: do you have a few minutes for an HO?  prep on bugs.
[00:00] <anastasiamac> hml: for u - anytime!
[00:01] <hml> anastasiamac: takeover my squad standup HO again?
[00:01] <anastasiamac> hml: i'll setup a eg meeting for this.. gimme a sec..
[00:01] <hml> anastasiamac: sure
[00:03] <anastasiamac> hml: should b in ur calendar, m in HO now
[00:03] <hml> anastasiamac: saw it, trying to get there… the double quotes are just ringing.  :-)
[00:03] <anastasiamac> k ;)
[00:09] <wpk> anastasiamac: everything ok, just commenting on babbageclunk talking to babbageclunk :)
[00:11] <babbageclunk> wpk: It's not surprising really, I talk to myself more than ever since I started working remotely.
[01:18] <menn0> wallyworld: do you happen to know why we don't create new sessions when running transactions, but do when querying?
[01:19] <wallyworld> menn0: no, not off hand. i guess we should be consistent though. not sure why there was that difference
[01:21] <menn0> wallyworld: i'm wondering if that's hurting performance. AFAICS all transactions use the State's own session.
[01:21] <wallyworld> we only started creating copies of sessions due to sessions being close under us and panicing
[01:22] <wallyworld> there's 2 modes - copy and clone (from memory)
[01:22] <menn0> yes that's right
[01:22] <menn0> for txns we don't do either
[01:23] <wallyworld> i don't really have an insight at this stage as to the reasoning
[01:23] <menn0> wallyworld: actually ignore everything I just said
[01:23] <menn0> wallyworld: I found the session copying
[01:23] <menn0> all good
[01:24] <wallyworld> that's good because i was sarting to wonder wtf
[01:32] <wallyworld> axw: babbageclunk: standup?
[01:32] <babbageclunk> doh, sorry
[02:01]  * babbageclunk needs to duck out for a bit.
[02:17] <thumper> anyone... https://github.com/juju/description/pull/10
[02:20]  * anastasiamac looking
[02:29] <thumper> axw: got a few minutes?
[02:29] <axw> thumper: yup?
[02:29] <thumper> actually... I think I'm ok
[02:29] <thumper> let me try something
[02:30]  * thumper mutters
[02:30] <thumper> axw: actually, quick call could help
[02:30] <thumper> and you can tell me if I'm crazy or not
[02:31] <axw> thumper: don't need a call for that... ho ho
[02:31] <axw> thumper: sure, umm, friday standup hangout?
[02:31] <thumper> sure
[02:44] <thumper> anastasiamac: thanks
[02:44] <anastasiamac> thumper: \o/
[02:55] <thumper> wallyworld: I'm going to put the state.Export of remote applications behind a feature flag because it doesn't handle status
[02:56] <thumper> and add a skip to the test until you fix it
[02:56]  * thumper thinks...
[02:56] <thumper> perhaps I'll just add a skip to the test
[02:56] <thumper> wallyworld: should I file a bug for it?
[02:57] <wallyworld> thumper: it will only have any to export if the cross-model flag is turned on
[02:57] <wallyworld> so without cross-model flag it should not be an issue
[02:57] <thumper> but it is broken
[02:57] <thumper> well... no
[02:57] <thumper> because state.Export tries
[02:58] <thumper> and it not fails a more strict export test
[02:58] <thumper> s/not/now
[02:58] <thumper> there is a status document for the remote app created
[02:58] <thumper> that isn't exported
[02:58] <thumper> and the remote application in the description package doesn't support Status
[02:58] <thumper> so it is missing bits
[02:58] <thumper> so... how do you want to limit this?
[02:59] <thumper> at the very least, the test needs a skip
[02:59] <wallyworld> ok, we can skip the test. in production it will not happen as there are no remote apps
[02:59] <wallyworld> i'll add a card to our board
[02:59] <thumper> sure, so do you want a bug?
[03:00] <wallyworld> i'll just add a card
[03:00] <thumper> k
[03:00] <wallyworld> if we filed bugs afor all the cmr work, there would be 1000000s
[03:00] <wallyworld> are you landing anythng? i can skip the test as a drive by
[03:02] <thumper> I am landing a more strict test
[03:02] <thumper> so I'll and the skip as it is my code causing it to fail
[03:03] <wallyworld> ok
[03:05] <wallyworld> babbageclunk: here's a small PR to rename the facade watcher api https://github.com/juju/juju/pull/7174
[03:10] <babbageclunk> wallyworld: ok, looking
[03:19] <babbageclunk> wallyworld: how's the flooding?
[03:25] <wallyworld> babbageclunk: hey, ok at the moment, am keeping an eye on it
[03:45] <thumper> next bit: https://github.com/juju/juju/pull/7176
[03:45] <anastasiamac> thumper: looking :D
[03:45] <thumper> I'm off to a BJJ seminar and grading now
[03:45] <thumper> catch ya tomorrow
[03:46] <wallyworld> babbageclunk: did you want a final catchup before you go for the day?
[03:47] <babbageclunk> wallyworld: oh, yup - I'm around for a bit longer but let's do it now.
[03:47] <wallyworld> ok
[05:05] <menn0> thumper, axw: here's the txn pruning fix: https://github.com/juju/txn/pull/22
[05:05] <axw> menn0: looking in a sec
[05:05] <menn0> thumper, axw: it hardly uses any memory and is so much faster
[05:06] <axw> menn0: awesome :)
[05:06] <menn0> 173% in my test
[05:09] <axw> menn0: how do you figure 173%? 154->11 is an order of magnitude
[05:09]  * axw reviews the actual code
[05:15] <axw> menn0: also, were you running on a recent db with the "s" index I just added?
[05:15] <menn0> yeah 173 isn't right
[05:16] <menn0> axw: should be approx -93%
[05:16] <menn0> axw: no, this was old dump from a production issue
[05:16] <axw> menn0: I'd be curious to know how much faster it'd run with the index, since the aggregation pipeline should use that?
[05:17] <menn0> axw: I believe the agg pipeline uses indexes
[05:17] <axw> anyway, it'll only be better, not worse
[05:18] <menn0> axw: loading all the txn ids now takes about 2 mins on my machine with that db dump. it's a significant part of the 11 mins but not the biggest part.
[05:18] <axw> menn0: ok, not too bad
[05:20] <menn0> axw: i've got to stop for now but will be back later on
[05:20] <menn0> i want to get this merged and used by juju
[05:21] <axw> menn0: no worries. still reviewing, should be done by then
[05:52] <jam> menn0: I reviewed your patch
[06:23] <anastasiamac> veebers: we have troubles landing https://github.com/juju/juju/pull/7175 for "ciritcal" hml fix
[06:23] <anastasiamac> veebers: because of grant test...
[06:24] <anastasiamac> can we make it gate landing past beta2?... or make the test more reliant?
[06:25] <wallyworld> i am assuming it is flakey because the landing before passed ok
[06:25] <wallyworld> and the one that fails is only an openstack change
[06:28] <veebers> anastasiamac: ah I wonder if the test fix for that didn't land. One sec I'll make sure the machines have the right version of code
[06:28] <anastasiamac> veebers: \o/
[06:29] <veebers> anastasiamac: note there was a fix for the grant/revoke password issue that balloons and i discussed this morning, it's possible that machines didn't get the update
[06:30] <anastasiamac> veebers: if it's something that u can do, we can land the fix that is currently blocking beta2... :D
[06:31] <veebers> anastasiamac: aye. If this doesn't work we'll get it unblocked. It's possible that if a run is in motion now for that branch it'll fail (as the update is going out now) but the next after that should be fine. And if it isn't we'll change the grant/revoke so it's not blocknig merge
[06:31] <anastasiamac> veebers: awesome - tyvm!
[06:32] <veebers> anastasiamac: I'm just going out for food. If that run fails for that branch, retry it if that one fails I'll fix it
[06:35] <anastasiamac> veebers: k. will do
[08:53] <menn0> axw, jam: thanks for your reviews. I've responded, sometimes in depth :)
[08:53] <axw> menn0: thank you for fixing
[13:08] <frankban|afk> axw: could you please take a look at this quick branch? https://github.com/juju/juju/pull/7179
[13:16] <jam> frankban|afk: axw: I think we'd need a team review before we add a dependency
[13:17] <frankban|afk> alright
[13:28] <jam> wpk: sorry I missed standup. my IRC has been flaky and I lost track of time
[13:28] <jam> want to meet quickly?
[13:28] <wpk> kk
[13:28] <wpk> waiting for you
[14:10] <jam> frankban: any chance you could send us some details about why that particular library, possible alternatives, etc?
[14:23] <frankban> jam: didn't do too much research, I started by doing it without an external library, and when the code started to grow I checked if there was already a lib, and that one from nytimes is the first result on google for "golang gzip http". the code seems similar to what I was originally writing, except a bit more sophisticated (sync.Pool), but it's tested and has benchmarks, so I went for it. The API is
[14:23] <frankban> reasonable, basically just a decorator fo http.Handler. I'd have no problem to switch to gorilla https://godoc.org/github.com/gorilla/handlers#CompressHandler if you prefer
[14:24] <jam> frankban: offhand we're already using gorilla for websocket it might make more sense
[14:24] <jam> but I haven't reviewed either package
[14:26] <mup> Bug #1662857 changed: cannot go get the source code  <juju-core:Confirmed> <https://launchpad.net/bugs/1662857>
[14:29] <frankban> jam: the gorilla one seems more straightforward. the nytimes one, on the other end, does not create a gzip writer for every request. it's a tradeoff, gorilla is more known as a lib I understand
[14:29] <jam> frankban: ultimately there is the burden of "how do we get patches, who maintains it, etc" where it feels gorilla is more likely to get updates
[14:30] <frankban> jam: ok, let me move that to using gorilla
[14:32] <mup> Bug #1662857 opened: cannot go get the source code  <juju-core:Confirmed> <https://launchpad.net/bugs/1662857>
[14:38] <mup> Bug #1662857 changed: cannot go get the source code  <juju-core:Confirmed> <https://launchpad.net/bugs/1662857>
[15:40] <frankban> jam, axw: ok updated https://github.com/juju/juju/pull/7179 to use gorilla/handlers