| === flaviamissi_ is now known as flaviamissi | ||
| rog | TheMue, fwereade: mornin' | 07:44 |
|---|---|---|
| fwereade | rog, TheMue, heyhey | 07:45 |
| TheMue | moin rog and fwereade | 08:01 |
| TheMue | fwereade: After my watcher moving proposal this morning I'm now testing the test refactoring we talked about. Looks fine. | 08:02 |
| fwereade | TheMue, cool | 08:17 |
| TheMue | fwereade: So, done for the "real" watchers. Now for the watcher package and it's done. | 08:19 |
| dpkingma | Hello everyone!! I'm looking for a Juju Charm for MongoDB v2.0+ | 09:47 |
| rog | fwereade: review delivered on the RPC CL | 10:30 |
| dpkingma | NM. has been answered! | 10:41 |
| rog | fwereade: review delivered on client RPC CL | 10:58 |
| fwereade | rog, tyvm | 10:58 |
| rog | fwereade: have you looked at the comments on the server CL? | 10:59 |
| fwereade | rog, just starting too, need to digest them a little | 10:59 |
| rog | fwereade: cool | 10:59 |
| rog | fwereade: i think that losing the SuperCommand will be a useful simplification | 11:00 |
| fwereade | rog, indeed, that's the bit I need to digest, because it doesn't fit my personal conception of the problem at all -- my current thinking is that SC already does exactly and precisely the job we need -- but you may well have a point :) | 11:02 |
| rog | fwereade: consider that we will never get flags *before* the command name. and we already know what command to execute. so we aren't using any of SC's functionality. | 11:03 |
| fwereade | rog, SC doesn't have that functionality | 11:12 |
| fwereade | rog, the recent split is all about separating the log stuff from the command selection stuff | 11:12 |
| fwereade | rog, (er, ok, it does, we moved the Log back in -- but the intent was absolutely that it be optional) | 11:12 |
| rog | fwereade: AFAICS SC is all about intermingling the flags from before the command and after the command, and selecting the command. | 11:13 |
| rog | fwereade: but we don't care about either of those things here | 11:13 |
| fwereade | rog, well, we do care about selecting the command, and the convenient representation of the data is in fact the representation that happens to be perfectly convenient already | 11:14 |
| fwereade | rog, you're just proposing a different way of selecting a command | 11:14 |
| rog | fwereade: that's true. one that's considerably simpler :-) | 11:15 |
| fwereade | rog, my vague idea was that a context should be able to just produce a list of commands it implements, and that the selection business could be taken care of by something that already does that | 11:15 |
| rog | IMO | 11:15 |
| rog | fwereade: but if a context can simply return a command for a given name, isn't that just as easy to do? | 11:16 |
| rog | fwereade: i don't see why we take the trouble to register all those commands with SC when we *already know* what command we're going to run! | 11:16 |
| dpkingma | Hi everyone! Question: is there any info on how to deploy stuff with juju on my own OpenStack cloud? Can't find any info online... | 11:21 |
| fwereade | dpkingma, very briefly: use the ec2 provider and set the ec2-uri, s3-uri, default-image-id and default-instance-type fields in its config | 11:22 |
| rog | pwd | 11:22 |
| dpkingma | fwereade: thanks I'll try that! | 11:24 |
| fwereade | rog, it seems to me that we know the name of the command we need to run but that actually executing it involves some extra work; and that it is surely convenient for a server.Context to know what commands it implements; but that it does not necessarily follow that we need to duplicate the command selection mechanism | 11:29 |
| rog | fwereade: the "command selection mechanism" is one map lookup. i don't see that it's any significant complexity. | 11:30 |
| rog | fwereade: but when i saw the SuperCommand logic, i had to think quite hard about what was actually going on. hence my suggestion. | 11:31 |
| fwereade | rog, and building the map in the first place; but I don't see how SC represents significant complexity either | 11:31 |
| rog | fwereade: it's a lot more complex than a simple map lookup | 11:32 |
| fwereade | rog, sorry -- it seemed perfectly natural to reuse the code that happened to solve precisely the problem we have here | 11:32 |
| rog | fwereade: i don't think it's solving the problem we've got here. i think you're modifying the problem so it looks like something that is good for SC :-) | 11:32 |
| rog | fwereade: try the code without using SC there. i *think* it will look a reasonable amount nicer. | 11:33 |
| fwereade | rog, it's building the map and extracting the command name and using it to select a command... and I agree that it's not complex, but it is work that's already been done | 11:33 |
| rog | fwereade: and if not, then let's use SC | 11:33 |
| fwereade | rog, SC takes a list which is a subcommand name followed by its args and does the needful | 11:34 |
| rog | fwereade: building the map is the same complexity as building the slice, which it has to do currently. the command name already has to be extracted by the juju client. | 11:34 |
| rog | fwereade: actually SC takes a list which is flags followed by subcommand name followed by flags followed by args... | 11:34 |
| fwereade | rog, (please do not assume my motivations -- I'm not *trying* to use SC, I merely observed that it precisely followed the problem) | 11:35 |
| fwereade | rog, only if you set the Log field | 11:35 |
| rog | fwereade: sorry, i wasn't trying to assume your motivations. i'm going from my initial gut reaction when i saw the code, which hasn't gone away on closer inspection. i think this would be simpler without SC here. | 11:37 |
| rog | fwereade: and easier to understand. | 11:38 |
| fwereade | rog, I think we need to figure out exactly what are differences are wrt the definition of simplicity :) | 11:39 |
| rog | fwereade: actually SuperCommand always takes flags followed by subcommand name - it always accepts --help for example. | 11:40 |
| rog | fwereade: lines of code is a good start | 11:40 |
| fwereade | rog, I see it and I think "right, a small chunk of the problem uses a well-understood type to so work that that type is expressly designed to do, I can forget that aspect of the problem for now" | 11:40 |
| fwereade | rog, s/to so work/to do work/ | 11:41 |
| rog | fwereade: i see it and think "that entire cmd function does nothing useful" | 11:41 |
| fwereade | rog, well, it uses the pieces we have in play right now to do its job | 11:41 |
| rog | fwereade: we already have the pieces IMHO - the built in map type and possibly the existing *Log type are all that's needed. | 11:42 |
| fwereade | rog, we definitely don't want a Log there | 11:42 |
| rog | fwereade: that's fine, we don't need to use it | 11:42 |
| rog | fwereade: even better! | 11:42 |
| rog | fwereade: so instead of building a slice of Commands and leaving it up to something else to do the selection, we can use a map of commands and an index expression... | 11:43 |
| rog | fwereade: which also means that potentially we could return a more useful error message when someone tries to execute a command in the wrong context | 11:44 |
| fwereade | rog, isn't "here's a nicely-formatted list of the appropriate commands for this context" useful error-message-wise? | 11:45 |
| rog | fwereade: not as useful as "you can't execute this command in this context for this reason" | 11:45 |
| rog | fwereade: supercommand will just say "command not found" or whatever | 11:45 |
| rog | hmm | 11:46 |
| fwereade | rog, and list the ones it can, which is IMO useful | 11:46 |
| rog | fwereade: i'm not sure. to the user, they all look like separate commands. seeing "usage: (->jujuc) ..." and a list of other commands isn't great. | 11:51 |
| rog | fwereade: in particular the (->jujuc) thing | 11:51 |
| fwereade | rog, heh, I felt that was useful information | 11:52 |
| rog | fwereade: it's feels more like an implementation detail to me | 11:52 |
| rog | s/it's/it/ | 11:52 |
| fwereade | rog, conceptually perhaps, but not one we can really hide from someone who takes the trouble to look | 11:53 |
| rog | fwereade: sure. but we don't want to flaunt it to everyone that happens to mistype a command name... | 11:53 |
| fwereade | rog, that'll just give them command not found | 11:54 |
| fwereade | rog, it's only if they're hitting something symlinked to jujuc in the first place | 11:54 |
| rog | fwereade: ok, to anyone that uses a command in the wrong context then .... | 11:55 |
| fwereade | rog, this is moot anyway, AIUI the long-term plan is that they should all always be available anyway | 11:55 |
| fwereade | rog, (but the wrong-context thing is IMO exactly when it'll be useful to see the commands that are valid in the current context) | 11:55 |
| rog | fwereade: there's nothing stopping us showing them anyway. | 11:56 |
| rog | fwereade: if we decide that's what we want. but an error message better than "unrecognised command" would be good. | 11:57 |
| fwereade | rog, that feels like still more reimplementation of existing functionality... | 11:57 |
| rog | fwereade: sure. i don't think it's really necessary. getting the right error message is more important. we *did* recognise the command, we just didn't act on it. | 11:58 |
| fwereade | rog, well, probably, anyway... no doubt someone will try to call jujuc directly sometime ;) | 11:59 |
| rog | fwereade: that's fine - we will get "unrecognised command" in that case :-) | 12:00 |
| fwereade | rog, ok, I'll give it a go | 12:01 |
| rog | fwereade: thanks for bearing with me :-) | 12:01 |
| fwereade | rog, please understand that it's frustrating to work on something for a week with the clear intent that it will be used imminently, and to then have it dropped on the floor | 12:02 |
| fwereade | rog, this essentially means that all the discussion and argument about how to extract Log from SuperCommand was pure academic wankery :( | 12:03 |
| rog | fwereade: yes, i do understand that very well, and please believe me when i say that i wouldn't suggest it unless i thought it would be a significant improvement | 12:04 |
| rog | fwereade: oh i see. | 12:04 |
| fwereade | rog, this turn of events is maybe also evidence that we flat-out suck at predicting the future ;) | 12:05 |
| fwereade | rog, don't get me wrong, SC turned out really nice, but... | 12:05 |
| rog | fwereade: well, that is always true in s/w development at least. anything else, i can predict 3 days in advance perfectly. | 12:05 |
| fwereade | rog, sure; but your simplicity argument does again hinge on future usage | 12:06 |
| rog | fwereade: i'm really happy with the way SC turned out too. it means we can add extra flags easily too if we want, in a nicely organised way | 12:06 |
| fwereade | rog, suggestion: | 12:06 |
| fwereade | rog, I follow your advice but for different reasons | 12:07 |
| rog | fwereade: i'm not sure. my simplicity argument is based on looking at the code as is | 12:07 |
| rog | fwereade: and seeing that it could be made simpler | 12:07 |
| fwereade | rog, that by implementing it as GetCmd(contextId, name) (string, error) I can thereby punt on the question of selection mechanism until we have an actual supplier of commands implemented | 12:08 |
| rog | fwereade: that's true too | 12:08 |
| fwereade | rog, you get simpler code to review and we defer any argument about the right way to do something until we're actualy doing it ;p | 12:08 |
| rog | fwereade: i wasn't sure whether you'd already got some code that implemented GetCmds already lurking somewhere though | 12:09 |
| fwereade | rog, no -- it's the simplest thing I could predict it would be easy to get from a Context :) | 12:09 |
| rog | fwereade: well, i'm glad about that at least - no downstream branches to mangle | 12:10 |
| rog | TheMue: ping | 12:22 |
| TheMue | rog: pong | 12:22 |
| rog | TheMue: i got a test failure on TestUnitWatchPorts | 12:22 |
| rog | TheMue: i've worked out the issue, and i think i have a slightly better way of working that test | 12:22 |
| rog | TheMue: how about this? http://paste.ubuntu.com/949642/ | 12:23 |
| rog | TheMue: this issue was a timeout BTW | 12:23 |
| rog | TheMue: the receiver of the changes wasn't waiting long enough for the generator | 12:23 |
| TheMue | rog: The tests are currently refactored to a more serialized way. But that will come in after the moving has a LGTM by Gustavo. | 12:24 |
| rog | TheMue: this change makes them both run in lock step (so it should be faster) and also uses the same table for both | 12:24 |
| rog | TheMue: ok, so you've got a similar change in the offing? | 12:24 |
| TheMue | rog: Yep | 12:24 |
| TheMue | rog: Wait, I paste one example. | 12:25 |
| rog | TheMue: cool. i'll ignore the test failures for the moment then. | 12:25 |
| TheMue | rog: http://paste.ubuntu.com/949648/ | 12:27 |
| rog | TheMue: that's cool. no need for the extra goroutine, of course, which i hadn't realised. nice. | 12:29 |
| TheMue | rog: I followed an idea of William. | 12:29 |
| rog | TheMue: 't'was a good idea | 12:29 |
| TheMue | rog: Indeed. | 12:29 |
| TheMue | fwereade: ping | 12:38 |
| fwereade | TheMue, pong | 12:38 |
| TheMue | fwereade: Just seen that you've got no roomie, like me. Shall I notify Marianna? | 12:39 |
| fwereade | TheMue, sure :) | 12:39 |
| TheMue | fwereade: OK, will do. | 12:39 |
| fwereade | TheMue, I'm reasonablycivilised most of the time ;) | 12:39 |
| TheMue | fwereade: I'll try my best to do so too. *lol* | 12:40 |
| rog | TheMue: where do you find out your roomie? | 12:40 |
| TheMue | rog: I went to the wiki and there "latest changes". | 12:44 |
| TheMue | rog: There's a "PeopleDetail" page. | 12:45 |
| rog | TheMue: got it | 12:45 |
| TheMue | fwereade: Mail is sent. | 12:47 |
| fwereade | rog, new cut at https://codereview.appspot.com/6120054/ | 12:47 |
| fwereade | rog, actually hold off, I can simplify further | 12:47 |
| rog | fwereade: yeah, jujucDoc and jujucPurpose can go, at least | 12:48 |
| fwereade | rog, that was precisely what I realised :) | 12:48 |
| rog | fwereade: LGTM | 12:52 |
| fwereade | rog, cool, thanks | 12:52 |
| rog | fwereade: i hope it feels ok | 12:53 |
| fwereade | rog, ii's good, thank you :) | 12:53 |
| fwereade | rog, btw, I've really come to appreciate lbox propose publishing all my drafts, really nice idea | 12:57 |
| rog | fwereade: i like that too. and the fact that i have to have a clean branch when proposing | 12:57 |
| fwereade | rog, yeah, that's saved me a lot of embarrassment :) | 12:58 |
| rog | fwereade: i wish cobzr switch would do that check too actually | 12:58 |
| fwereade | rog, I've actually given upon cobzr, it surprises me slightly more than bzr does and that makes me paranoid | 12:59 |
| rog | fwereade: i find it works pretty well actually. | 12:59 |
| rog | fwereade: it would be nice if there was a universal way of specifying a co-located branch, so i could diff against them | 13:00 |
| fwereade | rog, it's pretty clearly to do with a part of my brain that hasn't quite adapted to DVCSs in general | 13:00 |
| rog | fwereade: so how do you set your GOPATH? | 13:00 |
| fwereade | rog, so that's clearly soluble | 13:00 |
| fwereade | rog, but the easy diffing is too much to give up | 13:01 |
| fwereade | rog, sad to say, I'd rather just move directories ;) | 13:01 |
| rog | fwereade: i usually just push to launchpad and diff against there. slow but quick enough for my purposes | 13:01 |
| fwereade | rog, that would be fine if *something* I did didn't cause cobzr checkouts to occasionally forget their push branch :) | 13:02 |
| rog | fwereade: ah, i have seen that before, i think. but nothing that caused too many problems. | 13:03 |
| andrewsmedina | rog: thanks for the reviews :) | 13:27 |
| rog | andrewsmedina: np | 13:27 |
| === rog is now known as Guest17887 | ||
| === asavu_ is now known as asavu | ||
| niemeyer | Mornings! | 13:45 |
| fwereade | heya niemeyer | 13:46 |
| niemeyer | fwereade: Hey | 13:47 |
| niemeyer | fwereade: I suspect the diff in https://codereview.appspot.com/6116049/ got mixed up with review points that we've sorted elsewhere | 13:59 |
| niemeyer | fwereade: If that's the case, we can just get it in and let the other issues be sorted in whatever CL they are being debated | 14:02 |
| andrewsmedina | Guest17887: I will improve testing for LXC using the same line you used forthe ssh | 14:38 |
| === Guest17887 is now known as rogpeppe | ||
| rogpeppe | andrewsmedina: that sounds reasonable. | 14:39 |
| * niemeyer missing fwereade at the moment | 14:45 | |
| niemeyer | I don't understand why the checks in https://codereview.appspot.com/5845051/diff/17001/charm/charm_test.go are being removed.. | 14:45 |
| niemeyer | Ahh, I think I see.. it was moved to another test | 14:48 |
| niemeyer | Nice | 14:50 |
| TheMue | So, have to leave. | 15:12 |
| TheMue | niemeyer: Watcher moving is in at https://codereview.appspot.com/6131045/, could you please review? Thx. | 15:13 |
| TheMue | niemeyer: Watcher test refactoring is also ready locally (but based on the moved watchers). So it could be reviewed immediatelly after submit of moved watchers. | 15:14 |
| niemeyer | TheMue: Will do | 15:18 |
| niemeyer | TheMue: Cheers | 15:18 |
| * niemeyer => lunch too | 15:18 | |
| rogpeppe | niemeyer: i'm seeing a store test failure: http://paste.ubuntu.com/950070/ | 15:53 |
| rogpeppe | niemeyer, fwereade: https://codereview.appspot.com/6128046/ | 15:57 |
| rogpeppe | fwereade: https://codereview.appspot.com/6128046/ | 16:01 |
| rogpeppe | fwereade_: https://codereview.appspot.com/6128046/ | 16:01 |
| fwereade_ | rogpeppe, cheers | 16:02 |
| rogpeppe | fwereade_: *slightly* concerned about the fact that my test will only work if the juju build succeeds, but we're never gonna break the build, right? | 16:04 |
| fwereade_ | rogpeppe, that sort of thing never happens at all ;p | 16:04 |
| fwereade_ | rogpeppe, but tbh it's not clear what you can do about it... | 16:04 |
| rogpeppe | fwereade_: yeah. i don't think it matters too much. | 16:04 |
| rogpeppe | fwereade_: fix the build, then the tests can start working again | 16:05 |
| niemeyer | rogpeppe: Hmm.. is it failing consistently or some times? | 16:15 |
| rogpeppe | niemeyer: just that once, but i haven't run all the tests since then. will try again. | 16:16 |
| niemeyer | rogpeppe: I will increase the timeout there | 16:16 |
| rogpeppe | niemeyer, fwereade_: i'm off slightly early today. very shortly in fact. | 16:18 |
| fwereade_ | rogpeppe, niemeyer: off in a few short minutes myself | 16:19 |
| * fwereade_ almost avoids saying something about friday, friday... | 16:19 | |
| niemeyer | rogpeppe, fwereade_: Cool, I'll see you guys on Monday, hopefully | 16:19 |
| niemeyer | I'll be working from us-east, so we'll have little-to-no overlap | 16:19 |
| rogpeppe | niemeyer: did you see my latest CL BTW? archiving of juju client now works. only the S3 and shell script stuff to do. | 16:21 |
| niemeyer | rogpeppe: Woohay! | 16:21 |
| rogpeppe | niemeyer: store tests passed that time BTW | 16:22 |
| niemeyer | rogpeppe: init is close | 16:22 |
| rogpeppe | niemeyer: ? | 16:22 |
| niemeyer | rogpeppe: Cool.. it's the timeout indeed | 16:22 |
| niemeyer | rogpeppe: zkinit on server side | 16:22 |
| rogpeppe | niemeyer: cool. i reckon that'll probably be done by the time i've finished the S3 upload code | 16:22 |
| rogpeppe | niemeyer: a good place to stop for the day i reckon. have a good weekend all. and niemeyer, have a good flight, hope your ears give you no trouble... | 16:23 |
| rogpeppe | fwereade_: cheerio | 16:24 |
| niemeyer | rogpeppe: zkinit itself is done or mostly done I think.. next after the upload stuff is tweaking user-data setup to pick the right commands and run them | 16:24 |
| niemeyer | rogpeppe: I'm so excited about this stuff, btw | 16:24 |
| fwereade_ | rogpeppe, happy weekend | 16:24 |
| rogpeppe | niemeyer: 'xactly. "the shell script stuff" | 16:24 |
| niemeyer | rogpeppe: Yeha | 16:24 |
| rogpeppe | niemeyer: me too. | 16:24 |
| niemeyer | rogpeppe: That mechanism will make development of the upcoming stuff such a breeze.. I can barely believe we'll be able to just say upgrade-juju --upload-tools and *test the new code* | 16:25 |
| rogpeppe | niemeyer: the go tool made it almost trivial... kudos to russ | 16:26 |
| niemeyer | rogpeppe: Hmm.. I don't think that's entirely related | 16:26 |
| niemeyer | rogpeppe: Kudos to all of them for having standalone binaries.. *that's* the huge facilitator | 16:26 |
| fwereade_ | gn all, take care | 16:28 |
| rogpeppe | niemeyer: yeah, but that i could do "GOBIN=$tmp go install launchpad.net/juju/go/cmd/..." and have all the binaries made for me and up to date is just lovely | 16:28 |
| niemeyer | rogpeppe: Ah, I didn't realize you were going in that direction | 16:29 |
| niemeyer | fwereade_: Night man | 16:29 |
| rogpeppe | niemeyer: hope it works ok for you. | 16:29 |
| niemeyer | rogpeppe: Thinking.. | 16:29 |
| niemeyer | rogpeppe: This is most awesome for dev, but it means you need the dev environment in place too.. | 16:30 |
| niemeyer | rogpeppe: The alternative I was thinking off was looking for the tools in $PATH | 16:30 |
| niemeyer | s/off/of | 16:30 |
| niemeyer | rogpeppe: This would work in all cases, as long as one has the tools in their path.. both in dev and in cases when juju is installed via debs | 16:31 |
| rogpeppe | niemeyer: i'd assumed non-devs would use public binaries | 16:31 |
| niemeyer | rogpeppe: Sure, that's an assumption we can make, but the question is why | 16:32 |
| niemeyer | rogpeppe: What are we trading off | 16:32 |
| rogpeppe | niemeyer: i can easily add logic to find binaries in $PATH to the current code. | 16:34 |
| rogpeppe | niemeyer: perhaps in the next CL? | 16:34 |
| niemeyer | rogpeppe: Yeah, we can even wait longer | 16:35 |
| niemeyer | rogpeppe: Until we have answers for that | 16:35 |
| niemeyer | rogpeppe: Your scheme sounds better for the situation we're currently in | 16:35 |
| * niemeyer goes for a few errands in preparation for the trip | 19:42 | |
| === flaviamissi_ is now known as flaviamissi | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!