/srv/irclogs.ubuntu.com/2012/04/27/#juju-dev.txt

=== flaviamissi_ is now known as flaviamissi
rogTheMue, fwereade: mornin'07:44
fwereaderog, TheMue, heyhey07:45
TheMuemoin rog and fwereade08:01
TheMuefwereade: After my watcher moving proposal this morning I'm now testing the test refactoring we talked about. Looks fine.08:02
fwereadeTheMue, cool08:17
TheMuefwereade: So, done for the "real" watchers. Now for the watcher package and it's done.08:19
dpkingmaHello everyone!! I'm looking for a Juju Charm for MongoDB v2.0+09:47
rogfwereade: review delivered on the RPC CL10:30
dpkingmaNM. has been answered!10:41
rogfwereade: review delivered on client RPC CL10:58
fwereaderog, tyvm10:58
rogfwereade: have you looked at the comments on the server CL?10:59
fwereaderog, just starting too, need to digest them a little10:59
rogfwereade: cool10:59
rogfwereade: i think that losing the SuperCommand will be a useful simplification11:00
fwereaderog, 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
rogfwereade: 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
fwereaderog, SC doesn't have that functionality11:12
fwereaderog, the recent split is all about separating the log stuff from the command selection stuff11:12
fwereaderog, (er, ok, it does, we moved the Log back in -- but the intent was absolutely that it be optional)11:12
rogfwereade: AFAICS SC is all about intermingling the flags from before the command and after the command, and selecting the command.11:13
rogfwereade: but we don't care about either of those things here11:13
fwereaderog, 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 already11:14
fwereaderog, you're just proposing a different way of selecting a command11:14
rogfwereade: that's true. one that's considerably simpler :-)11:15
fwereaderog, 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 that11:15
rogIMO11:15
rogfwereade: but if a context can simply return a command for a given name, isn't that just as easy to do?11:16
rogfwereade: 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
dpkingmaHi 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
fwereadedpkingma, very briefly: use the ec2 provider and set the ec2-uri, s3-uri, default-image-id and default-instance-type fields in its config11:22
rogpwd11:22
dpkingmafwereade: thanks I'll try that!11:24
fwereaderog, 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 mechanism11:29
rogfwereade: the "command selection mechanism" is one map lookup. i don't see that it's any significant complexity.11:30
rogfwereade: but when i saw the SuperCommand logic, i had to think quite hard about what was actually going on. hence my suggestion.11:31
fwereaderog, and building the map in the first place; but I don't see how SC represents significant complexity either11:31
rogfwereade: it's a lot more complex than a simple map lookup11:32
fwereaderog, sorry -- it seemed perfectly natural to reuse the code that happened to solve precisely the problem we have here11:32
rogfwereade: 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
rogfwereade: try the code without using SC there. i *think* it will look a reasonable amount nicer.11:33
fwereaderog, 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 done11:33
rogfwereade: and if not, then let's use SC11:33
fwereaderog, SC takes a list which is a subcommand name followed by its args and does the needful11:34
rogfwereade: 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
rogfwereade: actually SC takes a list which is flags followed by subcommand name followed by flags followed by args...11:34
fwereaderog, (please do not assume my motivations -- I'm not *trying* to use SC, I merely observed that it precisely followed the problem)11:35
fwereaderog, only if you set the Log field11:35
rogfwereade: 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
rogfwereade: and easier to understand.11:38
fwereaderog, I think we need to figure out exactly what are differences are wrt the definition of simplicity :)11:39
rogfwereade: actually SuperCommand always takes flags followed by subcommand name - it always accepts --help for example.11:40
rogfwereade: lines of code is a good start11:40
fwereaderog, 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
fwereaderog, s/to so work/to do work/11:41
rogfwereade: i see it and think "that entire cmd function does nothing useful"11:41
fwereaderog, well, it uses the pieces we have in play right now to do its job11:41
rogfwereade: we already have the pieces IMHO - the built in map type and possibly the existing *Log type are all that's needed.11:42
fwereaderog, we definitely don't want a Log there11:42
rogfwereade: that's fine, we don't need to use it11:42
rogfwereade: even better!11:42
rogfwereade: 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
rogfwereade: which also means that potentially we could return a more useful error message when someone tries to execute a command in the wrong context11:44
fwereaderog, isn't "here's a nicely-formatted list of the appropriate commands for this context" useful error-message-wise?11:45
rogfwereade: not as useful as "you can't execute this command in this context for this reason"11:45
rogfwereade: supercommand will just say "command not found" or whatever11:45
roghmm11:46
fwereaderog, and list the ones it can, which is IMO useful11:46
rogfwereade: 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
rogfwereade: in particular the (->jujuc) thing11:51
fwereaderog, heh, I felt that was useful information11:52
rogfwereade: it's feels more like an implementation detail to me11:52
rogs/it's/it/11:52
fwereaderog, conceptually perhaps, but not one we can really hide from someone who takes the trouble to look11:53
rogfwereade: sure. but we don't want to flaunt it to everyone that happens to mistype a command name...11:53
fwereaderog, that'll just give them command not found11:54
fwereaderog, it's only if they're hitting something symlinked to jujuc in the first place11:54
rogfwereade: ok, to anyone that uses a command in the wrong context then ....11:55
fwereaderog, this is moot anyway, AIUI the long-term plan is that they should all always be available anyway11:55
fwereaderog, (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
rogfwereade: there's nothing stopping us showing them anyway.11:56
rogfwereade: if we decide that's what we want. but an error message better than "unrecognised command" would be good.11:57
fwereaderog, that feels like still more reimplementation of existing functionality...11:57
rogfwereade: 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
fwereaderog, well, probably, anyway... no doubt someone will try to call jujuc directly sometime ;)11:59
rogfwereade: that's fine - we will get "unrecognised command" in that case :-)12:00
fwereaderog, ok, I'll give it a go12:01
rogfwereade: thanks for bearing with me :-)12:01
fwereaderog, 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 floor12:02
fwereaderog, this essentially means that all the discussion and argument about how to extract Log from SuperCommand was pure academic wankery :(12:03
rogfwereade: 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 improvement12:04
rogfwereade: oh i see.12:04
fwereaderog, this turn of events is maybe also evidence that we flat-out suck at predicting the future ;)12:05
fwereaderog, don't get me wrong, SC turned out really nice, but...12:05
rogfwereade: well, that is always true in s/w development at least. anything else, i can predict 3 days in advance perfectly.12:05
fwereaderog, sure; but your simplicity argument does again hinge on future usage12:06
rogfwereade: 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 way12:06
fwereaderog, suggestion:12:06
fwereaderog, I follow your advice but for different reasons12:07
rogfwereade: i'm not sure. my simplicity argument is based on looking at the code as is12:07
rogfwereade: and seeing that it could be made simpler12:07
fwereaderog, 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 implemented12:08
rogfwereade: that's true too12:08
fwereaderog, you get simpler code to review and we defer any argument about the right way to do something until we're actualy doing it ;p12:08
rogfwereade: i wasn't sure whether you'd already got some code that implemented GetCmds already lurking somewhere though12:09
fwereaderog, no -- it's the simplest thing I could predict it would be easy to get from a Context :)12:09
rogfwereade: well, i'm glad about that at least - no downstream branches to mangle12:10
rogTheMue: ping12:22
TheMuerog: pong12:22
rogTheMue: i got a test failure on TestUnitWatchPorts12:22
rogTheMue: i've worked out the issue, and i think i have a slightly better way of working that test12:22
rogTheMue: how about this? http://paste.ubuntu.com/949642/12:23
rogTheMue: this issue was a timeout BTW12:23
rogTheMue: the receiver of the changes wasn't waiting long enough for the generator12:23
TheMuerog: 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
rogTheMue: this change makes them both run in lock step (so it should be faster) and also uses the same table for both12:24
rogTheMue: ok, so you've got a similar change in the offing?12:24
TheMuerog: Yep12:24
TheMuerog: Wait, I paste one example.12:25
rogTheMue: cool. i'll ignore the test failures for the moment then.12:25
TheMuerog: http://paste.ubuntu.com/949648/12:27
rogTheMue: that's cool. no need for the extra goroutine, of course, which i hadn't realised. nice.12:29
TheMuerog: I followed an idea of William.12:29
rogTheMue: 't'was a good idea12:29
TheMuerog: Indeed.12:29
TheMuefwereade: ping12:38
fwereadeTheMue, pong12:38
TheMuefwereade: Just seen that you've got no roomie, like me. Shall I notify Marianna?12:39
fwereadeTheMue, sure :)12:39
TheMuefwereade: OK, will do.12:39
fwereadeTheMue, I'm reasonablycivilised most of the time ;)12:39
TheMuefwereade: I'll try my best to do so too. *lol*12:40
rogTheMue: where do you find out your roomie?12:40
TheMuerog: I went to the wiki and there "latest changes".12:44
TheMuerog: There's a "PeopleDetail" page.12:45
rogTheMue: got it12:45
TheMuefwereade: Mail is sent.12:47
fwereaderog, new cut at https://codereview.appspot.com/6120054/12:47
fwereaderog, actually hold off, I can simplify further12:47
rogfwereade: yeah, jujucDoc and jujucPurpose can go, at least12:48
fwereaderog, that was precisely what I realised :)12:48
rogfwereade: LGTM12:52
fwereaderog, cool, thanks12:52
rogfwereade: i hope it feels ok12:53
fwereaderog, ii's good, thank you :)12:53
fwereaderog, btw, I've really come to appreciate lbox propose publishing all my drafts, really nice idea12:57
rogfwereade: i like that too. and the fact that i have to have a clean branch when proposing12:57
fwereaderog, yeah, that's saved me a lot of embarrassment :)12:58
rogfwereade: i wish cobzr switch would do that check too actually12:58
fwereaderog, I've actually given upon cobzr, it surprises me slightly more than bzr does and that makes me paranoid12:59
rogfwereade: i find it works pretty well actually.12:59
rogfwereade: it would be nice if there was a universal way of specifying a co-located branch, so i could diff against them13:00
fwereaderog, it's pretty clearly to do with a part of my brain that hasn't quite adapted to DVCSs in general13:00
rogfwereade: so how do you set your GOPATH?13:00
fwereaderog, so that's clearly soluble13:00
fwereaderog, but the easy diffing is too much to give up13:01
fwereaderog, sad to say, I'd rather just move directories ;)13:01
rogfwereade: i usually just push to launchpad and diff against there. slow but quick enough for my purposes13:01
fwereaderog, that would be fine if *something* I did didn't cause cobzr checkouts to occasionally forget their push branch :)13:02
rogfwereade: ah, i have seen that before, i think. but nothing that caused too many problems.13:03
andrewsmedinarog: thanks for the reviews :)13:27
rogandrewsmedina: np13:27
=== rog is now known as Guest17887
=== asavu_ is now known as asavu
niemeyerMornings!13:45
fwereadeheya niemeyer13:46
niemeyerfwereade: Hey13:47
niemeyerfwereade: I suspect the diff in https://codereview.appspot.com/6116049/ got mixed up with review points that we've sorted elsewhere13:59
niemeyerfwereade: If that's the case, we can just get it in and let the other issues be sorted in whatever CL they are being debated14:02
andrewsmedinaGuest17887: I will improve testing for LXC using the same line you used forthe ssh14:38
=== Guest17887 is now known as rogpeppe
rogpeppe andrewsmedina: that sounds reasonable.14:39
* niemeyer missing fwereade at the moment14:45
niemeyerI don't understand why the checks in https://codereview.appspot.com/5845051/diff/17001/charm/charm_test.go are being removed..14:45
niemeyerAhh, I think I see.. it was moved to another test14:48
niemeyerNice14:50
TheMueSo, have to leave.15:12
TheMueniemeyer: Watcher moving is in at https://codereview.appspot.com/6131045/, could you please review? Thx.15:13
TheMueniemeyer: 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
niemeyerTheMue: Will do15:18
niemeyerTheMue: Cheers15:18
* niemeyer => lunch too15:18
rogpeppeniemeyer: i'm seeing a store test failure: http://paste.ubuntu.com/950070/15:53
rogpeppeniemeyer, fwereade: https://codereview.appspot.com/6128046/15:57
rogpeppefwereade: https://codereview.appspot.com/6128046/16:01
rogpeppefwereade_: https://codereview.appspot.com/6128046/16:01
fwereade_rogpeppe, cheers16:02
rogpeppefwereade_: *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 ;p16:04
fwereade_rogpeppe, but tbh it's not clear what you can do about it...16:04
rogpeppefwereade_: yeah. i don't think it matters too much.16:04
rogpeppefwereade_: fix the build, then the tests can start working again16:05
niemeyerrogpeppe: Hmm.. is it failing consistently or some times?16:15
rogpeppeniemeyer: just that once, but i haven't run all the tests since then. will try again.16:16
niemeyerrogpeppe: I will increase the timeout there16:16
rogpeppeniemeyer, fwereade_: i'm off slightly early today. very shortly in fact.16:18
fwereade_rogpeppe, niemeyer: off in a few short minutes myself16:19
* fwereade_ almost avoids saying something about friday, friday...16:19
niemeyerrogpeppe, fwereade_: Cool, I'll see you guys on Monday, hopefully16:19
niemeyerI'll be working from us-east, so we'll have little-to-no overlap16:19
rogpeppeniemeyer: did you see my latest CL BTW? archiving of juju client now works. only the S3 and shell script stuff to do.16:21
niemeyerrogpeppe: Woohay!16:21
rogpeppeniemeyer: store tests passed that time BTW16:22
niemeyerrogpeppe: init is close16:22
rogpeppeniemeyer: ?16:22
niemeyerrogpeppe: Cool.. it's the timeout indeed16:22
niemeyerrogpeppe: zkinit on server side16:22
rogpeppeniemeyer: cool. i reckon that'll probably be done by the time i've finished the S3 upload code16:22
rogpeppeniemeyer: 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
rogpeppefwereade_: cheerio16:24
niemeyerrogpeppe: 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 them16:24
niemeyerrogpeppe: I'm so excited about this stuff, btw16:24
fwereade_rogpeppe, happy weekend16:24
rogpeppeniemeyer: 'xactly. "the shell script stuff"16:24
niemeyerrogpeppe: Yeha16:24
rogpeppeniemeyer: me too.16:24
niemeyerrogpeppe: 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
rogpeppeniemeyer: the go tool made it almost trivial... kudos to russ16:26
niemeyerrogpeppe: Hmm.. I don't think that's entirely related16:26
niemeyerrogpeppe: Kudos to all of them for having standalone binaries.. *that's* the huge facilitator16:26
fwereade_gn all, take care16:28
rogpeppeniemeyer: 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 lovely16:28
niemeyerrogpeppe: Ah, I didn't realize you were going in that direction16:29
niemeyerfwereade_: Night man16:29
rogpeppeniemeyer: hope it works ok for you.16:29
niemeyerrogpeppe: Thinking..16:29
niemeyerrogpeppe: This is most awesome for dev, but it means you need the dev environment in place too..16:30
niemeyerrogpeppe: The alternative I was thinking off was looking for the tools in $PATH16:30
niemeyers/off/of16:30
niemeyerrogpeppe: 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 debs16:31
rogpeppeniemeyer: i'd assumed non-devs would use public binaries16:31
niemeyerrogpeppe: Sure, that's an assumption we can make, but the question is why16:32
niemeyerrogpeppe: What are we trading off16:32
rogpeppeniemeyer: i can easily add logic to find binaries in $PATH to the current code.16:34
rogpeppeniemeyer: perhaps in the next CL?16:34
niemeyerrogpeppe: Yeah, we can even wait longer16:35
niemeyerrogpeppe: Until we have answers for that16:35
niemeyerrogpeppe: Your scheme sounds better for the situation we're currently in16:35
* niemeyer goes for a few errands in preparation for the trip19:42
=== flaviamissi_ is now known as flaviamissi

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