=== gary_poster is now known as gary_poster|away [03:22] axw: ping [03:22] thumper: ahoy [03:22] axw: how are you going for work? [03:22] axw: I'm wondering about flicking you a piece of work [03:22] I'm working on https://bugs.launchpad.net/juju-core/+bug/1167441 atm [03:22] <_mup_> Bug #1167441: environs/providers must report instance state, like py-juju [03:23] this shouldn't take too long I think [03:23] (or I can switch tracks if it's important) [03:27] thumper: ? [03:27] otp [03:27] ok [03:29] kk back [03:30] this isn't urgent, but it is important [03:30] so you don't have to switch [03:30] it is really just doing some checks prior to bootstrap for the local provider [03:30] with nice error messages [03:30] something like: [03:31] if ubuntu: check to make sure lxc and mongod installed [03:31] if not, give instructions: apt-get install blah blah [03:31] if linux: [03:31] check and give generic instructions: ie, plz install mongod and lxc [03:31] otherwise: [03:31] sorry, local provider not supported on your platform [03:32] * thumper looks to see if there is a bug already for it [03:35] https://bugs.launchpad.net/juju-core/+bug/1204094 [03:35] <_mup_> Bug #1204094: juju-core should suggest mongodb-server

[03:36] that's about as close as it gets [03:36] but slightly different [03:36] although I think the rationale for that bug is that we don't give good error messages if we fail [03:37] actually, right now, if you don't have it installed, the boostrap "works" [03:37] * thumper thinks [03:37] no it does [03:37] n't [03:37] it fails while waiting for the service to start [03:37] but most likely, not a good error message [03:39] oops sorry I wasn't looking - reading back [03:40] ok [03:40] I'll get this one under wraps, then start on that === flaviamissi is now known as flaviamissi_ === tasdomas_afk is now known as tasdomas [04:24] axw: awesome, thanks [04:48] axw: here's another bug about local provider error messages. bug 1206959 [04:48] <_mup_> Bug #1206959: error from no installed lxc is obscure [04:49] wallyworld_: thanks [04:49] axw: thanks for looking at it. i saw in the back scroll you were doing some work in this area. i'll assign the bug to you [04:50] nps === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas [06:10] wallyworld_: any idea why lbox would say this? [06:10] bzr: ERROR: Permission denied: "~axwalk/launchpad.net/goamz/": : Project 'launchpad.net' does not exist. [06:12] eh I think because I used go get originally [06:13] so I got the wrong push branch [06:17] bzr pull --remember lp:goamz [06:17] will fix it [06:17] bigjools: thanks, that's what I was looking for [06:17] np [06:26] --remember doesn't remember :( [07:14] axw: sorry, i was picking up my car from the repair shop, so missed your message [07:14] wallyworld_: nps, I've got it sorted now [07:15] I forgot I'd modified ~/.bazaar/locations.conf [07:15] so the push location as getting overridden [07:22] wallyworld_: I've got a trivial change on goamz, would you mind reviewing? https://codereview.appspot.com/12324043/ [07:22] sure [07:22] needed for a test in juju-core [07:24] axw: just land it, since it's trivial, no need for a 2nd +1 [07:24] cheers [07:24] np [07:25] wallyworld_: what's the merge process for goamz? [07:25] morning [07:25] bzr merge? [07:25] TheMue: morning [07:26] axw: you push to trunk [07:26] ok [07:26] you may not have permission if you are not in the group that owns it [07:26] i can do it for you if you are unable [07:27] just make sure you run all the tests [07:30] wallyworld_: tests all pass. I'm not a member of ~goamz, so I don't think I'm going to be able to push [07:31] axw: i'll land it [07:31] ta [07:36] Hi folks — any reviewers available for this one? https://codereview.appspot.com/12270043 === jtv2 is now known as jtv [07:37] axw: done [07:37] thanks! [07:38] TheMue: Morgen! Hast Du vielleicht etwas Zeit dafür? ^ [07:43] jtv: Oh, in German. Nice. Currently triaging a bug but almost done with it. Then I'll take a look. [07:44] Thanks. Somebody I know spoke German with me recently, and now I feel the urge to practice again. A decade without practice made me really bad at it. [07:44] It was probably my 3-rd best language at school, but now... [07:54] jtv: I did 6 years of German at school, never practiced it after, and now ich kann nichts .. rememberen ;) [08:15] axw: I can't fault your grammar, only your vocabulary. :-) [08:15] ;) [08:15] I think it's "und jetzt kann ich mich nichts mehr erinnern" [08:16] "remember" is transitive. [08:18] mornin' all [08:18] morning [08:18] axw: hiys [08:18] hiya even :-) [08:21] Hi rogpeppe [08:21] I mean, hiys! [08:21] jtv: hiys :-) [08:23] *phew* found it, feeling has been right that this bug is already fixed and committed [08:24] jtv: Nun kann ich deinen Code begutachten. (Now I can review your code.) ;) [08:24] Hurrah! [08:24] Ob das wirklich "begutachten" heisst wirden wir mal sehen... :-) [08:25] * jtv remembers alternative words such as ablenken, and scheitern. [08:30] "werden." :( [08:49] net's a little wonky, might be in and out [08:56] jtv: review is "begutachten", but it is a not very common term. "prüfen" may be better, but does not have the same official character has "begutachten". [08:57] jtv: and your code is reviewed. ;) [08:57] * TheMue just got a parcel with 4 books for review. in this case it is called "Rezension". === axw__ is now known as axw [09:10] Thanks TheMue — but "begutachten" is etymologically derived from "consider good," right? [09:21] jtv: even if it contains the stem "gut" it is more the verb for the noun "Gutachten". you can also say "ein Gutachten erstellen". and that surely can end in a bad result [09:23] Ah! [09:23] Thanks for explaining :) [09:34] could anyone please review https://codereview.appspot.com/12178043 ? I just need the second review, thanks! [09:35] frankban: i'll take a look [09:35] thanks dimitern [09:37] frankban: done [09:39] fwereade: ping [09:39] dimitern: thank you! re your suggestion, I don't want the test to fail if len(units) != 1, I just want the loop to continue [09:39] frankban: ah, I see, ok then - ignore that :) [09:39] cool [09:40] dimitern, heyhey [09:40] fwereade: hey, I'm decided to start working on the uniter API [09:40] fwereade: do we need to discuss it first, how do you think? [09:40] dimitern, probably not a bad idea [09:41] dimitern, quick g+? [09:41] fwereade: sure [09:41] fwereade: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 [10:02] fwereade: any chance of another look at https://codereview.appspot.com/12175043/ ? i'm currently blocked on your "not lgtm" [10:05] fwereade: also, you might want to have a look at https://codereview.appspot.com/12183043/ [10:10] fwereade: when you're not inundated, please see my reply to your latest question on the debug-hooks change. If you're okay with that, I'll land it on Monday [10:10] night all, have a nice weekend === axw is now known as axw- [10:59] * TheMue => lunch [11:04] fwereade: so removing the settings from UnitSettings seems a lot bigger than I originally though, and I'll leave it as is, as you suggested if it happens to be more difficult that expected [11:04] dimitern, bah, annoying, but fair enough [11:05] dimitern, is the complexity mostly on the watcher side or the client side? [11:08] fwereade: well a lot of hookqueue tests have to be changes and with each change I'm getting less certain i'm doing it right [11:08] fwereade: I can make them pass if I spend a few hours more perhaps [11:08] dimitern, yeah, I can understand that [11:09] dimitern, in that case just make it clear that UnitSettings.Settings is never guaranteed [11:09] dimitern, and we can then kill it with impunity at some point in the future [11:10] fwereade: ok, will do [11:22] rogpeppe, fwereade: https://codereview.appspot.com/12344043/ [11:24] dimitern: what's the proper way to contact IS about my reitveld sign-in problem? [11:24] natefinch: #is on the canonical irc server [11:24] dimitern: thanks [11:25] natefinch: there's also a request tracker somewhere, which I have never used [11:26] * fwereade gtg out I'm afraid, I'll do some more reviews after lunch [11:28] dimitern: is there a way to manually perform the steps that lbox does? Maybe that would give me a better idea of what's wrong [11:28] natefinch: what's your sign-in problem? [11:28] dimitern: reviewed [11:28] natefinch: I don't really know, but probably if you trace that the code's doing.. [11:28] rogpeppe: cheers [11:30] rogpeppe: when I try to sign into rietveld using lbox, it tells me bad username or password... I'm using my ubuntu one credentials, which definitely work on login.ubuntu.com [11:31] (and I can sign into reitveld in chrome w/ SSO no problem) [11:35] dimitern: standup === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas [12:26] mgz: hg log -l 1 --template '{node}\n' -r . [12:26] mgz: is the preferred solution i think [12:28] rogpeppe: https://codereview.appspot.com/12344043/ - is that better? [12:29] rogpeppe: I noticed a typo: s/remove/remote/ [12:30] >_< [12:36] dimitern: made another suggestion based on your version [12:37] rogpeppe: thanks [12:42] trivial CL anyone? https://codereview.appspot.com/12349043 [12:43] rogpeppe: looking [12:45] rogpeppe: lgtm [12:46] dimitern: trivial? [12:46] rogpeppe: i think so yeah [12:46] rogpeppe: method expressions? [12:46] dimitern: next in line [12:46] rogpeppe: ok [12:52] rogpeppe: reviewed [12:52] TheMue: thanks [12:52] Hi, does anyone have time for a relatively short review? https://codereview.appspot.com/12176044/ [12:52] I have one LGTM already, and this branch is a pre-req for another already approved branch. [12:53] allenap: looking [12:54] dimitern: Thanks! [12:54] allenap: i don't see your first LGTM though [12:55] dimitern: Oh, I thought jtv had done that. I guess I need another reviewer then; it's well past jtv's EOD now. [12:56] Anyone else for a shortish review? https://codereview.appspot.com/12176044/ [13:04] allenap: you've got a review [13:04] dimitern: Ta :) [13:08] lunch [13:12] sudo lunch [13:13] mgz: Can I threaten, er, politely request a review? https://codereview.appspot.com/12176044/ [13:13] allenap: sure :) [13:13] mgz: Ta muchly. [13:13] ah, and I actually read it already, so joy [13:14] allenap: oops, my bad - missed the ports arg there [13:15] dimitern: No worries :) [13:25] Perhaps an odd question: What's the release process like for Juju? Is it documented somewhere? [13:27] natefinch: not sure it's actually documented in one place, it's more like scattered around in mailing lists and few google docs [13:27] natefinch: mgz and davecheney are your best sources on that I think [13:27] yeah, [13:28] I did say I'd gather everything up into a releaseing doc at one point, we're still refining stuff each release [13:28] mostly dave does the work [13:28] mramm: ping [13:28] dimitern: pong [13:29] mramm: still no response from hr about my missing tasks in allhands, I wrote to claire o'connell yesterday [13:29] ok [13:29] let's give it a couple of days [13:29] ok, follow up... who decides what features go into a release? [13:29] and I'll follow up with her next week [13:30] mramm: ok, just saying i did my part to try and resolve this [13:30] natefinch: dave cheney or everybody depending on how you look at it [13:30] dave picks the point in trunk from which he cuts the release [13:30] but the idea is that everything that goes into trunk should be releasable [13:31] yep, cool [13:31] are there dedicated QA people? Or just us? [13:32] natefinch: wrt charms and stuff there are some automated tests [13:33] natefinch: but juju-core itself testing is mostly us - go tests and live testing on ec2/canonistack [13:33] natefinch: and we get feedback from a lot of other canonical (and some external) guys [13:33] dimitern: that's cool [13:34] natefinch: you'd probably want to have an ec2 account for testing and setup your canonistack creds for openstack live tests [13:35] natefinch: ec2 costs can be reimbursed [13:35] I have an ec2 account, don't have anything set up with canonistack yet [13:35] natefinch: take a look here https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack [13:39] dimitern: thanks [13:46] mgz: are you sure the bot's runining the ppa's golang 1.1.1 ? [13:48] mgz: ah, sorry, ignore that [13:48] wow, 35° [13:49] rogpeppe: your branch fails to build in rpc_test and apiserver/client_test [13:49] TheMue: ah, it's much cooler here today - 28 and cloudy for a change [13:50] hmm, haven't looked out actually - it's not cloudy at all [13:52] dimitern: I've got a list of all times and temps of all team members. only John has it warmer. ;) [13:54] TheMue: ah, well - 40+ there is like every day's average [13:54] TheMue: we had a bunch of 35-ish days earlier in the summer, but lately it's been more around 26, and today it's actually only about 20 out. [13:54] dimitern: yeah, very hot there [13:55] (26 is more like our normal summer temps) [13:55] natefinch: we have typically 20 to 25 and seldom above, but the whole July has been fascinating and it shall continue next week [13:57] natefinch: here in july and august it's typically 32-38, some days in august gettin 42-44 [14:00] dimitern: dang [14:01] Pretty sure if it ever hit 42 here, the entire town would burst into flames [14:02] natefinch: on the flip side, it never gets much below 10-12 in winter [14:02] :) [14:03] dimitern: Ha. -20 isn't that unusual here, and most of the time it's around -10 [14:04] * natefinch totally doesn't have google open to translate between F and C ;) stupid american units... [14:05] dimitern: ha, i was totally sure i'd run gotest-c ./... [14:05] natefinch: oh, in winter I grew up back home with -15 most of the time, -25 often, -35 at rarely, but very memorable :) [14:05] rogpeppe: ha! [14:06] natefinch: so i enjoy the hot weather, preferably indoors when it's too hot [14:06] natefinch: different units are always a pain, also when comparing inch and centimeters or miles and kilometers, not talk about feet [14:06] rogpeppe: when changing method expressions i might want to skip the apiserver/machiner [14:07] TheMue: one of the worst I think are volume measures - oz., gallons, etc. [14:07] TheMue: meters don't bother me, because I can pretty much translate 1:1 with yards, but kilometers are tricky.... and yeah, volume is the worst [14:07] dimitern: why so? [14:08] rogpeppe: well, to make my life a bit easier while refactoring machiner to use a common setstatuser [14:08] rogpeppe: or actually, don't worry, i'll deal with the conflicts [14:09] natefinch, dimitern: yeah, no idea of the volumes [14:09] dimitern: ok, thanks [14:10] gallons to liters is pretty easy, since a gallon is about 3.75 liters... you can just call it 4 ,and you're pretty close. Smaller volumes is harder. [14:10] TheMue: my second-most used google feature, after search is "x in " [14:10] ....but at least we don't use stones for weight :) [14:10] dimitern: yep, me too. Love that. [14:11] natefinch: oh, stones! yeah there's that as well [14:11] I think there's no plural actually: it's 20 stone :) [14:11] dimitern: i've got an app for it ;) [14:12] haha [14:12] dimitern: it also converts currencies [14:13] yep, I even wrote one (well, followed the tutorial really) currency converter for my ubuntu phone [14:13] intersting... I had tests that were failing last night that are passing this morning.... I hate that [14:14] natefinch: ah, we have a special tag for these "intermittent-failure" - if you happen across them check if they're already reported and file a bug please [14:15] dimitern: thanks. I'll do that if I come across them... unfortunately I closed the terminal they were in, and I don't remember exactly what they were [14:16] natefinch: no worries, they're tricky and usually helps to report them if you see them more than once in a while [14:17] natefinch: some tests are notoriously flaky because of some timeouts, which after lots of tweaking are *mostly* stable [14:17] dimitern: yeah, been there, done that. I understand [14:19] rogpeppe: are you going to introduce state/interfaces.go ? [14:19] dimitern: yeah, i think so [14:19] rogpeppe: ok, i'll have some to add there [14:21] rogpeppe: btw it'd be really nice if godef follows symlinks and reverts back to the symlink, rather than resolving it finally [14:22] rogpeppe: i mean, I have ~/work/go/src/launchpad.net/juju-core/ symlinked to ~/work/juju-core/ and every time I do a godef lookup in emacs it resolves it to the full path, rather than the one in ~/work/juju-core/ where I originally clicked [14:23] dimitern: hmm, i'll have to think about that [14:24] dimitern: i'm not entirely sure it's possible [14:24] rogpeppe: well, perhaps if you detect the input file is symlinked, you can use that prefix when returning the result? [14:25] rogpeppe: not a big deal really, just saying - I might try to hack something around that in my copious free time :) [14:26] dang.. so following go conventions i'll end up with a type like SetStatuserer [14:26] dimitern: i'm a bit surprised it works at all if you're passing it a filename like ~/work/juju-core/state/foo.go [14:27] dimitern: StatusSetter [14:27] rogpeppe: oh, it works like charm [14:27] dimitern: weird, 'cos that's not inside your $GOPATH [14:27] rogpeppe: probably the link resolution comes before that [14:28] dimitern: yeah, maybe go/build makes a canonical path [14:29] rogpeppe: I need type StatusSetter in apiserver/common and state interface StatusSetter [14:29] dimitern: seems not unreasonable [14:29] rogpeppe: cf. common/remove.go - Remover and Removerer [14:29] dimitern: "Removerer" is an abomination [14:29] dimitern: but also quite funny [14:30] rogpeppe: :) yeah, like double negative [14:30] rogpeppe: I'll need StatusSetter and StatusSetterer in common [14:31] dimitern: we're going to move away from having a method on state for each interface it can return [14:31] dimitern: and have a single method, Entity, which returns the methods that all entities have in common [14:32] dimitern: then each place that needs a particular interface can type-convert to that interface as required [14:32] rogpeppe: websters dictionary actually contains setterer [14:32] rogpeppe: yeah, that'd be nice [14:35] dimitern: "setterer" means "one who cuts the dewlap (of a cow or ox), and inserts a seton, so as to cause an issue." [14:35] dimitern: that is, a person that setters. [14:35] dimitern: because that's the meaning of the verb "to setter" [14:35] rogpeppe: not sure what either a dewlap or seton are [14:36] dimitern: neither me :-) [14:36] :) [14:36] dimitern: on a dog, the dewlap is the bit that hangs down over the teeth, istr [14:36] * TheMue is a differ, a person that does manual diffing ;) [14:37] dimitern: nope, i'm wrong [14:37] dimitern: http://en.wikipedia.org/wiki/Dewlap [14:37] wow :) [14:37] hey guys, so if I want to get say an m1.large and I put in the matching constraint numbers it gives me the next larger unit. [14:37] who do I need to convince that we'd like instance-types back? [14:38] jcastro: no-one, we'll have them [14:38] oh ok [14:38] jcastro: it was decided [14:38] well that was easy! [14:38] jcastro: and in the roadmap for next 2-3 weeks iirc [14:39] awesome! [14:39] jcastro: there was a lot of bikesheding around how to define them across providers/clouds though [14:40] jcastro: like, if you need fallbacks for the same provider, but different clouds, etc. [14:40] yeah [14:40] I would be happy with just ec2 since those are the ones people know [14:41] jcastro: i'm pretty sure openstack has to go there too [14:41] * jcastro nods [14:44] rogpeppe: for SetStatus I'll need a way to get the entity from it's tag, so I can call SetStatus on it [14:44] dimitern: that's what the State.Entity method will do [14:45] rogpeppe: is that in yet? [14:46] rogpeppe: will.. so probably not then [14:46] dimitern: no, sorry, i just got distracted by the dubious code in testing.TestLockingFunction [14:49] rogpeppe: ok, I'll work with the assumption it's there already [14:49] dimitern: cool. you can call State.Lifer for the time being [14:51] rogpeppe: how so? that only gets me Tag() and Life() [14:52] * rogpeppe just managed to get the go compiler to go into an apparently infinite loop using up all of memory [14:52] dimitern: Entity will only return a Tagger, probably [14:52] dimitern: you can type convert [14:53] rogpeppe: so I can do entity, err := state.Lifer(tag) and then if statusSetter, ok := entity.(state.StatusSetter); ok { statusSetter.SetStatus(...) } ? [14:54] dimitern: exactly [14:54] rogpeppe: ok, cool [15:06] so, both CLs are ready for review: https://codereview.appspot.com/12347043/ and https://codereview.appspot.com/12343045 [15:08] TheMue: will take a look [15:10] dimitern: thx [15:12] TheMue: so is it possible to say "remove the setting" if the default is !nil or "" ? [15:12] TheMue: like juju set x= ? [15:13] TheMue: or juju set --default x= (set the default to empty) ? [15:15] rogpeppe: it seems you reverted back one of the panics? [15:15] dimitern: i reverted back the panics that were necessary [15:17] rogpeppe: why not just return some error there? [15:18] dimitern: remove a string should only be possible if it is configured as default: null and you say set --default thatOption [15:18] dimitern: which one are you referring to? [15:18] https://code.google.com/p/go/issues/detail?id=6016 [15:19] dimitern: but that only with the 2nd cl. the first one doesn't change the behavior of set option= [15:20] rogpeppe: in rpc_test [15:20] TheMue: so what will now juju set option= do? [15:20] TheMue: can you do as well juju set --default option= ? [15:21] dimitern: because if we hit that line, something horrible has gone wrong [15:21] rogpeppe: wow :) you actually found a compiler bug, again? :) [15:21] dimitern: because it really should be unreachable [15:21] dimitern: seems like it [15:22] rogpeppe: awesome! [15:22] rogpeppe: seems like we're one of the main sources of go bugs :) [15:22] dimitern: as said, the 1st cl only adds --default as an alternative to option=, you cannot mix it. [15:22] dimitern: but you can do set option= [15:22] dimitern: erm, have you seen how many open bugs there are?! [15:22] dimitern: both set to default [15:22] dimitern: with the 2nd cl this changes [15:22] TheMue: I think that's confusing [15:23] TheMue: and needs more tests to verify all such cases [15:23] dimitern: then string option will be set to an empty string with option= [15:23] TheMue: and --default cannot take = after option or a value? [15:23] dimitern: you have to see both cls combined, only splitted in two cls [15:23] rogpeppe: haven't checked lately [15:24] dimitern: which case do you want to be tested? [15:24] dimitern: are you talking about the 1st cl? [15:24] dimitern: i already said twice, it cannot. why should it? [15:24] TheMue: --default option= and --default option=x at least [15:25] TheMue: because if you're able to do that without --default, people will expect you can do it with, and it should be tested [15:25] dimitern: it is, as those are detected as illegal options ;) [15:25] TheMue: I can only see --default invalidoption [15:26] TheMue: not --default validoption= or --default validoption=blah [15:26] dimitern: option= is an invalid option too, and option=x also [15:26] TheMue: ok, let's have 2 more tests for that then [15:26] TheMue: I'll commet it on the review [15:26] dimitern: i can add it, it helps you as a developer, but not the user [15:27] TheMue: it's exactly the other way around I think [15:28] TheMue: the tests should cover user stories, especially client-facing stuff like the CLI [15:29] TheMue: so --default is a flag? [15:29] TheMue: so we need tests that mix --default and other key=value pairs as well [15:31] TheMue: users might try juju set key1=val1 --default key2 key3=val3 [15:32] TheMue: that's why I don't think --default should be a flag [15:32] dimitern: that flag has been the result of a longer discussion. what would you propose? [15:33] TheMue: it should apply to the argument immediately following it, then it's obvious (and should be documented) it's an argument [15:33] TheMue: like --default=x (with or without the =) [15:34] dimitern: an argument looking like a flag? [15:34] TheMue: is --config a flag? [15:34] TheMue: it's not and it has an argument [15:34] dimitern: btw, also --default a b c d is working [15:35] TheMue: yeah, there are no tests for that as well [15:35] how do you handle multiple defauls in one tx? [15:36] TheMue: sorry? is it working or now? [15:36] not* [15:37] dimitern: in the cl set --default opta optb optc sets all three to default [15:37] dimitern: how should the call look like in your opinion? [15:38] TheMue: it can look like --default opta --default optb --default optc [15:38] dimitern: userfriendly? [15:39] TheMue: at least it's explicit, rather than key1=val1 --default key2 key3=val3 failing [15:39] dimitern: yeah, that's not optimal [15:40] TheMue: it has to be documented that --default has to be last [15:40] dimitern: but the explicit way is not user friendly [15:40]