[00:28] * thumper looks at anastasiamac_ [00:29] anastasiamac_: Is there a reason that block.ProcessBlockedError doesn't use errors.Cause(err) ? [00:31] * thumper stops staring and wonders why the test is still failing with that line added [00:31] haha [00:31] ha [00:31] hmm... [00:32] * thumper looks at trunk [00:32] yep... broken in trunk [00:32] * thumper enfixorates [01:14] * thumper does a little dance [01:14] my three outstanding branches landed today [01:14] \o/ [02:02] * menn0_ is struggling with the damn open ports migration (again) [02:03] the tests are sensitive to anything with the DB changing... [02:15] * thumper weeps [02:15] I know what is a great idea... [02:15] lets test the apiserver by exhaustively testing the command line client [02:17] or even better... [02:17] let's test the apiserver by calling the api client [02:17] what could possibly go wrong? [02:17] stabby stabby [02:18] * thumper takes a deep breath [02:22] * thumper breathes out [02:23] why does this make me so fucking angry? [02:23] because it's wrong [02:31] thank you waigani [02:31] waigani: I think it is work I made you do earlier this year that makes the work I'm doing now slightly less painful [02:33] ha, I thought it was another wallyworld typo [03:50] menn0_: https://github.com/juju/juju/pull/1295 [03:50] thumper: looking === menn0_ is now known as menn0 [03:51] menn0: like the machine command branch but for environment commands [03:51] 1710 lines, and I tried to keep it small [03:51] geez [03:52] menn0: I suppose I could have landed the apiserver and client test refactoring separately [03:52] that would have reduced it by about 300 lines [03:52] menn0: yeah I was thinking that but now that you've done it [03:52] ... [03:55] meh [03:55] just noticed doc help for environment get still metions get-environment [03:55] * thumper stops for coffee === kadams54 is now known as kadams54-away [04:27] jam1, are you around? [04:45] thedac: phew! review done. [04:46] thedac: that should have been thumper [07:01] jam1, ping? [07:01] mattyw: hi [07:01] jam1, hi there, I fixed http://reviews.vapour.ws/r/563/ after your comments, would you mind taking another look? [07:02] mattyw: looking [07:11] the diff still hasn't loaded.... [07:12] mattyw: refresh worked. Anyway LGTM [07:14] jam1, thanks very much [07:14] jam1, I'm going to land it [07:14] np [07:14] sounds good [07:35] axw, would you take a look at the latest diff on http://reviews.vapour.ws/r/606/ please? context is failed test here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1581/console [07:35] fwereade: looking [07:36] fwereade: http://reviews.vapour.ws/r/589/? :) [07:36] axw, dammit, ty [07:51] axw, so, the doubled fields don't feel quite right to me -- ISTM that there's a fundamental properties-of-a-single-block-device struct that wants to get out [07:52] axw, altough I *also* know that it's not quite that simple, witness the Constraints/HardwareCharacteristics dichotomy [07:53] fwereade: there is one already: storage.BlockDevice. it's pretty much parallel to Constraints/HC [07:53] axw, and I can also see the attraction to parsing constraints into a single struct that replaces the service-level one that came from the charm [07:54] axw, yeah, I'm quibbling about the doubled fields more than anything [07:54] fwereade: you mean Size vs. MinSize? [07:54] axw, instinct is suggesting that Minimum and Preferred would be better top-level fields? [07:54] ah, I see [07:55] axw, and I see how Count is a bit of a problem from that perspective [07:55] axw, but I'm starting to think that maybe it's a matter of an array of duped {min, pref} structs? [07:56] fwereade: I did wonder about that, but how do you say that a struct isn [07:56] erk [07:56] isn't required at all [07:56] s/struct/disk/ [07:57] i.e. I might like 100 disks, but I'll be happy if you have one or two [07:57] axw, right, I see, it probably can't sanely be an array [07:57] I would prefer if it's not in there though, since it's not an independent variable... [07:58] axw, indeed, it does feel like it wants to exist at another level [08:01] axw, although, hmm [08:01] axw, I think the min/pref thing does still apply [08:01] axw, we need at least 2 disks but really want 6 [08:02] axw, but you're right that they're independent [08:02] axw, I can well imagine preferring to have 2 awesome disks than 6 crappy ones [08:04] axw, that feels like it's pushing us towards more sophisticated fallback behaviour again [08:05] axw, because if we just do straight "try preferred, then try minimum" we'd end up with 2 crappy disks [08:05] good point [08:05] ugh [08:05] axw, can we make a case for count being different enough to be a separate dimension, even if it's specified together? [08:06] axw, but even then [08:06] fwereade: I think so- try preferred and then min count of (other) preferred constraints before [08:06] anything else [08:07] axw, it feels like we should *definitely* get explicit user feedback re choosing whether to degrade count or quality first [08:07] which equates to, "give me as many of the best disks you can give me" [08:07] yeah [08:07] axw, some people will certainly care more about redundancy than speed [08:08] fwereade: there's always going to be the option of being explicit about the constraints, in which case there's no degradation anyway [08:08] but yes, this needs some input from interested parties [08:08] axw, yeah, indeed [08:08] my last email got crickets... [08:09] axw, yeah, I feel this is something of a systemic issue [08:09] axw, there *are* interested parties, but they all have their own priorities, and fixing the bugs today tends to take priority over defining the features of tomorrow [08:11] * axw nods [08:14] fwereade: your diff LGTM [08:15] axw, cool, thanks [09:31] morning [09:53] perrito666: o/ [10:01] dimitern: standup ? === jam1 is now known as jam [10:01] jam, brt [10:54] fwereade: in the interest of getting something working, would you be satisfied with separating the constraints out into top-level Minimum and Preferred, and refactoring if it turns out that it doesn't fit with the default fallback approach decided on later? [10:54] axw, +1 [10:55] cool [10:55] axw, I think it's one of those cases where we'll have to converge to what's actually right regardless [10:56] fwereade: maybe, but I can't really see how there is a "right" here; it depends on the user, so it'd have to be policy driven [10:57] axw, I'm really just thinking about the shape of the code and the structs that most happily map between the user view and the substrate [10:57] oh, right [11:41] so, I'm suffering an attack of incandescent rage re: the uniter tests building jujud [11:41] does anyone have any bright ideas for how we might avoid doing this? [12:22] what's the story on juju actions? [12:22] we have apis but no cli? [12:24] hazmat, they're under development, in https://github.com/juju-actions [12:24] hazmat, hopefully soon tobe behind a feature flag as proposed by thumper, but I haven't kept up on whether he's done that [12:24] hazmat, jw4 or bodie_ should know the latest [12:39] fwereade: why do the uniter tests need jujud? are they executing hook tools? [12:40] axw, yeah [12:41] axw, I am *sooo* tempted to just use jsonrpc and hack up jujuc in python already :/ [12:42] axw, it used to be a separate executable [12:42] axw, but it's not very small [12:42] axw, and so we rolled it into jujud [12:43] yeah, not long after I started I think [12:43] axw, (but then that's not very nice for windows... /sigh) [12:43] axw, I thought it was even before that [12:44] maybe, maybe I just remember the old packages [12:44] axw, hey ho :) [12:45] * perrito666 tipes fearful that the power might once again go off .. [12:45] you have to love local power company [12:50] fwereade: as a minimal change, perhaps move jujuCMain out of cmd/jujud/main.go into worker/uniter/jujuc somewhere, and add a new minimal cmd package just for those tests that calls jujuCMain [12:50] then at least it doesn't build the entire tree [12:54] axw, yeah, I was thinking about that, and then I got stressed about having a separate code path for the tests [12:54] axw, which was leading me towards just doing a separate implementation in a scripting language [12:55] axw, and then I started trying to find out what the protocol was for plain golang rpc and *ofc* we'd have to change it out for json and grr arrgh hmmph [12:56] fwereade: what, everyone doesn't use websockets+json ? :) [12:56] axw, ;p === frankban__ is now known as frankban [14:09] hazmat: wrt actions - we've been holding off on the CLI until we can land the full implementation, but now that we have feature toggle we'll start landing what we have behind a flag. [14:17] jw4, interesting timing on this topic, I was just going to ask about it :) [14:17] coreycb: :) [14:17] jw4, any estimates on when cli will start to land? [14:18] Well, we have some finished already in the github.com/juju-actions/juju fork under the cli-action-dev branch [14:19] coreycb: my mission in the next couple days is to start landing the super command and sub commands behind a feature toggle [14:19] jw4, great, thanks. any chance you could point me to a charm that has action hooks? [14:20] coreycb: bodie_ mocked up a demo one that he's using for sample usage : https://github.com/binary132/actions-demo [14:21] coreycb: also, marcoceppi is using bleeding edge versions of the API for a project he's working on [14:22] jw4, awesome, thank you [14:23] coreycb: please hit bodie_, TheMue , or I up with any and all comments / feedback / issues [14:24] jw4, will do [14:44] natefinch: ping [14:45] ericsnow, wwitzel3: btw, realized I made a mistake with some of the configuration code for GCE..... we can talk about it in standup, but long story short, we have to keep all configuration in the original map[string]interface{}, unfortunately [14:45] wwitzel3: howdy [14:46] wwitzel3: want to hop in moonstone for the 1:1? [14:46] natefinch: yep [14:46] natefinch, We have a regressions bug 1401130 about joyent. There is only 1 suspect commit. Can you ask someone to investigate [14:46] Bug #1401130: Joyent deployments cannot download agents from state-server

[14:47] sinzui: sure [14:47] dimitern, how goes the work on bug 1397376? [14:47] Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints

[14:48] sinzui, live testing latest changes - maas still gives me some issues [14:48] :/ [14:48] sinzui, I'll propose the fix while waiting [14:48] thank you dimitern [15:06] coreycb, jw4 re marcoceppi's prototype action cli via api https://github.com/juju-solutions/juju-action [15:08] thanks hazmat [15:09] jw4, thanks! [15:09] I mean, hazmat ^ === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1401130 1400358 === kadams54 is now known as kadams54-away [15:33] ericsnow: ping [15:33] katco: hey [15:34] ericsnow: good morning :) [15:34] ericsnow: i'm reviewing http://reviews.vapour.ws/r/608/ [15:34] ericsnow: the code looks good, but i'm having trouble knowing if it's complete. can you point me to some light literature on the nature of the change? [15:35] katco: https://github.com/juju/juju ;) [15:35] ericsnow: haha [15:35] katco: I'm not expert on the uniter code nor on jujuc [15:36] ericsnow: i guess i'm trying to understand if availability zones need to be added elsewhere, or if any additional tests are needed [15:36] ericsnow: as i am not an expert on this concept either [15:36] katco: for this change I simply traced how we get the IP address stuff into relation-get and did the same for the availability zone [15:36] ericsnow: ah ok. so the use-case is much the same [15:37] katco: yep [15:37] ericsnow: do you think any additional tests are needed to ensure it's being set? [15:37] katco: see https://docs.google.com/a/canonical.com/document/d/1yVlzgKqfhKccUbm3WcZBq7WnzglBygknscr_I_u4bUg/ [15:37] ericsnow: thanks [15:38] katco: this patch is just a tiny part of all that spec [15:38] ericsnow: like maybe instead of checking for an empty string in uniter_base_test.go, we maybe fill in an availability zone and check it? [15:39] katco: I'd be glad to add more tests (there's always a gap to fill) [15:39] ericsnow: nothing too crazy or anything, maybe just a single test to ensure it's being passed around correctly? [15:40] katco: suggesting it in a review comment would be most helpful [15:40] ericsnow: you got it [15:40] katco: good idea [15:40] katco: tas [15:40] ericsnow: thanks for the explanation :) [15:40] katco: I just dumped everything I know on the subject ;) [15:41] ericsnow: haha well it was helpful :) [15:41] katco: good === kadams54-away is now known as kadams54 [16:10] natefinch: standup? [16:12] ericsnow: doh, coming [16:14] ericsnow, is the RB hook not working? [16:15] ericsnow, I have this PR https://github.com/juju/juju/pull/1297 - maybe the description is too long for the hook to handle and add the RB link? [16:15] anyway.. [16:16] dimitern: this happened the other day to axw [16:16] dimitern: I'll check it out [16:16] ericsnow, yeah, I guess the bot just said tl;dr :) [16:16] dimitern: :) [16:17] katco, as OCR can you have a look at this fix for bug 1397376 ? https://github.com/juju/juju/pull/1297 [16:17] Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints

[16:17] dimitern: one sec, on a call [16:18] katco, np, when you can [16:18] fwereade, is you're still around and willing can you have a look as well? ^^ [16:18] if* [16:40] dimitern: apologies. i am in the middle of reviewing axw's storage branch and then i'll hop onto yours [16:41] dimitern: ty for the ping :) [16:42] katco, it's ok, take your time [16:51] ericsnow: hey can you look at the diff for http://reviews.vapour.ws/r/589/ [16:51] ericsnow: i think review board has an error [16:51] ericsnow: it's not displaying the diff for some files [16:51] katco: will do [16:52] katco: were those files removed? [16:52] ericsnow: ty sir [16:52] ericsnow: um. hrm. [16:52] ericsnow: let me check, didn't think of that [16:53] ericsnow: ah yes they were. but that shouldn't show up as an error should it? [16:53] ericsnow: i would expect it to say something sensible, like "file deleted" for the RHS [16:56] dimitern: hey am i daft? i don't see your PR on review board? [16:57] katco, yeah - it got hit by the "desc tl;dr" RB bot bug [16:57] ..apparently [16:57] dimitern: oh, haven't hit that one yet. so can you post the diffs to RB manually? [16:57] katco, I can certainly try.. give me a sec [16:58] dimitern: ty sir [16:59] dimitern: looks like github is giving us a 404 when we go to pull the diff [16:59] dimitern: I'll need to investigate further [17:00] katco, there you go - http://reviews.vapour.ws/r/611/diff/ [17:00] ericsnow, oh boy.. it's not even that big :) ~1K lines [17:01] natefinch, is anyone working on bug 1401130 or bug 1400358 that block merges [17:01] dimitern: (though the 404 may actually mean 401) [17:01] Bug #1401130: Joyent deployments cannot download agents from state-server

[17:01] Bug #1400358: TestLoginsDuringUpgrade broken on i386

[17:01] dimitern: tyvm! [17:01] ericsnow, interesting - some auth cache/cookie expired? [17:02] dimitern, if you need to submit you fix for api-endpoints and CI is blocked, use "__JFDI__" in the message [17:02] sinzui: no, sorry, been in meetings all morning. I'll try to get someone on those now. [17:02] sinzui, yep, I know the drill :) [17:02] dimitern: pretty sure the auth is okay (but the 400 implies it's not) [17:03] weird.. [17:03] anyway I'll be off now [17:04] sinzui, I'll merge the fix tomorrow morning. it seems [17:05] dimitern: i'll ping you after i'm done reviewing in the off-chance you're still on [17:06] dimitern: but this one is likely going to take awhile [17:07] katco, ok [17:08] katco, btw don't feel obliged to approve it, if it's not clear; it's was a mess before, a little less now, but still not perfect [17:10] dimitern: no worries === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [17:39] ericsnow: ping [17:40] wwitzel3: ready? [17:41] ericsnow: yep, in moonstone [17:41] wwitzel3: brt [17:58] wwitzel3: port range parsing: http://reviews.vapour.ws/r/612/ [18:49] perrito666: can you take a look at https://bugs.launchpad.net/juju-core/+bug/1401130 ? unfortunately, I have to take the kids while my wife goes to a prenatal checkup, so I'll be out most of the afternoon. [18:49] Bug #1401130: Joyent deployments cannot download agents from state-server

[18:50] sinzui: menno has a fix for the other one, I think it best for him to just get that in later today (early in his day) [18:51] okay. thank you natefinch === sebas5384 is now known as _sEBAs_ [19:14] looking === kadams54 is now known as kadams54-away [19:19] We're beginning to land Actions CLI commands now behind an "action" feature flag [19:19] the first PR is http://reviews.vapour.ws/r/613/ [19:19] PTAL OCR ^^ [19:19] :) === kadams54-away is now known as kadams54 [19:24] jw4: PTAL? sorry still working my way through dimitern's change [19:26] sinzui: has anyone tried that by hand? [19:28] perrito666, about the which thing? [19:28] oh, I see [19:28] sinzui: sorry I swallowed the context [19:28] about the joyent issue [19:29] perrito666, Yes. I tried joyent with tip and 1.20.13 and 1.20.14 [19:29] perrito666, I the 1.20.x do work [19:29] perrito666, I attached the cloud-init-output.log of the 1.22-alpha1 machine that was stuck in pending [19:31] sinzui: it is interesting that you think it can be related to this bug https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1283992 [19:31] Bug #1283992: Multi-monitor: wallpaper is corrupted

[19:31] perrito666, Joyent has a history of good bootstraps and bad deployments because the other machines got a different network than the one the state-server was one. A few months ago, wallyworld or awx added a rule to select the right network [19:31] ahh buu the title is right here [19:31] oops. [19:31] * sinzui looks for other joyent network bug [19:32] * perrito666 changes wallpaper [19:33] perrito666, I think the current issue may relate to bug 1383922 [19:33] Bug #1383922: Services deployed joyent have broken networks

[19:34] perrito666, there is one other nuance. Joyent added firewalls as a feature for each. machine. We don't use them, but I wondered if joyent ever had a rule to bring up the machine with with firewall up, then takes it down when it thinks the machine is ready [19:55] sinzui: sorry to bother again, I am trying to make a picture of the issue here [19:56] go ahead perrito666 [19:59] sinzui: the cloudinit log from a failure, comes from an attempt with master tip? [19:59] (sorry for the dramatic pause, dog ran away into a pool of muddle) [19:59] perrito666, yes, was a few hours ago [20:00] * sinzui looks for commit [20:00] perrito666, it was commit 0363d9c6 [20:01] sinzui: I think a valid test would be to run by hand the last successful commit [20:01] it is a quick way to know if its us or them [20:01] perrito666, this log is uniformative http://juju-ci.vapour.ws:8080/job/joyent-deploy-precise-amd64/1240/console, so while it was stalled in pending, I sshed into one of the machine [20:02] perrito666, but there are no streams for it. I can run the entire build or... [20:02] * perrito666 thinks [20:03] I think the test would be valid enough with upload tools [20:03] ...or use a binary from http://juju-ci.vapour.ws:8080/job/publish-revision/1283/ with --upload tools [20:03] sidenote: we need to have a non hackish tools to publish a stream [20:17] perrito666, that last version just worked for me. [20:18] ok, so we broke something [20:24] waigani_: so "state-id" in the dummy config seems like it is not important [20:24] waigani_: I'm trying to see where it is used [20:24] waigani_: what exactly is failing for you? [20:24] ... value *errors.Err = &errors.Err{message:"cannot add a new machine", cause:(*errors.errorString)(0xc21027f730), previous:(*errors.errorString)(0xc21027f730), file:"github.com/juju/juju/state/addmachine.go", line:168} ("cannot add a new machine: invalid state-id \"90168e4c-2f10-4e9c-83c2-feedfacee5a9\"") [20:25] and if I don't pass the state-id in: [20:25] ... value *errors.Err = &errors.Err{message:"cannot add a new machine", cause:(*errors.errorString)(0xc21008b9c0), previous:(*errors.errorString)(0xc21008b9c0), file:"github.com/juju/juju/state/addmachine.go", line:168} ("cannot add a new machine: environment is not prepared") [20:25] thumper: ^ [20:26] waigani_: well a state id needs to be an integer [20:27] waigani_: and it seems llike the dummy env sets it itself [20:27] waigani_: because it expects only one environment [20:27] ah [20:27] waigani_: you may need to look through the dummy provider somewhat [20:28] waigani_: the dummy provider calls 'newState' which seems to do stuff we don't want [20:28] for secondary environments [20:28] thumper: right, maybe a new branch to get dummy to work with non-state-server envs? === menn0_ is now known as menn0 [20:29] waigani_: yeah... I think that may be needed [20:29] waigani_: it seems that dummy assumes too much now [20:29] haha, I am now three branches removed from what I started on this week [20:29] :-) [20:29] push another on the stack [20:29] eventually you'll get to pop some [20:30] yep [20:30] waigani_: please add a task card on kanban :) [20:30] waigani_: it could be worse. you might be using Subversion. [20:30] lol [20:31] thumper: okay, I'll shelve others, update kanban and start this new branch. [20:31] * thumper nods === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === fuzzy_ is now known as Ponyo === kadams54 is now known as kadams54-away === menn0_ is now known as menn0 [22:21] thumper: here's that test fix: http://reviews.vapour.ws/r/615/ [22:22] thumper: I think it's ok now (not *too* ugly) [22:23] * thumper looks [22:24] menn0: why refactor the machine agent? [22:24] what do you get out of it? [22:25] thumper: so that the specific workers that the test needs can be run [22:25] thumper: instead of spinning up the whole agent [22:26] thumper: moving the code that starts workers into methods makes it available from the test [22:27] s/it/them/ [22:27] ah.. [22:27] kk [22:27] hadn't got to the tests yet :) [22:27] thumper: right, I can see how the machine agent changes might have seemed unnecessary without seeing the tests :) [22:37] menn0: ship it! [22:37] thumper: cheers [22:39] thumper: I hadn't realised that this bug had been "promoted" to a CI blocker [22:40] thumper: just as well that I was working on it [22:40] :) [22:40] I didn't know either [22:40] oh, looky looky, there are two critical bugs in the topic [22:50] thumper, that is very observant of you [22:50] perrito666 is working one [22:51] or was the last time I checked in [22:52] alexisb: I try [22:56] Okay take two :: OCR PTAL http://reviews.vapour.ws/r/616/ [22:57] thumper: included your feedback into this new PR ^^ [22:57] jw4: ok, I'll take a look after lunch. not OCR but interested [22:58] thumper: cool, thanks - fwiw my approach to setting and restoring the flags might need to be generalized but I wanted to keep it light [22:58] jw4: I've not looked, but we probably want two tests for the commands, one to show it isn't there by default, and one to show it is when flag is set [22:59] * thumper wanders off for a bit [22:59] thumper: +1 [23:16] hmmm... this is a new merge failure [23:16] Traceback (most recent call last): [23:16] File "/var/lib/jenkins/juju-ci-tools/ec2-terminate-job-instances", line 3, in [23:16] from deploy_stack import destroy_job_instances [23:16] File "/var/lib/jenkins/juju-ci-tools/deploy_stack.py", line 23, in [23:16] from jujupy import ( [23:16] File "/var/lib/jenkins/juju-ci-tools/jujupy.py", line 25, in