[01:46] axw: PTAL? https://github.com/juju/juju/pull/7193 [01:48] anastasiamac: looking [01:50] anastasiamac: looks good apart from the panic inducing change made to defer order [01:52] axw: oh k -dunno how i kept that one ;) i'll revert that little tidbit ;) [01:56] anastasiamac: LGTM [01:56] \o/ [02:22] Can anyone advise on what the minimum instance size for 2.1.2 controller in Azure would be? I'm using a trial account, so I need to use the smallest possible instances. [02:36] blahdeblah: it depends how many models and units you intend on running with the controller [02:36] menn0: one A0 VM per region, for as many regions as the trial account will allow me [02:36] So probably around 10-15 VMs total [02:37] They'll be cs:ubuntu primaries, with telegraf, ntp, and maybe landscape-client subordinates [02:37] blahdeblah: I haven't used azure much but looking at their machine types an A-Small or A-Medium should do it [04:26] menn0: a small interesting 'mongo' thing. It seems aggregation pipeline has a $split operator, but it doesn't work everywhere. I don't know if it works in 3.4 (laptop) and not 3.2, or whether it doesn't work when you disable the V8 engine. [04:28] menn0: I *almost* managed a query that would pull out TXN ids into a table, but you have to convert strings to OIDs, and there doesn't seem to be any DB level request you can do for it. it has to be done in Javascript or client-side [04:32] menn0: I also saw that you landed "$gte: 5", in my testing the time for $gte: 5 is the same as $in [5, 6] [04:32] exact match on '6' is slightly faster, but it seems better to use a forward looking [5, 6] just in case? [04:46] jam: the agg pipeline doesn't seem to be very good at using the index [04:47] jam: I went with $gte b/c that's at least fast with the index with a normal find(), but $in isn't [04:47] jam: I figured it's more likely to be fast with the agg pipeline in some future mongodb version [04:48] jam: i'm not too worried anyway... the way things are now, it's not super fast but it's probably fast enough [04:49] jam: your $split query sounds interesting... but how much would it actually help? [04:51] jam: at some point the code is still going to have to iterate the result of the agg pipeline [04:51] jam: i'm not sure that'll be much faster than iterating the docs directly [04:52] it might even be slower [05:11] menn0: well $lookup seemed interesting [05:11] as a way to do almost all the work server side [05:11] but the lack-of-object-conversion makes it not possible [05:11] I was looking for a "look for completed so I could remove them from the queues" [05:12] jam: yeah I saw that too [05:12] jam: it's also not available in mongodb 2.x so we'd have to be careful with how it was used in mgopurge [06:01] Hi all, I'm running into https://bugs.launchpad.net/juju/+bug/1656723 at the moment; is there any word on when the fix will be released? Is there a workaround? [06:01] Bug #1656723: azure: firewall rules are wiped out when a new machine is added [06:18] axw: Your name is on that bug - any suggestions? [06:20] blahdeblah: the fix listed there was merged into 2.2, which is scheduled for stable release at the end of April [06:21] jam: Thanks - any workaround in the time being? It has basically cut me off from the instance I had running. [06:21] blahdeblah: that you'd have to talk to axw [06:22] It might be faster to just redeploy === akhavr1 is now known as akhavr [06:35] blahdeblah: I think if you unexpose and then re-expose, the rules will be recreated [06:35] axw: Yes, eventually worked that out. Thanks. :-) [06:35] I'll note that on the bug for future travellers [06:36] blahdeblah: cool, thanks === frankban|afk is now known as frankban [07:22] axw: I updated https://github.com/juju/juju/pull/7180 can you give it another look? [07:36] jam: looking [07:38] jam: I agree with your assessment, that we shouldn't need to check model life because we're not creating a new thing. can you please drop the checkModelActive too then? [07:38] brb [07:40] maybe I misunderstood your reply tho [09:15] hey guys! im having some trouble using the --switch flag when upgrading an application to a different, locally built, charm [09:16] ERROR cannot upgrade "X" to "Y" [09:16] it looks like this is the cause: https://github.com/juju/juju/blob/staging/cmd/juju/application/upgradecharm.go#L508 [09:16] am i not understanding the --switch flag correctly? i thought that was the point of it [09:50] SimonKLB: u may be running into https://bugs.launchpad.net/bugs/1673122 [09:50] Bug #1673122: Incorrect series used during upgrade to a local charm and no way to specify it manually

[09:51] anastasiamac: i dont think so, the error message i get is this one: https://github.com/juju/juju/blob/staging/cmd/juju/application/upgradecharm.go#L509 [09:52] which seem to be spawned when the old and the new charm names differ [09:53] SimonKLB: feel free to file a bug, with repro scenario and logs :) [09:56] anastasiamac: found one already :) https://bugs.launchpad.net/juju/+bug/1666904 [09:56] Bug #1666904: upgrade-charm --switch doesn't work with local charms

[10:13] SimonKLB: \o/ i thought i saw something recently.. no wonder - it only came in a month ago ;) === lazyPower is now known as lp|swap === freyes__ is now known as freyes [14:41] hi, could somebody take a look at this: https://github.com/juju/juju/pull/6843 ? === frankban is now known as frankban|afk [20:54] morning [21:03] morning thumper [21:22] morning redir [21:25] morning babbageclunk :) [22:14] morning thumper [22:14] thumper, can we get another look at this old PR: https://github.com/juju/juju/pull/6843 [22:16] approved [22:16] thumper, thanks!