andrewsmedinaits done00:30
andrewsmedinaniemeyer, hazmat https://codereview.appspot.com/570205500:30
niemeyerandrewsmedina: Woohay!00:35
andrewsmedinaniemeyer: :)00:35
niemeyerandrewsmedina: You should have a review by the morning tomorrow00:36
andrewsmedinaniemeyer: ok :D00:36
andrewsmedinaniemeyer: I will continue to work on local provider (lxc)00:37
hazmatandrewsmedina, nice00:47
hazmati thought that gofmt removed formatting concerns00:48
hazmatbesides subordinates i see alot of formatting/spacing diffs in there00:48
andrewsmedinahazmat: how I update a issue with other patch using lbox ?01:07
hazmatandrewsmedina, just lbox propose -cr  again.. it will update in place01:08
andrewsmedinahazmat: ok, I will fix the format01:09
niemeyerandrewsmedina: Just run "go fmt"01:18
niemeyerandrewsmedina: It will auto-format for you01:18
andrewsmedinaniemeyer: I know :p01:20
andrewsmedinahazmat, niemeyer done :D https://codereview.appspot.com/5702055/01:25
hazmatandrewsmedina, thanks much nicer01:26
niemeyerandrewsmedina: How long have you been coding with Go?01:31
andrewsmedinaniemeyer: since carnaval01:34
andrewsmedinaniemeyer: why?01:34
niemeyerandrewsmedina: Just happy to see how fast you've produced a nice change set for integration01:35
andrewsmedinaniemeyer: I contribute with several projects01:35
niemeyerandrewsmedina: From a quick look over it, looks very reasonable01:36
andrewsmedinaniemeyer: Most projects that use python01:36
andrewsmedinaniemeyer: I want do more for this project01:37
niemeyerandrewsmedina: From what I can see so far, you're very welcome to stay01:38
niemeyerandrewsmedina: make sure you're subscribed to the mailing list too, so that you can also participate in design decisions etc01:38
niemeyerWoohay.. just cut down the store tests timing by half.. was overlooking a silly setup/teardown cycle01:52
andrewsmedinaniemeyer: If you have more small issues to let me know01:57
niemeyerandrewsmedina: Thanks, they'll certainly show up, and I'll make sure to ping you to see if you're interested01:57
andrewsmedinaniemeyer: I'm waiting for you :D01:59
andrewsmedinaniemeyer: Now, I will try install c client for zookeper on mac os ou centos01:59
niemeyerandrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of gozk from source02:01
niemeyerandrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of *zookeeper* from source02:01
niemeyerandrewsmedina: It's not too painful..02:01
andrewsmedinaniemeyer: I'm not found the c client .tar.gz02:01
niemeyerandrewsmedina: It's the same source02:02
niemeyerandrewsmedina: The C client lives under src/c02:02
niemeyerandrewsmedina: ./configure && make02:02
andrewsmedinaniemeyer: I know, I found this in svn repo, but not in tar.gz package02:03
andrewsmedinaI will try again02:03
andrewsmedinaniemeyer: you were right02:04
niemeyerandrewsmedina: 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/include02:05
niemeyerandrewsmedina: We should have a default entry like that pointing to /usr/local/include so that you could just make install it02:06
niemeyerandrewsmedina: Not there yet, though02:06
andrewsmedinaniemeyer: your project lpad, it's broken with the last weekly version02:08
andrewsmedinaniemeyer: because contains two packages02:08
niemeyerandrewsmedina: I've already fixed it, but it's lacking the tag I suppose02:08
niemeyerandrewsmedina: Let me tag it02:08
niemeyerandrewsmedina: Please try again02:09
andrewsmedinaI have fixed this in my machine :p02:09
andrewsmedinaremoving the example.go02:09
niemeyerandrewsmedina: That works too :)02:13
andrewsmedinaniemeyer: Can I change zk.go to point to /usr/local/include ?02:14
niemeyerandrewsmedina: Yeah, we can certainly add that in the stock package02:14
niemeyerandrewsmedina: Just add it at the end, please02:14
niemeyerOkay.. I really ought to have some sleep now02:20
niemeyerHave a good night all02:21
niemeyerOr at least those that approach their bed time ;02:21
fwereadeniemeyer, hazmat: will you be free for a chat about constraints in ~90 minutes? (I need to collect Laura and eat lunch pretty soon)11:29
niemeyerfwereade: I will, but I believe hazmat must be asleep by now11:30
niemeyerfwereade: Morning, btw11:30
fwereadeniemeyer, heyhey :)11:30
fwereadeniemeyer, ah, ok, he was up late? I often seem to see him come on at about this time11:30
niemeyerfwereade: Ah, maybe he's changed his working hours11:31
niemeyerfwereade: I was assuming that just based on his TZ11:31
fwereadeniemeyer, I couldn't swear that's been normal recently, though, it's more a general impression that I developed at some stage11:32
=== Leseb_ is now known as Leseb
rogfwereade: so... i did a test implementation of the relation-get thing the way i suggested, and it seemed over complex11:45
fwereaderog, yeah, I peered through the docs a little and wasn't sure it'd save me much11:45
rogfwereade: but...11:45
rogfwereade: i thought this was better: http://paste.ubuntu.com/861798/11:45
rogfwereade: i think the streaming stuff is overkill11:45
rogfwereade: for the primitives we're implementing, i don't think there's any need to see output as it's produced.11:46
rogfwereade: the client side would look like this: http://paste.ubuntu.com/861802/11:47
fwereade_rog, I'll think about that, but I have to run to collect laura -- sorry11:48
rogfwereade_: np11:49
=== Leseb_ is now known as Leseb
andrewsmedinaniemeyer: https://codereview.appspot.com/5702055/13:50
rogfwereade_: any thoughts about that suggestion?14:24
fwereade_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 onerous14:25
rogfwereade_: won't this always be used in a scripting situation where it won't make any difference?14:27
rogfwereade_: apart from anything else it means that we can rely on a well tested RPC framework rather than rolling our own14:28
fwereade_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 copying14:29
fwereade_rog, I think the protocol is independent of the streaming question14:29
fwereade_rog, we can still stream stuff back with rpc14:30
rogfwereade_: yeah, but it's a fair amount of complexity. i'm questioning whether that complexity is worth it for some log messages.14:30
rogfwereade_: the streaming is what makes things more complex, AFAICS14:30
fwereade_rog, well,and the important output too14:31
rogfwereade_: but the output is relatively small, right?14:31
rogfwereade_: no more than 1MB, say14:31
fwereade_rog, indeed, probably not14:31
rogfwereade_: (do people put enormous things in relations?)14:31
fwereade_rog, and, indeed, the stderr output will probably not be ruinously big either14:32
rogfwereade_: i guess i'm just suggesting an "as simple as possible" approach. the client API looked identical for the streaming RPC version i did14:32
fwereade_rog, mainly it just feels like packing complete output streams into strings is the Wrong Thing To Do14:32
fwereade_rog, and I strongly favour implementing all our commands as Commands14:33
rogfwereade_: it's trivial to make it so there's a single entry that invokes the correct command if that's what we want14:34
rogfwereade_: (actually i had that before, but thought it might be better with several entry points)14:34
fwereade_rog, ok, I think we agree here, there's no sense hand-rolling the protocol14:35
rogfwereade_: even with multiple entry points, i don't think there's a reason we couldn't use Command14:35
fwereade_rog, out point of disagreement seems to be whether stdout and stderr socket paths should be passed as part of the remote procedure call14:36
fwereade_our point^^14:36
rogfwereade_: yeah.14:36
rogfwereade_: i think that we should just go the ultra-simple route until we encounter a command that actually produces lots of output14:36
fwereade_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 bear14:37
rogfwereade_: if in doubt i'd delete 120 lines of code...14:38
rogfwereade_: i know what you mean about streams wanting to be streams, but i don't think it's worth it here.14:41
fwereade_rog, I'm not sure exactly where you're getting that number... we can certainly lose the protocol, this much is agreed14:41
fwereade_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 stream14:42
rogfwereade_: i don't mind so much. it takes 0 lines of code to do that.14:43
rogfwereade_: and it's not going to make any practical difference14:43
rogfwereade_: i can't think of a way that the difference is going to be observable.14:43
fwereade_rog, hm;someone running them with --debug would like to see output more-or-less as it happens, maybe?14:44
rogfwereade_: BTW for reference, here's the server implementation using streaming with RPC: http://paste.ubuntu.com/861987/14:45
rogfwereade_: is it possible to run them at an interactive shell prompt?14:46
rogfwereade_: i thought they needed to be run within the context of a hook14:46
fwereade_rog, (1) I think hook-debug might enable something like that, but that may be FUD because Idon't recall using it14:47
rogfwereade_: (... and the client: http://paste.ubuntu.com/861989/)14:47
fwereade_(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 it14:47
fwereade_rog, or, hmm, wait; was that just getting access to relation context in non-relation hooks?14:48
fwereade_rog, sorry, that one makes more sense14:48
rogfwereade_: no, i think you were right: https://juju.ubuntu.com/docs/hook-debugging.html14:49
fwereade_rog, cool14:49
rogfwereade_: i didn't know about that14:50
rogfwereade_: but i still don't think it's sufficient justification14:50
rogfwereade_: all the in-hook commands are going to be short lived14:51
rogfwereade_: they essentially do a single zk transaction, right?14:51
fwereade_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:51
rogfwereade_: what would happen with your code if two things executed relation-get in parallel?14:52
fwereade_rog, probably, yes, in the working-correctly case14:52
fwereade_rog, nothing too much with a moderate amount of care taken in dealing with the different client contexts' caches14:53
rogheh, most people using relation get will be doing x=$(relation-get) anyway...14:53
rogfwereade_: it seemed to dial the same socket several times. i couldn't see how the different streams were separated.14:53
rogfwereade_: (if there were concurrent calls)14:54
rogi haven't looked too closely though.14:54
fwereade_rog, ah, yes, I would appear to be on crack :/14:54
* rog has another look14:54
niemeyerrog, fwereade_: That should be the end of the importer: https://codereview.appspot.com/570405614:56
rogfwereade_: 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
fwereade_niemeyer, cheers14:56
niemeyerWill just submit a command to run that in another CL14:56
rogniemeyer: i'll have a look14:57
niemeyerfwereade_: Then, at least as far as I recall, the HTTP API we need is trivial14:57
niemeyerWhich means we _migth_ have it ready by tomorrow14:57
niemeyerjcastro: ^14:57
fwereade_niemeyer, according to my fuzzy memories, that's right14:57
fwereade_niemeyer, awesome!14:57
jcastroniemeyer: woo!14:59
rogniemeyer: 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:00
niemeyerjcastro: This doesn't mean it will be live tomorrow, by any means :)15:01
niemeyerjcastro: But you can start planning15:01
niemeyerrog: That means even the first error message may not be relevant15:02
rogniemeyer: all the error messages are relevant, no?15:02
niemeyerrog: So we end up with "branch errors" as a message15:02
niemeyerrog: Not if you strip their content :-)15:02
jcastroniemeyer: yeah this will be Good Enough15:02
rogniemeyer: i'm suggesting keeping the first error message encountered (and indicating that there are more)15:03
niemeyerrog: and I'm saying the first error message may have multiple lines15:03
niemeyerrog: Because it comes from bzr15:03
* rog isn't too happy about that either15:03
rogniemeyer: messages are often written to log files, and it's useful that log file lines are consistently prefixed15:04
niemeyerrog: Heh15:04
niemeyerrog: The actual error is several orders of magnitude more interesting in a log file than its prefix15:05
niemeyerrog: If you're suggesting stripping the errors from the log file to keep it pretty, that's a big no-no15:05
rogniemeyer: agreed.  but prefixes are often used to extract relevant info.15:05
niemeyerrog: Please let's be realisitc15:06
niemeyerrog: 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 them15:06
rogniemeyer: it looks like all the errors are logged anyway15:07
niemeyerrog: So what you are suggesting is ... ?15:07
rogniemeyer: i'm not exactly sure. i just don't like Error() returning a multi-line error :-)15:08
niemeyerrog: 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 Error15:36
rogniemeyer: 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.go15:38
niemeyerrog: That doesn't work in this case for the reason I explained15:39
rogniemeyer: 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
niemeyerrog: Heh15:39
niemeyerrog: Let's stay on the reasonable side.. joining 10 lines in 1 won't improve the situation at all15:40
rogbzr errors are that big?15:40
niemeyerrog: Any command line tool can print an arbitrary amount of content in their standard error stream15:40
rogniemeyer: and we're treating that as "the" error message. i'm not keen. (not that i see a better approach yet though)15:41
niemeyerrog: Yeah, repeating that you're not keen isn't helpful.. I provided a suggestion. Does that help?15:42
niemeyerrog: Do you have a better one?15:42
rogniemeyer: 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:43
rogniemeyer: perhaps just finding the first line beginning "bzr: ERROR: " would be sufficient15:44
niemeyerrog: We still have to fall back in case we don't find it, and we still have to log the whole error message15:45
niemeyerrog: 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:47
niemeyerWe can improve that later as we find the need to15:48
niemeyerrog: Sounds good?15:48
rogniemeyer: yeah, it's better.15:48
rogniemeyer: was just looking in the bzr source to see how errors are dealt with15:48
niemeyerrog: It doesn't matter, really.. whatever heuristics we put to find an error message is still heuristics, and needs to have a fallback15:49
rogniemeyer: yeah, but the fallback for bzr could be easy - just use the first line regardless.15:49
niemeyerrog: It's human oriented text.. not a protocol, unfortunately15:49
rogniemeyer: (or all the lines joined, or whatever)15:50
rogniemeyer: but it's rare enough that it wouldn't matter, i think.15:50
rogniemeyer: 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
niemeyerrog: See above..15:51
niemeyerrog: It's not clear what you're trying to achieve.15:52
niemeyerrog: We'll be logging the whole message to aid in solving problems..15:52
niemeyerrog: What's the problem you're trying to solve?15:53
rogniemeyer: 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:54
niemeyerrog: There are several errors in there that have \n in them.. what are you trying to show me?15:55
rogniemeyer: hmm. yeah, there are some problems.15:56
rog    _fmt = "%(target)s\n" \15:56
rog            "is not compatible with\n" \15:56
rogbah humbug15:56
rogoh well15:56
niemeyerI'll have some quick lunch.. back in a bit15:57
rogjust strip out \n...15:57
rogniemeyer: ok15:57
rogniemeyer: enjoy15:57
niemeyerrog: Stripping out \n == huge message == what is rog trying to do?15:57
* niemeyer steps out for real15:57
rogniemeyer: 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:10
hazmatdo we log this channel?16:34
hazmatjcastro, i thought we had that setup.. but i don't see the logger/mup around16:34
roghazmat: if we don't, we should...16:42
hazmati don't really have any insight into getting _mup_ on here.. niemeyer ?16:43
jcastrohazmat: we did, it must have gone missing, I'll check16:44
niemeyerrog: I'd rather have something that is readable instead. Let's keep it as-is until we find a better scheme.17:15
rogniemeyer: fair enough.17:15
fwereade__bother it's 7, bbl if I can18:00
niemeyerThe world is falling!18:36
niemeyerI mean.. it's raining..18:36
niemeyerThe volume of water falling here is amazing..18:43
jimbakerniemeyer, 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 shorts18:46
rogi like rainstorms18:47
rogi'm off for the night, BTW. i smell spag boll!18:47
rogsee ya tomorrow18:47
niemeyerrog: Cheers! Enjoy!18:47
andrewsmedinawhy Go port dont have providers module?19:42
niemeyer_andrewsmedina: It's called environs19:57
=== niemeyer_ is now known as niemeyer
niemeyerandrewsmedina: After some back and forth we ended up renaming it19:57
niemeyerandrewsmedina: Well.. consolidating might be a better way to put it19:57
niemeyerandrewsmedina: Python has both environments and providers19:57
niemeyerandrewsmedina: Go has only environments19:57
andrewsmedinaniemeyer: hmm19:58
andrewsmedinaniemeyer: I updated gozk to use the last gocheck version19:59
niemeyerandrewsmedina: Ah, nice.. do you want to propose it?20:00
andrewsmedinaniemeyer: I'm at work now20:01
niemeyerandrewsmedina: Ah, super20:01
andrewsmedinaniemeyer: tonight I propose20:02
niemeyerandrewsmedina: Super20:02
niemeyerandrewsmedina: What's you daily project, btw?20:02
andrewsmedinaniemeyer: I work at globo.com20:02
niemeyerandrewsmedina: Ah, right.. what project there?20:03
niemeyerandrewsmedina: (if that's public info)20:03
andrewsmedinaniemeyer: now, I'm in working in a private PaaS using Openstack + juju + cloudfoundry20:03
niemeyerandrewsmedina: Hah, nice.. I heard about those. ;-)20:03
andrewsmedinaniemeyer: I work with flaviamissi20:03
niemeyerflaviamissi: Buenas :)20:06
andrewsmedinaniemeyer: I met you at pyconbrasil 2007 in joenvile20:06
flaviamissiniemeyer: hi!20:07
niemeyerandrewsmedina: Wow.. really? My memory sucks..20:08
andrewsmedinaniemeyer: I'm a django guy20:08
niemeyerI miss Dorneles..20:09
andrewsmedinaniemeyer: me too =/20:09
andrewsmedinaniemeyer: In 2007 I was a only brazilian django guy at pycon20:09
flaviamissiandrewsmedina: y u no work?!20:09
flaviamissiandrewsmedina: HAEUheauhEAhAEAE20:10
niemeyerflaviamissi: Let me know if you need anything.. happy to see you guys using juju there20:10
andrewsmedinaflaviamissi: oO20:10
flaviamissiniemeyer: sure! you'll hear a lot from us, or read... whatever20:11
hazmathmm.. 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:07
niemeyerhazmat: It's the machine raising against us!21:08
niemeyerTime for some outsiding.. back later21:21
hazmatniemeyer, 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 resolved21:43
hazmatit doesn't feel quite sane otherwise21:43
hazmatsigh.. feels like there are a couple of bugs here21:54
hazmatjimbaker, what's the rationale for juju do23:38
hazmaton its face it seems highly suspect to me23:39
jimbakerhazmat, i do have some use cases in the proposal that are derived from it23:39
jimbakerhazmat, i certainly would entertain any suggestions for alternatives that enable out-of-band hook exec23:39
hazmatjimbaker, your confusing the client with hooks calling other hooks23:40
hazmatie. the bugs wasn't about the user invoking arbitrary hooks23:40
jimbakerhazmat, i address that in a separate section23:40
jimbakerit is certainly ok with me if we don't implement. to quote, i'm not absolutely sure of anything...23:41
jimbakerexcept perhaps the well-ordered principle ;)23:41
hazmatyeah.. its not on the table.. imo.. its insane.. but i haven't finished reading.. so i'll defer discussion till then23:48
jimbakerhazmat, please certainly put that feedback in the email23:53
jimbakerthen we can definitively capture that it's a bad idea23:53
hazmati'm just reviewing in reitveld23:53
jimbakerhazmat, sure, that's a good place to review, but the high-level feedback needs to be on the mailing list23:54
jimbakerotherwise juju stakeholders are unlikely to see it23:54
hazmati think you've lost most of the relevant stake holders.. outside of the first paragraph23:55
hazmatthe rest is effectively spec merge review23:55
jimbakerhazmat, ok, i'm just trying to follow the process in https://lists.ubuntu.com/archives/juju/2011-November/000931.html23:57
hazmatjimbaker, fair enough23:58
hazmatjimbaker, and thanks for doing so23:58
jimbakerhazmat, no23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!