[03:22] <thumper> axw: ping
[03:22] <axw> thumper: ahoy
[03:22] <thumper> axw: how are you going for work?
[03:22] <thumper> axw: I'm wondering about flicking you a piece of work
[03:22] <axw> 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 <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1167441>
[03:23] <axw> this shouldn't take too long I think
[03:23] <axw> (or I can switch tracks if it's important)
[03:27] <axw> thumper: ?
[03:27] <thumper> otp
[03:27] <axw> ok
[03:29] <thumper> kk back
[03:30] <thumper> this isn't urgent, but it is important
[03:30] <thumper> so you don't have to switch
[03:30] <thumper> it is really just doing some checks prior to bootstrap for the local provider
[03:30] <thumper> with nice error messages
[03:30] <thumper> something like:
[03:31] <thumper> if ubuntu: check to make sure lxc and mongod installed
[03:31] <thumper> if not, give instructions: apt-get install blah blah
[03:31] <thumper> if linux:
[03:31] <thumper> check and give generic instructions: ie, plz install mongod and lxc
[03:31] <thumper> otherwise:
[03:31] <thumper> sorry, local provider not supported on your platform
[03:32]  * thumper looks to see if there is a bug already for it
[03:35] <thumper> https://bugs.launchpad.net/juju-core/+bug/1204094
[03:35] <_mup_> Bug #1204094: juju-core should suggest mongodb-server <papercut> <juju-core:Confirmed> <https://launchpad.net/bugs/1204094>
[03:36] <thumper> that's about as close as it gets
[03:36] <thumper> but slightly different
[03:36] <thumper> although I think the rationale for that bug is that we don't give good error messages if we fail
[03:37] <thumper> actually, right now, if you don't have it installed, the boostrap "works"
[03:37]  * thumper thinks
[03:37] <thumper> no it does
[03:37] <thumper> n't
[03:37] <thumper> it fails while waiting for the service to start
[03:37] <thumper> but most likely, not a good error message
[03:39] <axw> oops sorry I wasn't looking - reading back
[03:40] <axw> ok
[03:40] <axw> I'll get this one under wraps, then start on that
[04:24] <thumper> axw: awesome, thanks
[04:48] <wallyworld_> axw: here's another bug about local provider error messages. bug 1206959
[04:48] <_mup_> Bug #1206959: error from no installed lxc is obscure <juju-core:New> <https://launchpad.net/bugs/1206959>
[04:49] <axw> wallyworld_: thanks
[04:49] <wallyworld_> 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] <axw> nps
[06:10] <axw> wallyworld_: any idea why lbox would say this?
[06:10] <axw> bzr: ERROR: Permission denied: "~axwalk/launchpad.net/goamz/": : Project 'launchpad.net' does not exist.
[06:12] <axw> eh I think because I used go get originally
[06:13] <axw> so I got the wrong push branch
[06:17] <bigjools> bzr pull --remember lp:goamz
[06:17] <bigjools> will fix it
[06:17] <axw> bigjools: thanks, that's what I was looking for
[06:17] <bigjools> np
[06:26] <axw> --remember doesn't remember :(
[07:14] <wallyworld_> axw: sorry, i was picking up my car from the repair shop, so missed your message
[07:14] <axw> wallyworld_: nps, I've got it sorted now
[07:15] <axw> I forgot I'd modified ~/.bazaar/locations.conf
[07:15] <axw> so the push location as getting overridden
[07:22] <axw> wallyworld_: I've got a trivial change on goamz, would you mind reviewing?  https://codereview.appspot.com/12324043/
[07:22] <wallyworld_> sure
[07:22] <axw> needed for a test in juju-core
[07:24] <wallyworld_> axw: just land it, since it's trivial, no need for a 2nd +1
[07:24] <axw> cheers
[07:24] <wallyworld_> np
[07:25] <axw> wallyworld_: what's the merge process for goamz?
[07:25] <TheMue> morning
[07:25] <axw> bzr merge?
[07:25] <axw> TheMue: morning
[07:26] <wallyworld_> axw: you push to trunk
[07:26] <axw> ok
[07:26] <wallyworld_> you may not have permission if you are not in the group that owns it
[07:26] <wallyworld_> i can do it for you if you are unable
[07:27] <wallyworld_> just make sure you run all the tests
[07:30] <axw> 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] <wallyworld_> axw: i'll land it
[07:31] <axw> ta
[07:36] <jtv2> Hi folks ­— any reviewers available for this one?  https://codereview.appspot.com/12270043
[07:37] <wallyworld_> axw: done
[07:37] <axw> thanks!
[07:38] <jtv> TheMue: Morgen!  Hast Du vielleicht etwas Zeit dafür?  ^
[07:43] <TheMue> jtv: Oh, in German. Nice. Currently triaging a bug but almost done with it. Then I'll take a look.
[07:44] <jtv> 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] <jtv> It was probably my 3-rd best language at school, but now...
[07:54] <axw> jtv: I did 6 years of German at school, never practiced it after, and now ich kann nichts .. rememberen ;)
[08:15] <jtv> axw: I can't fault your grammar, only your vocabulary.  :-)
[08:15] <axw> ;)
[08:15] <jtv> I think it's "und jetzt kann ich mich nichts mehr erinnern"
[08:16] <jtv> "remember" is transitive.
[08:18] <rogpeppe> mornin' all
[08:18] <axw> morning
[08:18] <rogpeppe> axw: hiys
[08:18] <rogpeppe> hiya even :-)
[08:21] <jtv> Hi rogpeppe
[08:21] <jtv> I mean, hiys!
[08:21] <rogpeppe> jtv: hiys :-)
[08:23] <TheMue> *phew* found it, feeling has been right that this bug is already fixed and committed
[08:24] <TheMue> jtv: Nun kann ich deinen Code begutachten. (Now I can review your code.) ;)
[08:24] <jtv> Hurrah!
[08:24] <jtv> Ob das wirklich "begutachten" heisst wirden wir mal sehen...   :-)
[08:25]  * jtv remembers alternative words such as ablenken, and scheitern.
[08:30] <jtv> "werden."  :(
[08:49] <axw_> net's a little wonky, might be in and out
[08:56] <TheMue> 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] <TheMue> 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".
[09:10] <jtv> Thanks TheMue — but "begutachten" is etymologically derived from "consider good," right?
[09:21] <TheMue> 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] <jtv> Ah!
[09:23] <jtv> Thanks for explaining :)
[09:34] <frankban> could anyone please review https://codereview.appspot.com/12178043 ? I just need the second review, thanks!
[09:35] <dimitern> frankban: i'll take a look
[09:35] <frankban> thanks dimitern
[09:37] <dimitern> frankban: done
[09:39] <dimitern> fwereade: ping
[09:39] <frankban> 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] <dimitern> frankban: ah, I see, ok then - ignore that :)
[09:39] <frankban> cool
[09:40] <fwereade> dimitern, heyhey
[09:40] <dimitern> fwereade: hey, I'm decided to start working on the uniter API
[09:40] <dimitern> fwereade: do we need to discuss it first, how do you think?
[09:40] <fwereade> dimitern, probably not a bad idea
[09:41] <fwereade> dimitern, quick g+?
[09:41] <dimitern> fwereade: sure
[09:41] <dimitern> fwereade: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471
[10:02] <rogpeppe> fwereade: any chance of another look at https://codereview.appspot.com/12175043/ ? i'm currently blocked on your "not lgtm"
[10:05] <rogpeppe> fwereade: also, you might want to have a look at https://codereview.appspot.com/12183043/
[10:10] <axw> 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] <axw> night all, have a nice weekend
[10:59]  * TheMue => lunch
[11:04] <dimitern> 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] <fwereade> dimitern, bah, annoying, but fair enough
[11:05] <fwereade> dimitern, is the complexity mostly on the watcher side or the client side?
[11:08] <dimitern> 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] <dimitern> fwereade: I can make them pass if I spend a few hours more perhaps
[11:08] <fwereade> dimitern, yeah, I can understand that
[11:09] <fwereade> dimitern, in that case just make it clear that UnitSettings.Settings is never guaranteed
[11:09] <fwereade> dimitern, and we can then kill it with impunity at some point in the future
[11:10] <dimitern> fwereade: ok, will do
[11:22] <dimitern> rogpeppe, fwereade: https://codereview.appspot.com/12344043/
[11:24] <natefinch> dimitern: what's the proper way to contact IS about my reitveld sign-in problem?
[11:24] <dimitern> natefinch: #is on the canonical irc server
[11:24] <natefinch> dimitern: thanks
[11:25] <dimitern> 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] <natefinch> 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] <rogpeppe> natefinch: what's your sign-in problem?
[11:28] <rogpeppe> dimitern: reviewed
[11:28] <dimitern> natefinch: I don't really know, but probably if you trace that the code's doing..
[11:28] <dimitern> rogpeppe: cheers
[11:30] <natefinch> 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] <natefinch> (and I can sign into reitveld in chrome w/ SSO no problem)
[11:35] <TheMue> dimitern: standup
[12:26] <rogpeppe> mgz: hg log -l 1 --template '{node}\n' -r .
[12:26] <rogpeppe> mgz: is the preferred solution i think
[12:28] <dimitern> rogpeppe: https://codereview.appspot.com/12344043/ - is that better?
[12:29] <dimitern> rogpeppe: I noticed a typo: s/remove/remote/
[12:30] <mgz> >_<
[12:36] <rogpeppe> dimitern: made another suggestion based on your version
[12:37] <dimitern> rogpeppe: thanks
[12:42] <rogpeppe> trivial CL anyone? https://codereview.appspot.com/12349043
[12:43] <dimitern> rogpeppe: looking
[12:45] <dimitern> rogpeppe: lgtm
[12:46] <rogpeppe> dimitern: trivial?
[12:46] <dimitern> rogpeppe: i think so yeah
[12:46] <dimitern> rogpeppe: method expressions?
[12:46] <rogpeppe> dimitern: next in line
[12:46] <dimitern> rogpeppe: ok
[12:52] <TheMue> rogpeppe: reviewed
[12:52] <rogpeppe> TheMue: thanks
[12:52] <allenap> Hi, does anyone have time for a relatively short review? https://codereview.appspot.com/12176044/
[12:52] <allenap> I have one LGTM already, and this branch is a pre-req for another already approved branch.
[12:53] <dimitern> allenap: looking
[12:54] <allenap> dimitern: Thanks!
[12:54] <dimitern> allenap: i don't see your first LGTM though
[12:55] <allenap> 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] <allenap> Anyone else for a shortish review? https://codereview.appspot.com/12176044/
[13:04] <dimitern> allenap: you've got a review
[13:04] <allenap> dimitern: Ta :)
[13:08] <rogpeppe> lunch
[13:12] <allenap> sudo lunch
[13:13] <allenap> mgz: Can I threaten, er, politely request a review? https://codereview.appspot.com/12176044/
[13:13] <mgz> allenap: sure :)
[13:13] <allenap> mgz: Ta muchly.
[13:13] <mgz> ah, and I actually read it already, so joy
[13:14] <dimitern> allenap: oops, my bad - missed the ports arg there
[13:15] <allenap> dimitern: No worries :)
[13:25] <natefinch> Perhaps an odd question: What's the release process like for Juju?  Is it documented somewhere?
[13:27] <dimitern> 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] <dimitern> natefinch: mgz and davecheney are your best sources on that I think
[13:27] <mgz> yeah,
[13:28] <mgz> I did say I'd gather everything up into a releaseing doc at one point, we're still refining stuff each release
[13:28] <mgz> mostly dave does the work
[13:28] <dimitern> mramm: ping
[13:28] <mramm> dimitern: pong
[13:29] <dimitern> mramm: still no response from hr about my missing tasks in allhands, I wrote to claire o'connell yesterday
[13:29] <mramm> ok
[13:29] <mramm> let's give it a couple of days
[13:29] <natefinch> ok, follow up... who decides what features go into a release?
[13:29] <mramm> and I'll follow up with her next week
[13:30] <dimitern> mramm: ok, just saying i did my part to try and resolve this
[13:30] <mramm> natefinch: dave cheney or everybody depending on how you look at it
[13:30] <mramm> dave picks the point in trunk from which he cuts the release
[13:30] <mramm> but the idea is that everything that goes into trunk should be releasable
[13:31] <natefinch> yep, cool
[13:31] <natefinch> are there dedicated QA people? Or just us?
[13:32] <dimitern> natefinch: wrt charms and stuff there are some automated tests
[13:33] <dimitern> natefinch: but juju-core itself testing is mostly us - go tests and live testing on ec2/canonistack
[13:33] <dimitern> natefinch: and we get feedback from a lot of other canonical (and some external) guys
[13:33] <natefinch> dimitern: that's cool
[13:34] <dimitern> natefinch: you'd probably want to have an ec2 account for testing and setup your canonistack creds for openstack live tests
[13:35] <dimitern> natefinch: ec2 costs can be reimbursed
[13:35] <natefinch> I have an ec2 account, don't have anything set up with canonistack yet
[13:35] <dimitern> natefinch: take a look here https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack
[13:39] <natefinch> dimitern: thanks
[13:46] <dimitern> mgz: are you sure the bot's runining the ppa's golang 1.1.1 ?
[13:48] <dimitern> mgz: ah, sorry, ignore that
[13:48] <TheMue> wow, 35°
[13:49] <dimitern> rogpeppe: your branch fails to build in rpc_test and apiserver/client_test
[13:49] <dimitern> TheMue: ah, it's much cooler here today - 28 and cloudy for a change
[13:50] <dimitern> hmm, haven't looked out actually - it's not cloudy at all
[13:52] <TheMue> dimitern: I've got a list of all times and temps of all team members. only John has it warmer. ;)
[13:54] <dimitern> TheMue: ah, well - 40+ there is like every day's average
[13:54] <natefinch> 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] <TheMue> dimitern: yeah, very hot there
[13:55] <natefinch> (26 is more like our normal summer temps)
[13:55] <TheMue> 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] <dimitern> natefinch: here in july and august it's typically 32-38, some days in august gettin 42-44
[14:00] <natefinch> dimitern: dang
[14:01] <natefinch> Pretty sure if it ever hit 42 here, the entire town would burst into flames
[14:02] <dimitern> natefinch: on the flip side, it never gets much below 10-12 in winter
[14:02] <dimitern> :)
[14:03] <natefinch> 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] <rogpeppe> dimitern: ha, i was totally sure i'd run gotest-c ./...
[14:05] <dimitern> 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] <dimitern> rogpeppe: ha!
[14:06] <dimitern> natefinch: so i enjoy the hot weather, preferably indoors when it's too hot
[14:06] <TheMue> natefinch: different units are always a pain, also when comparing inch and centimeters or miles and kilometers, not talk about feet
[14:06] <dimitern> rogpeppe: when changing method expressions i might want to skip the apiserver/machiner
[14:07] <dimitern> TheMue: one of the worst I think are volume measures - oz., gallons, etc.
[14:07] <natefinch> 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] <rogpeppe> dimitern: why so?
[14:08] <dimitern> rogpeppe: well, to make my life a bit easier while refactoring machiner to use a common setstatuser
[14:08] <dimitern> rogpeppe: or actually, don't worry, i'll deal with the conflicts
[14:09] <TheMue> natefinch, dimitern: yeah, no idea of the volumes
[14:09] <rogpeppe> dimitern: ok, thanks
[14:10] <natefinch> 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] <dimitern> TheMue: my second-most used google feature, after search is "x <unit> in <other-unit>"
[14:10] <natefinch> ....but at least we don't use stones for weight :)
[14:10] <natefinch> dimitern: yep, me too. Love that.
[14:11] <dimitern> natefinch: oh, stones! yeah there's that as well
[14:11] <dimitern> I think there's no plural actually: it's 20 stone :)
[14:11] <TheMue> dimitern: i've got an app for it ;)
[14:12] <natefinch> haha
[14:12] <TheMue> dimitern: it also converts currencies
[14:13] <dimitern> yep, I even wrote one (well, followed the tutorial really) currency converter for my ubuntu phone
[14:13] <natefinch> intersting... I had tests that were failing last night that are passing this morning.... I hate that
[14:14] <dimitern> 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] <natefinch> 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] <dimitern> natefinch: no worries, they're tricky and usually helps to report them if you see them more than once in a while
[14:17] <dimitern> natefinch: some tests are notoriously flaky because of some timeouts, which after lots of tweaking are *mostly* stable
[14:17] <natefinch> dimitern: yeah, been there, done that.  I understand
[14:19] <dimitern> rogpeppe: are you going to introduce state/interfaces.go ?
[14:19] <rogpeppe> dimitern: yeah, i think so
[14:19] <dimitern> rogpeppe: ok, i'll have some to add there
[14:21] <dimitern> rogpeppe: btw it'd be really nice if godef follows symlinks and reverts back to the symlink, rather than resolving it finally
[14:22] <dimitern> 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] <rogpeppe> dimitern: hmm, i'll have to think about that
[14:24] <rogpeppe> dimitern: i'm not entirely sure it's possible
[14:24] <dimitern> rogpeppe: well, perhaps if you detect the input file is symlinked, you can use that prefix when returning the result?
[14:25] <dimitern> rogpeppe: not a big deal really, just saying - I might try to hack something around that in my copious free time :)
[14:26] <dimitern> dang.. so following go conventions i'll end up with a type like SetStatuserer
[14:26] <rogpeppe> 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] <rogpeppe> dimitern: StatusSetter
[14:27] <dimitern> rogpeppe: oh, it works like charm
[14:27] <rogpeppe> dimitern: weird, 'cos that's not inside your $GOPATH
[14:27] <dimitern> rogpeppe: probably the link resolution comes before that
[14:28] <rogpeppe> dimitern: yeah, maybe go/build makes a canonical path
[14:29] <dimitern> rogpeppe: I need type StatusSetter in apiserver/common and state interface StatusSetter
[14:29] <rogpeppe> dimitern: seems not unreasonable
[14:29] <dimitern> rogpeppe: cf. common/remove.go - Remover and Removerer
[14:29] <rogpeppe> dimitern: "Removerer" is an abomination
[14:29] <rogpeppe> dimitern: but also quite funny
[14:30] <dimitern> rogpeppe: :) yeah, like double negative
[14:30] <dimitern> rogpeppe: I'll need StatusSetter and StatusSetterer in common
[14:31] <rogpeppe> dimitern: we're going to move away from having a method on state for each interface it can return
[14:31] <rogpeppe> dimitern: and have a single method, Entity, which returns the methods that all entities have in common
[14:32] <rogpeppe> dimitern: then each place that needs a particular interface can type-convert to that interface as required
[14:32] <dimitern> rogpeppe: websters dictionary actually contains setterer
[14:32] <dimitern> rogpeppe: yeah, that'd be nice
[14:35] <rogpeppe> 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] <rogpeppe> dimitern: that is, a person that setters.
[14:35] <rogpeppe> dimitern: because that's the meaning of the verb "to setter"
[14:35] <dimitern> rogpeppe: not sure what either a dewlap or seton are
[14:36] <rogpeppe> dimitern: neither me :-)
[14:36] <dimitern> :)
[14:36] <rogpeppe> 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] <rogpeppe> dimitern: nope, i'm wrong
[14:37] <rogpeppe> dimitern: http://en.wikipedia.org/wiki/Dewlap
[14:37] <dimitern> wow :)
[14:37] <jcastro> 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] <jcastro> who do I need to convince that we'd like instance-types back?
[14:38] <dimitern> jcastro: no-one, we'll have them
[14:38] <jcastro> oh ok
[14:38] <dimitern> jcastro: it was decided
[14:38] <jcastro> well that was easy!
[14:38] <dimitern> jcastro: and in the roadmap for next 2-3 weeks iirc
[14:39] <jcastro> awesome!
[14:39] <dimitern> jcastro: there was a lot of bikesheding around how to define them across providers/clouds though
[14:40] <dimitern> jcastro: like, if you need fallbacks for the same provider, but different clouds, etc.
[14:40] <jcastro> yeah
[14:40] <jcastro> I would be happy with just ec2 since those are the ones people know
[14:41] <dimitern> jcastro: i'm pretty sure openstack has to go there too
[14:41]  * jcastro nods
[14:44] <dimitern> 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] <rogpeppe> dimitern: that's what the State.Entity method will do
[14:45] <dimitern> rogpeppe: is that in yet?
[14:46] <dimitern> rogpeppe: will.. so probably not then
[14:46] <rogpeppe> dimitern: no, sorry, i just got distracted by the dubious code in testing.TestLockingFunction
[14:49] <dimitern> rogpeppe: ok, I'll work with the assumption it's there already
[14:49] <rogpeppe> dimitern: cool. you can call State.Lifer for the time being
[14:51] <dimitern> 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] <rogpeppe> dimitern: Entity will only return a Tagger, probably
[14:52] <rogpeppe> dimitern: you can type convert
[14:53] <dimitern> rogpeppe: so I can do entity, err := state.Lifer(tag) and then if statusSetter, ok := entity.(state.StatusSetter); ok { statusSetter.SetStatus(...) } ?
[14:54] <rogpeppe> dimitern: exactly
[14:54] <dimitern> rogpeppe: ok, cool
[15:06] <TheMue> so, both CLs are ready for review: https://codereview.appspot.com/12347043/ and https://codereview.appspot.com/12343045
[15:08] <dimitern> TheMue: will take a look
[15:10] <TheMue> dimitern: thx
[15:12] <dimitern> TheMue: so is it possible to say "remove the setting" if the default is !nil or "" ?
[15:12] <dimitern> TheMue: like juju set <svc> x= ?
[15:13] <dimitern> TheMue: or juju set <svc> --default x= (set the default to empty) ?
[15:15] <dimitern> rogpeppe: it seems you reverted back one of the panics?
[15:15] <rogpeppe> dimitern: i reverted back the panics that were necessary
[15:17] <dimitern> rogpeppe: why not just return some error there?
[15:18] <TheMue> dimitern: remove a string should only be possible if it is configured as default: null and you say set <svc> --default thatOption
[15:18] <rogpeppe> dimitern: which one are you referring to?
[15:18] <rogpeppe> https://code.google.com/p/go/issues/detail?id=6016
[15:19] <TheMue> dimitern: but that only with the 2nd cl. the first one doesn't change the behavior of set option=
[15:20] <dimitern> rogpeppe: in rpc_test
[15:20] <dimitern> TheMue: so what will now juju set <svc> option= do?
[15:20] <dimitern> TheMue: can you do as well juju set <svc> --default option= ?
[15:21] <rogpeppe> dimitern: because if we hit that line, something horrible has gone wrong
[15:21] <dimitern> rogpeppe: wow :) you actually found a compiler bug, again? :)
[15:21] <rogpeppe> dimitern: because it really should be unreachable
[15:21] <rogpeppe> dimitern: seems like it
[15:22] <dimitern> rogpeppe: awesome!
[15:22] <dimitern> rogpeppe: seems like we're one of the main sources of go bugs :)
[15:22] <TheMue> dimitern: as said, the 1st cl only adds --default as an alternative to option=, you cannot mix it.
[15:22] <TheMue> dimitern: but you can do set option=
[15:22] <rogpeppe> dimitern: erm, have you seen how many open bugs there are?!
[15:22] <TheMue> dimitern: both set to default
[15:22] <TheMue> dimitern: with the 2nd cl this changes
[15:22] <dimitern> TheMue: I think that's confusing
[15:23] <dimitern> TheMue: and needs more tests to verify all such cases
[15:23] <TheMue> dimitern: then string option will be set to an empty string with option=
[15:23] <dimitern> TheMue: and --default cannot take = after option or a value?
[15:23] <TheMue> dimitern: you have to see both cls combined, only splitted in two cls
[15:23] <dimitern> rogpeppe: haven't checked lately
[15:24] <TheMue> dimitern: which case do you want to be tested?
[15:24] <TheMue> dimitern: are you talking about the 1st cl?
[15:24] <TheMue> dimitern: i already said twice, it cannot. why should it?
[15:24] <dimitern> TheMue: --default option= and --default option=x at least
[15:25] <dimitern> 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] <TheMue> dimitern: it is, as those are detected as illegal options ;)
[15:25] <dimitern> TheMue: I can only see --default invalidoption
[15:26] <dimitern> TheMue: not --default validoption= or --default validoption=blah
[15:26] <TheMue> dimitern: option= is an invalid option too, and option=x also
[15:26] <dimitern> TheMue: ok, let's have 2 more tests for that then
[15:26] <dimitern> TheMue: I'll commet it on the review
[15:26] <TheMue> dimitern: i can add it, it helps you as a developer, but not the user
[15:27] <dimitern> TheMue: it's exactly the other way around I think
[15:28] <dimitern> TheMue: the tests should cover user stories, especially client-facing stuff like the CLI
[15:29] <dimitern> TheMue: so --default is a flag?
[15:29] <dimitern> TheMue: so we need tests that mix --default and other key=value pairs as well
[15:31] <dimitern> TheMue: users might try juju set <svc> key1=val1 --default key2 key3=val3
[15:32] <dimitern> TheMue: that's why I don't think --default should be a flag
[15:32] <TheMue> dimitern: that flag has been the  result of a longer discussion. what would you propose?
[15:33] <dimitern> TheMue: it should apply to the argument immediately following it, then it's obvious (and should be documented) it's an argument
[15:33] <dimitern> TheMue: like --default=x (with or without the =)
[15:34] <TheMue> dimitern: an argument looking like a flag?
[15:34] <dimitern> TheMue: is --config a flag?
[15:34] <dimitern> TheMue: it's not and it has an argument
[15:34] <TheMue> dimitern: btw, also --default a b c d is working
[15:35] <dimitern> TheMue: yeah, there are no tests for that as well
[15:35] <TheMue> how do you handle multiple defauls in one tx?
[15:36] <dimitern> TheMue: sorry? is it working or now?
[15:36] <dimitern> not*
[15:37] <TheMue> dimitern: in the cl set --default opta optb optc sets all three to default
[15:37] <TheMue> dimitern: how should the call look like in your opinion?
[15:38] <dimitern> TheMue: it can look like --default opta --default optb --default optc
[15:38] <TheMue> dimitern: userfriendly?
[15:39] <dimitern> TheMue: at least it's explicit, rather than key1=val1 --default key2 key3=val3 failing
[15:39] <TheMue> dimitern: yeah, that's not optimal
[15:40] <dimitern> TheMue: it has to be documented that --default has to be last
[15:40] <TheMue> dimitern: but the explicit way is not user friendly
[15:40] <dimitern> TheMue: i don't think is unfriendly, but that's another thing
[15:40] <TheMue> dimitern: why has it to be the last?
[15:41] <dimitern> TheMue: because of k=v --default x w=v
[15:43] <TheMue> dimitern: ???
[15:44] <dimitern> TheMue: it has to be last, otherwise the user might assume he can continue passing key=value pairs after --default <something>
[15:45] <dimitern> TheMue: oh, I see, so you assume in the code there's either --default or not and it comes first
[15:46] <dimitern> TheMue: ok, this simplifies things, but has to be documented better - there are 2 ways to invoke juju set: 1) <svc> key=value ... pairs, 2) --default name name...
[15:47] <TheMue> dimitern: yes, the doc is currently not enough
[15:49] <natefinch> is there a keyboard shortcut to tell ubuntu to make a window half the screen size? Like when you drag it up against the side of the screen? It's the one thing I miss from WIndows, and I use it all the time.
[15:51]  * TheMue works with fullscreen on four virtual screens
[15:53] <natefinch> I like being able to see stuff side by side, and with big monitors, making things fullscreen is usually a waste of space
[15:54] <dimitern> TheMue: reviewed the first one
[15:54] <TheMue> dimitern: thx
[15:54] <dimitern> natefinch: there are all sorts of shortcuts - if you install ccsm you can set them yourself
[15:55] <dimitern> apt-get install compizconfig-settings-manager
[15:56]  * fwereade observes that a very small insect has somehow managed to get inside his laptop screen
[15:56] <natefinch> google figured it out for me, ctrl-super-<direction arrow>
[15:56] <dimitern> then run ccsm - go to to Window Management - Grid
[15:56]  * fwereade wonders how long it will crawl around in there for
[15:56] <TheMue> fwereade: inside? that's strange
[15:56] <dimitern> fwereade: wow :)
[15:56] <fwereade> TheMue, yeah, indeed
[15:56] <fwereade> TheMue, blasted countryside
[15:56] <fwereade> TheMue, full of life
[15:56] <natefinch> I tried installing ccsm on my last ubuntu VM and was not successful. The default shortcut is fine by me, especially since it is nearly the same as I'm used to on Windows
[15:57] <TheMue> fwereade: thought you were in london?
[15:57] <fwereade> TheMue, suffolk today
[15:59] <sidnei> reviews: https://codereview.appspot.com/12352043
[15:59] <dimitern> TheMue: reviewed the second as well
[16:00] <sidnei> fwereade: mramm told me to bug you about the cloud-init message i sent to the list. i suspect that's already on the schedule for being discussed next week?
[16:00] <dimitern> natefinch: also it's worth mentioning that dragging the window around the edges will also put it left/right or maximize it
[16:01]  * fwereade tries to load state for sidnei, just a mo
[16:01] <natefinch> dimitern: yeah, that's what I've been doing, but if I can avoid using the mouse, it's preferable
[16:01] <mramm> sidnei: it isn't yet, but I'm adding it now
[16:01] <sidnei> thanks mramm
[16:01] <natefinch> dimitern: it's also finicky with multiple monitors, easy to overshoot
[16:01] <TheMue> dimitern: thx
[16:01] <dimitern> natefinch: the defaults for grid window placement is ctrl+alt+keypad #
[16:02] <natefinch> ahh, neat
[16:02] <dimitern> sidnei: can you repropose please, the diff is not there
[16:02] <sidnei> yeah, just noticed. doing it.
[16:03] <dimitern> man.. i have sticky keypad now after yesterday's little beer spill
[16:03] <natefinch> haha
[16:03] <TheMue> i have no keypad
[16:03] <dimitern> it good it's the external kbd, rather than the laptop
[16:04] <sidnei> dimitern: there, fixed
[16:04] <dimitern> sidnei: looking
[16:04] <natefinch> dimitern: I did the same thing last week (soda, not beer)... also external kbd . Luckily no damage after letting it dry out overnight.
[16:04] <dimitern> sidnei: wow, i never heard of install before
[16:05] <dimitern> natefinch: i have to submerge it in water and leave it to dry :)
[16:05] <fwereade> mramm, thanks; sidnei, I think I understand your need but smoser's points are good ones; I'm a bit leery of exposing cloud-init directly to users, even sophisticated ones
[16:06] <natefinch> dimitern: yikes, good luck with that! Hope it's not an expensive keyboard
[16:06] <fwereade> sidnei, what does cloudinit do for you, beyond (say) runcmd and add-package?
[16:06] <dimitern> or probably just dismantle it and clean it up carefully
[16:08] <fwereade> sidnei, because it seems potentially viable for juju to expose those in some way itself, and just happen to implement them with cloudinit
[16:09] <fwereade> sidnei, (sorry, of course, apt-proxy as well)
[16:14] <dimitern> sidnei: reviewed
[16:24] <rogpeppe> dimitern, fwereade, anyone else: https://codereview.appspot.com/12354043/
[16:24] <dimitern> rogpeppe: looking
[16:28] <rogpeppe> mgz: do you think the dependency file should contain dependencies for a) just cmd/juju and cmd/jujud; b) the entire tree or c) the entire tree plus testing deps too ?
[16:28] <dimitern> rogpeppe: lgtm
[16:28] <rogpeppe> dimitern: ta
[16:28] <mgz> rogpeppe: the lot
[16:28] <rogpeppe> mgz: okey dokey
[16:29] <dimitern> oh, yeah, the lot +1
[16:45] <natefinch> getting an error building trunk after my last pull:
[16:45] <natefinch> # launchpad.net/juju-core/environs/azure
[16:45] <natefinch> ../juju-core/environs/azure/storage.go:149: context.GetContainerProperties undefined (type *gwacl.StorageContext has no field or method GetContainerProperties)
[16:45] <rogpeppe> i just saw a failure in MachineSuite.TestWatchMachine
[16:45] <rogpeppe> though i can't reproduce it reliably
[16:45] <mgz> natefinch: see gwacl, pull that
[16:45] <sidnei> fwereade: there's a lot of stuff in cloud-init. things like apt_mirror_discover_from_dns or whatever it's spelled are interesting. it looks up an ubuntu-mirror.%(domain)s hostname and uses that as the default mirror for example. it might be more interesting to people which are heavy cloud-init users indeed.
[16:45] <rogpeppe> machine_test.go:594:
[16:45] <rogpeppe>     testing.NewNotifyWatcherC(c, s.State, w).AssertOneChange()
[16:46] <rogpeppe> testing/watcher.go:85:
[16:46] <rogpeppe>     c.Fatalf("watcher sent unexpected change: (_, %v)", ok)
[16:46] <rogpeppe> ... Error: watcher sent unexpected change: (_, true)
[16:46] <rogpeppe> anyone seen that before?
[16:46] <mgz> yeah, not sure I have any other context for you though
[16:46] <dimitern> rogpeppe: it's intermittent
[16:46] <rogpeppe> dimitern: you've seen it too?
[16:46] <mgz> just remember complaining to william that the assert didn't show anything useful
[16:46] <dimitern> rogpeppe: i've seen it like 3-4 times out of 50 runs
[16:46] <fwereade> sidnei, yeah, the trouble is that if we expose it we end up relegating anything we don't provision with cloud-init to a second class citizen
[16:47] <sidnei> fwereade: that's also smoser's concern yes.
[16:48] <sidnei> fwereade: for now i'd settle on simply fixing https://bugs.launchpad.net/juju-core/+bug/1203816 the simplest way, and then we can discuss further.
[16:48] <_mup_> Bug #1203816: local provider should support use of local proxy <juju-core:New> <https://launchpad.net/bugs/1203816>
[16:48] <fwereade> sidnei, yep, that sounds good to me
[16:49] <fwereade> sidnei, triaged high
[16:50] <fwereade> sidnei, and next week is bug week
[16:50] <fwereade> sidnei, so hopefully the immediate issue will be handled while we try to figure out the bigger ones
[16:51] <sidnei> fwereade: if i didn't make it clear, im working on a branch already. and i'll be at the sprint next week.
[16:51] <natefinch> mgz: thanks, that fixed me up
[16:51] <fwereade> sidnei, ah, I didn't spot that -- many thanks then
[16:54] <sidnei> dimitern: trying to make a const as you suggested in the review, but im failing to make it better to read. help?
[16:54] <sidnei> dimitern: or something like this is ok? http://paste.ubuntu.com/5940759/
[16:55] <rogpeppe> dimitern: i think i see how it can happen
[16:56] <rogpeppe> dimitern: but i'm not yet sure how to fix the test so it's reliable
[16:57] <dimitern> sidnei: my suggestion was (perhaps failed to mention) to use ` quotes
[16:57] <dimitern> sidnei: that way you don't need to concat the lines
[16:58] <sidnei> dimitern: http://paste.ubuntu.com/5940764/ ?
[16:59] <dimitern> sidnei: something like this http://paste.ubuntu.com/5940765/
[16:59] <dimitern> sidnei: yeah :)
[16:59] <sidnei> dimitern: your version adds an extra \n at the beginning. is it possible to avoid that with `\ like in python?
[17:00] <dimitern> rogpeppe: well, it happes rarely
[17:00] <dimitern> sidnei: no, for version seems better actually, if it works for you use it - it reads better already
[17:00] <sidnei> oki
[17:00] <rogpeppe> dimitern: it's important that tests are reliable
[17:01] <rogpeppe> dimitern: and that we know why they're failing
[17:01] <dimitern> rogpeppe: i agree completely
[17:01] <dimitern> rogpeppe: but i failed to see a reason why that particular one could fail
[17:02] <rogpeppe> dimitern: it depends on the state/watcher implementation, and whether that will send an event or not
[17:02] <dimitern> rogpeppe: can you make it fail more often than not?
[17:03] <dimitern> rogpeppe: not can you make it, but does it do that with you
[17:03] <rogpeppe> dimitern: i thought i'd be able to, but i haven't succeeded yet, which might mean my theory is bollocks
[17:05] <rogpeppe> dimitern: right, i can now make it fail reliably
[17:07] <natefinch> I'm getting some weird build failures trying to run go test in my new branch...
[17:07] <natefinch> cmd/environmentcommand_test.go:44: undefined: cmd.GetDefaultEnvironment
[17:07] <dimitern> rogpeppe: what was needed?
[17:07] <dimitern> natefinch: did you pull trunk recently?
[17:07] <natefinch> ...except that cmd.GetDefaultEnvironment is properly defined in a _test.go file
[17:07] <natefinch> yeah
[17:07] <rogpeppe> dimitern: i changed AssertOneChange to this: http://paste.ubuntu.com/5940791/
[17:08] <rogpeppe> dimitern: and called that function at the end of TestWatchMachine
[17:08] <dimitern> rogpeppe: well, commenting out the sync stuff will surely cause any time-sensitive watcher test to fail
[17:08] <rogpeppe> dimitern: in theory, making those changes should not affect the behaviour of the test
[17:08] <natefinch> dimitern: yeah, just pulled. Do I need to clean something out?
[17:08] <rogpeppe> dimitern: not really
[17:09] <rogpeppe> dimitern: the poll interval of state/watcher is 5s, considerably shorter than testing.LongTimeout
[17:09] <dimitern> natefinch: can you paste the log you're getting with the errors?
[17:09] <dimitern> rogpeppe: but the sync stuff is needed to get the changes after triggering them one the line just before the assert, right?
[17:10] <natefinch> dimitern: http://pastebin.ubuntu.com/5940792/   (plus a lot more)
[17:10] <rogpeppe> dimitern: only if you don't want to wait for the state/watcher to get around to polling
[17:10] <rogpeppe> dimitern: it's a short cut, not essential
[17:11] <dimitern> rogpeppe: I had to add it to a lot of tests to cause them to pass at all
[17:11] <dimitern> natefinch: pulling trunk and trying now myself
[17:12] <rogpeppe> dimitern: that's because the timeout was probably less than 5s
[17:13] <dimitern> rogpeppe: most of the time it's a lot less
[17:14] <dimitern> natefinch: so the cmd.GetDefaultEnvironment should be in cmd/export_test.go - can you see it there?
[17:14] <rogpeppe> dimitern: these days, the worst case timeout should always be testing.LongWait (10s)
[17:14] <natefinch> dimitern:  yep. it's there
[17:15] <natefinch> dimitern:  the code looks correct, but go test seems to disagree
[17:15] <dimitern> natefinch: try cd cmd/ && go test -gocheck.vv
[17:15] <natefinch> dimitern: same log output, same failures
[17:16] <dimitern> natefinch: it seems like there shouldn't be any failures, because it fails to build the tests
[17:16] <natefinch> sorry... I meant same failure to build
[17:16] <dimitern> natefinch: ok, but hmmm..
[17:17] <dimitern> natefinch: try pasting "go env"
[17:18] <natefinch> dimitern: http://pastebin.ubuntu.com/5940823/
[17:18] <natefinch> dimitern:  go version go1.1.1 linux/amd64
[17:19] <dimitern> natefinch: I think your gopath is wrong
[17:19] <dimitern> natefinch: it should be just one path, not a list of paths
[17:20] <rogpeppe> dimitern: here's a sketch of what i think is going on: http://paste.ubuntu.com/5940824/
[17:21] <dimitern> rogpeppe: did you try the race detector?
[17:21] <rogpeppe> dimitern: there's no memory race
[17:21] <rogpeppe> dimitern: plus unfortunately we can't use the race detector currently because of the bug i linked to earlier
[17:22] <sidnei> rogpeppe: can i get your blessing on https://codereview.appspot.com/12352043
[17:22] <rogpeppe> sidnei: looking
[17:22] <dimitern> rogpeppe: these 2 simple code paths have some serious and nasty complications
[17:22] <rogpeppe> dimitern: how do you mean?
[17:22] <dimitern> rogpeppe: we need to sync watchers so they don't compete like this
[17:23] <natefinch> dimitern: gopath can be a list of paths... https://code.google.com/p/go-wiki/wiki/GOPATH
[17:23] <dimitern> natefinch: it can be, but it's better that it's not
[17:23] <dimitern> natefinch: it's tricky and flaky, trust me
[17:24] <dimitern> rogpeppe: i mean the entitywatcher should somehow wait for the state watcher to poll first
[17:24] <TheMue> so, will step out into vacation
[17:24] <TheMue> dimitern: review is handled
[17:24] <dimitern> TheMue: have a great holiday!
[17:24] <dimitern> TheMue: thanks
[17:25] <rogpeppe> dimitern: i *think* the problem in this case may be solved simply by calling Sync rather than StartSync
[17:25] <TheMue> will keep an eye on further reviews so that i can push the stuff during some spare time
[17:25] <TheMue> dimitern: thanks
[17:25] <rogpeppe> dimitern: alternatively, it would be great if StartSync didn't allow a window for other events to arrive before actually starting to sync
[17:26] <rogpeppe> dimitern: although fixing that implies restructuring the state/watcher control loop a bit
[17:27] <dimitern> rogpeppe: yeah, a whole new can of worms i suspect
[17:27] <rogpeppe> dimitern: it shouldn't be too bad, in theory
[17:28] <rogpeppe> dimitern: i don't understand this comment, BTW
[17:28] <rogpeppe> // NewLaxNotifyWatcherC returns a NotifyWatcherC that runs a full watcher
[17:28] <rogpeppe> // sync before reading from the watcher's Changes channel, and hence cannot
[17:28] <rogpeppe> // verify real-world coalescence behaviour.
[17:28] <dimitern> rogpeppe: me neither, you should ask jam
[17:28]  * dimitern steps out for 10m
[17:28] <natefinch> dimitern: changed gopath to just the first directory, which is now reflected by go env, but same problem
[17:29] <natefinch> dimitern: take your time, I'll go work on something else, no big deal
[17:32]  * fwereade is off again, back again later
[17:37] <dimitern> natefinch: try and paste go list all
[17:41] <natefinch> dimitern: http://pastebin.ubuntu.com/5940890/
[17:44] <dimitern> natefinch: I think there's your problem
[17:44] <dimitern> natefinch: you have multiple copies of juju-core in your gopath
[17:45] <dimitern> natefinch: if you try removing all juju-core* dirs except juju-core2 from $GOAPTH/src/launchpad.net/
[17:45] <dimitern> natefinch: or moving them out of the way at least
[17:45] <natefinch> hmm ok
[17:46] <dimitern> natefinch: and also, rename $GOPATH/src/launchpad.net/juju-core2 to juju-core
[17:46] <dimitern> natefinch: import paths and work dir checkouts must match the import paths
[17:47] <dimitern> natefinch: yeah, too many import paths :)
[17:49] <natefinch> dimitern: right, right... silly me.  I don't usually have multiple branches going of the same code in Go... forgot you can't just call them something else
[17:51] <natefinch> that did it
[17:51] <dimitern> natefinch: cool!
[17:52] <natefinch> dimitern: thanks... I'll remember that for next time - gotta rename the branch I'm building to juju-core first
[17:52] <dimitern> natefinch: np :)
[17:59] <dimitern> natefinch: and now, after you fixed you lbox woes and everything is up and running, please don't forget to lbox propose your branch
[18:00] <natefinch> dimitern: yep. Gotta write tests for my change first, which is why I was trying to run the tests in the first place. Probably by EOD though.
[18:00] <dimitern> natefinch: no worries, it's good you have it running smoothly anyway
[18:00] <natefinch> yep
[18:01]  * dimitern reached eod: happy weekend everyone!
[18:01] <natefinch> dimitern: have a good weekend!
[18:02] <dimitern> natefinch: cheers, you too!
[18:07] <rogpeppe> mgz: https://codereview.appspot.com/12361043
[18:39]  * rogpeppe has reached eod too
[18:39] <rogpeppe> g'night and happy weekends all
[18:44] <natefinch> rogpeppe: g'night!
[18:45] <sidnei> bummer, no review from rog. natefinch: are you into doing reviews yet?
[18:46] <natefinch> sidnei: I don't think I'm qualified to do reviews yet. I can certainly review the quality of the code, but as for how it interacts with the rest of the system... I'm going to miss anything that's more than a little subtle
[18:47] <natefinch> sidnei: in other words, I can review, but it won't count for much :)
[18:47] <sidnei> natefinch: tis fine, a mostly trivial branch. https://codereview.appspot.com/12352043/
[19:10] <natefinch> sidnei: done.  lgtm.
[19:13] <natefinch> sidnei: if it were me, I'd rename addscripts to AddRunCmds or something similar, but that's really more of a complaint against the original code, not your changes
[19:13] <sidnei> natefinch: i think it's a good suggestion, i'll make the change.
[19:13] <natefinch> sidnei: cool.