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