[00:30] its done [00:30] niemeyer, hazmat https://codereview.appspot.com/5702055 [00:35] andrewsmedina: Woohay! [00:35] niemeyer: :) [00:36] andrewsmedina: You should have a review by the morning tomorrow [00:36] niemeyer: ok :D [00:37] niemeyer: I will continue to work on local provider (lxc) [00:47] andrewsmedina, nice [00:48] i thought that gofmt removed formatting concerns [00:48] besides subordinates i see alot of formatting/spacing diffs in there [01:07] hazmat: how I update a issue with other patch using lbox ? [01:08] andrewsmedina, just lbox propose -cr again.. it will update in place [01:09] hazmat: ok, I will fix the format [01:18] andrewsmedina: Just run "go fmt" [01:18] andrewsmedina: It will auto-format for you [01:20] niemeyer: I know :p [01:25] hazmat, niemeyer done :D https://codereview.appspot.com/5702055/ [01:26] andrewsmedina, thanks much nicer [01:31] andrewsmedina: How long have you been coding with Go? [01:34] niemeyer: since carnaval [01:34] niemeyer: why? [01:35] andrewsmedina: Just happy to see how fast you've produced a nice change set for integration [01:35] niemeyer: I contribute with several projects [01:36] andrewsmedina: From a quick look over it, looks very reasonable [01:36] niemeyer: Most projects that use python [01:37] niemeyer: I want do more for this project [01:38] andrewsmedina: From what I can see so far, you're very welcome to stay [01:38] andrewsmedina: make sure you're subscribed to the mailing list too, so that you can also participate in design decisions etc [01:52] Woohay.. just cut down the store tests timing by half.. was overlooking a silly setup/teardown cycle [01:57] niemeyer: If you have more small issues to let me know [01:57] andrewsmedina: Thanks, they'll certainly show up, and I'll make sure to ping you to see if you're interested [01:59] niemeyer: I'm waiting for you :D [01:59] niemeyer: Now, I will try install c client for zookeper on mac os ou centos [01:59] =/ [02:01] andrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of gozk from source [02:01] Sorry [02:01] andrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of *zookeeper* from source [02:01] andrewsmedina: It's not too painful.. [02:01] niemeyer: I'm not found the c client .tar.gz [02:02] andrewsmedina: It's the same source [02:02] andrewsmedina: The C client lives under src/c [02:02] andrewsmedina: ./configure && make [02:03] niemeyer: I know, I found this in svn repo, but not in tar.gz package [02:03] I will try again [02:04] niemeyer: you were right [02:05] andrewsmedina: You'll have to tweak the source of gozk so that the CFLAGS line in zk.go has something like -I/path/to/your/src/c/include [02:06] andrewsmedina: We should have a default entry like that pointing to /usr/local/include so that you could just make install it [02:06] andrewsmedina: Not there yet, though [02:08] niemeyer: your project lpad, it's broken with the last weekly version [02:08] niemeyer: because contains two packages [02:08] andrewsmedina: I've already fixed it, but it's lacking the tag I suppose [02:08] andrewsmedina: Let me tag it [02:09] andrewsmedina: Please try again [02:09] I have fixed this in my machine :p [02:09] removing the example.go [02:13] andrewsmedina: That works too :) [02:14] niemeyer: Can I change zk.go to point to /usr/local/include ? [02:14] andrewsmedina: Yeah, we can certainly add that in the stock package [02:14] andrewsmedina: Just add it at the end, please [02:20] Okay.. I really ought to have some sleep now [02:21] Have a good night all [02:21] Or at least those that approach their bed time ; [02:21] ) [11:29] niemeyer, hazmat: will you be free for a chat about constraints in ~90 minutes? (I need to collect Laura and eat lunch pretty soon) [11:30] fwereade: I will, but I believe hazmat must be asleep by now [11:30] fwereade: Morning, btw [11:30] niemeyer, heyhey :) [11:30] niemeyer, ah, ok, he was up late? I often seem to see him come on at about this time [11:31] fwereade: Ah, maybe he's changed his working hours [11:31] fwereade: I was assuming that just based on his TZ [11:32] niemeyer, I couldn't swear that's been normal recently, though, it's more a general impression that I developed at some stage === Leseb_ is now known as Leseb [11:45] fwereade: so... i did a test implementation of the relation-get thing the way i suggested, and it seemed over complex [11:45] rog, yeah, I peered through the docs a little and wasn't sure it'd save me much [11:45] fwereade: but... [11:45] fwereade: i thought this was better: http://paste.ubuntu.com/861798/ [11:45] fwereade: i think the streaming stuff is overkill [11:46] fwereade: for the primitives we're implementing, i don't think there's any need to see output as it's produced. [11:47] fwereade: the client side would look like this: http://paste.ubuntu.com/861802/ [11:48] rog, I'll think about that, but I have to run to collect laura -- sorry [11:49] fwereade_: np === Leseb_ is now known as Leseb [12:50] lunch [13:30] morning [13:50] niemeyer: https://codereview.appspot.com/5702055/ [14:24] fwereade_: any thoughts about that suggestion? [14:25] rog, well, it'd surely work, but it still feels more correct to stream the output back, and I don't really think the setup is that onerous [14:27] fwereade_: won't this always be used in a scripting situation where it won't make any difference? [14:28] fwereade_: apart from anything else it means that we can rely on a well tested RPC framework rather than rolling our own [14:29] rog, well, it seems that it won;t make any difference only if we guarantee that output never grows too irritatingly large to prefer streaming over copying [14:29] rog, I think the protocol is independent of the streaming question [14:30] rog, we can still stream stuff back with rpc [14:30] fwereade_: yeah, but it's a fair amount of complexity. i'm questioning whether that complexity is worth it for some log messages. [14:30] fwereade_: the streaming is what makes things more complex, AFAICS [14:31] rog, well,and the important output too [14:31] fwereade_: but the output is relatively small, right? [14:31] fwereade_: no more than 1MB, say [14:31] rog, indeed, probably not [14:31] fwereade_: (do people put enormous things in relations?) [14:32] rog, and, indeed, the stderr output will probably not be ruinously big either [14:32] fwereade_: i guess i'm just suggesting an "as simple as possible" approach. the client API looked identical for the streaming RPC version i did [14:32] rog, mainly it just feels like packing complete output streams into strings is the Wrong Thing To Do [14:33] rog, and I strongly favour implementing all our commands as Commands [14:34] fwereade_: it's trivial to make it so there's a single entry that invokes the correct command if that's what we want [14:34] fwereade_: (actually i had that before, but thought it might be better with several entry points) [14:35] rog, ok, I think we agree here, there's no sense hand-rolling the protocol [14:35] fwereade_: even with multiple entry points, i don't think there's a reason we couldn't use Command [14:36] rog, out point of disagreement seems to be whether stdout and stderr socket paths should be passed as part of the remote procedure call [14:36] our point^^ [14:36] fwereade_: yeah. [14:36] fwereade_: i think that we should just go the ultra-simple route until we encounter a command that actually produces lots of output [14:36] YAGNI... [14:37] rog, most of my arguments come back to my feeling that it's truer to the nature of a stream to let it be a stream; and that I'm not convinced that it's an unreasonable burden for the codeto bear [14:38] fwereade_: if in doubt i'd delete 120 lines of code... [14:41] fwereade_: i know what you mean about streams wanting to be streams, but i don't think it's worth it here. [14:41] rog, I'm not sure exactly where you're getting that number... we can certainly lose the protocol, this much is agreed [14:42] rog, that it feels inelegant and lumpen to convert a stream to a []byte to send it to another process so it can output it again as a stream [14:43] fwereade_: i don't mind so much. it takes 0 lines of code to do that. [14:43] fwereade_: and it's not going to make any practical difference [14:43] fwereade_: i can't think of a way that the difference is going to be observable. [14:44] rog, hm;someone running them with --debug would like to see output more-or-less as it happens, maybe? [14:45] fwereade_: BTW for reference, here's the server implementation using streaming with RPC: http://paste.ubuntu.com/861987/ [14:46] fwereade_: is it possible to run them at an interactive shell prompt? [14:46] fwereade_: i thought they needed to be run within the context of a hook [14:47] rog, (1) I think hook-debug might enable something like that, but that may be FUD because Idon't recall using it [14:47] fwereade_: (... and the client: http://paste.ubuntu.com/861989/) [14:47] (2) I'm sure there has been talk of allowing the commands to actually work outside of the hook context, but I'm not sure where to look for it [14:48] rog, or, hmm, wait; was that just getting access to relation context in non-relation hooks? [14:48] rog, sorry, that one makes more sense [14:49] fwereade_: no, i think you were right: https://juju.ubuntu.com/docs/hook-debugging.html [14:49] rog, cool [14:50] fwereade_: i didn't know about that [14:50] fwereade_: but i still don't think it's sufficient justification [14:51] fwereade_: all the in-hook commands are going to be short lived [14:51] fwereade_: they essentially do a single zk transaction, right? [14:51] rog, I'll look through your code again, my cursory look suggested you were doing more than I was; is it that I missed significant functionality? [14:52] fwereade_: what would happen with your code if two things executed relation-get in parallel? [14:52] rog, probably, yes, in the working-correctly case [14:53] rog, nothing too much with a moderate amount of care taken in dealing with the different client contexts' caches [14:53] heh, most people using relation get will be doing x=$(relation-get) anyway... [14:53] fwereade_: it seemed to dial the same socket several times. i couldn't see how the different streams were separated. [14:54] fwereade_: (if there were concurrent calls) [14:54] i haven't looked too closely though. [14:54] rog, ah, yes, I would appear to be on crack :/ [14:54] * rog has another look [14:56] rog, fwereade_: That should be the end of the importer: https://codereview.appspot.com/5704056 [14:56] fwereade_: i did really like my stream-over-RPC code, BTW. the possibility has been in my head for ages. i'll save the code. but i think it's more complexity than we need. [14:56] niemeyer, cheers [14:56] Will just submit a command to run that in another CL [14:56] cool [14:57] niemeyer: i'll have a look [14:57] fwereade_: Then, at least as far as I recall, the HTTP API we need is trivial [14:57] Which means we _migth_ have it ready by tomorrow [14:57] jcastro: ^ [14:57] niemeyer, according to my fuzzy memories, that's right [14:57] niemeyer, awesome! [14:59] niemeyer: woo! [15:00] niemeyer: i'm not entirely happy about the trend towards multi-line error messages. i quite liked the approach taken by go/parser, where the error says "some error (and 27 more)" and the underlying error type provides a way to get all of them if desired. [15:01] jcastro: This doesn't mean it will be live tomorrow, by any means :) [15:01] jcastro: But you can start planning [15:02] rog: That means even the first error message may not be relevant [15:02] niemeyer: all the error messages are relevant, no? [15:02] rog: So we end up with "branch errors" as a message [15:02] rog: Not if you strip their content :-) [15:02] niemeyer: yeah this will be Good Enough [15:03] niemeyer: i'm suggesting keeping the first error message encountered (and indicating that there are more) [15:03] rog: and I'm saying the first error message may have multiple lines [15:03] rog: Because it comes from bzr [15:03] * rog isn't too happy about that either [15:04] niemeyer: messages are often written to log files, and it's useful that log file lines are consistently prefixed [15:04] rog: Heh [15:05] rog: The actual error is several orders of magnitude more interesting in a log file than its prefix [15:05] rog: If you're suggesting stripping the errors from the log file to keep it pretty, that's a big no-no [15:05] niemeyer: agreed. but prefixes are often used to extract relevant info. [15:06] rog: Please let's be realisitc [15:06] rog: We're not dropping the error message out of the log file.. I'm happy to have solutions, but that by itself is not one of them [15:07] niemeyer: it looks like all the errors are logged anyway [15:07] rog: So what you are suggesting is ... ? [15:08] niemeyer: i'm not exactly sure. i just don't like Error() returning a multi-line error :-) [15:09] sorry [15:36] rog: The only reasonable thing I can think of is to make BranchErrors string return a "one or more branches failed to be published" message from Error [15:38] niemeyer: as i said, i think the approach taken here (see ErrorList.Error) is a reasonable one: http://weekly.golang.org/src/pkg/go/scanner/errors.go [15:39] rog: That doesn't work in this case for the reason I explained [15:39] niemeyer: but it won't work if some of the errors are already multi-line. perhaps bzr errors could be joined into a single line or something. [15:39] rog: Heh [15:40] rog: Let's stay on the reasonable side.. joining 10 lines in 1 won't improve the situation at all [15:40] bzr errors are that big? [15:40] rog: Any command line tool can print an arbitrary amount of content in their standard error stream [15:41] niemeyer: and we're treating that as "the" error message. i'm not keen. (not that i see a better approach yet though) [15:42] rog: Yeah, repeating that you're not keen isn't helpful.. I provided a suggestion. Does that help? [15:42] rog: Do you have a better one? [15:43] niemeyer: try to work out the actual error line in the bzr output? (saving the rest for callers that want to see the whole thing) [15:44] niemeyer: perhaps just finding the first line beginning "bzr: ERROR: " would be sufficient [15:45] rog: We still have to fall back in case we don't find it, and we still have to log the whole error message [15:47] rog: I think I'll just stick a static error message in there for now. That solves your main concern, and doesn't really change the overall behavior in any way. [15:48] We can improve that later as we find the need to [15:48] rog: Sounds good? [15:48] niemeyer: yeah, it's better. [15:48] Cool [15:48] niemeyer: was just looking in the bzr source to see how errors are dealt with [15:49] rog: It doesn't matter, really.. whatever heuristics we put to find an error message is still heuristics, and needs to have a fallback [15:49] niemeyer: yeah, but the fallback for bzr could be easy - just use the first line regardless. [15:49] rog: It's human oriented text.. not a protocol, unfortunately [15:50] niemeyer: (or all the lines joined, or whatever) [15:50] niemeyer: but it's rare enough that it wouldn't matter, i think. [15:51] niemeyer: it seems to me that the first line has all the relevant info - the rest is just suggestions like "However, you can get around this by doing this" [15:51] rog: See above.. [15:52] rog: It's not clear what you're trying to achieve. [15:52] rog: We'll be logging the whole message to aid in solving problems.. [15:53] rog: What's the problem you're trying to solve? [15:54] niemeyer: sometimes verbosity can hide problems. to my mind, looking at the possible bzr errors, (http://paste.ubuntu.com/862070/) they look like Go errors. that's what the first line would give you. but i guess it's possible you can get several errors in a row. [15:55] rog: There are several errors in there that have \n in them.. what are you trying to show me? [15:56] niemeyer: hmm. yeah, there are some problems. [15:56] _fmt = "%(target)s\n" \ [15:56] "is not compatible with\n" \ [15:56] bah humbug [15:56] oh well [15:57] I'll have some quick lunch.. back in a bit [15:57] just strip out \n... [15:57] niemeyer: ok [15:57] niemeyer: enjoy [15:57] rog: Stripping out \n == huge message == what is rog trying to do? [15:57] * niemeyer steps out for real [16:10] niemeyer: yeah, it's a difficult call. but on balance i think i'd prefer an error message that conformed to the usual one-line convention, even if the one line was very long, to one that didn't. [16:34] do we log this channel? [16:34] jcastro, i thought we had that setup.. but i don't see the logger/mup around [16:42] hazmat: if we don't, we should... [16:43] i don't really have any insight into getting _mup_ on here.. niemeyer ? [16:44] hazmat: we did, it must have gone missing, I'll check [17:15] rog: I'd rather have something that is readable instead. Let's keep it as-is until we find a better scheme. [17:15] niemeyer: fair enough. [18:00] bother it's 7, bbl if I can [18:36] The world is falling! [18:36] I mean.. it's raining.. [18:43] The volume of water falling here is amazing.. [18:46] niemeyer, sounds like the snowstorms we sometimes get here. best appreciated when it comes suddenly during a 22 deg C day in the spring, while wearing shorts [18:47] i like rainstorms [18:47] i'm off for the night, BTW. i smell spag boll! [18:47] see ya tomorrow [18:47] rog: Cheers! Enjoy! [19:42] why Go port dont have providers module? [19:57] andrewsmedina: It's called environs === niemeyer_ is now known as niemeyer [19:57] andrewsmedina: After some back and forth we ended up renaming it [19:57] andrewsmedina: Well.. consolidating might be a better way to put it [19:57] andrewsmedina: Python has both environments and providers [19:57] andrewsmedina: Go has only environments [19:58] niemeyer: hmm [19:59] niemeyer: I updated gozk to use the last gocheck version [20:00] andrewsmedina: Ah, nice.. do you want to propose it? [20:01] niemeyer: I'm at work now [20:01] andrewsmedina: Ah, super [20:02] niemeyer: tonight I propose [20:02] andrewsmedina: Super [20:02] andrewsmedina: What's you daily project, btw? [20:02] niemeyer: I work at globo.com [20:03] andrewsmedina: Ah, right.. what project there? [20:03] andrewsmedina: (if that's public info) [20:03] niemeyer: now, I'm in working in a private PaaS using Openstack + juju + cloudfoundry [20:03] andrewsmedina: Hah, nice.. I heard about those. ;-) [20:03] niemeyer: I work with flaviamissi [20:04] :) [20:06] flaviamissi: Buenas :) [20:06] niemeyer: I met you at pyconbrasil 2007 in joenvile [20:07] niemeyer: hi! [20:08] andrewsmedina: Wow.. really? My memory sucks.. [20:08] niemeyer: I'm a django guy [20:09] I miss Dorneles.. [20:09] niemeyer: me too =/ [20:09] niemeyer: In 2007 I was a only brazilian django guy at pycon [20:09] andrewsmedina: y u no work?! [20:10] andrewsmedina: HAEUheauhEAhAEAE [20:10] flaviamissi: Let me know if you need anything.. happy to see you guys using juju there [20:10] flaviamissi: oO [20:11] niemeyer: sure! you'll hear a lot from us, or read... whatever [21:07] hmm.. adding the alias expansion to the scheduler is harder than i thought, it really wants to reduce redundant events.. and the expansion is redundant. [21:08] hazmat: It's the machine raising against us! [21:21] Time for some outsiding.. back later [21:43] niemeyer, i'm thinking its time to revisit the notion that hook errors on relation events, drop the event. i'm starting to think we should keep/replay the event post resolved [21:43] it doesn't feel quite sane otherwise [21:54] sigh.. feels like there are a couple of bugs here [23:38] jimbaker, what's the rationale for juju do [23:39] on its face it seems highly suspect to me [23:39] hazmat, i do have some use cases in the proposal that are derived from it [23:39] hazmat, i certainly would entertain any suggestions for alternatives that enable out-of-band hook exec [23:40] jimbaker, your confusing the client with hooks calling other hooks [23:40] ie. the bugs wasn't about the user invoking arbitrary hooks [23:40] hazmat, i address that in a separate section [23:40] k [23:41] it is certainly ok with me if we don't implement. to quote, i'm not absolutely sure of anything... [23:41] except perhaps the well-ordered principle ;) [23:48] yeah.. its not on the table.. imo.. its insane.. but i haven't finished reading.. so i'll defer discussion till then [23:53] hazmat, please certainly put that feedback in the email [23:53] then we can definitively capture that it's a bad idea [23:53] i'm just reviewing in reitveld [23:54] hazmat, sure, that's a good place to review, but the high-level feedback needs to be on the mailing list [23:54] otherwise juju stakeholders are unlikely to see it [23:55] i think you've lost most of the relevant stake holders.. outside of the first paragraph [23:55] the rest is effectively spec merge review [23:57] hazmat, ok, i'm just trying to follow the process in https://lists.ubuntu.com/archives/juju/2011-November/000931.html [23:58] jimbaker, fair enough [23:58] jimbaker, and thanks for doing so [23:58] hazmat, no [23:58] problem