[01:30] <bigjools> g'day thumper
[01:30] <thumper> hi bigjools
[01:30] <bigjools> talking to yourself all morning and I felt sorry for you
[01:31] <thumper> :)
[08:03] <jtv> fwereade: can I just run another refactoring by you that might slim down the providers a bit more and save us some time?
[08:04] <fwereade> jtv, sure, but I'm in a meeting at the moment
[08:04] <jtv> OK, I'll hang on
[08:04] <fwereade> jtv, so expect slightly slowresponses
[08:25] <jam> rvba: I think I know why lbox is creating a new Rietveld review when you submit, though I don't know how to fix it. Specifically, lbox edits the description of the merge to include the link to codereview..., Your proposals are getting a new comment, but *not* getting the description edited.
[08:27] <rvba> jam: that's right, when I run 'lbox propose' it spits out an error ("Failed to update merge proposal").
[08:30] <fwereade> jtv, I'm here now
[08:30] <jtv> fwereade: argh, just going into my standup!   Got time in half an hour?
[08:30] <fwereade> jtv, sure :)
[08:31] <jtv> Thanks!
[08:31] <TheMue> jam: as I didn't follow rog with the upgrade stuff, could you pls give a short intro into it to me?
[08:31] <jam> TheMue: basic summary, bootstrap a 1.10 system, add a couple of units to it. Then try to upgrade it to 1.11
[08:32] <TheMue> jam: and currently no issue nor card where he noted the problems? ok ...
[08:32] <jam> TheMue: so I think the test can be : juju bootstrap; juju status; juju deploy mysql; # wait for it to run; juju upgrade-juju --upload-tools
[08:33] <jam> TheMue: I believe it was pretty ad hoc testing. It came up in a meeting, so he poked at it.
[08:33] <fwereade> jam, TheMue, you should check 1.10 agents bootstrapped both with 1.10 and with trunk, upgrading to trunk in each case
[08:34] <jam> fwereade: so juju-1.10 bootstrap && juju-1.10 deploy && juju-trunk upgrade-juju --upload-tools
[08:34] <jam> as well as juju-trunk for all of those, correct?
[08:34] <TheMue> fwereade: yep, will do
[08:35] <jam> rvba: the only thing that comes to mind is when you gave lbox permissions to run as your account, it somehow didn't get the right perms. But that doesn't quite make sense, since it can post for you, I would think that means it can change things for you as well.
[08:39] <fwereade> jam, yes
[08:40] <jam> fwereade: thoughts on a name for State.Watch? that watches the same document as WatchEnvironConfig but uses a NotifyWatcher rather than putting the content into Changes()?
[08:40] <jam> current best guess was "WatchForEnvironConfigChanges" which is quite a bit more verbose than other watcher.s
[08:41] <fwereade> jam, that doesn't sound too awful -- because I think it'll be becoming plain WatchEnvironConfig once we get rid of the current implementation
[08:42] <jam> fwereade: should I be pushing to make all current WatchEnvironConfig callers do it? It seemed much larger than trying to get this other bit done.
[08:42] <jam> fwereade: fwiw, I can't see any direct testing of WatchEnvironConfig seeing changes to the environment.
[08:42] <fwereade> jam, yes but not today -- parallel implementation gets us where we need quicker
[08:42] <fwereade> jam, ha
[08:42] <jam> there is WaitForEnviron stuff in workers
[08:43] <jam> well, maybe state_test.go.
[08:43] <fwereade> jam, yeah, that looks like it does roughly the right thing
[08:45] <jam> fwereade: alternatively, I only really need WatchAPIVersion which could secretly do environ config underneath
[08:46] <fwereade> jam, sure, that'd be what you expose over the api
[08:46] <jam> fwereade: right, which means it is what I could expose on State
[08:46] <jam> and assert in the test suite
[08:46] <jam> and the implementation would be on the Environ Config doc.
[08:46] <fwereade> jam, but in state I'd rather name it after what it does today, ie watch everything in the config
[08:47] <fwereade> jam, we can filter better later behind the api
[08:47] <fwereade> jam,sane?
[08:47] <jam> fwereade: do you think we would filter in the API, or filter in the future watcher?
[08:48] <fwereade> jam, I *suspect* we'll have cause to do smarter filtering directly in state
[08:48] <fwereade> jam, but I'm agnostic really
[08:49] <jam> fwereade: from what I've read in the code, the only way to set the agent-version is to rewrite the hole Config dict. Does that match your understanding ?
[08:49] <fwereade> jam, yeah, afraid so
[08:49] <jam> (environs/jujutest/livetests.go setAgentVersion is the only place I've seen it)
[08:51] <fwereade> jam, honestly I don't actually think agent-version fits very well with the rest of environ config anyway,it's been a bit of a dumping ground
[08:52] <fwereade> jam, but as usual until it's obscured behind the api we're stuck with it
[08:55] <mgz_> go 1.1.1 for saucy built okay: https://launchpad.net/~james-page/+archive/golang-backports
[08:56] <jam> fwereade: one of the tests I'm cribbing from (state/unit_test.go TestWatchConfigSettings) has an assert that changing an object 2 times results in only OneChange.
[08:56] <jam> When I try that on an EntityWatcher, it fails
[08:56] <jam> should I be asserting that or just not worry about it
[08:56] <fwereade> jam, that is surprising to me, I think it deserves a little bit of worry
[08:57] <fwereade> jam, paste me the test you have maybe?
[08:57] <jam> fwereade: I might have just been doing it wrong. Testing again now looks like it is doing the right thing... :(
[08:58] <fwereade> jam, ok, cool :)
[09:04] <jamespage> fwereade, mgz, jam: backport of golang 1.1.1 for 12.04->13.10 - we need to put that somewhere more official for the juju-core PPA builds
[09:04] <jamespage> https://launchpad.net/~james-page/+archive/golang-backports
[09:18] <jtv> fwereade: got time for a hangout?
[09:19] <fwereade> jtv, sure
[09:20] <fwereade> jtv, would you start one please?
[09:20] <jtv> Working on it...  whom do I invite?
[09:21] <jtv> Found you!
[09:22] <jtv> fwereade: G+ says it looks like you aren't available.  It does that a lot for me.
[09:22] <jtv> Maybe I invited your wrong account after all.
[09:22] <fwereade> jtv, https://plus.google.com/hangouts/_/51118536cbb3ae1f18ea3cec8ef8be231497d69b?hl=en
[09:22] <jtv> Thanks
[09:54] <jtv> fwereade: buggeration...  once again the dummy provider is the *only* provider that doesn't play along.  I'll have to go with a "utility" Bootstrap.
[09:54] <jtv> A shame, because there already is an environs.Bootstrap and I can't just move functionality in there.
[09:55] <jtv> Although...  I guess with the dummy provider I can just see whether the changes will actually break tests.
[09:55] <fwereade> jtv, I would not object to a type switch that accommodates strange providers that want their own Bootstrap method
[09:55] <fwereade> jtv, even if doing that *just* for the dummy kinda smells
[09:55] <jtv> Positively reeks.  :)
[09:56] <fwereade> well put :)
[09:57] <fwereade> jtv, curse that dummy provider... it doesn't even properly do bootstrap *anyway* AFAIR
[09:57] <fwereade> hey ho
[09:57] <jtv> Well in that case there's hope.
[09:57] <fwereade> jtv, IIRC it has a bunch of stuff copy-pasted and then diverged from jujud bootstrap-state
[09:58]  * fwereade wonders if there's something nearby he can set fire to on general principles
[10:02] <jtv> Good thinking.  Fire helps.  Fire cleanses.
[10:43] <jam> jamespage: what does "somewhere more official" mean?
[10:43] <jam> Do you want it under ~juju/+archive/golang or something like that?
[10:43] <jamespage> something like that yes
[10:45] <jam> jamespage: Can I just copy the ones you already have?
[10:45] <mgz_> you can.
[10:46] <fwereade> jam, hey, tag vs id in the api -- does that phrase cause any immediate response?
[10:46] <fwereade> jam, some places it seems we use tags, some places ids
[10:46] <jam> fwereade: tag == Machine.Tag() or Unit.Tag()
[10:46] <jam> so you can pass one to be for any agent
[10:46] <jam> Id can only be used for a specific one in context
[10:47] <jam> fwereade: so I would use Tag unless you have a different reason to
[10:47] <fwereade> jam, sure -- I guess I'm asking why we use ids anywhere
[10:47] <jam> though it is "ok" to do stuff like GetMachine(id) because you have the context
[10:47] <jam> fwereade: hysterical raisons ?
[10:47] <fwereade> jam, that kinda works against the possibility of common reuse though
[10:48] <jam> fwereade: so IMO, I would use Tag unless you really needed something else. As tag => id is lossless
[10:48] <jam> and Id => Tag can only be done with external context.
[10:49] <fwereade> jam, technically it works both ways actually, but we're not sure it will always do so
[10:50] <jam> fwereade: from what I've seen of Id it is just an integer in a string
[10:50] <jam> Is unit Ids different?
[10:50] <fwereade> jam, or unit name, or service name, or...
[10:51] <fwereade> jam, machine, service, unit, user
[10:51] <jam> fwereade, mgz: When you get a chance, feedback on https://codereview.appspot.com/10891044/ will help me get the Worker up and running.
[10:52] <jam> fwereade: I'll note that today we have: globalKey which gives essentially the same result as Tag() except it is private and only the Presence code seems to use it
[10:52] <jam> Tag() which gives a unique and segmented identifier, but no code to actuall y invert any given Tag back into its original type
[10:52] <jam> (something that takes a Tag and gives you a UNit or Machine)
[10:52] <jam> and Id
[10:52] <fwereade> jam, globalKey is used in any collection that holds data associated with more than one type of entity
[10:52] <jam> which is pretty context sensitive, and nobody wants to inspect it.
[10:52] <jam> fwereade: but why did we reinvent globalKey calling it Tag?
[10:53] <fwereade> jam, globalKey is (1) internal and (2) a bit more complex -- relation units have globalkeys for the settings and scope collections, which don't correspond to actual entities themselves
[10:54] <fwereade> jam, tag solves roughly the same problem, but in a human-readable and externally visible context
[10:54] <jam> fwereade: anyway, all the API stuff *I* wrote uses Tag. I'd like to see more of that in the API because we defined Tag as being namespaced and unique.
[10:54] <thumper> jtv: please wait
[10:54] <fwereade> jam, great, +1
[10:54] <thumper> jtv: with the bootstrap refactoring
[10:54] <thumper> jtv: as I have some in progress
[10:55] <thumper> jtv: that I have been using wtih local provider
[10:55] <fwereade> jam, in that case I think I will be smacking some of the machiner bits around so I can move existing code into common and reuse it
[10:55] <jam> https://codereview.appspot.com/10891044/ adds the WatchForEnvironConfigChanges and hooks the UpgraderAPI to use it. Which is the last piece the actual Worker should need. Which is the next step I want to finish off.
[10:55] <fwereade> jam, dropping things like MachineLifeResults when they could just be LifeResults etc
[10:56] <jam> fwereade: sounds good to me.
[10:56] <fwereade> jam, great, thanks for the sanity check
[10:56] <jam> I was fortunate that I knew what I was working on was going to be for both Uniters and Machiners so I had to be agnostic :)
[10:56] <fwereade> jam, cool
[10:56] <jam> Though it doesn't, today, support Uniters because of that lack of Tag => agent lookup mechanism.
[10:57] <fwereade> jam, hmm, I think that does exist somewhere actually... just a mo
[10:59] <fwereade> jam, state.go:562?
[10:59] <fwereade> jam, specifically State.Authenticator, a few lines up, which uses it
[11:02] <fwereade> jam, hey, do we have a meeting now? I thought I saw it on my calendar this am but it seems to bemissing now
[11:02] <jam> fwereade: thanks, I'll keep that in mind when I enable Uniters in Upgrader. It probably holds all I need for the "are you allowed to do this" check.
[11:02] <jam> fwereade: I saw mramm mark it as removed.
[11:02] <fwereade> jam, yeah, should be
[11:02] <jam> I think he was off
[11:02] <jam> so he just cancelled it
[11:02] <fwereade> jam, ah, I thought he was coming in for it
[11:03] <fwereade> jam, still, my nose still has the same amount of skin
[11:03] <jam> fwereade: he was coming in for the "early" meetings. Apparently 11:00UTC isn't early enough.
[11:09] <mgz_> jam: reviewed
[11:13] <jam> fwereade: I don't see an exposed API in state/api/*/* that actually runs a Watcher. And the one in state/api/watcher.NotifyWatcher requires a State object.
[11:13] <jam> fwereade: am I missing something?
[11:13] <jam> I have the feeling the naming in the API is my fault
[11:13] <fwereade> jam, just a mo,let me look
[11:14] <jam> and that is the "this was copied out of state/watcher.go" without someone actually thinking it through.
[11:14] <fwereade> jam, it's a *State, not a *state.State
[11:14] <fwereade> jam, yay helpful naming
[11:15] <fwereade> jam, not sure it is your fault though
[11:15] <jam> fwereade: well I renamed it from EntityWatcher
[11:15] <fwereade> jam, I think that's a good thing though?
[11:15] <jam> but probably should have gone the route of making it an interface and leaving it an entity watcher.
[11:15] <jam> fwereade: well, it directly calls Watch inside of the loop() function
[11:15] <jam> which means I can't reuse the code for WatchAPIVersion
[11:16] <jam> fwereade: and also, no code actually calls newNotifyWatcher
[11:16] <jam> so I'm probably fine changing it :)
[11:16] <jam> fwereade: my thought was that the client API for Upgrader would be
[11:17] <fwereade> jam, I think I'm missing something myself, surely we only need one implementation client-side for anything server side with a `Changes() <-chan struct{}`?
[11:17] <jam> Upgrader.WatchAPIVersion(agentTag string) (state.NotifyWatcher, error)
[11:17] <jam> though that could certainly be api.NotifyWatcher
[11:17] <jam> because we don't want to expose "state" things in the API
[11:17] <fwereade> jam, yeah, I think it's just a NotifyWatchResults or whatever it's called?
[11:18] <jam> fwereade: well, the API on the wire returns you a NotifyWatcherId which is the handle to the specific watcher running in the API server.
[11:18] <jam> that comes from NotifyWatchResults
[11:18] <jam> you then need to turn that into something that calls Changes or Next or whatever.
[11:18] <jam> and I'd like WatchAPIVersion to do that translation for you.
[11:18] <fwereade> jam, I think that's what the state/api watcher code does
[11:19] <fwereade> jam, ah, hmm, that's still very much domain-object-centric, though, isn't it
[11:19] <jam> fwereade: it *does* but with a caveat, that it also   Call("Machine", "", "Watch", "0") for you before
[11:19] <jam> at the beginning of loop()
[11:20] <jam> While what I want is to hand something the NotifyWatcherId I already have.
[11:20] <fwereade> jam, gaah, I see
[11:20] <jam> fwereade: which I could just rip out the code as it exists, since nobody actually calls newNotifyWatcher.
[11:21] <jam> or instantiates an api.NotifyWatcher.
[11:21] <fwereade> jam, yeah, I'm pretty sure we should be constructing those with watcher ids
[11:21] <fwereade> jam, or perhaps, for clarity/consistency's sake, with a NotifyWatchResult
[11:22] <fwereade> jam, because a StringsWatchResult will need the ancillary first-event-contents data, even if there isnone for the notify watcher
[11:22] <jam> fwereade: sure. Though looking at the code, I don't think it works today.
[11:23] <jam> ah nm
[11:23] <fwereade> jam, (btw, domain-object-centricity on watcher bothers me very little, don't go fixing that unless there's a clear reason to)
[11:23] <jam> I thought it was blocking on something ,but it is blocking in a defer x
[11:23] <jam> so only on exit.
[11:23] <fwereade> jam, cool
[11:23] <jam> fwereade: well domain-object-centricty means I can't reuse it for WatchAPIVersion because you don't call Upgrader.Watch.
[11:25] <jam> But I don't really see why it needs to happen in loop() anyway, which would mean I could pull that small bit out and into either a different newDomainNotifyWatcher, or something of the sort.
[12:24] <jam> fwereade: what is the syntax for go channel receives. If you do "_, ok := <-c.Watcher.Changes()" but there is nothing in the channel, won't that still return ok = True?
[12:26] <jam> sorry, I mean it will return, but with ok= False
[12:32] <jam> fwereade: I'm trying to use your NotifyWatcherC code for the API stuff, but it is failing because it is getting an ok=false result. And I'm trying to figure out why it shouldn't return at all.
[12:34] <TheMue> ouch
[12:34] <TheMue> upgrade from 1.10 to trunk terminates all instances
[12:34] <jam> TheMue: it is supposed to restart the agents, but it is killing the AMI instances?
[12:34] <jam> that doesn't sound quite right :)
[12:35] <TheMue> jam: yes, the instances are terminating :(
[12:35] <jam> TheMue: could it be "the agents don't seem to be alive, so let me kill the instances" ?
[12:36] <TheMue> jam: dunno
[12:36] <TheMue> jam: during trunk to trunk it worked, with upgrading the agents
[12:37] <jam> TheMue: go question. When does "foo, ok := <-chan" return false for ok, only when chan is closed?
[12:38] <TheMue> jam: imho yes, passing a blocked but open channel needs a select with a default
[12:38] <TheMue> jam: will take a look
[12:39] <TheMue> jam: http://golang.org/ref/spec#Receive_operator => when closed or empty
[12:40] <TheMue> jam: eh, closed and (!) empty
[12:41] <jam> TheMue: well closed *and* empty, not closed *or* empty
[12:44] <TheMue> jam: yes, what I corrected
[12:44] <jam> TheMue: yeah. The issue is that I'm seeing the channel be closed, but it should still be alive and waiting for more stuff.
[12:44] <jam> so I'm trying to sort that out.
[12:48] <fwereade> jam, sorry, was eating
[12:48] <TheMue> jam: where?
[12:49] <fwereade> jam, paste me maybe?
[12:49] <TheMue> jam: foo, ok := <-chan blocks, ok is only false if the chan is closed
[12:49] <jam> fwereade: currently neck deep in it, and thinking the api.Watcher code wasn't sending the fields in the right location, causing the channel to become immediately killed.
[12:50] <TheMue> jam: but a select with a default allows to pass the receiving when there's nothing in the channel
[12:50] <jam> right
[12:50] <jam> TheMue: thanks. Confirms that the channel really is closed, and I need to dig into why
[12:51] <fwereade> jam, possibly resource lifetimes somehow? I think the resource registry kills stuff if the connection is closed?
[12:51] <jam> fwereade: from what I see in the DEBUG from json codec, I'm not seeing the NotifyWatcherId sent across the wire, which means it has no clue what thing I'm trying to watch.
[12:51] <jam> and thus closes the local side because of the error it go
[12:51] <jam> got
[12:52] <fwereade> jam, that sounds like it'd do it :)
[12:52] <jam> fwereade: the commonLoop code says "if I get NotFound or Stopped from any api call, kill the local session"
[12:54] <fwereade> jam, kill the watcher, right? that does sound correct
[12:59] <jam> fwereade: found it. I was passing a parameter that was locally declared, instead of the attribute of the struct. Which meant it was passing "" as the Id, which meant it wasn't getting put on the wire.
[13:02] <fwereade> jam, heh, bad luck
[13:02] <jam> :w
[13:05] <fwereade> bbiab
[13:13] <jam> fwereade: something to consider. NotifyWatcher("id").Next() is a root level function, and is not bulk. Should we instead have NotifyWatcher().Next(["id1", "id2']) or is that wrong because we want the block forever sort of functionality.
[13:13] <jam> to be honest, it scares me how many Watchers end up running for a single entity because of the layering.
[13:14] <jam> A lot of <-in => out <- transitions
[13:21] <fwereade> jam, yeah, I know what you mean
[13:22] <fwereade> jam, I am uncertain about bulk ops there -- do we return when all of them have sent? I guess we'd have to, but is that useful?
[13:22] <fwereade> jam, I'm less worried about lots of channels/goroutines
[13:22] <fwereade> jam, thousands and thousands of those *ought* to be fine
[13:23] <jam> fwereade: yeah, the block-on-one means we probably don't want bulk. Though it is the sort of one-round-trip per each thing you are watching. But we sort of *want* those to block.
[13:23] <fwereade> jam, although... maintaining *state* for all those watchers on the server side *does* bother me
[13:23] <jam> fwereade: but on another note. I have an api.NewNotifyWatcher() that can take a NotifyWatcherResult and turn it into a NotifyWatcher.
[13:23] <fwereade> jam, sweet
[13:24] <jam> fwereade: but the question is. Should you call WatchAPIVersion()=>result; NewNotifyWatcher(result)
[13:24] <jam> or
[13:24] <jam> should client.Upgrader().WatchAPIVersion() => NotifyWatcher
[13:24] <jam> fwereade: I like the later, but run into import cycles.
[13:24] <jam> because I have to import "api" in api/upgrader
[13:24] <fwereade> jam, damn,I was just about to say definitely the latter
[13:24] <jam> fwereade: that is really what I wanted, too
[13:25] <fwereade> jam, api/watcher package?
[13:25] <jam> fwereade: I can move the api code into api/watcher?
[13:25] <jam> yeah
[13:25] <jam> *sigh*
[13:25] <fwereade> jam,+1
[13:25] <jam> how many watcher.go/watcher packages will we end up with ? :)
[13:25] <jam> maybe as many as we have state
[13:25] <jam> and testing
[13:26] <fwereade> jam, it's a lesser evil than the monster packages in which everything is friends with everything else
[13:26] <fwereade> jam, kinda like python except no strong convention for "don't touch this"
[13:27] <jam> fwereade: :). The other nice thing is that api.NotifyWatcher conforms to state.NotifyWatcher (they are the same definition), which means state/testing/NotifyWatcherC works even for API watchers.
[13:27] <fwereade> jam, awesome
[13:27] <jam> It is a bit odd that it does stuff like state.FullSync() but hey, that just makes sure the api triggers, right?
[13:28] <fwereade> jam, yeah
[13:28] <fwereade> jam, ffs, MachineAgentGetMachinesResults?
[13:28] <fwereade> jam, (not you, just general bitching)
[13:32] <mgz_> is that an imperative?
[13:33] <mgz_> should it have OrElse on the end?
[13:36] <jam> fwereade: it is a bit of a mix because you are going from extreme namespacing of go, and then putting everything into one file for the API so everything gets explict namespacing.
[13:37] <jam> and the bulk logic means we end up with the struct that is one
[13:37] <jam> and the struct that traps that one with an error
[13:37] <jam> and the one that wraps that into an array
[13:37] <fwereade> jam, yeah, but it's only in one package because hurf durf small packages are bad :/
[13:37] <jam> fwereade: well, I'm running into troubles pulling out Watcher, because State/ErrCode/CodeStopped are all defined in api
[13:37] <jam> api.ErrCode
[13:38] <jam> so you can't use api.* in any subdir
[13:38] <jam> it seems a bit of a misfeature that you have to have api/params
[13:38] <jam> rather than api.Param to be used in an api.Foo.Something
[13:38] <jam> I like not having circular imports
[13:38] <fwereade> jam, yeah, +1
[13:38] <jam> but I don't quite understand where the circle is.
[13:39] <fwereade> jam, it just means that if you have people who think small packages are bad you have to put *everything* in onepackage
[13:39] <fwereade> jam, and then it's impossible to factor anything out
[13:40] <jam> fwereade: but why is it that launchpad.net/something/foo can't import launchpad.net/something ?
[13:40] <fwereade> jam, it can
[13:40] <mgz_> you may just also have circular import issues?
[13:41] <fwereade> jam, it's just some type that someone or other thought didn't deserve a package
[13:41] <fwereade> jam, and now you get to search for it
[13:42] <fwereade> jam, a thought: should those bits maybe go in params? that's the giant package that's intended to hold things relevant to both sides of the api
[13:42] <jam> mgz_: well I moved the stuff out, but AllWatcher wants direct access to Client who wants direct access to AllWatcher
[13:42] <jam> so I had to move that one back
[13:42] <fwereade> jam, not that that is itself a good solution
[13:42] <jam> but it turnsout I ended up circular
[13:42] <jam> fwereade: I moved NotifyWatcher the interface into params
[13:42] <jam> which I'm hoping is enough. But yeah, ErrCode? Maybe.
[13:42] <jam> For now, I think I sorted out the circle
[13:43] <fwereade> jam, cool
[13:43] <jam> fwereade: though I'll note
[13:43] <jam> upgrader can't import api
[13:43] <jam> because api.State.Upgrader() is a function
[13:43] <jam> so it needs access to return upgrader stuff
[13:46] <jam> so that is probably the source of most loops
[13:46] <jam> helper-functions on an api.* object, that need access to api/*/* stuff
[13:47] <jam> ugh. upgrader can't import watcher because watcher imports api and api imports upgrader because of api.State.Upgrader()
[13:48] <jam> so I'm back to moving api.ErrCode and api.Code* into api.params.
[13:48] <mgz_> I also found refactoring inside of api lots of fun :)
[13:57]  * fwereade is going through similarly rage-inducing crap himself
[14:13] <jam> fwereade: "Can we rely on resources.StopAll to clean things up?" yes, but I'd like to assert that we can do a clean Stop() in the code, and leave the StopAll to ensure the test suites stay clean.
[14:13] <jam> is that ok to land then?
[14:13] <jam> put another way, AssertStop is used to fail the test if we don't get a clean (error free) Stop9)
[14:13] <jam> StopAll is used to ensure the next test will not fail just because this one did.
[14:15] <fwereade> jam, yeah, sgtm
[14:22] <mgz_> so, the ~juju team has dave, kapil and gustavo as admins, one of them needs to create a golang ppa
[14:34] <jam> mgz_: https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.80lo482fb2s9gkfk4o8r4e70ho if you can make it
[14:34] <jam> mgz_:  I also think fwereade should be added to admins.
[14:40] <mgz_> I'm making it over jamespage's shoulder :)
[14:41] <mgz_> jam: adding fwereade sounds sensible, but also requires an admin... or the owner
[14:42] <jam> mgz_: I added you to the weekly call, so it should be in your calendar now.
[14:42] <jam> mgz_: Yeah, we need one of dave niemeyer etc to add fwereade as an Admin of the ~juju group. We just have to find them when they are online.
[14:42] <niemeyer> I'm here
[14:43] <niemeyer> fwereade is now an admin
[14:43] <jam> niemeyer: thanks !
[14:43] <fwereade> niemeyer, cheers :)
[14:43] <niemeyer> jam: np
[14:44] <jam> mgz_: I think fwereade is in that meeting as well, so you can tell him to set up the PPA :)
[14:44] <mgz_> it's already over :)
[14:45] <mgz_> fwereade: can you please add a golang ppa to ~juju, thanks!
[14:45] <fwereade> mgz_, probably, but I lack context, have been focusing elsewhere
[14:47] <mgz_> fwereade: it involves clicking some buttons on https://code.launchpad.net/~juju
[14:49] <fwereade> mgz_, does https://launchpad.net/~juju/+archive/golang look like what you need?
[14:50] <mgz_> thanks!
[14:55] <mgz_> okay, copied in the binaries and added dep from devel to golang
[14:55] <mgz_> so, ppa will build on 1.1.1 next time.
[15:17] <mgz_> so... what makes mgo.DialWithInfo hang, without ever calling the dial function...
[15:18] <mgz_> answer: giving it a hostname that does not resolve
[15:21] <mgz_> give it an ip it can't connect to instead (like 0.0.0.0) and it loops trying to connect instead
[15:42] <fwereade> jam, btw, I'm wondering a bit about AgentTools
[15:43] <fwereade> jam, what's the advantage of having all those fields vs packing them all into the normal string form?
[15:44] <fwereade> jam, not saying it's bad, just kinda wondering
[15:50] <jam> fwereade: because you don't have to then parse the string form to pull out the actual integers you need elsewhere?
[15:51] <fwereade> jam, parsing a string seems like less hassle than sending all those extra bytes every time but I guess it's debatable
[15:59] <jam> fwereade: code we have to write vs parsing we get for "free". I agree a simple string could be good. I don't really care. JSON.Unmarshal did the work for me so I don't have to see the bytes on the wire :)
[16:00] <fwereade> jam, fair enough, I have more important things to worry about than mindlessly tweaking that anyway :)
[16:03] <jam> mgz, fwereade: If you feel like reviewing: https://codereview.appspot.com/10939043/ is the refactoring of watchers into their own subpackage
[16:03] <fwereade> jam, I'd love to, the urge to set fire to things is only growing over here
[16:05] <fwereade> jam, it seems like everything is entwined with everything else but nothing uses anything resembling a common convention
[16:13] <fwereade> jam,reviewed
[19:17] <jam> fwereade: the out := w.out thing
[19:17] <jam> fwereade: the issue is that it actually triggers double out
[19:18] <jam> Because the watcher on the server side has the initial report to give
[19:18] <jam> and you are adding one on the local side.
[19:18] <jam> the original statement was "Watch calls Next" but I have no indication that that was ever true.
[19:18] <jam> AFAICT there weren't any tests of the original behavior
[22:02]  * thumper is prepared for another day talking to himself
[22:12] <ahasenack> thumper: do you usually have a team mate in your timezone?
[22:13] <thumper> ahasenack: wallyworld is normally working, and only two hours out
[22:13] <thumper> dave cheney is often around but pretty quiet
[22:13] <thumper> I really should hire another NZer just for the company
[22:14] <ahasenack> :)
[22:14] <wallyworld> thumper: you feeling lonely? awww.
[22:14] <thumper> wallyworld: you are on holiday right?
[22:14] <ahasenack> funny the "normally working" remark :)
[22:14] <wallyworld> yeah. just poked my nose in to see what's happening
[22:14] <wallyworld> gotta do painting and house stuff today. rather be working :-(
[23:38] <davecheney> i appologise for my outburst last night
[23:38] <davecheney> sorry, i'm just so dang frustrated
[23:56] <thumper> davecheney: which outburst? i thought you were reasonably measured
[23:57] <thumper> you certainly didn't leave any psychic scars or nothing :-)
[23:58] <thumper> davecheney: would you be supportive of an upload-tools that doesn't build them?
[23:59] <thumper> davecheney: I wrote myself a small script
[23:59] <thumper> to effectively find the executable path