[00:12]  * babbageclunk goes for a run, bye!
[00:13]  * babbageclunk comes back, just want to $$merge$$ that PR first
[00:31] <katco> menn0: thanks for the feedback. i responded to a few of your comments and i'm implementing the others
[00:33]  * babbageclunk is actually foing for a run now.
[00:33]  * babbageclunk gah, going
[00:36] <anastasiamac> axw: as an OCR, there is also this PR that's worth looking at :D https://github.com/juju/juju/pull/6563
[00:40] <menn0> katco: looks good. i've approved the pr.
[00:40] <katco> menn0: ta
[00:41] <mup> Bug #1468752 opened: "juju ssh" adds an additional strings to all commands when used on Windows, in interactive mode <ssh> <windows> <juju:In Progress by gz> <juju 2.1:In Progress by gz> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1468752>
[00:49] <anastasiamac> wallyworld: u r off the hook - all is good in the land :)
[00:49] <wallyworld> yay
[00:50] <anastasiamac> menn0: ping me when u want a break from migrations (not in the next 30mins tho)
[00:52] <menn0> anastasiamac: ok
[01:37] <thumper> menn0: you'd think that finding this would be easy...
[01:37]  * thumper grumbles
[01:52] <menn0> anastasiamac: now?
[01:53] <menn0> babbageclunk: your last merged PR was perfect timing. I needed exactly the changes you made for something I'm doing.
[01:56] <anastasiamac> oh menn0'
[01:56] <anastasiamac> i mean 'ok menn0'... h is the new k, right?
[01:56] <anastasiamac> ho or irc?
[01:57] <menn0> anastasiamac: HO is probably more efficient
[02:01] <babbageclunk> menn0: :)
[02:32] <menn0> anastasiamac: just noticed this: https://github.com/natefinch/lumberjack/pull/16
[02:33] <menn0> anastasiamac: someone already has a PR up that does gzip compression on rotation
[02:33] <menn0> seems like it's close to ready
[02:33] <anastasiamac> menn0: \o/ this will make asking Nate nicely even easier :D
[02:34] <menn0> anastasiamac: and it will give him permission to work on it during work hours
[02:38] <anastasiamac> axw: this one does not seem to be transacation related... https://bugs.launchpad.net/juju/+bug/1644396
[02:38] <mup> Bug #1644396: machine-0 takes up massive memory, slows down to unusable, "upgrade in progress" loops <juju:New> <https://launchpad.net/bugs/1644396>
[02:39] <anastasiamac> transaction* (who needs to type today?)
[02:41] <axw> anastasiamac: interesting. I don't have time to look into it atm, doing OCR
[03:30] <babbageclunk> thumper, menn0: Should I be deleting logs for the migrated model from the source controller after the transfer is complete?
[03:30] <thumper> babbageclunk: I'd say yes
[03:30] <thumper> menn0: ?
[03:31] <babbageclunk> migrating back and forth between two controllers, now I've got quite a lot of logs.
[03:33] <menn0> babbageclunk: yes I think so
[03:33] <menn0> otherwise they'll never go away
[03:33] <menn0> babbageclunk: in fact, that should be part of the REAP phase
[03:40] <wallyworld> anastasiamac: i cannot reporduce any "unknown remoteApplications collection" errors. The only bug I can see refers to the cmr feature branch which has been obsolete for some time now. Do you have any recent occurrences?
[03:41] <anastasiamac> wallyworld: let me have a look at CI logs.. this were i saw them yesterday :)
[03:42] <anastasiamac> wallyworld: it's behind feature flag on both 2.0 and develop, right?
[03:43] <wallyworld> always has been :-)
[03:43] <wallyworld> unless i missed a place
[03:43] <wallyworld> but i diffed 2.0 and develop
[03:45] <anastasiamac> wallyworld: k.. i'll ping u if i find anything :) pretend everything is awesome for now... \o/
[03:45] <wallyworld> ok
[03:45] <wallyworld> i couldn't see anything
[03:55] <anastasiamac> wallyworld: so... in the latest develop run, http://reports.vapour.ws/releases/4591, go to first failure - azure - http://reports.vapour.ws/releases/4591/job/azure-arm-native-deploy-bundle/attempt/1017
[03:55] <anastasiamac> wallyworld: under artifcats, open up controller/machine-0/machine-0.log.gz
[03:55] <anastasiamac> wallyworld: lines from 1447 :)
[04:03] <jam> menn0: are you still able to meet today?
[04:23] <wallyworld> axw: i've not used the new worker catacomb before - i didn't know about Plan.Init. but that makes it much easier
[04:31] <axw> wallyworld: cool
[04:32] <axw> wallyworld: catacomb makes this particular worker a whole lot easier to write in general
[04:32] <wallyworld> axw: even though i wasn't using Init, the logic resulted in te same thing but the code was clumsy
[04:32] <natefinch> menn0, anastasiamac: just saw your ping about log compression
[04:32] <wallyworld> yeah, the catacomb is nice
[04:32] <axw> wallyworld: not quite, because if Invoke failed, you weren't killing the watcher (unless I missed something)
[04:33] <wallyworld> axw: the invoke could only fail if things were not properly set up. and those same failures would not see the init thngs registred either
[04:33] <axw> wallyworld: Invoke *always* kills the Init workers, regardless of how it fails. see the defer at the top of Invoke
[04:34] <wallyworld> oh, so it does
[05:11] <wallyworld> axw: testing the sub worker wait errors will be a pita since there's no easy way right now to override the Wait() methods
[05:13] <wallyworld> i could override the new() methods in export test and use a shim where i control the error
[05:13] <wallyworld> or go all the way and pass in the new methods via the worker config
[05:13] <wallyworld> or i could ignore for now
[05:15] <axw> wallyworld: that doesn't sound quite right. I think you should have ObserveRelationUnitsChange return an error; trigger a RU change; trigger a relation change, and arrange for it to be NotFound
[05:15] <axw> wallyworld: that would cause it to try and stop the RUW, at which point it'll get the error that ObserveRelationUnitsChange returned
[05:16] <wallyworld> axw: aren't we talking about the worker.Stop() errors being propagated?
[05:16] <wallyworld> they are the ones i was ignoring
[05:17] <wallyworld> i can also add that other scenario
[05:18] <axw> wallyworld: if you cause the RUW to fail atm (e.g. by having Observe... return an error), what happens to the remote application worker?
[05:20] <wallyworld> it should exist with that error, but there's no test for that, i'll add one
[05:20] <wallyworld> *exit
[06:13] <wallyworld> axw: i've pushed some changes to fix some races, should be good now i think
[06:13] <axw> wallyworld: ok, looking
[06:32] <wallyworld> axw: thanks for review. so many pieces to this cmr puzzle. will be several more prs yet
[06:33] <wallyworld> axw: i have a one liner as well https://github.com/juju/juju/pull/6610
[06:49] <anastasiamac> axw: i have a small but volatile one too :-P ... yes, wallyworld :) https://github.com/juju/juju/pull/6422
[07:01] <axw> anastasiamac: reviewed
[07:24] <frobware> axw: thanks for the review comments
[07:47] <anastasiamac> axw: thnx \o/
[08:08] <SimonKLB> would it be out of the question to allow some kind of generic relation where the only thing youre really interested in is the name of the other charm you add the relation to? a relation that didnt require an interface that is
[10:01] <macgreagoir> jam frobware voidspace: Any need for the regular juju-core-team HO?
[10:02] <jam> macgreagoir: given Turkey day, I'd guess not many will show, thoughts?
[10:02] <macgreagoir> Likely just the same people as the stand-up later. I say can it.
[10:03] <jam> macgreagoir: nobody is there right now, at least.
[10:03] <jam> just me
[10:03] <macgreagoir> I just left :-)
[10:43] <anastasiamac> axw: add-model help PR updated.. :)
[11:03] <jam> frobware: I need to grab some food, but I'll join the hangout in a moment.
[11:03] <frobware> jam: np
[11:04] <jam> I ended up doing back-to-back meetings today and haven't carved out food time yet.
[11:18] <axw> anastasiamac: thanks, your wording on name uniqueness is very clear
[11:26] <jam> frobware: I'm joining the hangout now
[11:31] <anastasiamac> axw: \o/ made my day! m going to land it ;)
[11:31] <anastasiamac> axw: (especially since it's ur wording all the way!) :D
[12:16]  * perrito666 just realizes that today is a holiday in the US
[14:40] <mup> Bug #1644566 opened: juju bootstrap hangs forever at "Attempting to connect to 10.0.4.130:22" <amd64> <apport-bug> <zesty> <juju-core:New> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1644566>
[17:27] <mattyw> evilnickveitch, it's there, many thanks
[18:37] <mup> Bug #1644566 changed: juju bootstrap hangs forever at "Attempting to connect to 10.0.4.130:22" <amd64> <apport-bug> <zesty> <juju-core:Invalid> <golang (Ubuntu):New for mwhudson> <juju-core (Ubuntu):Invalid> <lxd (Ubuntu):Invalid> <https://launchpad.net/bugs/1644566>
[20:24] <babbageclunk> hey menn0, I proved to myself that mongo's sort isn't stable, quelle surprise. Do  you think it would be feasible to add _id to the model,time index?
[20:25] <menn0> babbageclunk: so make the index model,time,_id?
[20:25] <babbageclunk> yeah
[20:25] <menn0> that should be fine
[20:25] <menn0> queries that use model,time will still take advantage of the index
[20:26] <babbageclunk> menn0: I'm just making a test to show the problem and then I'll try that.
[21:49] <babbageclunk> menn0: quick review? https://github.com/juju/juju/pull/6612/files
[21:51] <menn0> babbageclunk: give me 5 mins
[21:54] <babbageclunk> menn0: no rush
[21:55] <babbageclunk> menn0: I meant quick in the sense that it should be straightforward, not "hey do this quickly"! :)
[21:59] <menn0> babbageclunk: got it :)
[22:41] <menn0> babbageclunk: your change looks great but something needs to remove the previous index
[22:41] <menn0> babbageclunk: the correct way to do that is to add an upgrade step
[22:42] <menn0> babbageclunk: have you done one before? I can guide you through it.
[22:47] <babbageclunk> menn0: No, I haven't
[22:48] <menn0> babbageclunk: quick HO?
[22:49] <babbageclunk> menn0: Sure
[22:51] <babbageclunk> menn0: https://hangouts.google.com/hangouts/_/canonical.com/menno
[23:34] <blahdeblah> Anyone around to give some quick advice/explanation on how relation scoping works in juju 1.x?  Here's my environment: https://pastebin.canonical.com/171809/
[23:34] <blahdeblah> The canonical-livepatch charm has an nrpe-external-master relation which allows it to relate to nrpe.  However, there are two nrpes in the environment with different service names.
[23:35] <blahdeblah> I've found relating it to both doesn't work; do I need two separate canonical-livepatch services to make that happen?
[23:36] <menn0> blahdeblah: let me dig into that for you
[23:37] <blahdeblah> menn0: thanks; I'm guessing this is something to do with relation scopes, which is an area that I've always found a bit head-scratchy
[23:37] <menn0> blahdeblah: you're not the only one :)
[23:37] <blahdeblah> I'm glad. :-)
[23:38]  * blahdeblah goes to re-read charm author doc on that stuff
[23:38] <menn0> blahdeblah: when you say "relating it to both doesn't work", is Juju giving you an error or the relation doesn't do what you expect?
[23:39] <blahdeblah> it just never seems to build the relation
[23:39] <blahdeblah> No errors or anything; it's just that nothing seems to happen in debug-log
[23:43] <menn0> blahdeblah: so in your environment what is canonical-livepatch subordinate to?
[23:43] <blahdeblah> the main primary charm
[23:43] <blahdeblah> but we need to add the relation to the nrpe charm so that canonical-livepatch produces a nagios check which we can monitor
[23:44] <blahdeblah> I've looked at the source of both charms, and they're both set to use container scope for the nrpe-external-master relation, which is correct from my reading of the documentation.
[23:45]  * menn0 looks at the code
[23:46] <menn0> blahdeblah: actually, i've got a standup now... back in a bit
[23:46] <blahdeblah> no worries - thanks anyway