[00:25] katco: pong [01:45] let the merge wars commence [01:46] thumper wallyworld waigani anastasiamac: if you have things waiting, master is got unblocked [01:46] \o/ [01:46] naturally I started mine merging before I told you [01:46] axw: lol, cheers [01:53] Bug #1501381 changed: panic: cannot pass empty version to VersionSeries()

[01:53] Bug #1501432 changed: BootstrapSuite tests fail on non-ubuntu platforms with no matching tools

[01:53] Bug #1501786 changed: juju cannot provision precise instances: need a repository as argument

=== Guest68817 is now known as anthonyjf [02:18] perrito666: how big? [02:19] rick_h_: something that can compile mongo in less than the time it takes for launchpad I am trying to fix the willy build of a mongo3 ppa and I dont have a willy nor intentions of breaking my laptop [02:20] perrito666: what's your LP id? [02:20] rick_h_: hduran-8 [02:23] perrito666: oh bah, it's in use. [02:23] rick_h_: ?? [02:23] perrito666: well you can ssh to maas.jujugui.org and create an lxc container on that laptop and use it if you'd like, though tit's not that fast [02:24] perrito666: I thought we had an unused node in our guimaas the team uses [02:24] rick_h_: I appreciate it, ill ponder on it if I dont fall asleep on the kb before [02:24] perrito666: but looks like the team put it to use [02:25] perrito666: ok, well let me know. We've got hardware if it'll help. However you should be able to create a wily lxc and do the builds in there and keep the laptop safe [02:26] lol compiling mongo is super slow... it took forever even on my quad core i7 with a beastly SSD. That's C++ for you. [02:26] perrito666: worst case can ask urulama to take over the QA environment for a bit and get full machines [02:27] I think it took like 45 minutes on my laptop [02:27] natefinch: have a 6 core 32gb machine if the instructions are easy for me to dupe [02:29] rick_h_: I haven't done it in like a year, but IIRC, the directions were terrible [02:30] natefinch: :/ well if it would help happy to try to get something better working. shoot, maybe just get a giant ec2 machine for a bit. but understand if it's just a pita [02:31] it is sort of a pita, especially the one I am trying to build, which is a debian package [02:31] rick_h_: it's a good lesson for why perrito666 shouldn't buy such namby pamby laptops [02:32] lol [02:32] laptops are for portability, many core desktops with lots of ram for real work :) [02:32] natefinch: my laptop kicks ass, I just dont want to install willy on it [02:32] haha [02:32] perrito666: but surely in an lxc it's safe? [02:32] rick_h_: ill give it a shot, I hadn't thought of it [02:32] perrito666: just giving you shit :) [02:33] natefinch: so is mongo :p [02:33] I really need to buy some heavy lifting machine I am just too lazy to import it [02:33] and to cheap to pay local price for what I can get here [02:33] perrito666: probably easier to just get us to stop using mongo [02:35] perrito666: I saw our new competitor nomad uses boltdb... which blows mongo out of the water as far as compile time and ease of setup. Of course, it doesn't have replication, so they must be doing that themselves somehow.. but still.. I love boltdb... pure Go, man. That's the way to do it. [03:18] I like boltdb, i've used it in some side-projects and it's always been great to work with. I've never really pushed it in terms of concurrent txns though. [07:11] Bug #1502016 opened: Juju-quickstart error message lacks detailed error info

[07:14] Bug #1502016 changed: Juju-quickstart error message lacks detailed error info

[07:17] Bug #1502016 opened: Juju-quickstart error message lacks detailed error info

[08:37] fwereade: Happy Birthday [08:48] fwereade, oh wow, happy birthday indeed! :) [08:50] fwereade: ¸¸♬·¯·♩¸¸♪·¯·♫¸¸Happy Birthday To You¸¸♬·¯·♩¸¸♪·¯·♫¸¸ [08:58] TheMue, dimitern, anastasiamac: <3 [08:59] * fwereade is tired and is taking a pre-travel swap day to relax [09:02] fwereade: hippy bathday fella [09:02] fwereade: enjoy the rest and seattle [09:02] voidspace, cheers :) === Spads_ is now known as Spads [09:21] frobware: dimitern: conflicts resolved and unit public address branch set to attempt to land on master (again...) [09:21] mfoord, awesome! [09:21] frobware: dimitern: ec2 subnets branch also landing on master [09:21] mfoord, [09:22] mfoord, and it did land on 1.25 alread? [09:22] dimitern: yup, already landed there [09:22] * dimitern gaahh I seem to be eating letter today [09:22] :-) [09:34] mfoord: fancy a review? http://reviews.vapour.ws/r/2822 [09:36] rogpeppe: sure, coffee first [09:36] mfoord: ta! [10:11] rogpeppe: the only wart is having assertErrorResponse return the failure for a single use case [10:12] mfoord: yeah, i had to think a bit about that [10:12] mfoord: if you've got a better suggestion... ? [10:12] rogpeppe: haha, not sure I do :-) [10:12] I'll have another look [10:12] the rest is straightforward [10:13] mfoord: thanks [10:13] it's a common pattern in error testing (or testing in general) - to have some detail that only needs checking once [10:19] rogpeppe: as doer is only used once, and it's a one line function, does it need to be a separate function? [10:22] mfoord, is a Doer constructed by a Doerer ?:D [10:23] dimitern: the doerer is the function that does the doer [10:23] and what that does, well... [10:24] is Do()es [10:24] it even [10:25] rogpeppe: LGTM with the minor proviso about (maybe) inlining doer [10:25] mfoord: thanks [10:25] mfoord: it's like that in the other tests [10:26] rogpeppe: ah right, fair enough [10:26] mfoord: it could be inlined, but it's like it is to make it trivial to make other similar tests [10:26] ok [10:26] fine, drop the issue then [10:49] mfoord: done :) [10:50] fwereade: ping [10:57] rogpeppe: he's swapping due to Seattle [10:57] TheMue: ah, np [11:06] TheMue, reviewed - quite a lot of comments I'm afraid, ping me if anything is unclear [11:06] dimitern: ok, and I appreciate any comments [11:16] dimitern: jfi, I'll fix it in the 1.25 branch first but mark the issues in your review. later we can forward-port the 1.25 [11:26] TheMue, cheers, sounds good [11:43] niemeyer: is -run deprecated in gocheck in favor of check.f? [11:46] dimitern: great input, you speak juju networking fluently ;) changes are now visible in http://reviews.vapour.ws/r/2823/ [11:50] TheMue, looks good, thanks! I'll leave frobware / voidspace to proof-read as discussed [11:51] dimitern: cheers [12:36] TheMue, I have a few comments - just wondering whether you want to address dimiter's first before I add mine [12:37] frobware: I already have done and pushed it, see http://reviews.vapour.ws/r/2823/. [12:37] frobware: dimitern reviewed my master branch, this is the 1.25 one. [12:44] TheMue, I've add some comments but will want to take another pass. Just adding and publishing now so you're not blocked. OK? [12:44] frobware: great, thanks [12:54] frobware: deploy.go:118, singular "space" or plural "spaces"? the latter sounds more natural to me. [12:57] TheMue, You could drop this bit "but not of the cmd and the database space" [12:58] frobware: ok, thx [12:58] TheMue, leaving it as "deploy 2 instances of haproxy on cloud instances inside subnets of the dmz space only" [12:59] frobware: short and clear, sounds even better ;) [13:00] TheMue, also note I saw a reference to "carret" which should be "caret" [13:01] frobware: fixed [13:14] bogdanteleaga: Not deprecated per se.. -run still has its usual meaning, but it's orthogonal to gocheck.. The latter has check.f for its own use [13:15] niemeyer: hmm, -run doesn't seem to work for me, while check.f does with the same simple regex [13:27] Bug #1502127 opened: TestNoUniterUpdateStatusHookInError never reached desired status

[13:27] Bug #1502130 opened: charm upload fails often on maas

[13:30] Bug #1502139 opened: Panic in TestUpgradeJuju on wily and vivid

[13:33] Bug #1502139 changed: Panic in TestUpgradeJuju on wily and vivid

[13:36] Bug #1502139 opened: Panic in TestUpgradeJuju on wily and vivid

[13:51] Bug #1502139 changed: Panic in TestUpgradeJuju on wily and vivid

[13:52] what are you on mup... [13:54] Bug #1502139 opened: Panic in TestUpgradeJuju on wily and vivid

[13:55] bogdanteleaga: Probably because you're expecting -run to do something it doesn't do [13:57] niemeyer: the docs seem to say they do pretty much the same thing(-run and check.f), just that check.f takes suites as well [13:57] Bug # opened: 1502149, 1502153, 1502154, 1502158 [14:00] dimitern, I was just getting back to the demo. Which region did you create the subnets in? [14:00] frobware, eu-central-1 [14:00] frobware: dimitern: done, now just swapping offices. if branch is ok I will immediately merge it into 1.25 and then port it to master [14:01] TheMue, cheers, will have one last look [14:07] Bug #1502140 opened: panic in lastlogin upgrade step

[14:09] dimitern, TheMue: taking another look [14:09] bogdanteleaga: Just that they are different, yes :-) [14:10] Bug #1502140 changed: panic in lastlogin upgrade step

[14:12] dimitern, how do I get to eu-central? My choices are frankfurt or ireland. [14:18] the 1.25 branch is blocked at present, see ^ that bug [14:19] Bug #1502140 opened: panic in lastlogin upgrade step

[14:27] frobware, eu-central-1 is in frankfurt :) [14:31] dimitern, yeah. I noticed. [14:31] :) [14:38] fwereade: you around? [15:04] ericsnow: anything I need in the environments.yaml besides type: lxd? [15:05] natefinch: nope [15:08] fwereade: hey can you give a high-level review of http://reviews.vapour.ws/r/2814 ? i'm doing a detailed review, but i want to make sure we're not doing anything wrong, conceptually [15:08] fwereade: i.e. i think it will need a +2 from you [15:09] natefinch: i see several places ericsnow's multi error patch would help :) [15:09] if only it were in the codebase.... le'sigh [15:10] katco: what!!! someone isn't opposed! ;) [15:10] ericsnow: hey, i've always thought it was a good idea [15:10] ericsnow: very common patterns [15:11] katco: all providers use it (and not for necessarily API-related stuff) [15:11] (it = the pattern) [15:12] definitely a common APIMultiError would be good.... it's just proposed as being more general than it needs to be now [15:12] katco: check out Environ.Instances in conjunction with ErrNoInstances and ErrPartialInstances [15:13] natefinch: I wrote it in the first place to meet a non-API use case [15:13] natefinch: yeah not sure that's true... ericsnow ran into a place yesterday [15:14] it just assumes you have an id for each error, which is not always the case... but it would fit many cases, most of which are bulk calls in the API [15:15] natefinch: the ID is neither required not necessarily unique [15:15] (not -> nor) [15:16] bbl people [15:16] natefinch: I don't like that retry function much [15:17] means all those tests will have an extra 3s ceiling runtime? [15:17] mgz: we have to wait for the worker... I don't know how to get around that [15:19] mgz: and in theory it's up to 3 seconds... though in small scale tests I did find it took a couple seconds for the watcher to notify the worker and for the worker to do its job [15:20] mgz: I don't know why the worker/watcher cycle is so slow [15:21] mgz: I also don't know if that slowness is outside the norm.... are they usually instant? I don't know the details of how the watchers and workers work.... but I know there's a lot of machinery between them. [15:22] natefinch: yeah, i don't have a good answer on overall speed, but why not usin LongAttempt [15:23] mgz: I thought about using the attempt code, but it didn't really fit with the pattern I wanted, IIRC' [15:24] mgz: I could certainly look at it again [15:25] mgz: on second thought, I could make that work.. I missed the fact that I could call HasNext() [15:26] natefinch: that would make me happier, at least we're staying with the existing constants [15:29] mgz: makes me happier, too. [15:37] Bug #1502202 opened: toolsversionchecker worker failing [15:37] mgz: fixed :) [15:38] natefinch: thanks! [15:38] mgz: thanks for getting me to look at the attempt code again. I definitely prefer using something already written than handcrafting my own. [15:41] jcastro: alexisb: lp:1502202 is the first I found. I'm trying to recreate the second. [15:43] Bug #1502202 changed: toolsversionchecker worker failing [15:46] Bug #1502202 opened: toolsversionchecker worker failing [15:55] jcastro: alexisb: I can't recreate the second issue. I've been running 1.25 since alpha1 for daily work and it's been solid except for the previously mentioned issue. Kudos. [16:17] natefinch: that is some hairy code. lgtm, but i think we really need someone like fwereade to look at it [16:18] katco, natefinch: link? (no promises today though) [16:18] fwereade: http://reviews.vapour.ws/r/2814/ [16:18] katco, cheers [16:18] fwereade: a high-level overview should suffice. just need to make sure we're conceptually doing the right thing. [16:19] fwereade: this is the combining txns you and natefinch have been discussing [16:19] katco, so I see -- awesome :) [16:23] fwereade: I have a couple concerns... I'm using raw ids across the API... I think that's a no-no, but not sure if I should be creating a new tag just for my new mini collection [16:24] natefinch, for watcher results it's the least wrong thing to do actually [16:24] natefinch, might be inclined to go with unit ids though [16:24] fwereade: that's certainly doable [16:25] fwereade: the other one is that this is a general worker, but maybe it should be a singular worker? We don't want multiples of these things doing assignments of the same things at the same time [16:25] natefinch, (translating id->tag at apiserver Next() time has complications -- but that's where it should be fixed, and for every watcher at once) [16:25] natefinch, I'd favour making it safe when racing with itself [16:26] natefinch, singular is a bit yucky [16:26] natefinch, but you're probably right [16:26] natefinch, yeah, make it singular, we just need a less layer--breaky singular implementation [16:26] fwereade: yeah, I started to go down the singular route, but all the current examples seem to use state directly, which I know is a Bad Thing... and trying to get it working with the API was tricky [16:27] natefinch, yeah, it should just affect where you launch it in the machine agent [16:27] natefinch, there's a singular wrappper func which at least keeps the evil out of its clients' hair [16:27] natefinch, gtg for now [16:27] fwereade: ok, thanks for the input [18:03] ericsnow: gah, I hate having methods on a type outside the file where that type is defined... when we get some time, can we maybe not do that? [18:05] natefinch: yeah, we should split types like that up along the same line as the files (and compose them into the main type) [18:05] natefinch: otherwise we end up with enormous files [18:07] ericsnow: well.... if it's done well, not not just done to get the methods out of the same file, I think that's ok. But given that the environ.go file is only 147 lines right now, I think we have a long way to go before we need to start breaking things up. [18:26] frobware, you potentially around? [18:27] how do you people keep feature branches up to date? [18:27] perrito666: merge from master once in a while [18:27] perrito666: it's not fun [18:27] natefinch: was thinking on the details :) [18:27] pr? [18:27] direct merge? [18:27] perrito666: meh, just merge [18:28] rebase if you're feeling lucky [18:28] natefinch: and you push that to the feature branch directly? [18:29] perrito666: oh uh... hmm.. [18:29] perrito666: I guess PR.. sorry, wasn't thinking [18:29] perrito666: though it's generally not something that can really get reviewed [18:35] mm, can I get permissions to push into a branch in our repo? [18:40] Bug #1502140 changed: panic in lastlogin upgrade step

[18:43] Bug #1502140 opened: panic in lastlogin upgrade step

[18:46] Bug #1502140 changed: panic in lastlogin upgrade step

[19:44] Bug #1502306 opened: cannot find package gopkg.in/yaml.v2

[20:29] Bug #1502314 opened: juju-deployer never completes landscape deployment to vmLDS

[20:32] Bug #1502314 changed: juju-deployer never completes landscape deployment to vmLDS

[20:35] Bug #1502314 opened: juju-deployer never completes landscape deployment to vmLDS

[20:41] aisrael, jcastro, I really appreciate the feedback on 1.25, that is great! [20:44] Bug #1502314 changed: juju-deployer never completes landscape deployment to vmLDS

[20:47] Bug #1502314 opened: juju-deployer never completes landscape deployment to vmLDS

[21:38] alexisb, do we have an eta on the fix for the being ppa-consumable somewhere? https://bugs.launchpad.net/juju-core/+bug/1335885 [21:38] Bug #1335885: destroy-environment reports WARNING cannot delete security group

[21:38]

[22:06] heya beisner [22:06] we have a fix committed for that bug for 1.24, but we are currently working to get a blessed build for 1.24 on CI [22:07] beisner, eta for a 1.24.7 release is next week pending a blessed CI revision [23:48] alexisb, woot, thanks