[00:10] niemeyer: do you have any further comments on https://codereview.appspot.com/6215045/ ? [00:18] davecheney: Heya [00:18] davecheney: Good morning [00:19] davecheney: I'll have a pass on your branches [00:19] davecheney: Just back from dinner now [00:19] davecheney: Will finish Rog's one first, though.. already half way through the massive branch [00:48] davecheney: ping? [00:51] ack [00:55] davecheney: Heya [00:55] davecheney: How are you? [00:55] good [00:55] sorry, was downstairs having breakfast [00:55] davecheney: No worries at all [00:55] i generally work from when I get up to when sam gets up [00:55] davecheney: Just wanted to take the chance we're both up and kicking to chat a bit [00:56] sure thing [00:56] davecheney: Who's Sam? [00:56] my partner [00:56] she's not a morning person [00:56] davecheney: Aha, I can understand that! :) [00:57] so, what can I do to get those reviews cleared away [00:57] davecheney: I work in the morning because I interact with the guys in the EU, but it's certainly not my most productive moment in the day [00:57] davecheney: I'm just finishing that monster review for Rog.. I have yours next up [00:57] no worries [00:57] davecheney: I think I still have spare energy to get through them [00:58] i'm not blocked at the moment [00:58] davecheney: How've you been feeling this week with the work-at-home situation? [00:58] it's working well [00:59] i ordered a new X220 [00:59] so when taht arrives i'll be more mobile [00:59] but for the moment i'm just kicking it in the spare room [01:06] davecheney: Nice. Coincidently, my battery just died today, so I'm stuck in the office :) [01:07] so i read [01:07] li-ions tend to fall off a cliff [01:11] Phew.. [01:12] davecheney: Yeah [01:12] Branch reviewed [01:12] That was a long oen [01:12] nice work [01:12] i understand, small branches >> large brances [01:13] hi guys [01:13] :D [01:16] * davecheney waves [01:23] davecheney: https://codereview.appspot.com/6215045/ has a review, and LGTM with the points addressed. [01:23] andrewsmedina: Heya! [01:23] andrewsmedina: juju team is 24x7 now ;) [01:24] Well, 24x5 at least! [01:24] I'm 24x7 [01:24] niemeyer: I'm working on https://codereview.appspot.com/6099051/ [01:25] andrewsmedina: No, I'm serious.. davecheney is in Australia.. we're going round-the-clock now :) [01:25] niemeyer: thanks for https://codereview.appspot.com/6215045/, i'll address those comments and submit [01:25] I will tell you when I finish it [01:27] davecheney: My pleasure, and thanks [01:27] andrewsmedina: Super! [01:28] negronjl: re your final comment [01:28] I would personally find it ok if we injected the "name" attribute on the [01:28] environment configuration when reading it out of environments.yaml. [01:28] can I handle that in a later branch ? [01:28] i'll change the config to be a TODO [01:32] niemeyer: did you have a chance to consider the race with AddMachine() ? [01:32] davecheney: Re. "name", yeah, definitely.. wasn't suggesting it'd be for the same branch. I suggest fixing the "TODO", though. [01:33] davecheney: re. the race, which race? [01:33] the way state.AddMachine works currently, it's changes are visible to the MachineWatcher while the topology is inconsistent [01:35] davecheney: Duh.. that kind of thing is the core reason why we have the topology [01:35] davecheney: I forgot about it when reviewing. Thanks a lot for pointing that out. [01:36] i haven't looked into it too much, but it might be possible to fix the problem by reordering the operations inside AddMachines [01:36] but as it stands now, the MachineWatcher observes /machines changing, but when it calls state.Machine("the name of the key that just arrived"), it can fail because the topology has not yet changed to reflect that [01:37] davecheney: The only reason we have a central monotonic topology is so that we can get atomicity in that kind of operation [01:38] davecheney: I suggest a quick look at the watch_machine_states in the Python side [01:38] will do [01:38] davecheney: If we reorder operations, we have the same problem on the opposite side [01:39] davecheney: (code reading the topology explodes due to lack of nodes) [01:39] right [01:39] davecheney: Eventually, we may have to get smarted than that to scale up to more extreme levels [01:39] smarter [01:40] davecheney: But then we'll need to consider races, locks, expirations, etc [01:40] davecheney: The monotonic topology is a cheap way to get going for a long time without having to invest much on scenarios that re unrealistic in the near future [01:41] i think i haven't explain myself properly [01:41] i shouldn't have said the topology is inconsistent [01:41] more that state.Machine() races with state.AddMachine() [01:52] davecheney: It doesn't [01:52] davecheney: At least not any more than the fact everything always races with everything [01:53] davecheney: Changing the topology is atomic.. AddMachine will add to the topology atomically, and state.Machine will read it atomically [01:55] davecheney: The watcher needs to observe the topology, though, not the nodes themselves [01:59] davecheney: Btw, when you "lbox submit", the latest changes in the branch are pushed to the codereview [01:59] davecheney: So, unless you want to have a last look online, the propose preceding it isn't necessary [02:02] davecheney: Ah, I think I've got the context for what you're talking about now, looking at your branch [02:02] davecheney: Sorry for the noise [02:03] niemeyer: re lbox propose, yeah I do that so I have a diff of what is the final state [02:03] it probably don't need to do that [02:04] davecheney: It doesn't bother me.. was just pointing out that submit does send the diff too [02:04] (since it's not obvious) [02:04] niemeyer: when you say context, you're talking about the comment at the bottom of MachinesWatcher.toMachines [02:04] davecheney: yeah [02:04] davecheney: Was just prising the comments, coincidently [02:05] davecheney: You got a LGTM on it [02:05] nice [02:06] there is a similar problem with doing state.Machine('an id which was just deleted') but for more obvious reasons [02:06] davecheney: yeah [02:15] niemeyer: thanks for the reviews [02:15] I started to work on the provisioning agent proper yesterday [02:15] so I shold have a wip branch this evening [02:21] davecheney: Woot [02:21] i have a plan to model the current privider (environs.Environ) as a goroutine [02:22] which should hide the fact that it can reload itself as the environment changes [02:22] without having to require a lot of retry logic [02:24] davecheney: Btw, would you mind to work on a branch fixing WatchMachines? [02:24] sure [02:25] so, you would like WatchMachines to not return a *Machine unless it is properly visible in the topology ? [02:26] davecheney: WatchMachines should be a content watcher, not a child watcher [02:26] davecheney: and watch the topology [02:27] davecheney: Otherwise it will be notifying about machines before they are visible, which will create all kinds of bugs [02:27] davecheney: The Python logic already works like that for the same reason [02:27] ok, understood [03:20] Aaand that's bad time! [03:20] I mean, good time! [03:20] Good time for bed! :) [03:20] Have a good night all [03:20] davecheney: And a good day to you, Dave [03:45] night mate [04:18] davecheney, x230s are around the corner [04:18] always something i suppose [06:17] davecheney: hiya [06:27] hi rog [06:28] hazmat: don't tell me that, i just dropped a gorilla on an x 220 [06:38] davecheney: hey, we coincide! [06:39] shazam [06:39] so, after redoing watchmachine, i have to redo it again :) [06:39] oh well, at least I got two commits off my plate today [06:39] davecheney: yeah, i saw that. bummer. [06:39] davecheney: is it that it can't use the child watcher? [06:40] no, not directly, although i'll probably end up implenting the same logic [06:40] the problem witht eh child watcher is i observe new /machine keys arriving before they exist in the topology [06:40] gustavo says i need to watch the topology insteam [06:40] davecheney: i wonder if *anything* can legitimately use the child watcher [06:40] rogpeppe: i'm starting to think not [06:42] still, once we get the provisioning agent right, the machine and unit agents will probably be 95% the same [06:42] davecheney: interesting. i'm sure the python version watches children somewhere. but maybe it's wrong. [06:43] davecheney: machine agent is simple. the unit agent is a bit more complex as it needs the logic for determining which hook to run when (the core of juju in fact) [06:43] no, it watches the topology, [06:46] trunk/juju/state/relation.py:653 [06:47] trunk/juju/state/relation.py:839 [06:47] davecheney: so there is at least *one* place that watches children [06:48] davecheney: i can't immediately work out if it's legit though [06:48] will read in a sec [06:52] davecheney: BTW after discussion with gustavo last night, i have an idea for simplifying the ConfigChecker part of EnvironProvider, and making it slightly more statically typed. [06:53] rogpeppe: if you want to do a branch for that, i'll gladly review it [06:54] davecheney: cool. it might only be 10 minute's work. i'll have a look now. [06:55] rogpeppe: the part where you pass an untyped 'something' through the Checker and receive another opaque 'something' back which is specific to the Provider that checked it, doesn't make me feel wholesome [06:56] davecheney: yeah. i don't mind the second part so much, but now that we mandate that the initial "something" is actually [string]interface{}, we should reflect that in the API. [06:56] rogpeppe: +1 [06:57] davecheney: heh, maybe it should return a func() Environ, rather than an opaque "something" [06:57] davecheney: then the state would be hidden behind a closure. [06:59] rogpeppe: now that would be more appropriate for Go [06:59] davecheney: i think so [07:04] davecheney: how about something like this: http://paste.ubuntu.com/991940/ [07:05] btw, state/machine.py ~ 103 sort of does what your child watcher does [07:08] davecheney: yeah. i think when i did the child watcher i was misremembering that piece of code. [07:09] well, it does do what your child does, ie it takes an old set, then waits for a new set, the produces a delta of machines added and machines left [07:09] davecheney: BTW if you don't mention my IRC nick, i tend not to see your comments (it makes my machine beep...) [07:10] davecheney: exactly. i think i'd misremembered the fact that it reads topology not children. [07:10] rogpeppe: np, anyway, i hope the functionality exists inside the topology (haven't looked yet) [07:11] davecheney: i don't think there's a similar watcher yet. [07:11] * davecheney fml [07:12] fml? [07:14] http://www.urbandictionary.com/define.php?term=FML&defid=5145198 [07:14] that bad, eh? [07:17] no, not really [07:24] rogpeppe: re http://paste.ubuntu.com/991940/ [07:24] rogpeppe: why produce a func that produces an Environ, why not produce the Environ directly ? [07:25] davecheney: because we want to be able to check all the environments in environments.yaml for correctness without instantiating them all. [07:25] davecheney: an environment is perfectly entitled to do some expensive operation when opened. [07:25] fair enough [07:26] davecheney: i'm liking the way it's looking so far [07:26] rogpeppe: yup, fair point, in that case func(Environ, error) is really just an anonymous type for EnvironProviderHolder, or something [07:26] but it gets the job done [07:26] davecheney: yeah. [07:27] it could return a Config type. type Config interface { Open() (Environ, error) } [07:28] but i don't mind returning a simple function. [07:28] although.... [07:28] i'd argue for the functional approach [07:28] actually that might be nice. we've already got a config type in ec2 and elsewhere. [07:28] and we'd just need to define an Open method on it. [07:29] i could go either way [07:29] rogpeppe: so, Check(config map) => Config; Config.Open() => Environ ? [07:29] davecheney: yeah [07:30] davecheney: i think i prefer that actually. [07:31] s/Config/EnvironConfig/ i think [07:33] davecheney: current state: http://paste.ubuntu.com/991957/ [07:34] rogpeppe: LGTM [07:34] rogpeppe: how did your networking explorations go ? [07:36] davecheney: i totally failed to set up a bpf filter (no idea why - couldn't see anything in the kernel code to indicate why i was getting EINVAL); but i've realised that i *think* i can just use the tun device and get the kernel to do all the filtering for me. [07:36] davecheney: had fun on the plane writing a little translator to the bpf VM language. came across a really nice use of defer. [07:37] rogpeppe: as a suggestion, if you're bringing up a tun device, then you can just use IP routing to do what you want [07:37] davecheney: exactly. [07:37] rogpeppe: bpf might get you max nerd cred, but IP routing is easier and better understood [07:37] davecheney: i just have to work out how to use an etun device because you can't share a network interface across lxc instances [07:38] davecheney: but that's probably easy to do through the lxc interface in fact. [07:38] rogpeppe: yeah, lxc has a number of networking options; I would _think_ that we do _not_ want bridging (which is what it does out of the box) [07:39] davecheney: yes. [07:39] from experience with OpenVZ, on the host side, you get an interface called venet0, which you assign all the ip's of the containers you're running [07:39] as long as you get the IP packets to the host, it will do the rest [07:39] davecheney: i *think* that etun (a kind of interface "pipe") does what i'm after, but i haven't had great joy finding docs. [07:40] essentially the OpenVZ guests are running ppp (think point to point, not ppp serial) links to the host [07:40] so there is layer 3 routing involved [07:40] davecheney: the most important thing is being able to read the IP packets generated by the guests from some central point. [07:41] davecheney: and that the kernel knows enough to route between local guests. [07:41] yeah, dunno if you can sniff on the host side of an LXC container [07:41] the kernel will be able to route between the local LXC containers [07:41] that sorta comes for free [07:42] davecheney: i found this to be a useful intro: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ [07:43] rogpeppe: thanks for the link [07:43] davecheney: i got all that stuff working ok. [07:43] davecheney: but i haven't put it together with lxc yet [07:43] rogpeppe: ip (iproute2) is an amazing tool, and virtually completely without documentation, unless you've used cisco routers, then it's like second nature [07:44] davecheney: it seems ok actually. the syntax isn't too shit. [07:44] rogpeppe: i found it pretty unfriendly to exploration [07:44] davecheney: it reminds me of the configuration language you use for talking to the plan 9 ip device [07:44] althoguh i got pretty friendly with ip r s [07:44] davecheney: it would be nice to have some decent docs though, it's true. [07:45] ip r s? [07:45] ip route show [07:45] ah [07:45] ip r a 10.0.0.1/32 gw tun0 [07:45] was another favorite [07:46] davecheney: using the ip command beats working out the right argument to pass to the right ioctls... [07:47] davecheney: what's the difference between route add and addr add? [07:47] rogpeppe: adding an address to an interface is an endpoint [07:47] adding a route, establishes a possible flow between endpoints [07:48] davecheney: ok. that makes sense. [07:48] davecheney: in my case though, i'm using an endpoint as a route... [07:49] rogpeppe: yeah, it gets murkey [07:49] traditionally you'll say, ip r a 192.168/16 gw tun0 [07:49] sorry [07:49] ip r a 192.168/16 gw 10.0.0.1 [07:50] that is, send anything for 192.168/16 to 10.0.0.1, it knows what to do [07:50] davecheney: is 192.168/16 equiv to 192.168.0.0/16 ? [07:50] but there are more complex combinations, generally when the next hop is either not local to our network, or a point to point link [07:50] yes, http://en.wikipedia.org/wiki/CIDR_notation [07:51] they are all shorthand [07:52] anyway, i'd better get my self together to go out [07:52] devops sydney starts in an hour [07:52] davecheney: k [07:52] davecheney: have fun [07:52] wd [07:54] davecheney: hmm, not obvious from that page that 192.168 is equivalent to 192.168.0.0. [07:55] davecheney: i've used 127.1 as an alias for 127.0.0.1 in the past, so it's not universal... [09:30] heya rogpeppe [09:30] fwereade: yo man! [09:30] fwereade: thought you were off! [09:31] rogpeppe, today's cold and dull :) [09:31] fwereade: where r u? [09:31] rogpeppe, my mum's house in gloucestershire [09:32] fwereade: ah, cold and grey is par for the course currently... [09:32] rogpeppe, I will almost certainly take a couple more off over the next week but I don't want to entirely cut myself off :) [09:32] fwereade: cool. [10:15] rogpeppe, btw, I really enjoyed lord valentine's castle [10:15] fwereade: great, innit?! [10:15] fwereade: there are sequels... [10:15] rogpeppe, good old-fasjioned gripping yarn, nicely written, cool tech just peeking out of the background [10:15] 'xactly [10:15] i really liked that world [10:16] rogpeppe, yeah, I was thinking I'd have to look them up :) [10:17] rogpeppe, also there's something quite nice about a world running on tech they don't understand that *doesn't* draw all its drama from the obvious "it's breaking down and nobody understands it" scenario [10:17] fwereade: yeah. the tech is not central. [10:21] fwereade: i also fondly imagine, though i haven't read it in a while, that it hasn't dated badly. [10:21] fwereade: because of its lack of connection to the present day [10:21] fwereade: did you ever read Helliconia Spring BTW? [10:21] rogpeppe, perhaps ever such a gentle sepia tinge [10:22] rogpeppe, but quite possibly that was just triggered off it being an old book, becaue I can't think of anything specific [10:22] rogpeppe, nope [10:22] fwereade: great series. Brian Aldiss. [10:22] * fwereade is *sure* he read some of his stuff but can't remember what [10:23] * rogpeppe hasn't read any of his stuff in ages, but read most of it years ago. [10:24] fwereade: http://www.amazon.co.uk/Helliconia-Spring-Summer-Hellonica-MASTERWORKS/dp/0575086157/ref=sr_1_1?ie=UTF8&qid=1337250194&sr=8-1 [10:24] rogpeppe, cool, that series has not led me wrong at any time I can recall [10:25] fwereade: not sure i've read anything from that series actually [10:25] fwereade: the original helliconia covers were definitely better. [10:25] fwereade: http://www.amazon.co.uk/Helliconia-Spring-Brian-W-Aldiss/dp/0586053654/ref=sr_1_4?ie=UTF8&qid=1337250194&sr=8-4 [10:26] fwereade: http://www.amazon.co.uk/Helliconia-Summer-Panther-Books-Aldiss/dp/0586053662/ref=sr_1_5?ie=UTF8&qid=1337250194&sr=8-5 [10:26] rogpeppe, I haven't read all that many I guess but all the ones I've read have been good [10:26] fwereade: http://www.amazon.co.uk/Helliconia-Winter-Brian-Aldiss/dp/0586053670/ref=sr_1_6?ie=UTF8&qid=1337250194&sr=8-6 [10:26] :-) [10:26] rogpeppe, yeah, those are much more interesting [10:26] fwereade: they're also fairly close to the actual contents of the book, which is unusual [10:28] rogpeppe, I still keenly remember the disappointment of my first don't-judge-etc moment ;) [10:28] fwereade: :-) [10:29] fwereade: the style isn't as accessible as Valentine's Castle. you can get a good idea from the Look Inside... [10:31] rogpeppe, seems quite pleasing to me [10:31] rogpeppe, I can imagine times I wouldn't be in the mood for it [10:31] fwereade: it's definitely lingered in my mind. [10:48] fwereade: you might want to have a look at https://codereview.appspot.com/6145043/ [10:48] fwereade: it's got quite a bit of new stuff in after discussions with niemeyer [10:49] fwereade: in particular, check out the Storage types in environs/interface.go [11:16] morning. [11:21] rogpeppe, sorry I missed that, I'll take a look; morning Aram [11:22] Aram: hey [11:44] fwereade: i've uploaded a new version addressing niemeyer's comments. [11:45] rogpeppe, just saw, thanks [11:48] rogpeppe, and the storage stuff is indeed very pleasing, nice work [11:51] fwereade: cool. it's funny how a tiny niggle (ToolsPath in this case) can lead to a significant advance. [12:02] fwereade: "This being an interface method says to me that it's done by definition ;)." [12:02] fwereade: not quite sure what you mean there [12:19] fwereade: "juju1.2.3-precise-i386.tgz" vs "juju-1.2.3-precise-i386.tgz" ? [12:19] fwereade: which do you prefer? [12:19] rogpeppe, sorry, it would appear I can't read and failed to notice it was commented out [12:19] * fwereade looks bashful and goes to eat lunch [12:19] fwereade: np [12:20] rogpeppe: juju-1.2.3-precise-i386.tgz is better for awk. [12:21] Aram: ok. good enough. that's what i have already. [12:21] i just noticed i had also had the other variant in the past [12:52] * rogpeppe goes for lunch [13:21] Morning! [13:21] heya niemeyer [13:22] fwereade: Heya, how're things going there? [13:22] fwereade: Still in the uk? [13:22] niemeyer, not bad; cold and wet [13:23] niemeyer, that should answer your followup too ;) [13:23] Haha :) [13:23] fwereade: Having fun with the family? [13:23] niemeyer, yeah, it's lovely [13:23] fwereade: nice [13:24] niemeyer, I think since I have the opportunity I will take tomorrow until tues as a proper holiday if that's ok with you [13:24] fwereade: Yeah, it's cool [13:24] niemeyer, great, thanks :) [13:26] fwereade: no worries, good to enjoy the family every once in a while :) [13:26] niemeyer, absolutely :) [13:27] niemeyer, laura brought be a bunch of flowers today, it was awesome :) [13:27] fwereade: Hah, so sweet :) [13:35] Heya! [13:35] andrewsmedina: Morning! [13:38] niemeyer: morning! [14:09] niemeyer: hiya! [14:13] rogpeppe: Hey man [14:13] rogpeppe: How's tricks? [14:13] niemeyer: great. am pleased with the last couple of branches. just working on upload-tools, to integrate the upstream stuff. [14:13] niemeyer: sorry about the size of the last one [14:14] niemeyer: lp doesn't make it easy to split a branch during review [14:14] rogpeppe: No worries, it was partly self-inflicted :) [14:15] niemeyer: i'm hoping you like the new Listen/Close thing in the dummy environ. [14:15] niemeyer: that's the only substantive change this time round, i think. [14:15] rogpeppe: Why do we need it? [14:15] rogpeppe: Can't we simply Reset a single time in the test? [14:15] niemeyer: because we need to be able to signal to the dummy environ that no more changes are coming [14:16] niemeyer: we need to Reset to listen; then we need to wait for any changes on the channel. [14:16] rogpeppe: Ok, that may be done with a single Reset [14:16] niemeyer: by closing it, we know there are no more to come. [14:16] niemeyer: but we also want to be able introspect the state after the channel has been closed. [14:16] niemeyer: so that we can tell that tools have been uploaded for example. [14:17] niemeyer: that was why i added the bool arg, but i think Listen/Close is cleaner. [14:17] rogpeppe: I don't see why we need to do that afterwards.. but either way I like the sound of it too [14:18] niemeyer: well, we can't do it before! [14:19] pwd [14:21] rogpeppe: We only need to Reset once in a test.. you then have a channel of events to introspect [14:21] rogpeppe: You can use that single channel of events in all verifications [14:21] niemeyer: yes, but we need to introspect *after* all events have completed. [14:22] rogpeppe: Not really [14:22] rogpeppe: There's no intrinsic reason why that would be the case [14:22] niemeyer: we don't necessarily know what operations will be performed [14:22] what's a branch in this context, it seems to me the branches you're talking about are not VCS branches, right? [14:22] Aram: VCS branches, yes [14:22] or is bzr different? [14:22] rogpeppe: Yes, we don't.. welcome to mocking [14:22] hmm. [14:22] rogpeppe: You're asserting that you know it.. [14:23] niemeyer: i don't *think* so. [14:23] niemeyer: i'm asserting that i know at least one operation that will be performed. and that the files can be downloaded afterwards. [14:23] niemeyer: if the channel isn't closed, then i'll have to time out on error, and i don't want to do that. [14:24] rogpeppe: Huh.. you're asserting a sequence of operations, and closing the channel in a way that explodes if it doesn't work [14:24] rogpeppe: Anything else done by the environment will cause the test to explode [14:25] rogpeppe: You might as well do that without resetting in the middle, for example [14:25] niemeyer: i'm asserting that the operation does a sequence of operations, yes. i don't think anything will explode if it doesn't work - unless the operation does operations aynchronously after it's returned. [14:26] rogpeppe: I can't follow you.. "i'm asserting that the operation does" and "i don't think anything will explode if it doesn't work" are not compatible with each other [14:26] * rogpeppe goes to look at the code again [14:27] niemeyer: what do you mean by "explode"? [14:27] rogpeppe: The test will explode [14:27] niemeyer: nothing will panic, if that's what you mean [14:27] rogpeppe: Fail [14:27] niemeyer: that's what i want to happen [14:27] rogpeppe: No.. I mean the test will fail [14:27] niemeyer: isn't that the correct behaviour? [14:28] rogpeppe: Yes, and this correct behavior doesn't need Reset in the middle. [14:28] rogpeppe: It will fail if you don't reset in between things too. [14:28] niemeyer: what happens if the operation does no actions? [14:28] rogpeppe: Yes, what happens? [14:28] rogpeppe: Today? [14:28] rogpeppe: The same will happen [14:28] niemeyer: i wait for something to arrive on the channel, but nothing arrives. [14:29] rogpeppe: Yep.. same will happen if you don't reset [14:29] niemeyer: no, that's why i have Close. [14:29] Sorry, I don't get it.. [14:29] rogpeppe: Reset, A, B, Reset, C, D [14:29] rogpeppe: Why do you need the Reset in the middle? [14:30] rogpeppe: Reset the dummy environment, and use a single channel from end to end.. [14:30] niemeyer: we need a Reset at the end of the test as well as at the beginning. [14:30] rogpeppe: That's not the question asked [14:30] niemeyer: otherwise what happens when we're expecting to read D but it wasn't sent [14:30] ? [14:30] rogpeppe: Why do you need the Reset in the middle [14:31] niemeyer: we don't. we have one Reset at each side of the tested operation (or, in the new way, a Reset at the start and a Close at the end) [14:32] rogpeppe: Bingo.. we don't need a Reset in the middle, which means we don't need clear, or to change the interface of the dummy package. [14:32] niemeyer: there is no Reset in the middle right now. there never has been. [14:32] rogpeppe: There is.. that's the only reason why you've introduced clear [14:32] or clean [14:32] rogpeppe: To reset the environment without actually resetting it [14:33] rogpeppe: If you only actually reset when the test starts or ends, the current interface suffices [14:33] niemeyer: look at cmd_test.go:150 [14:33]