[01:48] <davecheney> niemeyer: testing/mgo_test.go wasn't being run
[01:48] <davecheney> i'll roll that fix into my next proposal
[02:14] <niemeyer> davecheney: Oops.. thanks!
[02:19] <davecheney> niemeyer: https://code.launchpad.net/~niemeyer/goetveld/trunk/+merge/126136
[02:20] <davecheney> ^ not propsed with lbox, sorry
[02:22] <davecheney> urgh, change list is empty as well ...
[02:24] <davecheney> ahh, because i did it ass backawards
[02:25] <davecheney> niemeyer: https://code.launchpad.net/~dave-cheney/goetveld/001-add-darwin-termios-support/+merge/126137
[03:16] <niemeyer> davecheney: LGTM
[03:16] <niemeyer> davecheney: I've just changed the project so it's trunk is owned by the gophers team
[03:16] <niemeyer> s/it's/its/
[03:16] <niemeyer> davecheney: Please feel free to repropose against the new trunk and submit it straihgt
[03:16] <niemeyer> straight
[03:24]  * niemeyer => bed
[07:52] <fwereade> ha! my first Refresh-related bug with a long-lived-entity
[07:52] <rogpeppe> fwereade: morning!
[07:52] <rogpeppe> fwereade: it was bound to happen
[07:52] <fwereade> rogpeppe, what would you think about putting Refresh in at the start of Watch on Unit and Service?
[07:53] <fwereade> rogpeppe, that way the initial event actually is the current state, rather than potentially being whatever aged rubbish you started to watch?
[07:53] <rogpeppe> fwereade: what are the events that those watchers produce?
[07:54] <fwereade> rogpeppe, something-changed
[07:54] <fwereade> rogpeppe, send fresh units back
[07:54] <rogpeppe> fwereade: so won't the initial event be a fresh unit?
[07:54] <rogpeppe> fwereade: and hence have all the currently correct settings?
[07:54] <fwereade> rogpeppe, AFAICT it'll correspond to *some* transaction more recent than the revno of the old document
[07:55] <fwereade> rogpeppe, hey wait that makes no sense
[07:55] <rogpeppe> fwereade: hmm, that seems wrong
[07:55] <fwereade> rogpeppe, ok, time seemed to be flowing in reverse, and a Refresh fixed it, but clearlymore thought is required
[07:55] <rogpeppe> fwereade: the initial event should be the most recent revno
[07:56] <fwereade> rogpeppe, ah, no, the initial event is just the unit yu originally watched
[07:56] <rogpeppe> fwereade: that seems wrong to me
[07:56] <fwereade> rogpeppe, yeah, agreed
[07:56] <rogpeppe> fwereade: then there's no point in having the initial event
[07:57] <fwereade> rogpeppe, well, yeah; we could either Refresh it or reconstruct a new one and send that back
[07:57] <rogpeppe> fwereade: i'd incline towards the latter
[07:57] <rogpeppe> fwereade: we don't do any implict Refresh anywhere else
[07:58] <rogpeppe> TheMue: yo!
[07:58] <fwereade> rogpeppe, ok, sgtm
[07:58] <rogpeppe> fwereade: and every other event on the channel is a fresh object
[07:58] <fwereade> TheMue, heyhey
[07:58] <fwereade> rogpeppe, yeah, feels neat
[07:58] <TheMue> morniing rogpeppe and fwereade
[08:32] <fwereade> rogpeppe, TheMue: should be trivial: https://codereview.appspot.com/6571047
[08:35] <rogpeppe> fwereade: LGTM
[08:36] <fwereade> rogpeppe, cheers; trivial enough to submit directly, do you think?
[08:37] <rogpeppe> fwereade: i *think* so, but it is a significant change in one sense.
[08:37] <rogpeppe> fwereade: even though the code is trivial
[08:38] <fwereade> rogpeppe, in the sense that it causes the uniter to work properly, it is significant ;p
[08:39] <fwereade> rogpeppe, and I think it is unambiguously (1) correct, because watches should send current state and then deltas; and (2) safer, because we don't ever send the originating entity over to some unknown client over a channel
[08:39] <rogpeppe> fwereade: it's that last thing that i think is the killer argument
[08:39] <fwereade> rogpeppe, indeed, it is only secondary in my mind because it wasn't the thing that bit me
[08:40] <rogpeppe> fwereade: i'd say go for it
[08:40]  * fwereade cheers
[09:41] <Aram> moin.
[09:42] <davecheney> hello and goodbye
[09:42] <davecheney> time to make the dinner
[09:42] <davecheney> then i'll see ya'll for the hangout
[09:46] <fwereade> ok  	launchpad.net/juju-core/worker/uniter	117.284s
[09:46] <fwereade> ok  	launchpad.net/juju-core/worker/uniter/charm	7.835s
[09:46] <fwereade> ok  	launchpad.net/juju-core/worker/uniter/hook	0.007s
[09:46] <fwereade> ok  	launchpad.net/juju-core/worker/uniter/relation	8.826s
[09:46] <davecheney> fwereade: did you see my comment to the list about i/o usage
[09:46] <davecheney> that might explain your excessive test times
[09:46] <fwereade> davecheney, I did, makes a lot of sense
[09:46] <fwereade> davecheney, thanks
[09:46] <davecheney> fwereade: maybe aram can help
[09:46] <davecheney> i had a look today, but I wasn't much chop for anything
[09:47] <davecheney> invoking mgo the way the tests do, doesn't make it create that big _tmp
[09:47] <davecheney> flie
[09:47] <davecheney> but then again, I never connected a client to the manually invoked one
[09:47] <Aram> 20MB
[09:47] <Aram> make it smaller
[09:47] <Aram> 1MB
[09:47] <davecheney> on my machine _tmp was 256mb
[09:47] <Aram> hmm?
[09:47] <Aram> perhaps testing/mgo had leaked?
[09:48] <Aram> or was this only from one test?
[09:48] <Aram> aaah
[09:48] <Aram> I know
[09:48] <Aram> niemeyer made the capped collection 20MB
[09:48] <Aram> 200
[09:48] <davecheney> aram what is _tmp ?
[09:48] <Aram> and it needs contiguous space for that
[09:48] <davecheney> (see email)
[09:48] <fwereade> Aram, aaaahhh, and it's only made little in *some* tests
[09:48] <Aram> ok, let me read the email
[09:48] <fwereade> Aram, right?
[09:49] <davecheney> fwereade: only made little in cloudinit -> deploy to ec2
[09:50] <davecheney> oh, that explains why my had started version didn't use any disk space
[09:50] <davecheney> it won't do that until someone connects to it and does ensure index ...
[09:53] <fwereade> davecheney, StartMgoServer specifies everything that addMongoToBoot does, doesn't it?
[09:54] <Aram> fwereade: make the capped collection 1MB and see if tests take less.
[09:54] <Aram> in open.go
[09:55] <Aram> wtf is wrong with launchpad today, so slow.
[09:56] <Aram> actually, my internet is slow.
[09:56]  * Aram reboots router
[10:15] <TheMue> lunchtime, see you in the hangout
[10:59] <TheMue> hmm, my build complains about an undefined bson.SetZero. i already update mgo. or is it a different problem?
[10:59] <Aram> bzr pull
[10:59] <Aram> go get -u is not enough
[11:00] <TheMue> Aram: thx, will try
[11:01] <TheMue> Aram: it pulled nothing, but i'm still using 1.0.2. may this be the problem?
[11:01] <Aram> no
[11:01] <Aram> you pulled mgo, right?
[11:02] <TheMue> yes
[11:02] <Aram> what does bzr log --line -r -1 say?
[11:03] <davecheney> so, how about that meeting ...
[11:04] <TheMue> funny, 172 with the added SetZero
[11:04] <davecheney> TheMue: maybe a fast path is to
[11:04] <davecheney> rm -rf .../v2/mgo
[11:04] <davecheney> go get ...
[11:04] <davecheney> the cd v2/mgo
[11:05] <davecheney> bzr pull
[11:05] <davecheney> that is what I did
[11:05] <davecheney> i'm pretty sure it will work
[11:05] <TheMue> will try that too
[11:05] <davecheney> please double check you don't have another mgo snuck away somewhere else
[11:05] <Aram> davecheney: but it's always funny to find new bzr misfeatures and broken behaviors to complain about them.
[11:06]  * davecheney smiles at Aram 
[11:06] <davecheney> its like bzr has set the revision to a revision in a branch
[11:07] <fwereade> hm, should we be meeting now?
[11:08] <davecheney> indeed
[11:08] <davecheney> we should
[11:12] <Aram> we should have a meeting about the lack of the meeting.
[11:13] <davecheney> Aram: please propose an agenda first
[11:13] <Aram> a user story.
[11:13] <Aram> which we have to send to a program manager.
[11:13] <TheMue> shall i sent out the invite?
[11:14]  * davecheney is texting mrarmm
[11:15] <fwereade> TheMue, please do
[11:16] <TheMue> done
[11:17] <mramm> sorry I was late to the meeting
[11:17] <davecheney> s'ok
[11:17] <davecheney> lets get going
[11:20] <mramm> I'm in the meeting, called by frank
[11:20] <davecheney> err, nobody else is
[11:21] <Aram> we are
[11:21] <Aram> :)
[11:21] <Aram> davecheney: https://plus.google.com/hangouts/_/74ad471b07ee1c4e3215133bbf54c62e79ff5c7b?authuser=1&hl=en
[11:21] <davecheney> ta
[11:23] <Aram> rogpeppe: ^ ^
[11:24] <rogpeppe> oops, didn't see it
[11:24] <rogpeppe> will be there in a moment
[11:29] <mramm> 16:06 niemeyer: Woah
[11:29] <mramm> 16:06 niemeyer: services:
[11:29] <mramm> 16:06 niemeyer:  builddb:
[11:29] <mramm> 16:06 niemeyer:    charm: builddb
[11:29] <mramm> 16:06 niemeyer:    exposed: false
[11:29] <mramm> 16:06 niemeyer:    units:
[11:29] <mramm> 16:06 niemeyer:      builddb/0:
[11:29] <mramm> 16:06 niemeyer:        agent-version: 0.0.0
[11:29] <mramm> 16:06 niemeyer:        machine: 1
[11:29] <mramm> 16:06 niemeyer:        public-address: ec2-204-236-223-223.compute-1.amazonaws.com
[11:29] <mramm> 16:06 niemeyer:        status: started
[11:33] <fwereade> davecheney, sorry, did you paste it somewhere I missed?
[11:33] <davecheney> sorry, email
[11:33] <davecheney> irc is on another machine, sorry
[11:35] <fwereade> davecheney, np, ty
[11:59] <fwereade> lunch bbl
[12:48] <niemeyer> Morning juju masters!
[13:06] <davecheney> niemeyer: hello
[13:06] <niemeyer> davecheney: Heya!
[13:06] <davecheney> sleep it would seem, eludes me
[13:10] <TheMue> niemeyer: hi
[13:14] <niemeyer> davecheney: Wow, yeah, you've been here for a while :)
[13:14] <niemeyer> TheMue: Yo
[13:30] <fwereade> niemeyer, heyhey
[13:30] <niemeyer> fwereade: Heya
[13:30] <niemeyer> fwereade: Just reviewing the relation units stuff
[13:30] <niemeyer> fwereade: Superb so far
[13:31] <fwereade> niemeyer, for some reason I made the make-uniter-work branch depend on that one
[13:31] <fwereade> niemeyer, jolly good, hopefully I won't need to reparent the followup ;)
[13:31] <fwereade> niemeyer, I submitted one trivial this morning btw that was necessary
[13:32] <niemeyer> fwereade: No, certainly not.. I think there were a few opportunities to have split the branches, as you noted yourself in the description, but it's alright.. happy to have it in whatever form.
[13:33] <fwereade> niemeyer, cheers
[13:33] <niemeyer> fwereade: Super, thanks re. trivial
[13:34] <fwereade> niemeyer, now I come to think of it, the timeout bumps in the followup are surely only necessary because I wasn't using a tmpfs
[13:34] <fwereade> niemeyer, I will adjust them down as seems fit
[13:35] <niemeyer> fwereade: Hmm
[13:35] <niemeyer> fwereade: The timeouts on the sad cases may be high
[13:35] <fwereade> niemeyer, I was thinking "conservatively", at first, anyway -- just to what they were originally
[13:35] <niemeyer> fwereade: Those prevent spurious breaks when the machine happens to get some load or when tests are running on a slow machine
[13:36] <niemeyer> fwereade: I haven't seen the branch
[13:36] <niemeyer> fwereade: What were they?
[13:36] <fwereade> niemeyer, 5s to 10s is the notable one, in a couple of places
[13:36] <fwereade> niemeyer, and I really don't think it deserves that long
[13:36] <niemeyer> fwereade: wow
[13:36] <niemeyer> fwereade: Yeah, that's a lot
[13:37] <niemeyer> fwereade: How come we're getting such long timeouts? Are we missing a resync?
[13:37] <fwereade> niemeyer, that was pessimistic, in practive it only missed the 5s mark by a few milliseconds even under load
[13:37] <fwereade> niemeyer, but I was in no mood to mess around ;)
[13:37] <fwereade> niemeyer, almost certainly it is because the mongo tests stress the hell out of my machine unless I have a tmpfs
[13:37] <niemeyer> fwereade: Hmm
[13:38] <niemeyer> fwereade: I wonder why
[13:38] <niemeyer> Well, I do have an SSD
[13:38] <fwereade> niemeyer, I think Aram and davecheney have a better developed understanding of it -- the stuff I've been working on has not generally been affected enough to get really worked up about when you're running a few tests at a time
[13:39] <fwereade> niemeyer, that said, it feels *much* nicer now than it ever did before, not sure is this is psychosomatic
[13:39] <fwereade> niemeyer, is anyone working on jujud btw?
[13:39] <niemeyer> fwereade: not that I know of
[13:40] <niemeyer> fwereade: I was about to ask what else has broken tests atm
[13:40] <fwereade> niemeyer, that seems to be the one remaining eyesore in the test output
[13:40] <niemeyer> fwereade: Anything obvious there?
[13:40] <fwereade> niemeyer, barely looked tbh
[13:40] <fwereade> niemeyer, focus has been elsewhere
[13:41] <fwereade> niemeyer, schema error in bootstrap_test is the first
[13:41] <fwereade> niemeyer, the remaining failures can probably be mostly attributed to collateral damage
[13:42] <niemeyer> fwereade: That rings a bell somehow
[13:57] <niemeyer> fwereade: Review sent
[13:57] <fwereade> niemeyer, cheers
[14:00] <niemeyer> Aram: ping
[14:00] <Aram> pong
[14:01] <niemeyer> Aram: Heya
[14:01] <niemeyer> Aram: How're things going there?
[14:02] <fwereade> niemeyer, the resyncing is to pick up Alive changes, without which Unit.Status will report "down" regardless of content
[14:02] <Aram> niemeyer: yesterday I've taken a swap day and today I'm working on the missing watchers and lifecycle in watchers. but a little bit later, ATM I'm running some rrands.
[14:02] <Aram> errand
[14:02] <Aram> s
[14:03] <niemeyer> fwereade: Sorry, I'm still slow today.. can you cover it a bit more piecemeal?
[14:03] <niemeyer> Aram: Okay, let's please talk once you're back
[14:04] <fwereade> niemeyer, ah, sorry, ok: I'm actually on crack, that's a different piece of code
[14:04] <fwereade> niemeyer, no reason for the resyncing you correctly complain about
[14:04] <niemeyer> fwereade: Is it just a matter of refreshing the unit itself?
[14:04] <fwereade> niemeyer, yeah, that is the sane and easy way
[14:05] <niemeyer> fwereade: Super.. I'm really just trying to understand these new patterns and see where/whether they fall short
[14:05] <fwereade> niemeyer, that was almost certainly an unremoved attempt at working around the weirdness in the entity watchers
[14:11] <rogpeppe> niemeyer, fwereade: just checking, do you think the provisioner is currently working in trunk?
[14:11] <fwereade> rogpeppe, STM to be, just deployed a unit
[14:12] <fwereade> rogpeppe, not from trunk, but I haven't touched the provisioner
[14:12] <rogpeppe> fwereade: hmm, my live tests aren't working
[14:12] <niemeyer> rogpeppe: It was yesterday
[14:12] <rogpeppe> niemeyer: the live test?
[14:12] <niemeyer> rogpeppe: The provisioner
[14:14] <rogpeppe> niemeyer: the provisioner test suite runs fine for me locally - just not live
[14:14] <niemeyer> rogpeppe: I've used the provisioner live yesterday
[14:15] <niemeyer> rogpeppe: Multiple times
[14:15] <rogpeppe> niemeyer: i've probably broken the live tests somehow then
[14:15] <niemeyer> rogpeppe: Or they are just not working after the state migration
[14:16] <rogpeppe> niemeyer: entirely possible. but it's not relying on watchers, so i *thought* it should work ok
[14:19] <rogpeppe> niemeyer: did juju status report you the correct agent version for the bootstrap machine?
[14:20] <niemeyer> rogpeppe: Yep
[14:21] <niemeyer> rogpeppe: I have a paste somewhere, hold on
[14:23] <niemeyer> rogpeppe: Sorry, can't find it
[14:23] <niemeyer> rogpeppe: I can easily fire a new env, though
[14:23] <rogpeppe> niemeyer: i think i saw it actually
[14:23] <rogpeppe> niemeyer: i'm trying again, but not in the test this time
[14:27] <niemeyer> fwereade: I think we'd benefit from adding back service.CharmURL, btw
[14:27] <niemeyer> fwereade: We can probably just revert it from somewhere in history
[14:28] <fwereade> niemeyer, I can only think of one place it's be a real boon... quite often we want the charm itself as well
[14:28] <niemeyer> fwereade: In hindsight, it was the SetCharmURL bit that was ill-conceived.. CharmURL is fine
[14:28] <fwereade> niemeyer, but yeah no actual objections
[14:28] <niemeyer> fwereade: Yeah, but often we grab the charm and throw it away.. we might grab the charm only if
[14:29] <fwereade> niemeyer, fair enough
[14:29] <niemeyer> fwereade: Not an issue by any means.. just sharing brain state :)
[14:36] <fwereade> niemeyer, ok, re MachineUnitsWatcher: what is the mechanism by which it guarantees it does not send events with the same unit both Added and Removed?
[14:37] <niemeyer> fwereade: I think there isn't any right now..
[14:38] <niemeyer> fwereade: I've pondered about the same thing in the context of the MachinesWatcher
[14:38] <fwereade> niemeyer, I guess that was true both before and after the loop change
[14:38] <niemeyer> fwereade: Right
[14:38] <niemeyer> fwereade: I've actually made a comment regarding this in the CL
[14:38] <niemeyer> fwereade: Dave suggested it wasn't an issue, but I'm not yet sure
[14:39] <niemeyer> fwereade: I'm tempted to drop them too
[14:39] <fwereade> niemeyer, it feels to me like it is
[14:39] <niemeyer> fwereade: If nothing else, we must handle the situation where it doesn't show up correctly
[14:39] <niemeyer> fwereade: Because it is just a perspective of timing
[14:39] <niemeyer> fwereade: If we made the same query moments afterwards, we'd see nothing
[14:40] <fwereade> niemeyer, yeah, indeed
[14:40] <fwereade> niemeyer, I guess it's best to use that style though, and fix the watchers so that mergeChanges always does the Right Thing
[14:41] <niemeyer> fwereade: +1
[14:41] <fwereade> niemeyer, the advantage of the double-loop style in RUW is that I think it *did* allow me to make useful guarantees of that nature
[14:41] <fwereade> niemeyer, anyway, shouldn't be too tricky :)
[14:41] <niemeyer> fwereade: I've been doing a few changes, btw: renaming mergeChanges to merge; getInitialEvent to initial, and pass the change itself onto initial; plus the w.out change I've mentioned
[14:42] <niemeyer> fwereade: Hmm
[14:42] <fwereade> niemeyer, those all sgtm
[14:42] <niemeyer> fwereade: I don't think so
[14:42] <niemeyer> fwereade: I mean, I don't think there were any guarantees before either
[14:42] <niemeyer> fwereade: Because events were aggregated regardless
[14:43] <fwereade> niemeyer, I *think* that because the loops in which I send and the loops in which I get scope changes are different, it all Just Works
[14:43] <fwereade> niemeyer, I don;t pick up a new scope event until I've sent the change derived from the first one
[14:43] <niemeyer> fwereade: I don't see why it makes a difference.. the code that may be executed or not is exactly the same, with the new convention or with the old one
[14:43] <fwereade> niemeyer, that change may have had any number of settings changes merged in but those are safe
[14:43] <niemeyer> fwereade: The second loop is exactly a copy with the first one with the send disabled
[14:43] <fwereade> niemeyer, not in RUW
[14:44] <niemeyer> fwereade: Which is exactly what we do in the new convention, but with less code
[14:44] <niemeyer> fwereade: Oh?
[14:44] <niemeyer> fwereade: /me looks again
[14:44] <fwereade> niemeyer, although it is just one more var to track really
[14:47] <niemeyer> fwereade: I see.. I think it's actually preferable to teach merge about how to handle the situation
[14:47] <niemeyer> fwereade: Otherwise it's unnecessarily buffering changes arbitrarily
[14:47] <fwereade> niemeyer, yeah, sounds sane
[14:48] <rogpeppe> niemeyer: ah, i think i *may* have discovered the reason why live tests are failing
[14:48] <niemeyer> rogpeppe: Sweet!
[14:48] <rogpeppe> niemeyer: just a hunch as yet
[14:49] <rogpeppe> niemeyer: but...
[14:49] <rogpeppe> niemeyer: what's the name of the public bucket containing the mongo binaries?
[14:49] <niemeyer> rogpeppe: juju-dist.. why does it matter?
[14:50] <rogpeppe> niemeyer: is it hard-coded?
[14:50] <niemeyer> rogpeppe: yes
[14:50] <rogpeppe> drat
[14:50] <niemeyer> rogpeppe: As of today
[14:50] <niemeyer> rogpeppe: It shouldn't be, but this avoids yet another refactoring without all tests green
[14:50] <rogpeppe> niemeyer: that's fine. hrmph.
[14:52] <niemeyer> fwereade: Follow up reviewed too
[14:52] <TheMue> niemeyer: test of removals in firewaller always showed an effect. the fw dislikes the service removal when it is stopped. stopping the service watcher returns an error then.
[14:52] <fwereade> niemeyer, ta
[14:53] <niemeyer> TheMue: More details please?
[14:54] <niemeyer> TheMue: If the firewaller is stopped, how can it dislike anything?
[14:54] <fwereade> niemeyer, ok, so *that* was the bit with a weird StartSync that I think is justified
[14:54] <niemeyer> fwereade: Yeah, I imagined it when reading
[14:54] <fwereade> niemeyer, Unit.Status does an alive check on the UA
[14:54] <niemeyer> fwereade: I'm just curious about how it unrolls into it
[14:54] <niemeyer> fwereade: Aha, ok.. is that all?
[14:55] <fwereade> niemeyer, Status returns "down" when the pinger is not there
[14:55] <fwereade> niemeyer, yeah, that's it
[14:55] <niemeyer> fwereade: So a suggestion: let's move the sync down to right before Status, and call Sync rather than StartSync
[14:55] <fwereade> niemeyer, ah, yeah, sounds sensible
[14:55] <fwereade> niemeyer, cheers
[14:56] <niemeyer> fwereade: Thanks!
[14:56] <niemeyer> TheMue?
[15:02] <TheMue> niemeyer: sorry, my wife called me ;)
[15:02] <TheMue> niemeyer: fw.Stop() is expected to return no error
[15:02] <TheMue> niemeyer: but if a service is removed it returns a service not found
[15:03] <TheMue> niemeyer: because during the stop all internal go routines are stopped, and there the service watchers
[15:03] <TheMue> niemeyer: and this stopping does state.Service(name) for the non-existing service
[15:03] <niemeyer> TheMue: This is a bug that should be fixed
[15:04] <TheMue> niemeyer: indeed
[15:04] <TheMue> niemeyer: so you had the right feeling about testing it
[15:05] <niemeyer> TheMue: Would you mind to review all fw call sites that grab objects, and consider the appropriate action when the respective entity isn't found?
[15:06] <niemeyer> TheMue: Happy to have that done in tiny branches that follow each other so that we have a good way to coordinate as we go
[15:06] <TheMue> niemeyer: could you please rephase "fw call sites"? thx.
[15:06] <niemeyer> TheMue: call site == a point in the code that calls something
[15:07] <TheMue> niemeyer: ah, yes. ok, will do.
[15:07] <niemeyer> TheMue: Once you have that first issue fixed, please push for review so we can talk a bit about it with more concrete logic
[15:08] <TheMue> niemeyer: ok
[15:26] <rogpeppe> niemeyer: hmm, live tests fail even though bootstrapping and deploying live work ok. looks like the provisioner never sees the new machine.
[15:27] <niemeyer> rogpeppe: How can the provisioner never see the new machine if it is the one firing off new machines
[15:28] <rogpeppe> niemeyer: it's not the one that creates the new Machine though
[15:28] <niemeyer> rogpeppe: Exactly.. and if it didn't see that machine, it wouldn't fire an instance fo rit
[15:29] <niemeyer> rogpeppe: Also, tests pass
[15:29] <rogpeppe> niemeyer: the live deploy tests are currently disabled
[15:29] <niemeyer> rogpeppe: Provisioner tests pass
[15:30] <rogpeppe> niemeyer: sure. i'm just saying what i see.
[15:30] <niemeyer> rogpeppe: Of course, and I'm just explaining that "provisioner never sees the new machine" can't be true on its own
[15:30] <niemeyer> rogpeppe: The builddb charm works
[15:30] <niemeyer> rogpeppe: Firing new machine
[15:30] <niemeyer> rogpeppe: With machiner, uniter, etc
[15:30] <rogpeppe> niemeyer: absolutely. i see that working too.
[15:30] <niemeyer> rogpeppe: That doesn't happen with a provisioner that never sees a new machine
[15:31] <rogpeppe> niemeyer: but my live test that used to work no longer works. so *something* is up.
[15:31] <rogpeppe> niemeyer: it might be the fact that the second machine is added before the provisioner comes up
[15:31] <niemeyer> rogpeppe: I'm sure..
[15:32] <niemeyer> rogpeppe: Again, tests pass..
[15:32] <niemeyer> rogpeppe: You seem to argue that the provisioner is completely broken.. I doubt it's as simple as that
[15:32] <rogpeppe> niemeyer: i'm not arguing that at all
[15:32] <rogpeppe> niemeyer: i'm saying that live tests fail that used to pass, that's all
[15:33] <rogpeppe> niemeyer: and i don't see the provisioner see the new machine, which seems to be a symptom
[15:33] <niemeyer> rogpeppe: Sorry, okay.. I don't know how to help then
[15:33] <rogpeppe> niemeyer: i'm not asking for help, just giving a status update
[15:33] <niemeyer> rogpeppe: That live tests are broken, ok :)
[15:34] <rogpeppe> niemeyer: yeah, it's weird
[15:35] <niemeyer> fwereade, rogpeppe: Regarding https://codereview.appspot.com/6571047, I really want to stop sending entities down the pipe at all
[15:36] <niemeyer> Everything is a lot simpler and more correct if we just sent the entity identification
[15:36] <rogpeppe> niemeyer: just send a change notification?
[15:36] <niemeyer> rogpeppe: Yeah, with the id/name
[15:36] <rogpeppe> niemeyer: i tend to agree.
[15:36] <niemeyer> The machines watcher was significantly simpler and more obvious to handle correctly on the other side with it
[15:37] <niemeyer> That said, I've been resisting suggesting this for now, just so we can get it all working as it used to
[15:37] <niemeyer> After we're comfortable again, I think we should change
[15:37] <fwereade> niemeyer, no strong feelings myself
[15:38] <niemeyer> This also avoids the spurious reads we have nowadays within the watcher itself
[15:38] <niemeyer> when the entity changes repeatedly without being consumed
[15:38] <niemeyer> and it also simplifies the Dead-handling logic..
[15:38] <niemeyer> Anyway, lunch time here
[15:39] <niemeyer> rogpeppe: If you're still struggling by the time I'm back, let's try to pair on it
[15:39] <rogpeppe> niemeyer: i think i might be getting somewhere now. just expressing the problem was helpful.
[15:39] <rogpeppe> niemeyer: aaargh!
[15:39] <rogpeppe> niemeyer: found it
[15:41] <rogpeppe> so frickin simple
[16:02] <platypusfriend> Greets
[16:03] <platypusfriend> I'd like to suggest that, on the https://juju.ubuntu.com/ page, under the "Try it for yourself" heading, the instructions to install Juju from the PPA don't work out of the box with Ubuntu 12.04.1
[16:04] <platypusfriend> gregkrsak@brewmaster:~$ add-apt-repository ppa:juju/pkgs
[16:04] <platypusfriend> The program 'add-apt-repository' is currently not installed.  You can install it by typing: sudo apt-get install python-software-properties
[16:04] <platypusfriend> (thanks!)
[16:18] <niemeyer> platypusfriend: kthxbye
[16:19] <niemeyer> rogpeppe: What was it?
[16:19] <rogpeppe> niemeyer: well, one problem was that i was assuming that the machine received from the machine watcher had no information content, so was reading agent tools from the original.
[16:20] <rogpeppe> niemeyer: but... that doesn't appear to have fixed the problem. we will see.
[16:20] <rogpeppe> niemeyer: am currently running a live test again
[16:24] <rogpeppe> niemeyer: hmm, looks like the machine watcher might not be sending an initial event.
[16:25] <niemeyer> rogpeppe: Indeed, I don't think it is
[16:25] <rogpeppe> niemeyer: i thought we tested for that
[16:27] <niemeyer> rogpeppe: I can fix that.. what else is using it?
[16:28] <niemeyer> Hmm
[16:28]  * rogpeppe checks
[16:28] <niemeyer> Apparently only used in tests
[16:28] <niemeyer> In two places only, one of them being the live tests
[16:28] <rogpeppe> niemeyer: that sounds about right
[16:29] <niemeyer> rogpeppe: I'm on it.. will take the chance to simplify the watcher according to the latest conventions
[16:29] <rogpeppe> niemeyer: sounds good
[16:30] <niemeyer> rogpeppe: Hah, curious
[16:30] <niemeyer> rogpeppe: If we send just the id, the initial event becomes a bit silly
[16:31] <rogpeppe> niemeyer: i'm not sure
[16:31] <rogpeppe> niemeyer: it's actually still useful, even though it carries no info content
[16:32] <rogpeppe> niemeyer: because it for a very simple pattern inside various watcher clients
[16:32] <rogpeppe> s/it/it makes/
[16:32] <niemeyer> rogpeppe: Cool, I'm not suggesting we change the convention right now either way, since we're in the middle of a huge transition
[16:32] <rogpeppe> niemeyer: +1
[16:32] <niemeyer> rogpeppe: Let's just observe the changed sites and see how they look once we do this
[16:32] <rogpeppe> niemeyer: sounds good
[16:33] <rogpeppe> niemeyer: my observation was that in quite a few places, the initial event is not acted upon any differently from a changed event, so it makes sense to handle them both in the same branch of the select statement.
[16:34] <niemeyer> rogpeppe: If that's generally the case for the entity watchers, +1
[16:34] <rogpeppe> niemeyer: so it's nice to guarantee that we get at least one event
[16:34] <niemeyer> rogpeppe: It perhaps also conveys useful information, although I'm not entirely sure:
[16:34] <niemeyer> rogpeppe: When we get the watch fired, we know we're subscribed
[16:35] <rogpeppe> niemeyer: interesting. i wonder if that's ever actually useful to know.
[16:35] <niemeyer> rogpeppe: Ah, no, sorry, it doesn't matter
[16:35] <niemeyer> rogpeppe: We provide the machine revno when watching, so there are no holes
[16:36] <rogpeppe> niemeyer: ah, so in that case the initial event *does* carry useful info
[16:36] <niemeyer> rogpeppe: ?
[16:36] <rogpeppe> niemeyer: oh, sorry, other way around
[16:36] <niemeyer> Yeah
[16:36] <rogpeppe> niemeyer: i thought you were suggesting the events would contain the revno as well as the id
[16:36] <rogpeppe> niemeyer: which may be a good idea, i suppose
[16:37] <niemeyer> rogpeppe: Nope.. not suggesting that yet, at least
[16:37] <rogpeppe> niemeyer: it kinda makes sense - you give a revno to watch from, then you're handed revnos as it changes.
[16:38] <niemeyer> rogpeppe: I'm slightly concerned that we might see code ignoring the initial watch thinking "Oh, but when the initial event arrives, the machine/unit/service hasn't yet changed"
[16:38] <niemeyer> rogpeppe: Which is not necessarily true.. let's watch out for that
[16:38] <rogpeppe> niemeyer: yeah
[16:38] <niemeyer> rogpeppe: The concept of revno is internal pretty much everywhere
[16:38] <niemeyer> rogpeppe: I'm not keen on exposing it, if possible
[16:39] <rogpeppe> niemeyer: fair enough.
[16:39] <rogpeppe> niemeyer: though doesn't the uniter make use of revnos?
[16:39] <niemeyer> rogpeppe: That where the "pretty much" comes from. The only exception is the settings version, because we have to persist them to disk.
[16:43] <rogpeppe> niemeyer: here's an idea for how an updated watcher API might work:
[16:43] <rogpeppe> http://paste.ubuntu.com/1226959/
[16:43] <rogpeppe> niemeyer: i.e. each entity watcher embeds the entity that it's watching
[16:44] <rogpeppe> niemeyer: oops, with one crucial addition: http://paste.ubuntu.com/1226963/
[16:45] <niemeyer> rogpeppe: I don't understand what this is solving
[16:45] <rogpeppe> niemeyer: it's solving, for me at any rate, the fact that i want to watch the same kind of thing on two different kinds of entity
[16:46] <rogpeppe> niemeyer: perhaps that's not a problem anywhere else though, i guess
[16:46] <rogpeppe> niemeyer: it seems kinda logical to tie the watcher together with the thing it's watching.
[16:47] <niemeyer> rogpeppe: What is the MachineUnitsWatcher going to be tied with?
[16:47] <rogpeppe> niemeyer: is MachineUnitsWatcher an entity watcher?
[16:48] <rogpeppe> niemeyer: i'm only thinking of this for things where currently we just send an instance of the object down the channel
[16:48] <niemeyer> rogpeppe: Sorry, seems like a big red-herring
[16:48] <rogpeppe> niemeyer: ok fair enough
[16:48] <rogpeppe> niemeyer: i wondered if UnitWatcher and MachineWatcher could actually be implemented by the same type, and that led me to think in this direction
[16:51] <rogpeppe> niemeyer: looking at TestWatchMachine, it looks as if it *does* test for an initial event
[16:52] <niemeyer> rogpeppe: Please leave that with me.. I'll send a branch in a moment
[16:52] <rogpeppe> niemeyer: ok
[17:08] <rogpeppe> niemeyer: i'm off now. might be able to have a look back in a bit, otherwise see ya tomorrow!
[17:13] <niemeyer> rogpeppe: have a good time there
[17:19] <niemeyer> rogpeppe: Do live tests work, btw?
[17:25] <rogpeppe> niemeyer: no, i'm waiting for your machine watcher CL
[17:25] <niemeyer> rogpeppe: Well.. this will just add an extra event
[17:25] <rogpeppe> niemeyer: i *think* that's what's stopping them passing
[17:25] <rogpeppe> niemeyer: that will be good enough
[17:26] <rogpeppe> niemeyer: currently it blocks waiting for that event and never gets it
[17:26] <niemeyer> rogpeppe: It's a spurious event.. should be trivial to just not wait for it
[17:27] <niemeyer> Either way, too late.. the watcher is ready and you're off.. I'll have a look at it later
[17:27] <rogpeppe> niemeyer: i've actually got another hour or so now
[17:27] <niemeyer> rogpeppe: Oh, okay, let me push the watcher then
[17:31] <niemeyer> rogpeppe: I don't think it's the initial event here, btw
[17:31] <niemeyer> rogpeppe: Have you changed the test so it calls Refresh?
[17:32] <rogpeppe> niemeyer: ok. i changed the test so it used the Machine that it receives on the channel
[17:32] <niemeyer> rogpeppe: That won't work.. the channel contains an id now..
[17:32] <niemeyer> rogpeppe: Just Refresh the machine
[17:32] <rogpeppe> niemeyer: ok, i'll change as needed when i merge
[17:32] <niemeyer> rogpeppe: Ok, I won't touch it
[17:33] <rogpeppe> niemeyer: sounds good
[17:33] <niemeyer> rogpeppe: You'll see why the original tests were working, btw
[17:33] <rogpeppe> niemeyer: cool
[17:33] <niemeyer> Committing & proposing
[17:33] <rogpeppe> niemeyer: i'm interested - they looked plausible!
[17:34] <niemeyer> rogpeppe: Agreed.  Two bugs coalesced for it to work.
[17:37] <niemeyer> rogpeppe:  https://codereview.appspot.com/6564049
[17:37] <rogpeppe> *click*
[17:44] <rogpeppe> niemeyer: so the test was ok, then, and the problem was that the txn-revno was out of date, so it sent an event anyway?
[17:44] <rogpeppe> niemeyer: i'm not sure i see the other bug you refer to though
[17:44] <niemeyer> rogpeppe: Right
[17:45] <niemeyer> rogpeppe: Well, the other bug is the fact it didn't send
[17:45] <niemeyer> rogpeppe: The two bugs, together, make the test pass
[17:46] <rogpeppe> niemeyer: the watcher didn't send?
[17:46] <niemeyer> rogpeppe: The initial event.. :-)
[17:46] <rogpeppe> niemeyer: ah of course!
[17:46] <rogpeppe> niemeyer: it all becomes blindingly obvious
[17:47] <rogpeppe> niemeyer: it would be nice if we could have a test that would have failed with the previous bugs.
[17:48] <niemeyer> rogpeppe: The current test fails if we fix the revno issue
[17:49] <niemeyer> rogpeppe: But it's not easy to test the fact the revno was wrong, precisely because it causes an initial event to be sent, which is the behavior we want
[17:49] <rogpeppe> niemeyer: i wondered about getting a machine from a different source than AddMachine
[17:49] <niemeyer> rogpeppe: The bug is in AddMachine
[17:49] <niemeyer> was
[17:49] <rogpeppe> niemeyer: given that there are several Machine constructors that can be bad in different ways
[17:49] <rogpeppe> niemeyer: indeed.
[17:50] <niemeyer> rogpeppe: Nope.. they are all ok, because they grab the db value
[17:50] <rogpeppe> niemeyer: if the original hadn't used AddMachine, we'd have found the bug
[17:50] <niemeyer> rogpeppe: AddMachine is special because it uses the memory value
[17:51] <rogpeppe> niemeyer: yeah, i'm just saying. maybe there should be a test that AddMachine returns exactly the same values as Machine. but that's hard to do externally.
[17:54] <niemeyer> rogpeppe: We could abuse DeepEquals for that.. it's generally a bad idea, but we can have a single trivial spot doing that for the entities, at least so we consciously know when we break that rule.
[17:58] <rogpeppe> niemeyer: i wondered about that
[17:58] <niemeyer> rogpeppe: I'll add a test
[18:05] <rogpeppe> niemeyer: one thought: is it really worth sending the machine id down the channel. we're never going to actually use it AFAICS. why not chan struct{} ?
[18:09] <niemeyer> rogpeppe: Happy to take it off while we don't care
[18:19] <Aram> niemeyer: what is it that you wanted to talk about?
[18:20] <rogpeppe> niemeyer: it would make me happy. then MachineWatcher and UnitWatcher can implement the same interface.
[18:20] <niemeyer> Aram: Isn't it quite late for you already?  If you're taking the day off, we can talk tomorrow..
[18:21] <niemeyer> rogpeppe: Cool, I'll drop it before merging
[18:21] <Aram> niemeyer: it's late but it's fine, if we talk today I can work on it tomorrow in the morning, when you'll not be here.
[18:22] <rogpeppe> niemeyer: in fact, both Machine.Watch and Unit.Watch could return the same interface type. then Machine and Unit are directly compatible for watching.
[18:23] <rogpeppe> niemeyer: the MachineWatcher type could be unexported.
[18:23] <niemeyer> Aram: I don't actually have much to talk about, I think.. I was going to bring up the auth + SSL stuff, but we don't even have the machine units watcher done yet, so that's probably the first thing to work on
[18:23] <niemeyer> Aram: I think you've seen as well discussion about the latest conventions
[18:24] <Aram> niemeyer: aah, yes. so we continue to do full document watchers or just ids?
[18:24] <niemeyer> Aram: Regarding w.out, nil, dropping the two loops, etc
[18:24] <Aram> I've seen that
[18:24] <Aram> very nice way of dropping the extra loop
[18:24] <niemeyer> Aram: Just ids, and with liveness
[18:24] <niemeyer> Aram: Similar to how the current MachinesWatcher is working
[18:25] <Aram> ok
[18:25] <niemeyer> Aram: Dead+Alive rather than added/removed
[18:25] <Aram> yeah
[18:25] <niemeyer> rogpeppe: Yeah, we can do a lot, but let's hold off a bit.. this is already going quite far
[18:26] <rogpeppe> niemeyer: cool. agreed.
[18:26] <niemeyer> I'm actually going to split this equivalence stuff in its own branch
[18:27] <rogpeppe> niemeyer: that sounds good too
[18:27] <niemeyer> I had to do changes for the charm equivalence which is unrelated to the original goal
[18:33] <niemeyer> Come on LP
[18:38] <niemeyer> rogpeppe: It's in
[18:38] <rogpeppe> niemeyer: i saw. thanks!
[18:39] <niemeyer> rogpeppe: np, will push the follow up for review onw
[18:52] <niemeyer> https://codereview.appspot.com/6566050
[18:56] <niemeyer> rogpeppe: ^
[18:56]  * rogpeppe looks
[18:58] <rogpeppe> niemeyer: LGTM
[18:59] <niemeyer> rogpeppe: Thanks!
[19:15] <rogpeppe> niemeyer: ok, i've updated the live tests for the new interface. now running them live - we'll see what happens.
[19:15] <niemeyer> rogpeppe: Fingers crossed!
[19:15] <rogpeppe> niemeyer: i've got a bus to catch in 15 minutes so if this doesn't work, it'll have to be tomorrow
[19:16]  * rogpeppe wants a connection with faster upload speed
[19:16] <niemeyer> rogpeppe: +1
[19:17] <Aram> yeah, in Romania I have 100Mbps upload for $9/month.
[19:17] <Aram> here in Austria I pay 50€ for only 10Mbps.
[19:18] <Aram> that's 71 times more expensive upload.
[19:19] <rogpeppe> Aram: here i have no option for faster upload. it's crappy copper and they've no plans to upgrade.
[19:19] <Aram> yeah, in Romania I was lucky to have fiber.
[19:20] <rogpeppe> still, it only took 3:10 to upload the tools that time
[19:20] <Aram> at some point they forgot to set speed limits for me and I have 1Gbps download/upload for months :-).
[19:21] <rogpeppe> i should do what dave does and run the live tests on ec2 itself
[19:22] <rogpeppe> gotta go, or will miss bus
[19:23] <rogpeppe> tests still waiting mongod
[19:23] <rogpeppe> niemeyer, Aram: have fun
[19:23] <Aram> cheers.
[19:31] <niemeyer> I wonder what "tests still waiting mongod" means.. It's pretty much instantaneous for me nowadays
[20:01] <hazmat> out of curiosity how big are the tools?
[20:05] <niemeyer> hazmat: Each binary is about 5M stripped
[20:06] <hazmat> niemeyer, and what's the size with symbol?
[20:06] <niemeyer> hazmat: 7MB or so
[20:06] <hazmat> niemeyer, cool, thanks
[20:06] <niemeyer> hazmat: np
[21:23] <niemeyer> Stepping out for a while.. back soon
[22:56] <fwereade> niemeyer, discussion in https://codereview.appspot.com/6567044/ ; trivial in https://codereview.appspot.com/6570050 ; it would be awesome if you could take a look at the first, in particular, if you're around at any stage
[22:57] <niemeyer> fwereade: I'm here
[22:57] <niemeyer> fwereade: Looking
[22:57] <niemeyer> fwereade: Hmm
[22:57] <niemeyer> fwereade: I've already replied to the first a while ago
[22:58] <fwereade> niemeyer, ah, sorry, missed that
[22:58] <niemeyer> fwereade: np
[22:59] <niemeyer> fwereade: LGTM on second
[22:59] <fwereade> niemeyer, hmm, ok, I see; LGTM re out = nil
[22:59] <niemeyer> fwereade: Super
[23:00] <fwereade> niemeyer, LGTM stands with the change then?
[23:00] <niemeyer> fwereade: I'll have some food while another round of live tests run
[23:00] <niemeyer> fwereade: Yep!
[23:00] <fwereade> niemeyer, sweet, the tests will look much nicer once the uniter's in
[23:00] <niemeyer> fwereade: Btw, I'd like to bring the id on machine watcher bakc
[23:01] <fwereade> niemeyer, sorry, context
[23:01] <niemeyer> fwereade: I think it was a mistake to remove it.. the first time I've tried to fix some code, it was using the return :)
[23:01] <niemeyer> fwereade: Ah, sorry
[23:01] <niemeyer> fwereade: We've dropped the result this afternoon, so it returns struct{}
[23:01] <niemeyer> fwereade: It was a candidate change, but it was a mistake.. first code I went to fix in the live tests, it was using the id of the result meaningfully
[23:02] <niemeyer> fwereade: I'll send a branch so we can bring it back.. I don't want to hack the tests more at this point
[23:02] <fwereade> niemeyer, cool, I should sleep soon but I'll be around for a few mins at least
[23:04] <fwereade> niemeyer, I'll just treat those failures as deliberate/expected
[23:05] <niemeyer> fwereade: Which failures?
[23:05] <fwereade> niemeyer
[23:05] <fwereade> cmd/jujud/provisioning_test.go:69: undefined: state
[23:05] <fwereade> # launchpad.net/juju-core/environs/jujutest
[23:05] <fwereade> environs/jujutest/livetests.go:262: m.AgentTools undefined (type struct {} has no field or method AgentTools)
[23:05] <fwereade> # launchpad.net/juju-core/environs/jujutest
[23:05] <fwereade> environs/jujutest/livetests.go:262: m.AgentTools undefined (type struct {} has no field or method AgentTools)
[23:06] <fwereade> niemeyer, I was assuming that jujud was broken deliberately to prevent ugly panics dirtying up the test log
[23:06] <niemeyer> fwereade: Yeah, this is broken and is expected.. I'm working to fix all of this
[23:06] <fwereade> niemeyer, cool
[23:06] <fwereade> niemeyer, I shall not allow them to trouble me
[23:06] <niemeyer> fwereade: https://codereview.appspot.com/6571053
[23:06] <niemeyer> fwereade: Hehe :)
[23:07] <fwereade> niemeyer, LGTM
[23:08] <niemeyer> fwereade: Cheers
[23:09] <niemeyer> fwereade: I have quite a few nice trivials on the pipeline, but I'll try to catch up with Dave after dinner
[23:09] <niemeyer> fwereade: Thanks, and have a nice sleep there
[23:09] <fwereade> niemeyer, cool, perhaps gently encourage him to fix config-get, because I think that will give us more charms to play with right away
[23:10] <niemeyer> fwereade: I think he's on it, but I'll talk to him
[23:10] <fwereade> niemeyer, tyvm
[23:10] <niemeyer> fwereade: np
[23:10] <niemeyer> Dinner time.. biab
[23:10] <fwereade> niemeyer, enjoy