#juju-dev 2012-05-01 <rogpeppe> niemeyer: morning! <niemeyer> rogpeppe: Heya! <rogpeppe> niemeyer: thanks for the LGTM, BTW <rogpeppe> niemeyer: will submit after i've upgraded to precise this morning. thought it might be a good idea before heading to UDS. i'm hoping the battery life will have reverted towards what i got under natty... <niemeyer> rogpeppe: Ah, super <niemeyer> rogpeppe: Just finishing reviews to get some sleep here as well <rogpeppe> niemeyer: hmm, precise says it's going to remove libzookeeper-dev, i wonder why <rogpeppe> niemeyer: oh yes, one thing i discussed with william last night <rogpeppe> niemeyer: how do you feel about upload-tools being a separate subcommand rather than a flag? <niemeyer> rogpeppe: Where would it upload to? <rogpeppe> niemeyer: to private storage <niemeyer> rogpeppe: Which private storage? <niemeyer> rogpeppe: There's no environment.. <rogpeppe> niemeyer: the storage mentioned in environments.yaml <niemeyer> rogpeppe: The environment doesn't exist <rogpeppe> niemeyer: it is created when necessary. it doesn't matter if it's created by bootstrap or upload-tools, i think <niemeyer> rogpeppe: bootstrap is what creates it.. we can't expect the private storage to work before that happens. <niemeyer> rogpeppe: Heh <niemeyer> rogpeppe: So you're turning upload-tools into bootstrap.. <niemeyer> rogpeppe: Doesn't feel great. <rogpeppe> niemeyer: bootstrap is all about starting the first machine, i think. the storage is somewhat incidental. <niemeyer> rogpeppe: bootstrap is all about creating the environment. Everything else is a side effect of that. <niemeyer> rogpeppe: Storage can't be assumed to work at all before the environment has been bootstrapped. <rogpeppe> niemeyer: ok, so if it's not a command, which commands should get --upload-tools (or --upload-client?) as a flag? <niemeyer> rogpeppe: There are environments that already depend on that (local) and it's pretty much certain that private storage will move out of S3 in the future and into a custom service <niemeyer> rogpeppe: Right now, bootstrap <rogpeppe> niemeyer: and what if you want to upload tools for several architectures before bootstrapping? <niemeyer> rogpeppe: You can't. There's no where to upload to before bootstrap happens. <rogpeppe> niemeyer: if there was a separate command that could only run after bootstrap, in addition to the --upload-tools flag on bootstrap, that could work <rogpeppe> niemeyer: something to think about anyway. for the time being, i'll just do the flag on bootstrap. <rogpeppe> niemeyer: thanks for the input. <niemeyer> rogpeppe: Maybe, but it might work fine to have --upload-tools as a flag of upgrade-juju as well <niemeyer> rogpeppe: Hmm.. not sure <niemeyer> rogpeppe: Maybe upload-tools would be cleaner <rogpeppe> niemeyer: yeah, not sure either. <rogpeppe> niemeyer: it seems like it's mostly orthogonal <niemeyer> rogpeppe: Yeah, you're right <niemeyer> Okay.. really need some sleep now <rogpeppe> niemeyer: yeah, you do! <rogpeppe> niemeyer: yeah, you do!) <rogpeppe> :-) <niemeyer> rogpeppe: Have a great day :) <niemeyer> and talk to you in a few hours maybe <rogpeppe> niemeyer: yeah <rogpeppe> niemeyer: sweet dreams.. <niemeyer> Thanks man * niemeyer => sweetness <wrtp> niemeyer: mornin' <wrtp> niemeyer: sleep well? :-) <niemeyer> wrtp: Heya! <niemeyer> wrtp: Yep <niemeyer> wrtp: All good, thanks <niemeyer> wrtp: How was the day? <wrtp> niemeyer: not quite as productive as hoped. i'm a little unsure about the best way to proceed. <wrtp> niemeyer: i might change the proposal i made earlier - i'm currently thinking that an "uploadTools" bool argument to Bootstrap might be better. <niemeyer> wrtp: We might have both, I suppose <niemeyer> wrtp: Actually, hmm.. <wrtp> niemeyer: i think that's the best way <niemeyer> wrtp: What's the background? <wrtp> niemeyer: one current problem is that given the Environ interface, i'm forced to call PutFile before Bootstrap <wrtp> niemeyer: i thought about having a separate "Create" call to create the environment's state, but that seems wrong. <niemeyer> wrtp: Yeah, I see what you mean.. maybe the bool is the best solution.. let me think for a moment as well <wrtp> niemeyer: the other problem is how to tell the Environ to do exact version matching. <wrtp> niemeyer: i'm also trying to think forward with an eye towards constraints. <niemeyer> wrtp: Talk me through it <wrtp> niemeyer: my current idea is that if the uploadTools bool arg to Bootstrap is true, the environ creates the state appropriately and calls environs.UploadTools. it also triggers exact version matching (which will need to be an argument to the provisioning agent). <wrtp> niemeyer: *and* (for the future) it adds the current architecture to the bootstrap constraints. <wrtp> niemeyer: in addition to that, we'd have an upload-tools command to juju which would upload tools for the current version/arch with no other side effects. <wrtp> niemeyer: how does that sound? <niemeyer> wrtp: It sounds reasonable <wrtp> niemeyer: cool. <niemeyer> wrtp: Both things seem interlocked really <niemeyer> wrtp: We can't bootstrap without the tools, and we can't upload the tools without bootstrapping <niemeyer> wrtp: So it makes sense to have the chicken being fabricated to get started :) <wrtp> niemeyer: yeah. well, maybe - it works ok on ec2, but maybe not with other providers as you've said <wrtp> niemeyer: and we'd need another arg to bootstrap anyway to ask for an exact version. <niemeyer> wrtp: Even EC2 itself may not work so well with that in the near future <niemeyer> wrtp: Think environment storage moving onto the nodes <Aram> hi folks. <wrtp> niemeyer: how can that work? <niemeyer> Aram: Heya <wrtp> niemeyer: how can we know what node to contact without some storage? <wrtp> Aram: hi <niemeyer> wrtp: There are good ways to tag machines in EC2 nowadays <wrtp> niemeyer: ah, yeah, that seems reasonable then. ec2 metadata becomes the storage... <niemeyer> wrtp: Not really the storage.. <wrtp> niemeyer: the storage for the initial contact info <wrtp> niemeyer: replacing zookeeper-addresses (or whatever the name is) <niemeyer> wrtp: yeah.. this is really a lookup mechanism rather than actual storage <niemeyer> wrtp: It'll actually be a lot nicer that way <niemeyer> wrtp: We can even move into this direction today, I guess <niemeyer> wrtp: Well, not yet <niemeyer> wrtp: We'd still need the control bucket either way <wrtp> niemeyer: yeah <niemeyer> wrtp: But it'll be awesome to drop that ugly setting <wrtp> niemeyer: although calling it "control-bucket" would soon be a bit wrong <niemeyer> wrtp: Well, I hope we kill it for good <niemeyer> wrtp: It'll also be a lot nicer to port it across providers <niemeyer> Oops.. time to talk about juju here.. <wrtp> niemeyer: have fun <wrtp> niemeyer: off for the day. see you tomorrow some time, hopefully. <niemeyer> andrewsmedina: Heya <niemeyer> andrewsmedina: How're things going there? <andrewsmedina> niemeyer: hi <andrewsmedina> niemeyer: I'm finishing the works in the networking for local provider <andrewsmedina> niemeyer: rog did the review <andrewsmedina> niemeyer: https://codereview.appspot.com/6099051/ <niemeyer> andrewsmedina: I noticed, that's awesome.. a bit rushy this week due to the event here, but I'm looking forward to checking it out #juju-dev 2012-05-02 <TheMue> morning <TheMue> davecheney: Welcome to the team. <davecheney> hey there! <TheMue> davAlready officially started or has it been the 01.06.? <TheMue> davecheney: Oops, forgotten to press tab. ;) <davecheney> yes, i started on the 1st <fwereade> heya wrtp <wrtp> fwereade: mornin'! <TheMue> fwereade, wrtp: Morning <fwereade> morning TheMue <wrtp> TheMue: yo! <TheMue> fwereade, wrtp: Will be funny in future, Dave just left the channel. <wrtp> TheMue: yeah, big time difference... <wrtp> TheMue: has he started now? <TheMue> wrtp: Yes, yesterday. <fwereade> where's he based? <wrtp> fwereade: oz * TheMue is preparing his 12.04 upgrade. <wrtp> TheMue: i did mine yesterday <wrtp> TheMue: it was *not* hassle-free! <wrtp> TheMue: but it finally worked <TheMue> wrtp: Tell me more (while my backup is running). <wrtp> TheMue: well, i set the upgrade process working. it got most of the way through, but at some point everything went blank. the machine wasn't down (i could switch to a terminal) but the window system was dead. <wrtp> TheMue: then the recovery console came up, but i couldn't log in, so i tried "shutdown now" in a terminal, which hung, so i had to do a hard power down <wrtp> TheMue: when i rebooted, all the installation process was borked half way through (the mouse didn't work and the resolution was about 640x480). then i had to run "apt-get install -f" and another command, which finally completed the installation, but again shutdown didn't work and i had to hard power down. <wrtp> TheMue: after that, it seems to work. <wrtp> TheMue: oh yes, when installing packages, it hung for an hour or two until i realised that i had to click on "Terminal" in the upgrade manager and press return to get through an interactive bit. <TheMue> wrtp: Aha, good hints. So I'll see what happens here. <fwereade> TheMue, wrtp: yeah, that "terminal" business was annoying; I started my upgrade just before going out for the night <wrtp> fwereade: (yorkshire voice) it's a bloody disgrace! <wrtp> fwereade: honestly, if i'd been a naive user, my install would've failed there. i wonder what my neighbour did... <TheMue> Hehe. <Aram> moin. <TheMue> wrtp: So far it looks like everything worked fine here. <wrtp> TheMue: cool, have you rebooted into precise then? <TheMue> wrtp: Yes, looks good so far. First a bit higher load, but now it's ok. <wrtp> TheMue: guess it's just my machine then <wrtp> TheMue: or my malign influence <TheMue> wrtp: There are enough influencing factors. <TheMue> wrtp: But you have to know that my Ubuntu runs in a VM, so always an optimal environment. <wrtp> TheMue: i didn't know that. what do you run it inside? <TheMue> wrtp: My machine is a MacBook Pro, and Ubuntu runs very good in VMware Fusion. <TheMue> wrtp: The Mac is large enough, i7-2720 and 8 Gig, so I can spend the half to Ubuntu. ;) <wrtp> TheMue: ah, i thought you were using an ubuntu laptop. i guess you just didn't want to bring a mac laptop to a canonical event :-) <TheMue> wrtp: I've been Apple user for a longer time now. Then I tried a Dell (you've seen it in January) but never really been happy with it. So I switched back. <wrtp> TheMue: carmen has stolen my macbook now :-) <TheMue> wrtp: Hehe, intelligent wife. <wrtp> fwereade: you've got a review <wrtp> fwereade: you might wanna have a look at https://codereview.appspot.com/6145043/ <fwereade> wrtp, tyvm <fwereade> wrtp, btw, um, a review for what? <wrtp> fwereade: https://codereview.appspot.com/6163044/ <fwereade> wrtp, thanks (sorry, mail just arrived) <fwereade> wrtp, LGTM <wrtp> fwereade: thanks * TheMue is happy to see that his Sublime Text works fine with HUD * wrtp will probably never use the HUD except when he hits "Alt" by mistake... * wrtp ordered a new phone this morning. indulgent i am. <fwereade> wrtp, cool, what are you getting? <wrtp> fwereade: HTC One S <fwereade> wrtp, oo, shiny :) <wrtp> fwereade: am a little concerned about battery life and it's annoying it won't take an extra SD card, but looks fairly good otherwise. it was a snap decision, might be a bad one! <fwereade> wrtp, objectively, everything you can possibly buy it crap: consider your decision a blow against the confusopoly <wrtp> fwereade: serves me right for not doing full research before calling vodafone ("we've got a good deal for you but only if you choose NOW") <fwereade> wrtp, grar <wrtp> fwereade: yeah. every phone i've ever got has been a snap decision. and i've mostly been happy (that nokia thing was dreadful though) <wrtp> fwereade: yeah, i do hate it when they do that. and maybe her "i'll just go and speak to my manager" was code for "i'll just put you on hold for a couple of minutes and then give you the standard deal"... <TheMue> wrtp: You don't think they talk to their manager especially for you? (wonder) <wrtp> TheMue: well, i *think* she probably did, 'cos she seemed quite reasonable and informed etc, but you just can't tell. <TheMue> Reminds me when we bought our kitchen. To get the optimal deal she had to talk to her manager too. Afterwards you smelled the cigarette smoke, she just made a pause. <TheMue> The listed prices for kitchens here are almost always about the double of the price you can negotiate. <wrtp> TheMue: yeah. not sure if that's true for IKEA though. <TheMue> wrtp: No, there it isn't. <TheMue> wrtp: But regular IKEA prices and negotiated trading prices are almoste the same. We designed our kitchen with the IKEA design application and got a part and price list. But then they changed the front design, so we took a look at a different trader (with that list in our hand). <TheMue> wrtp: And we got a better kitchen for almost the same price (including delivery and installation). <wrtp> TheMue: interesting. we're quite happy with our ikea kitchen actually. carmen spent long hours with that pretty crappy design app. i think she ended up with 19 possible versions! <TheMue> wrtp: Hehe, indeed, a crappy app. I also needed some time to enter Carmen and my ideas. <TheMue> Aaaaargh! <TheMue> Enjoyed working on the veranda so far. Now a neighbor started his lawnmower. <fwereade> wrtp, TheMue: the hook commands which produce output default to a "smart" mode which basically just (python) str()s the result <fwereade> wrtp, TheMue: any thoughts on what we should be doing there? <wrtp> fwereade: is smart mode intended for readability or program parseability? <fwereade> wrtp: if it were meant to be parseable, I'd expect a repr() <fwereade> wrtp, but frankly str() of a big dict ain't all that readable itself <wrtp> fwereade: i suppose that we should really produce an identical version because people will be parsing the result and using in scripts <fwereade> wrtp, so... I have no idea what the point is really :( <wrtp> fwereade: but if it was up to me i'd provide a way to produce JSON ouput <fwereade> wrtp, that's already there <TheMue> wrtp: +1 <fwereade> wrtp, I have a lurking suspicion that nobody uses the default output mode for anything at all <wrtp> fwereade: it would be nice to be able to grep across all known charms... <fwereade> wrtp, hmm, does charmtools getall (or whatever it is) still work, I wonder <wrtp> fwereade: thing is, it's never going to be used interactively, so there's no really use for a pretty output AFAICS <fwereade> wrtp, well, there's always debug-hooks <wrtp> fwereade: ah, i'd forgotten about that <fwereade> wrtp, but I did indeed always wonder just how smart the "smart" formatting really was <wrtp> fwereade: it would be nice to do something that actually looks decent. but not if it breaks charms - i don't think it would be worth it for that. <fwereade> wrtp, well, the worry is that I'll end up sidetracking myself into writing "encodings/python_useless" <fwereade> effectively <wrtp> fwereade: yeah, i totally see that <wrtp> fwereade: i'd ignore it for now <wrtp> fwereade: it can be one of the last things we do before "feature parity" probably. <fwereade> wrtp, hmm, that sounds like a good idea to me <fwereade> wrtp, cheers :) <wrtp> fwereade: np <wrtp> fwereade: i was just contemplating the checkContext method <fwereade> wrtp, oh yes? <fwereade> wrtp, feels a touch clunky to me, improvements welcome :) <wrtp> fwereade: i wonder if it might be better to have newX functions to create commands. <wrtp> fwereade: then they can check the context for themselves <fwereade> wrtp, hmm, maybe... I can't really tell which is better tbh <fwereade> morning niemeyer <wrtp> e.g. func NewConfigGetCommand(ctx *Context) (cmd.Command, error) <wrtp> niemeyer: hiya <wrtp> fwereade: then all the commands could go into a table... <fwereade> wrtp, sorry, expand a little there? <niemeyer> fwereade, wrtp: Heya! <wrtp> fwereade: var commands = map[string]func(*Context)(cmd.Command, error) {"config-get": NewConfigGetCommand, etc...} <fwereade> wrtp, true, that's nice... I guess it saves a couple of lines of code :) <wrtp> fwereade: the table is static, so it's more obviously regular too, i think. <fwereade> wrtp, yeah <fwereade> wrtp, ok, SGTM <wrtp> fwereade: and it means the command type can go... for now :-) <fwereade> wrtp, I need to be off in a very short mo; I'll just -wip that and propose the followup, which should be independent <fwereade> wrtp, even better <fwereade> wrtp, cool <wrtp> fwereade: great <fwereade> g'night all, happy coding; would appreciate your thoughts on https://codereview.appspot.com/6165044 <wrtp> fwereade: g'night <SpamapS> hazmat: hey, whats the plan on landing strong ACL support in galapagos? I'd like to get it in sooner rather than later. <andrewsmedina> why does juju use local-hostname/public-hostname instead local-ipv4/public-ipv4 to get ip address metadata for ec2 provider? <niemeyer> andrewsmedina: Because the ec2 provider isn't the only one, and we may not have ipv4 for a machine <andrewsmedina> niemeyer: But, In the OpenStack, hostname is not always resolved <niemeyer> andrewsmedina: How's that an issue? <andrewsmedina> niemeyer: I'm using juju with openstack. And in my openstack setup I will use only private ips, with that hostnames, public ips, cant be resolved <niemeyer> andrewsmedina: How's that an issue? <niemeyer> andrewsmedina: IPs aren't resolved.. <niemeyer> andrewsmedina: Charms can just use the private address to intercommunicate <andrewsmedina> niemeyer: hmm <SpamapS> andrewsmedina: isn't it 'address'? <SpamapS> andrewsmedina: not "hostname" ? <SpamapS> So its expected that it may be a host name or an IP <SpamapS> andrewsmedina: most charms use private address to do almost everything anyway <andrewsmedina> SpamapS: nice, I will try use private address in my charms #juju-dev 2012-05-03 <wrtp> fwereade: goat moaning <fwereade> wrtp, baaaaa <TheMue> mornin' <fwereade> heya TheMue <TheMue> fwereade: Today St Peter does his work to not make Roger jealous. It's raining here. <fwereade> TheMue, haha <wrtp> TheMue: yo! <wrtp> TheMue: it's dry here, at least <wrtp> TheMue: but still grey <wrtp> and cold <TheMue> wrtp: Temperature dropped by about 10Â° and rain has replaced sun. <fwereade> wrtp, good advice last night, I think it's much better: https://codereview.appspot.com/6163044/ <wrtp> fwereade: cool. yeah, i think that does look cleaner, thanks. <fwereade> wrtp, btw, I think it *is* a getCommand not a command -- but do you have a better name in mind? <fwereade> wrtp, maybe commands should be commandGetters * wrtp has another look <fwereade> wrtp, alittle voice from my misspent youth is telling me I should use the word "factory", but I'm trying to pretend I can't hear it ;) <wrtp> lol <wrtp> fwereade: perhaps the word "new" should come into it somewhere <fwereade> wrtp, not so sure, I feel that "new" binds too weakly <fwereade> wrtp, "newCommands" sounds to me like it's doing something diferent <wrtp> fwereade: newc ? cmdMaker ? plain "new" ? <wrtp> cf ? :-) <fwereade> wrtp, "constructors"? <wrtp> fwereade: i don't mind the name "commands". it's just "getCommand" that reads oddly to me. <wrtp> fwereade: it sounds more like it's getting a command that already exists rather than constructing a new one <fwereade> wrtp, a method called "GetCommand" that chooses a "getCommand" helper and returns its result feels pretty natural to me <fwereade> wrtp, hmm, yeah <wrtp> fwereade: or that it's an actual command that gets something <fwereade> wrtp, maybe the method itself should be NewCommand(string name) <wrtp> fwereade: +1 <fwereade> wrtp, then "newCommands" and "newCommand" feel good <fwereade> wrtp, cool <fwereade> thanks :) <wrtp> fwereade: tbh in such a local context, a short variable name would read well, i think. <wrtp> fwereade: then you have to look elsewhere for context, and you'll see the type of commands etc <fwereade> wrtp, "c" it is then :) <wrtp> fwereade: or "f"? given it's a function not a command. <fwereade> wrtp, +1 * wrtp likes "NewCommand" <wrtp> fwereade: LGTM <fwereade> wrtp, cheers <fwereade> wrtp, TheMue: should be utterly trivial: https://codereview.appspot.com/6184044 <TheMue> *click* <fwereade_> morning niemeyer <niemeyer> fwereade_: Hey man! <niemeyer> fwereade_: Good timing, I was "talking to you" :-) <fwereade_> niemeyer, dammit, is my astral projection wandering again? <fwereade_> niemeyer, what can I do for you? <niemeyer> fwereade_: Was just answering https://codereview.appspot.com/6124051/ * fwereade_ reads... <fwereade_> niemeyer, fair enough :) <fwereade_> niemeyer, although I'm not sure how to communicate exit codes with that model <niemeyer> fwereade_: Hmm <niemeyer> fwereade_: I almost suggested before that the Main function in cmd should actually return an error instead, precisely for that reason <fwereade_> niemeyer, I'd kinda prefer to keep the exit codes meaningful really <niemeyer> fwereade_: Maybe that's what we should do.. there's a single situation we return an error different than 1, right? <fwereade_> niemeyer, Init errors return 2 <fwereade_> niemeyer, which could really be caused by anything under the general heading of parsing <niemeyer> fwereade_: Ok.. anyway.. we can easily get going by merely returning the code from Main <fwereade_> niemeyer, ok, sounds good <niemeyer> fwereade_: I've used both of these schemes in other applications before <niemeyer> fwereade_: Both the early dying and the return err <niemeyer> fwereade_: Returning errors generally ended up producing better code <fwereade_> niemeyer, except, hmm again: a code of 1 could come either from the "real" command, or from jujuc, and I think we only want to print jujuc help in the latter case <niemeyer> fwereade_: Let's please never print help unless the user asks for it <fwereade_> niemeyer, in practice I think that means either "never print help" or "complicate things an irritating amount to detect the cases in which the user asked for help and didn't get it from the real command" <niemeyer> fwereade_: I don't understand.. <niemeyer> fwereade_: If the user asked for help and didn't get from the real command, that's a bug in the real command <fwereade_> niemeyer, I'm thinking of the case in which we couldn't talk to the agent for whatever reason <niemeyer> fwereade_: "error: couldn't talk to the agent"? <fwereade_> niemeyer, that was the original intent: that the various things that can go wrong at this end print an appropriate error *and* an explanation of what's going on; otherwise everything is handled through the stuff returned by the agent <niemeyer> fwereade_: I understand, but I don't think explaining how things work every single time is necessary, or even nice <niemeyer> fwereade_: an error message explaining what went wrong should be good enough <niemeyer> fwereade_: ssh => invalid password; vs. ssh => invalid password + ssh is an application that requires a password to be set blah blah blah <fwereade_> niemeyer: so I should change this everywhere? <niemeyer> fwereade_: Do we have other locations doing the same thing? <niemeyer> fwereade_: I recall making the same comment elsewhere before <fwereade_> niemeyer, parse errors print help; others don't <niemeyer> fwereade_: I'm personally less concerned about those, but I don't mind if you decide to change them to behave that way as wel <niemeyer> l <fwereade_> niemeyer, jujuc seemed to me to be a special case in that an error out of jujuc itself implies extreme brokenness <fwereade_> niemeyer, personally I like getting help when I type utter gibberish <fwereade_> niemeyer, but that's by the by <niemeyer> fwereade_: Sure, if you want to keep showing help on parse errors, I personally don't mind either. That said, I don't *miss* the help, even in those cases <fwereade_> niemeyer, assumed context for printing help when jujuc is run in a bad environment is "users should only actually see this when they try to run jujuc on its own" <niemeyer> fwereade_: I prefer a one-liner error saying "error: you mistyped --gibberush" than "blah blah blah blah blah blah blah.. and you mistyped --gibberush" <niemeyer> fwereade_: "error: jujuc must be called from its symlinks"? <fwereade_> niemeyer, hmm, ok, how about printing that iff filepath.Base(os.Args[0]) == "jujuc" <fwereade_> niemeyer, and otherwise not offering help (except as supplied by remote commands ofc) <niemeyer> fwereade_: Sounds good <fwereade_> niemeyer, cool, thanks <niemeyer> fwereade_: Thank you, and sorry for not being very clear about those ideas before <wrtp> niemeyer: hiya <wrtp> niemeyer: any chance of a review of https://codereview.appspot.com/6159044/ ? <niemeyer> wrtp: Ah, sorry.. I half-reviewed it already but forgot to finish yesterday <wrtp> niemeyer: np. i'm working on another s3 branch which i'd hoped would be independent but turns out it's not. <niemeyer> wrtp: LGTM <wrtp> niemeyer: cool, thanks. * TheMue will next propose the relation methods of topology. The code is even more compat than Py. Nice. <niemeyer> TheMue: Sweet <TheMue> niemeyer: Yes, indeed. But I still would like you to tell me a bit more about the relations concept next week. Inside topology it's simple, but I'm still feeling unsecure regarding the relation manager etc. <niemeyer> TheMue: SOunds good <TheMue> niemeyer: Thx <jimbaker> hazmat, were you able to take a look at lp:~jimbaker/juju/unit-rel-lifecycle-start-invoker ? (https://codereview.appspot.com/6131061/) <hazmat> jimbaker, checking it now <jimbaker> hazmat, thanks <fwereade_> gn all <wrtp> fwereade_: see ya tomorrowq <wrtp> niemeyer: just discovered a slight oddity in the s3 package <wrtp> niemeyer: is it right that the ETag has double-quotes around it? <wrtp> niemeyer: the tests check that, but it seems odd <niemeyer> wrtp: I don't really have memories about that anymore, but if it's there, it means I've probably seen somewhere at least <wrtp> niemeyer: yeah, it seems weird, but i'll add a bit of documentation for others to note. <niemeyer> wrtp: Worth testing <wrtp> niemeyer: yeah, it bowled out an error in my test server. <TheMue> Hmm, today my net is pretty unstable. <wrtp> niemeyer: https://codereview.appspot.com/6185044 <wrtp> niemeyer: sorry about the gofmt noise, but i think it's easy to see when a file has only changed white space <wrtp> right, good moment to stop. <wrtp> see y'all tomorrow <niemeyer> wrtp: Cool <niemeyer> wrtp: have a good time <hazmat> jimbaker, sorry got de-railed for scale test demo of juju on 10k nodes.. <jimbaker> hazmat, no worries <fwereade_> niemeyer, if you have a moment, I'm not sure what the issue is with contexts <niemeyer> fwereade_: I'm not sure either, so happy to talk if you're not sleeping yet :) <fwereade_> niemeyer, there is server.Context and cmd.Context which are entirely distinct <niemeyer> fwereade_: The basic question is: how come we have two contexts, and one of the is completely ignored? <niemeyer> fwereade_: Yes, and that's confusing.. why there are two contexts and why is one of them getting into the function without being used? <fwereade_> niemeyer, the cmd.Context isn't used if we happen not to use stdout/stderr/working-dir <niemeyer> fwereade_: It's quite possible that it's totally fine, but the fact I'm confused is at least an indicator that it'll not be obvious why that exists in a bit <fwereade_> niemeyer, I think/hope that the source of the confusion is the fact that we have 2 different typs in different packages whih have the same name and end up being used close to one another <niemeyer> fwereade_: It's more than that.. we have two different types, in different types, used for the same thing, and getting to the context in two different ways, with one of them being entirely ignored at times <niemeyer> s/in different types/in different packages/ <fwereade_> niemeyer, how are they being used for the same thing? <fwereade_> niemeyer, one of them is about th ee <niemeyer> fwereade_: Maybe I'm just confused then * niemeyer looks at the code <fwereade_> niemeyer, ...the execution environment, and one of them is about the state we're working against <fwereade_> niemeyer, I haven't found it confusing myself *but* that's no doubt because I'm in an extremely privileged position there <fwereade_> niemeyer, the name "Context", now I think of it, is not much better than "DataManager" <niemeyer> fwereade_: DataManager is as good as Struct :-) <fwereade_> niemeyer, I had hoped the cmd.Context/server.Context distinction would be considered appropriately gotastic, but clearly that's not the case ;) <niemeyer> fwereade_: and the issue may come out of the naming indeed.. by definition, a thing executing in two contexts at the same time is unexpected <fwereade_> niemeyer, part of me wanted to call server.Context something like server.State, but then we hit the same issue with state.State <niemeyer> fwereade_: Their name is ok in isolation, but the moment you have two contexts at once, something feels wrong <niemeyer> fwereade_: The issue is partly in my head indeed, anyway <niemeyer> fwereade_: Don't worry about it.. the issue is less important than I though <niemeyer> fwereade_: We can find a better name later if necessary <niemeyer> fwereade_: I'll review the code again in light of your explanation, thanks <fwereade_> niemeyer, cool, thanks -- I was toying with explicit cmdCtx/serverCtx throughout, but that felt painful too <fwereade_> niemeyer, suggestions appreciated :) <niemeyer> fwereade_: I don't have any good suggestions either right now.. if I come up with something that you might like I'll post in the review <niemeyer> fwereade_: Thanks, and sorry for the noise <fwereade_> niemeyer, cheers <fwereade_> niemeyer, and no worries :) <fwereade_> ttyl <niemeyer> fwereade_: Ok, got a more concrete suggestion that might take away the minor confusion <niemeyer> fwereade_: Review is up, with an associated LGTM assuming you're happy with it too #juju-dev 2012-05-04 <fwereade_> morning wrtp <wrtp> fwereade_: hiya * wrtp is somewhat grazed <fwereade_> wrtp, bike ride complications? <wrtp> fwereade_: yeah, coming down hill, did a spectacular slide on a bend. <fwereade_> wrtp, heh, at least it was spectacular, I suppose ;) <wrtp> fwereade_: yeah, as is the scrape on my hip! <fwereade_> wrtp, ouch :( <wrtp> fwereade_: at least the bike's ok too <fwereade_> wrtp, jolly good <fwereade_> wrtp, when I was commuting by bike it surprised me how much the various associated expenses added up <wrtp> fwereade_: yeah. i think i'm going to cheat and leave it at a shop to be serviced this week... <wrtp> fwereade_: when are you arriving at UDS BTW? <fwereade_> wrtp, er, lunchtime-ish on sunday <fwereade_> wrtp, and you? <wrtp> fwereade_: sat afternoon <fwereade_> wrtp, ah, nice <wrtp> fwereade_: got the new phone yesterday afternoon. it *is* shiny. <fwereade_> wrtp, cool <fwereade_> wrtp, I'm vaguely hoping to hold off on new phones until I can get one with ubuntu for android <fwereade_> wrtp, but, well, my current one is hanging by a thread <fwereade_> wrtp, we'll see how long it lasts :) <wrtp> fwereade_: that would be quite cool. <wrtp> fwereade_: you could probably do that on this one if you jailbroke it <fwereade_> wrtp, probably not on an iphone <fwereade_> wrtp, well, ok, probably it's *possible*, but it strikes me as hte sort of monstrous horror-project that is not worth the bragging rights ;) <fwereade_> oo, breakfast :) <TheMue> morning <wrtp> TheMue: hi! <TheMue> wrtp: Hi <TheMue> Hmm, the San Francisco photo walk would be nice, but we have our team dinner on Wednesday. <fwereade_> wrtp, TheMue: I'm trying to figure out what the best thing to do next is <fwereade_> wrtp, TheMue: it seems to me that it might have to be constraints <TheMue> fwereade_: Wouldn't conflict with me. I'm currently doing relations in topology. <fwereade_> wrtp, TheMue: because that's needed for bootstrap/PA parity <fwereade_> TheMue, ok, cool -- I guess we'll both be messing around in state for that at some stage but I can certainly start off without conflicts <fwereade_> wrtp, TheMue: *however* I suspect that conversations at UDS will affect precisely how we go ahead with it <TheMue> fwereade_: Yes, think so too. <fwereade_> wrtp, TheMue: so I'm open to, and sl. in favour of, other suggestions as well <wrtp> fwereade_: i wondering if constraints is quite close to what i'm on currently <wrtp> fwereade_: i'm thinking that agent stuff might be a better area <wrtp> fwereade_: because i'm soon to have go stuff running on the server side and we can't do anything without agents <wrtp> fwereade_: although i have to say i was probably going to move on to the provisioning agent next <fwereade_> wrtp, hmm, ok, the PA is definitely the first one we need <fwereade_> wrtp, do we have any upstart-conf-generating stuff yet? <wrtp> fwereade_: nope <fwereade_> wrtp, that should hopefully be quite self-contained then, I'll take a look at that <wrtp> fwereade_: is that done by the machine agent? <fwereade_> wrtp, it's done by and for several things -- MA will create them for UA, PA will I think create them for the MA and send them over in cloud-init <fwereade_> wrtp, bootstrap should do so for the PA (plus the MA) <fwereade_> wrtp, it's not strictly necessary in any of those cases, we did fine for a while just starting the processes <wrtp> fwereade_: interesting, i hadn't seen any of that (perhaps upstart stuff was added after i ported the basic provider cloudinit stuff?) <fwereade_> wrtp, but dropping them in shouldn't be too painful <fwereade_> wrtp, quite possible, it was "done" back in oct/nov but I'm not sure it actually went in until jan :/ <wrtp> fwereade_: so the purpose of using upstart is... to restart things when they fall over? <fwereade_> wrtp, yeah, and when the machine reboots, etc <wrtp> fwereade_: of course. do we reboot machines now? <fwereade_> wrtp, we should be able to, yeah, nobody's complained about it not working <mthaddon> hi there, I'm interesting in finding out where I would find the most up to date version of a particular charm - haproxy in this case - would that just be lp:~charmers/charms/precise/haproxy/trunk ? <fwereade_> haha, cute: "There are 16 methods of Regexp that match a regular expression and identify the matched text. Their names are matched by this regular expression: " <wrtp> fwereade_: :-) <fwereade_> wrtp, would you consider `func (s *Service) pid() int`, in which -1 signals an error, to be evil? (when none of the clients care what the error is, and (int, err) therefore ends up feeling somewhat redundant) <wrtp> fwereade_: i don't mind it, but it's possible gustavo might... <wrtp> fwereade_: i don't mind in-band errors when reasonable <wrtp> fwereade_: and that seems fine to me. <wrtp> fwereade_: strings.Index is another example <fwereade_> wrtp, cool, we'll see how it flies :) <fwereade_> wrtp, in-band is ok if it's out-of-domain, as it were <wrtp> not sure i get that... out-of-domain? <fwereade_> wrtp, hm, I should probably have said "range", been a long time since I did maths ;) <wrtp> fwereade_: ah, yeah. <wrtp> fwereade_: out of range and no other information added <TheMue> Ha! state has now 100 tests. Yeah. <wrtp> i *thought* the time was earlier than i expected... then i looked at a phone and found out that the clock at the top of my desktop has been stopped for 4 hours! * wrtp steels himself to factory-wipe his old phone <TheMue> wrtp: Hehe. You've got to show me on Monday. <wrtp> TheMue: new one is really quite nice <wrtp> TheMue: only real downer is i can't plug in extra SD card memory * TheMue waves, we'll see on Monday. Today Carmen and I have a dinner, tomorrow is our 23rd wedding day. <wrtp> TheMue: when do you arrive in Oakland? <TheMue> wrtp: Sunday at about 12:20. <TheMue> wrtp: Eh, that's SFO. I think it will be about 14:00 at the hotel. <wrtp> i wonder where those "chunk mismatch" errors come from <TheMue> wrtp: We should talk about our workflow. Perhaps you have a different order or other steps that you do. <wrtp> TheMue: i haven't managed to work out any common factors <wrtp> TheMue: i only get that error very occasionally <TheMue> wrtp: Strange, indeed. <wrtp> TheMue: and the diffs have uploaded fine <TheMue> wrtp: When will you arrive? Early enough for Marks talk? <wrtp> TheMue: saturday afternoon. <wrtp> TheMue: early enough to go to Jono's heavy metal gig :-) <TheMue> wrtp: Ah, hehe, have fun. And we'll meet at the talk. <wrtp> TheMue: deffo <TheMue> wrtp: I'm off now for a fine Steak. Yeah. <fwereade> need to be off for now; see you all in oakland :) <wrtp> fwereade: see you soon! <wrtp> right, i'm off. next stop UDS! look forward to seeing everyone again. #juju-dev 2012-05-05 <wrtp> fwereade: yo! #juju-dev 2012-05-07 <rogpeppe> jimbaker: ping <Leseb> hi everyone! <Aram> evening. <Aram> hi wrtp. <Aram> wrtp: yeah, no problem whatsoever circumventing that web-page login nonsense with mac spoofing. <Aram> I even used skype and I believe that's UDP. <Aram> Some systems are not mac based though, they do transparent HTTP proxying and inject a hidden iframe that checks for a cookie. <Aram> terrible systems, anyway. #juju-dev 2012-05-08 <Aram> evening :) <Aram> hi rogpeppe. <rogpeppe> Aram: yo! #juju-dev 2012-05-10 <hazmat> niemeyer, kapilt.com/files/topology.data <SpamapS> hazmat: I hear there's some kind of smack-off going on with 1000+ nodes <SpamapS> hazmat: still going on? <hazmat> SpamapS, yeah <hazmat> SpamapS, f*cking yaml <hazmat> ;-) <SpamapS> hazmat: eh? <SpamapS> hazmat: I thought the problem was watching the topology in zk <hazmat> SpamapS, it was yaml parsing that was problematic <SpamapS> oh! <hazmat> SpamapS, it was really slow with larger yaml docs <SpamapS> that makes perfect sense <SpamapS> what yaml do we have that is large? <hazmat> like 6s for 100k, takes like 0.01s with json <SpamapS> yeah yaml is not for big docs <hazmat> SpamapS, topology <SpamapS> so we keep a yaml.. of the whole topo ?! <hazmat> SpamapS, yup <SpamapS> *doh* <SpamapS> so its not so much that we're sending it to everybody.. its that yaml is complex to parse <SpamapS> hazmat: so are you guys trying a json based version? <hazmat> SpamapS, not yet, its done <hazmat> SpamapS, i will add it though <hazmat> SpamapS, we should talk tomorrow though about it <hazmat> its a hoser for existing envs <Aram> evening. <Aram> where's gustavo, I wonder? <fwereade> Aram, gustavo's heading off home today; not ure if he's actually *gone* but he's certainly going <Aram> thanks fwereade <Aram> hi rogpeppe <rogpeppe> Aram: yo! <Aram> rogpeppe: I might try to do a better os than os in Inferno today. <Aram> any tips? <Aram> I never actually written any limbo before :). <rogpeppe> Aram: "a better os than os" ? <Aram> the one that sets the current directory. <rogpeppe> Aram: still in the dark <rogpeppe> Aram: ah, you mean os(1) ? <Aram> yes. <rogpeppe> Aram: was it you i had the discussion with about reverse-mapping paths? <Aram> yes. <rogpeppe> Aram: and i didn't ever find that package, right? <Aram> right. <Aram> I wonder if there's a better way than trying to make sense of /prog/<pid>/ns <Aram> I'm not sure if parsing /prog/<pid>/ns is enough, in all cases... <rogpeppe> Aram: it definitely isn't <Aram> yeah... <Aram> so what do you suggest? <rogpeppe> Aram: but it's the best we can do <Aram> I see. <rogpeppe> Aram: -> #inferno <hazmat> m_3, ping <hazmat> m_3, seems to work for me <hazmat> m_3, the src wasn't up to date on the controler node <m_3> pong <m_3> hazmat: ok, I'll pull and try again <hazmat> m_3, sorry messed with your vim accidentally, i quit it to avoid any random changes <m_3> np <m_3> kicked it off, we'll dig through the prov agent once it's up <m_3> hazmat: sweeet! <hazmat> m_3, cool <m_3> hazmat: (that was supposed to be "Duuuude!") <m_3> we'll try again.... <hazmat> ;-) <m_3> hazmat: sweeeet! <hazmat> m_3, where you at? <m_3> in session... up in a few <m_3> damn, that's fast <hazmat> m_3, yeah? <m_3> *\o/* <hazmat> m_3, nice! <hazmat> m_3, clock it.. i'd like to know if we need to make it faster still <m_3> I'll buy the beer! <m_3> we're going up to 11! <m_3> it's clocked in the deploy.log (head it and tail it and compare) <m_3> (when done) <m_3> gotta detach... you in 205? <hazmat> m_3, yup #juju-dev 2012-05-14 <TheMue> morning <fwereade> heya TheMue <TheMue> Hi fwereade, had a good flight back? <fwereade> TheMue, not bad, thanks; and yourself? <TheMue> This time I've been able to sleep a lot a the flight back. That helped. Today it's almost normal, but I think I'll get tired early today. <TheMue> But those safety controls suck, had three this time. Will next time try to have a different flight with only one stop. <fwereade> TheMue, heh, I totally haven't adjusted, I started at 4am this morning ;p <TheMue> Uuuh, a bit early. <wrtp> fwereade, TheMue: morning! <wrtp> (just) * wrtp just slept for 14 hours straight. <TheMue> wrtp: Yo' man. <TheMue> wrtp: Hehe, fwereade started 4am this morning. <Aram> moin. <wrtp> Aram: hiya <wrtp> TheMue: i think he probably had *some* sleep the night before :-) <TheMue> wrtp: I slept a lot during flight and so slept from 11pm to 7am this morning. We'll see when I get tired again. <TheMue> Aram: Moin. <wrtp> TheMue: i didn't sleep at all in the flight. managed to do a little translator into a packet filter language, but didn't actually get it working quite. <TheMue> wrtp: I've yesterday not been able to concentrate on anything. <wrtp> TheMue: i came up with the neatest use for defer that i've yet found. <fwereade> heya wrtp <wrtp> fwereade: how's tricks? <fwereade> wrtp, not too bad, my body still thinks it's in the wrong place <wrtp> fwereade: not sure how my technique of almost no sleep for days beforehand and then lots of sleep now will work for body-clock adjustment. experiment still in progress! <Aram> wrtp: what use of defer did you find? <fwereade> wrtp, not really sleeping on the flight and going to bed slightly early really didn't work at all for me <wrtp> Aram: some code for generating virtual machine instructions. until you've generated the instructions, you don't know the destination for forward jumps. i use defer to do the late patching for me. here's some of the code (see the emit function) http://paste.ubuntu.com/986981/ <Aram> ah yes, this seems a really great use case. <wrtp> Aram: it won't work if i start generating jump instructions inside subroutines though. <Aram> heh, yes, still. <TheMue> lunchtime <wrtp> TheMue: you're running ubuntu in a VM, right? <wrtp> oh, darn, too late <wrtp> i discovered i could crash my machine with one echo statement <wrtp> echo /dev/*/tun* <wrtp> don't try it unless you don't care about an instant kernel panic <Aram> interesting. <TheMue> Hmm, strange, losing connection very often today. <niemeyer> Hello everybody! <niemeyer> Welcome back home to those that ramirezanna@example.org. :) <Aram> hi. <fwereade> niemeyer, heyhey <niemeyer> Hey folks <fwereade> niemeyer, how's it going? <niemeyer> fwereade: Wonderfully <fwereade> niemeyer, awesomd :D <niemeyer> fwereade: Good trip home, all worked out nicely, had a great rest, and glad to be back in action now too :) <fwereade> niemeyer, jolly good :) <fwereade> niemeyer, I'm a touch messed up on my sleep still so it'll be my EOD very soon <fwereade> niemeyer, I was going to take a quick look at the review queue first and gently remind you that I'm waiting for 4 of my own when yu get a moment ;) <niemeyer> fwereade: Thanks for the reminder <niemeyer> fwereade: My day is a bit messed up by pending stuff too, but I definitely have all those reviews close to the top of my list <fwereade> niemeyer, cool <fwereade> niemeyer, btw, I was wondering what your thoughts were on caching stuff in the local provider <niemeyer> fwereade: Hmm <niemeyer> fwereade: How do you mena? <niemeyer> mean <fwereade> niemeyer, I have the impression you're -1 on released binaries; does this imply the same for charm-store charms? <niemeyer> fwereade: Sorry, I'm a bit out of context <niemeyer> fwereade: What was I -1 about again? <fwereade> niemeyer, putting the jujud etc binaries into provider storage when they're the released versions that can be got from a canonical place <fwereade> niemeyer, this is secondhand, perhaps via wrtp; I may have misunderstood <niemeyer> fwereade: Ah, yeah, I think it was partially misunderstood in one of the hops <fwereade> niemeyer, my own heart says that we should stick everything in provider storage and always get it from the same place (with likely-to-be-lower bandwidth costs) <fwereade> niemeyer, the disadvantage is that if we do it naively we round-trip through the user's machine <niemeyer> fwereade: My original idea around that was to indeed allow uploading released binaries, but only when --upload-tools is used <wrtp> niemeyer: the question was whether we should always copy the juju tools binaries into local provider storage AFAIR <wrtp> niemeyer: hi BTW! <niemeyer> wrtp: Heya! <niemeyer> wrtp: Ah, yes, for that my vote is -1.. <wrtp> niemeyer: thought so <wrtp> niemeyer: so why aren't charms the same? <fwereade> niemeyer, ok, the followup: does that imply that charm-store charms should also not be copied into provider storage? <fwereade> niemeyer, we've always done it so far; but that may just be an artifact of not having had a charm store until very recently <niemeyer> fwereade: It's a great question <niemeyer> fwereade: and I suspect we may end up with similar answers for both <niemeyer> fwereade: which look unlike what we have right now in both cases <fwereade> niemeyer, yeah, it feels like fundamentally the same question <niemeyer> fwereade: The issues is this: <niemeyer> fwereade: Downloading several MB from S3 to stick back onto S3 sounds quite silly <niemeyer> fwereade: Even more considering we may have to download several different versions, depending on which constrains we're satisfying <niemeyer> fwereade: There's also the issue that the environment stands on itself <niemeyer> fwereade: We may not be around by the time the environment decides to fire a machine for which we didn't yet upload the respective binaries <niemeyer> fwereade: I think the ultimate goal would be to indeed cache binaries locally onto the environment, but have it so that the *environment* is able to do that by itself <niemeyer> fwereade: and this sounds like a sane approach both for the toolset and for the charms <niemeyer> fwereade: In edge cases, such as with --upload-tools, we'll continue to upload though <fwereade> niemeyer, cool, avoiding the round-trip sounds like a good thing to me <fwereade> niemeyer, the question becomes relevant because I'm looking at juju deploy and thinking I have no reason to download cs: charms at all <fwereade> niemeyer, because I can get the SHA256 and the bundle URL from the store anyway <niemeyer> fwereade: Right, that's indeed the original intention <niemeyer> fwereade: We didn't do that because it was cheap <niemeyer> fwereade: (to just continue to do the same) <fwereade> niemeyer, ok, great, I'll do what's definitely needed for cs: charms to begin with, and defer the caching for now <niemeyer> fwereade: Sounds good <niemeyer> mthaddon: ping <wrtp> niemeyer, fwereade, TheMue: i'm going to take the afternoon off as half swap day, if that's ok. <niemeyer> wrtp: Absolutely <fwereade> wrtp, fine by me <TheMue> wrtp: Understandable. <wrtp> thanks. i'll see y'all tomorrow! <niemeyer> wrtp: Have a good one <niemeyer> fwereade, TheMue: Please feel free to do the same and take some good rest today.. we need fresh brains! 8) <fwereade> niemeyer, I'm still confused what time it is; woke up fresh as a daisy at 3 and started at 4, so I consider my day kinda over already ;) <fwereade> niemeyer, I'm just picking up what easy reviews I can now <niemeyer> fwereade: Woah <niemeyer> fwereade: Indeed.. this has the sound of a great afternoon nap <fwereade> niemeyer, yeah, I'm feeling it a bit now <TheMue> niemeyer: I'm currently fixing a local mail prob. Afterwards I want at least to finish the tests after the latest refactorings William and I discussed last week. <TheMue> niemeyer: But I'll be offline from Wednesday to Sunday. <niemeyer> TheMue: Super <TheMue> niemeyer: The changes for relations and endpoints really feel better. More simple. * TheMue this morning discovered that there's a plugin for his editor to directly jump into Godoc/GoPkgDoc. <niemeyer> TheMue: Sweet <niemeyer> TheMue: I tend to use the web page.. I really like the formatting and all <TheMue> niemeyer: Yes, so do I. And this plugin tells Firefox to open a browser tab there. <Aram> I guess in acme one might come up with a plumbing rule that invokes either go doc or the browser. <Aram> might try it at some point. <niemeyer> TheMue: Yeah, I imagined this was the case since GoPkgDoc only works in a web browser <niemeyer> Aram: Indeed <TheMue> niemeyer: A nice HTML rendering in an editor tab would be fine too. But that doesn't work. <niemeyer> andrewsmedina: Heya <andrewsmedina> niemeyer: everything ok? <niemeyer> andrewsmedina: Yeah, all good <niemeyer> andrewsmedina: Back at home after two intense weeks <fsouza> hi <niemeyer> fsouza: Hey! Bye! <niemeyer> fsouza: Heya <niemeyer> Lunch time here <niemeyer> Back in ~1h <niemeyer> mthaddon: ping <niemeyer> Stepping out for a doc appointment.. back later * niemeyer respawns * davechen1y waves <niemeyer> davechen1y: Heya <niemeyer> davechen1y: Will pick Ale up.. back in a few minutes <davecheney> protip: bzr remove-branch doens't do what I it did <davecheney> afk: breakfast #juju-dev 2012-05-15 <niemeyer> davecheney: :-) <niemeyer> davecheney: Are you using cobzr? <niemeyer> davecheney: It may help <niemeyer> davecheney: It's really boring to use GOPATH without it <niemeyer> Alright, calling a day I am <niemeyer> Have a good night/day all <davecheney> niemeyer: yes, alias bzr=cobzr <davecheney> will cobzr close (ie, remove from my local branch list) branches that have been submitted ? <TheMue> morning * davecheney waves * TheMue waves back <davecheney> i heard tell there is a pastebin for canonical <davecheney> the public one <TheMue> davArrived in the right timezone? ;) <davecheney> yesterday was not pretty <TheMue> davecheney: Yes <davecheney> walked around like a zombie til 5pm <davecheney> then gave in to the inevitable <TheMue> http://paste.ubuntu.com/ <davecheney> TheMue: http://paste.ubuntu.com/988455/ <TheMue> davecheney: Funnily this time I had almost no problems. But I slept a lot during flight. <davecheney> what do you think of that? <davecheney> the logic is, watch /environment <davecheney> get the *ConfigNode, pass config.Map() to this function, receive Environ <TheMue> davecheney: Loks straight. <TheMue> Looks * davecheney shakes his fist at the interface{}'s being passed around everywhere <davecheney> well, mainly inside environs/config.go <TheMue> davecheney: Hehe, indeed, anonymous interfaces are always some kind
{'channel': 'juju-dev', 'month': 5}