[02:20] axw: sorry, finger slipped :-) [02:20] wallyworld: bye :p [04:13] * thumper is done [04:14] laters === kadams54 is now known as kadams54-away [09:02] dimitern: hangout? [09:03] dimitern: http://reviews.vapour.ws/r/1970/ [10:38] TheMue, LGTM [10:43] dimitern: thx [10:44] dooferlad: thanks [11:48] dooferlad: failing tests, so I'll have to investigate and resubmit [11:48] dooferlad: on my branch (thought I'd run the tests - but obviously not) [11:53] voidspace, TheMue, dooferlad, guys, I'm not feeling well and need to get some rest, so I might be back later in the evening [11:53] dimitern: oh, hope you'll get well soon [11:54] thanks === kadams54-away is now known as kadams54 === anthonyf is now known as Guest97499 [13:00] anyone know how to bootstrap a local provider without apt-get installing juju-local [13:00] ? [13:00] i really don't want to have juju-local installed because i never ever want to use /usr/bin/juju [13:01] fwereade: ^ ? [13:01] rogpeppe, afraid not [13:01] rogpeppe, I don't mind having a /usr/bin/juju hanging around :) [13:01] fwereade: problem is, i can remove /usr/bin/juju but it keeps on *coming back* [13:02] fwereade: i like being able to do go install juju/... and then running "juju". it always surprises me when it chooses /usr/bin/juju [13:02] rogpeppe: curtis has a fake juju-local package [13:02] that you can install, plus the real deps of juju-local [13:02] mgz: ha, that would be great (although, wtf!) [13:03] ISTM that juju should check for the actual deps it needs, not juju-local per se [13:03] rogpeppe, to be fair it's not optimal: I do have a mild `ll $(which juju)` habit [13:03] mgz: know where i can get it from? [13:04] trying to find it again [13:04] mgz: ta [13:05] rogpeppe: forwarded you mail [13:05] mgz: thanks! [13:06] I presume it still works, is a hack from a year ago [13:06] * rogpeppe tries to remember how to install debs directly [13:06] dpkg -i [13:07] ah dpkg [13:07] i should do it more often [13:11] mgz: thanks, that worked nicewly [13:11] nicely, even [13:11] Bug #1464356 changed: TestCloudInit fails

[13:16] hi [13:16] soulc somebody take a look at http://reviews.vapour.ws/r/1116/ and tell me if it's a bad idea? [13:17] is dimitern off today? [13:17] if so, probably want someone else to fix the 1.24 branch [13:18] s/soulc/could [13:18] see bug 1464356 [13:18] Bug #1464356: TestCloudInit fails

[14:00] ug, why the heck does juju/errors/NewErr return a value that does not satisfy the error interface? :/ [14:01] natefinch: because satisfying the interface is too mainstream [14:02] perrito666: It just means that you can't use that function to directly embed the value into another error type... which is the only reason that function even exists. [14:03] natefinch: standup [14:03] wwitzel3: not sure if you're here yet, but standup if you are [14:05] katco: coming' [15:05] hello, re restrictions (block/unblock), does an unblock override a restriction set in environments.yaml ? === kadams54 is now known as kadams54-away [15:54] is anyone who worked on status-history aroound? [15:55] fwereade: I am [15:56] perrito666, so, we seem to do things quite strangely there [15:56] tell me [15:56] perrito666, ISTM that we destroy history before we're finished with it [15:56] perrito666, and that unit.Destroy now runs 2 transactions in flagrant violantion of sense or sanity [15:57] fwereade: mmm, destruction of history was one of the things that I was unsure of [15:57] fwereade: wanna hangout? [15:58] perrito666, sure, start one [15:59] fwereade: come to https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand it is a deserted land at this time of the day [15:59] perrito666, by which I mean "please, good sir, would you be so kind as to start a hangout and invite me to join it" :) [16:24] Bug #1466269 changed: bootstrap instance started but did not change to Deployed

[17:32] ericsnow, katco: I'm not going to be able to get this landed before I get back, which will be in approximately 2 hours. Sorry, the rebase caused some conflicts, and I evidently did the wrong thing when merging them (i.e. I had removed plugin.go from the process dir in my branch, and it looks like more was added to that file in eric's branch). === kadams54-away is now known as kadams54 [17:32] natefinch: if you don't mind, I can take a stab at getting it merged... [17:33] ericsnow: natefinch: we can wait since our planning meeting is on mon [17:33] katco, natefinch: k [17:33] ericsnow: you're welcome to. [17:33] natefinch: but we do need that landed today i think [17:33] katco: yep [17:34] katco: it's a matter of putting back the plugin.go file and removing the launch details struct from it, I believe. [17:34] ericsnow: ^ [17:34] natefinch: if it can wait it will probably be better for you to sort it out [17:34] ericsnow: that's fine [17:34] I should have time [17:34] gotta run [17:34] natefinch: also, considering merging rather than rebasing === natefinch is now known as natefinch-afk [17:35] natefinch: take care [18:03] Bug #1466951 opened: juju no-proxy does not work with apt-http-proxy === bcsaller_ is now known as bcsaller === kadams54 is now known as kadams54-away [19:06] i have the machine-0 jujud agent consuming our entire cpu on both of our environments, independantly [19:06] has anyone here seen this before? [19:06] Bug #1466969 opened: Upgrading 1.20.14 -> 1.24.0 fails

[19:09] moqq: not me, is there any logging that we can see? [19:10] after startup everything appears idle from the logs, strace reveals its spending a lot of time on futex [19:10] i can grab the startup logs one sec [19:11] mongo also is spiking a lot with it [19:11] moqq: juju version? [19:11] less consistently, but there seems to be a lot of activity between them [19:12] 1.23.3-trusty-amd64 === kadams54-away is now known as kadams54 [19:22] perrito666: https://gist.github.com/tysonmalchow/765ed773a7edfc0a2f96 is the startup log [19:23] moqq: weird, I see nothing out of the ordniary :( [19:27] :( [19:28] i really dont want ot have to scrap juju 1 month after getting it into our production env… but unless i can fix this we’re going to have to :( [19:29] moqq: sadly it is friday afternoon so not many people around to help either, if you can hold it is very likely that more of us around could solve your issue [19:30] okay well that’s comforting to hear [19:31] moqq: though the last link they passed in #juju seems relevant [19:32] yeah i’ve tried as many permutations of the advice on that thread as possible to no avail so far === natefinch-afk is now known as natefinch [19:48] ericsnow: doing the fixup now. I noticed your LaunchDetails validate method errored if status is empty.... do we really want to error in that case? Seems like ID should be required, but status is just a nice to have. [19:50] natefinch: one key motivation for this feature is to display the current status of a managed workload process, so I'm leaning toward always requiring it [19:51] ericsnow: fair enough [19:55] ericsnow: so, thinking about this some more.. it's somewhat problematic. We've told the plugin to launch a process, and presumably it has. It has returned an ID, but no status.... returning an error from Launch would probably make the rest of the system think that no process was launched, even though one was. I'm worried that'll leave people in a weird state. [19:55] ericsnow: I guess the error from launch would cause whatever hook is firing to go into an error state... which might be good enough, since it should only happen at dev time [19:56] (hopefully) === kadams54 is now known as kadams54-away [20:00] natefinch: that sounds right [20:01] yay, I got the most totalitarian rb id yet [20:01] http://reviews.vapour.ws/r/1984/ [20:04] fwereade: loooool [20:05] fwereade: double plus good [20:06] Bug #1466984 opened: juju cannot remove-machine even with --force [20:07] means we had at least that amount of reviews in a year [20:07] perrito666: less than a year, really [20:07] less? [20:07] mm true, was around july right? [20:08] perrito666: something like that... I forget exactly when it went live.. .august even, I thought [20:08] perrito666: I dunno, it took ericsnow forever to get that thing deployed ;) [20:08] I do recall we showcased it in the induction sprint for ericsnow and katco [20:08] natefinch: :) [20:09] and at that point it was near the 4th of july because we had this very cool trip to boston with many patriotic things going on [20:09] perrito666: ericsnow: we decided to move to RB at my induction sprint. implementation was that winter. [20:09] perrito666: ericsnow: sometime between oct.-dec. [20:09] Bug #1466984 changed: juju cannot remove-machine even with --force [20:11] katco, perrito666: first one (mid-September): http://reviews.vapour.ws/r/18/ [20:12] Bug #1466984 opened: juju cannot remove-machine even with --force [20:15] ericsnow: what do you think about the proc-register command needing to pass the same format as launch returns? i.e. id and status both in a json blob? [20:15] ericsnow: would let us reuse more code and keeps the API consistent [20:15] natefinch: makes sense [21:01] ericsnow, katco: I'm going to have to finish up this merge tonight.... there's just a ton of places where we're using the old process.LaunchDetails that need to be modified to use plugin.ProcDetails. [21:01] natefinch: k [21:01] also ericsnow - env_test.go:80: envSuite.TestUnparseEnvOkay - this is relying on map ordering... you need to use jc.SameContents [21:01] natefinch: k please make sure it gets done [21:01] natefinch: k [21:01] katco: I will. Sorry, been busting my butt, but there was a lot more to the merge than I had hoped. [21:02] katco: I have a couple more hours of work time to get it done tonight and I think I'n really close right now. [21:02] katco: just gott arun for dinner.. natives are restles === natefinch is now known as natefinch-afk === kadams54 is now known as kadams54-away [23:16] Bug #1466984 changed: juju cannot remove-machine even with --force === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away