[00:26] <davecheney> hello
[00:26] <davecheney> starting the release process now
[00:26] <davecheney> can anyone tell me what the new release number shold be ?
[00:27] <thumper> hi davecheney
[00:27] <thumper> I thought we were going to release as 1.11.? and get it hammered by people
[00:28] <thumper> and if that was good, release the same thing as 1.12
[00:28] <thumper> so until we make the decision to go with 1.12
[00:28] <thumper> I'd increment whatever the third number is
[00:28] <thumper> 1.11.2?
[00:28] <davecheney> thumper: yes, that is what I understood
[00:28] <davecheney> we'll release 1.11.1, bump to 1.11.2
[00:28] <thumper> ack
[00:28] <thumper> +1
[00:31] <davecheney> thumper: will 1.11.1 become 1.12.0 ?
[00:31] <davecheney> ie, should I start a 1.12. branch ?
[00:32] <thumper> as long as we tag the 1.11.1 release revision, we don't need to start a 1.12 branch until we are ready to release it
[00:32] <thumper> and yes, if the release is good, 1.11.1 will be rebuilt as 1.12.0
[00:32] <thumper> so branch off the 1.11.1 release tag, change the version number, rebuild
[00:32] <thumper> push to lp:juju-core/1.12
[00:32] <thumper> actually
[00:32] <thumper> probably not
[00:32] <thumper> but tag as 1.12
[00:33] <thumper> merge into trunk
[00:33] <thumper> and bump to 1.13.0
[00:33] <thumper> we are then working on 1.13 in trunk
[00:33] <thumper> that is how I'd do int
[00:33] <thumper> s/int/it/
[00:34] <thumper> we then have the 1.12 release tag in trunk, and working on 1.13
[00:34] <thumper> davecheney: sound sane?
[00:35]  * davecheney observes that tagging 1.11.1 is sort of pointless as we don't control the deps
[00:35] <davecheney> but decides not to swallow that footgun
[00:39] <davecheney> thumper: here is what I am thinking
[00:39] <davecheney> tag release
[00:39] <davecheney> then a script checks out the tag and all the other deps at thatpoint in time
[00:39] <davecheney> and produces a tagball
[00:39] <davecheney> that is what we push to lp
[00:40] <thumper> davecheney: so effectively tarring up all the deps?
[00:41] <thumper> so go install with that tar ball is repeatable?
[00:41] <thumper> as long as we ignore the core libraries?
[00:41] <davecheney> thumper: effectively making a fake gopath, bzr branch the tag, go get -v ... << will fetch all the deps at that point in time, then tar that up
[00:42] <thumper> me nods
[01:01]  * davecheney wonders if lbox can do tags ...
[01:08] <davecheney> aaaah, my local apt mirror is offline
[01:17] <davecheney> and the answer to the previous question
[01:17] <davecheney> lucky(~/src/launchpad.net/juju-core) % lbox propose
[01:17] <davecheney> error: Failed to run "bzr push": exit status 3
[01:17] <davecheney> -----
[01:17] <davecheney> bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
[01:25] <davecheney> thumper: https://code.launchpad.net/~dave-cheney/juju-core/122-tag-release-1.11.1/+merge/171945
[01:30]  * thumper is back
[01:30] <thumper> sorry, was walking the dog
[01:31] <davecheney> np
[01:31] <davecheney> looks like lbox totally choken on a tag
[01:31] <thumper> davecheney: how did you create the branch?
[01:31] <davecheney> my first attempt ?
[01:31] <davecheney> it was my trunk branch
[01:31] <davecheney> it may not have been clean
[01:31] <davecheney> try this fresh mp
[01:33] <davecheney> https://code.launchpad.net/~dave-cheney/juju-core/122-tag-release-1.11.1/+merge/171945
[01:34] <thumper> is says the diff is empty
[01:34] <thumper> is it just a tag?
[01:34] <davecheney> yes
[01:34] <thumper> lgtm
[01:35] <davecheney> thanks
[01:40] <davecheney> thumper: https://codereview.appspot.com/10725044 << bump dev version to 1.11.2
[01:41] <davecheney> thumper: question: if i'm writing a release script to build the full $GOPATH for a release
[01:41] <davecheney> why don't I just write it in a way to checkout all the deps at a specific revision
[01:42] <thumper> davecheney: that would be great if you did that
[01:42] <davecheney> just becuase the go tool doesn't support that, doesn't mean we can't manage this ourselves
[01:42]  * thumper nods
[01:42] <davecheney> thumper: understood
[01:42] <thumper> we talked about having a requirements.txt in root of trunk
[01:42] <thumper> which listed revnos/hashes etc for dependencies
[01:42] <davecheney> yeah, that never went anywaywhere
[01:43] <davecheney> thumper: will the bot process approcals/merges in order ?
[01:43] <davecheney> or should I wait til the tag branch lands ?
[01:43] <thumper> um...
[01:43] <thumper> I'm not actually sure on how it handles ordering
[01:43] <thumper> to be safer I'd wait
[01:45] <davecheney> understood
[01:58]  * davecheney crickets
[01:58] <davecheney> is the bot broken ? or just slow ?
[02:09] <davecheney> wallyworld_: thumper can someone check the bot
[02:09] <davecheney> it's been an hour
[02:10] <thumper> davecheney: did you set a commit message?
[02:10] <thumper> that is the normal blocker
[02:10]  * davecheney goes to set a commit message
[02:16]  * thumper fixes some dumbness
[02:21] <davecheney> still waiting ...
[02:25] <thumper> arse biscuits
[02:26] <thumper> davecheney: I wonder if tarmac thinks that there is nothing to do.
[02:26] <thumper> davecheney: you may want to do a pointless commit
[02:29] <thumper> davecheney: 'bzr commit -m "Tag 1.11.1 release" --unchanged
[02:29] <thumper> davecheney: then bzr push
[02:29] <davecheney> third times a charm
[02:29] <thumper> then go and reapprove to get the last revision
[02:29] <thumper> davecheney: may want to move the tag to that revision too
[02:29] <thumper> to avoid confusion :-)
[02:30] <thumper> anyone else seen this? PANIC: server_test.go:550: StoreSuite.TestBlitzKey
[02:31] <davecheney> i've seen a lot of panics
[02:31] <davecheney> that one rings a bell
[02:34] <thumper> davecheney: good call using the gofmt
[02:34] <davecheney> semantic noop
[02:45] <bigjools> apparently Windows 8.1 has something called "charms" ...
[02:46] <davecheney> ohh err
[02:46] <davecheney> lets call ours Lucky Charms
[02:46] <davecheney> oh, wait ...
[02:53] <davecheney> thumper: https://code.launchpad.net/~dave-cheney/juju-core/123-set-development-version-to-1.11.2/+merge/171946
[02:53] <davecheney> ^ can I get an approver ?
[02:53] <thumper> bigjools: what do windows charms do?
[02:53] <bigjools> NFI
[02:54] <thumper> davecheney: what do you need?
[02:54] <davecheney> dunno, bot is still be a turd
[02:55] <thumper> davecheney: you only approved it 6 minutes ago
[02:55] <thumper> sometimes the bot takes 10-15
[02:55] <bigjools> thumper: it's like PQM all over again
[02:55] <thumper> bigjools: slow tests is all
[02:55] <thumper> but yes.
[02:55] <davecheney> PQM ?
[02:56] <bigjools> landing bot for Launchpad
[02:57] <bigjools> LP's tests were 40 minutes when I started on LP, by the time I left they were ~5hours IIRC
[03:00] <davecheney> bigjools: atlassians' tests took longer than a work day to run
[03:00] <davecheney> committing fixes was an expontential time to completion
[03:00] <bigjools> the ultimate "compiling?"
[03:01] <wallyworld_> davecheney: sorry, was eating, missed the ping. is everything resolved?
[03:01] <davecheney> yup
[03:02] <davecheney> wallyworld_: should be
[03:02] <davecheney> thanks mate
[03:02] <davecheney> speaking of eating
[03:02] <davecheney> it is 13:00 local, time for carbohydrates
[03:02] <bigjools> liquid carbs?
[03:03] <davecheney> bigjools: oh my, is it friday already
[03:03] <bigjools> davecheney: seems so.  I thought Friday was yesterday and was rather disappointed when I found out it wasn't
[03:04]  * bigjools launches unity-webapps-plugin into the neighbour's yard
[03:10] <wallyworld_> thumper: maybe you could +1 this with the proviso i address the remaining couple of issues (which i am working on) and then william can +1 it tonight and i can land https://codereview.appspot.com/10447045/
[03:10] <thumper> wallyworld_: ok, I'll look in a few minutes
[03:10] <wallyworld_> no hurry. thanks
[03:49] <davecheney> wallyworld_: did you land the goose fix you mentioned on the call yesterday ?
[03:49] <wallyworld_> davecheney: sure did. i added the bug to the release notes at the same time
[03:50] <davecheney> super
[04:01] <davecheney> wallyworld_: new command, create-machine ?
[04:04] <davecheney> wallyworld_: create machine doesn't appear to be part of the juju cli
[04:04] <davecheney> just wondering if I shuld call it out in the release notes
[04:14] <davecheney> thumper: would you be a dear and delete this https://code.launchpad.net/~thumper/+recipe/juju-core-daily
[04:14] <davecheney> ^ it's no longer needed
[04:24] <thumper> ack
[04:24] <thumper> davecheney: done
[04:52]  * thumper reviews wallyworld_'s branch again
[04:55] <davecheney> SHIT
[04:56] <davecheney> the PPA recipe has been using hte old cgo based goayml
[05:03] <wallyworld_> davecheney: add-machine
[05:04] <wallyworld_> it was create machine but someone (forget who) asked it to be changed
[05:06] <davecheney> wallyworld_: no probs
[05:06] <davecheney> so
[05:07] <davecheney> add-machine can be used to prepopulate an environment with blank machines ?
[05:07] <wallyworld_> yes, or containers
[05:07] <wallyworld_> add-machine /lxc
[05:07] <wallyworld_> creates a new instances with a lxc container on it
[05:07] <wallyworld_> add-machine 1:/lxc
[05:07] <davecheney> thumper: that tag didn
[05:07] <wallyworld_> adds a lxc container to machine 1
[05:07] <davecheney> didn't tag
[05:08] <thumper> :-(
[05:08] <thumper> I don't know why
[05:08] <davecheney> bzr tags is empty
[05:08] <thumper> davecheney: I would ask jam, but he is working Sun->Thu now
[05:08] <davecheney> or not empty
[05:09] <thumper> davecheney: you could always poke on #bzr for some help
[05:09] <davecheney> oh well, we'll tag it again another time
[05:09] <davecheney> thumper: what is the bzr word for tip ?
[05:09] <thumper> tip
[05:09] <davecheney> bzr branch -r tip doens't do what I think
[05:09] <thumper> ah...
[05:09] <thumper> heh
[05:10] <thumper> um.. by default it does tip
[05:10] <thumper> bzr branch foo bar # takes tip of foo
[05:10] <thumper> -r -1 refers to the last one
[05:10] <davecheney> thanks that'll do
[05:12] <davecheney> FUCK
[05:12] <davecheney> https://code.launchpad.net/~dave-cheney/+recipe/juju-core
[05:12] <davecheney> ^ spot the problem with this build receipe
[05:12] <davecheney> hit, tarmac
[05:12] <davecheney> hint
[05:15] <thumper> hah, not the right branch
[05:15]  * thumper EOWs
[05:16] <thumper> see ya people
[05:16] <thumper> wallyworld_: you have your review
[05:16] <wallyworld_> thumper: \o/
[05:16] <thumper> and I've put a few skeleton ones up for local provider
[05:16] <wallyworld_> have a good weekend
[05:16] <wallyworld_> ok
[05:22] <davecheney> later
[05:39] <davecheney> gahhh, lp access is so slow
[05:39] <davecheney> i'm having to run my scripts in the states
[05:59] <wallyworld_> sadly it has always been a bit slow from aus
[06:00] <davecheney> checkout speeds are all over the shop today
[06:33] <davecheney> gah
[06:33] <davecheney> going to go home and try a different internet connection
[06:33] <davecheney> LP is so slow i cannot download the debs from PPA
[06:33] <davecheney> https://codereview.appspot.com/10676046/
[08:21] <TheMue> fwereade_: ping
[08:28] <mattyw> morning folks, when I try to lbox submit this https://codereview.appspot.com/10683043/ I get a readonly transport error from bazaar, anyone seen something like this?
[08:38] <fwereade_> TheMue, pong
[08:38] <fwereade_> mattyw, we're using tarmac now
[08:38] <fwereade_> mattyw, set the commit message and approve it in LP
[08:38] <mattyw> fwereade_, got it, thanks!
[08:48] <mattyw> fwereade_, all I can do is set it needs review or merged in lp
[08:53] <TheMue> fwereade_: one moment, phone ;)
[08:53] <fwereade_> mattyw, ah, sorry, I'll approve it then
[08:54] <mattyw> fwereade_, thanks :)
[08:54] <fwereade_> mattyw, done, it should land soonish
[08:54] <mattyw> fwereade_, thanks very much
[08:58] <TheMue> fwereade_: aargh, half an hour administrative call *sigh*
[08:58] <TheMue> fwereade_: just pinged you because of a method in charm/config.go
[08:59] <fwereade_> TheMue, no worries :) which method?
[08:59] <TheMue> fwereade_: there is a FilterSettings(), which is only used in state/service.go changeCharmOps()
[08:59] <fwereade_> TheMue, yep
[09:00] <fwereade_> TheMue, what's the issue with it?
[09:00] <TheMue> fwereade_: I changed in config.go the ReadConfig() that it now allows a default with empty string
[09:01] <TheMue> fwereade_: tests are also fine (you can see it in the CL)
[09:01] <TheMue> fwereade_: but in the test of the FilterSettings() an input of an empty string filters that setting to nil
[09:02] <fwereade_> TheMue, as it should, you're just fixing the default bug today
[09:02] <TheMue> fwereade_: and I'm not sure if that's correct (dimiter pointed me to that behavior)
[09:02] <fwereade_> TheMue, if defaults are making it into FilterSettings I think we're Doing It Wrong somewhere
[09:02] <TheMue> fwereade_: ah, fine, than I interpreted it correctly
[09:02] <fwereade_> TheMue, cool
[09:03] <TheMue> fwereade_: so then the CL waits for your review *smile*
[09:03] <fwereade_> TheMue, when we figure out the nice way to promote "" to equality everywhere that stuff will have to change sometime
[09:03] <fwereade_> TheMue, cool; link please?
[09:03] <TheMue> fwereade_: https://codereview.appspot.com/10682043/
[09:10]  * TheMue just downloads the whole stuff to OS X to build a client there
[09:30] <TheMue> Now let's start the dependency hell ...
[09:32] <fwereade_> TheMue, LGTM, just drop the redundant/confusing test (and rearrange the logic if you think it looks like a good idea)
[09:34] <TheMue> fwereade_: thx. the one tests uses a pre-created .juju dir, the other not, that's the difference
[09:34] <fwereade_> TheMue, huh, sorry?
[09:34] <fwereade_> TheMue, why do we hit .juju in ReadConfig?
[09:35] <fwereade_> TheMue, or do I have the wrong context?
[09:36] <TheMue> fwereade_: aargh, no, I've mixed up two CLs
[09:36] <TheMue> fwereade_: ;)
[09:37] <TheMue> fwereade_: I should read your review before I say anything
[09:39] <TheMue> fwereade_: so, read it, thx for your review
[09:40] <fwereade_> TheMue, cool (btw which was the other one? should I take a look at that? rings a bell but it's a bit mixed up with all the other CLs in my mind)
[09:42] <TheMue> fwereade_: this one https://codereview.appspot.com/10507043/
[09:48] <TheMue> Huh, all deps seem to build fine on OS X.
[09:49] <fwereade_> TheMue, nice
[09:49] <fwereade_> TheMue, about that CL you just linked
[09:49] <fwereade_> TheMue, ISTM that the two tests you wrote could just as easily be one
[09:49] <fwereade_> TheMue, (that checks both dir and file permissions)
[09:50] <fwereade_> TheMue, but that you should have a test with a pre-existing file, and a surprising dir permission, and check that the dir permission stays (but is logged) but the file is rewritten with 0600
[09:51] <TheMue> fwereade_: the one, where WriteEnvirons() creates the directory it will have 0700. otherwise it has what has been set before by the user
[09:51] <fwereade_> TheMue, quite so
[09:51] <fwereade_> TheMue, but that's not tested that I can see
[09:52] <TheMue> fwereade_: a pre-existing file will be overwritten
[09:52] <fwereade_> TheMue, yes, I think you're telling me what I told you..?
[09:53] <fwereade_> TheMue, the behaviour is fine but the tests don't exercise that path
[09:53] <TheMue> fwereade_: eh, no, i'm only wondering, because we never tested that a file is overwritten
[09:53] <TheMue> fwereade_: the tests only check the right, as this is the only changed feature
[09:54] <fwereade_> TheMue, I think that now we're messing with permissions we need to write tests that actually cover all the relevant cases
[09:54] <TheMue> fwereade_: what's indeed untested is the logging. have to see how this can be tested.
[09:54] <fwereade_> TheMue, pre-existing lack of coverage is an opportunity to improve, not a straitjacket ;)
[09:55] <fwereade_> TheMue, I'm pretty sure LoggingSuite will do the trick
[09:55] <fwereade_> TheMue, c.GetTestLog()
[09:55] <TheMue> fwereade_: ok, will change (even after your first lgtm *smile*)
[09:56] <fwereade_> ;p
[10:01] <TheMue> *drummroll*
[10:01] <TheMue> Will build now ...
[10:04] <TheMue> Da fuck *sorry*
[10:05] <TheMue> the build is incredible fast (I spend it all 8 cores)
[10:14] <rogpeppe> fwereade_, dimitern: ping
[10:14] <fwereade_> rogpeppe, heyhey, sorry I missed you last night
[10:14] <dimitern> rogpeppe: heyhey
[10:14] <rogpeppe> yo!
[10:14] <TheMue> rogpeppe: hey, the norway guy
[10:14] <TheMue> rogpeppe: you shall relax and recreate
[10:14] <dimitern> rogpeppe: is it cold out there?
[10:15] <rogpeppe> dimitern: not bad - about 18 degrees and reasonably sunny
[10:15] <dimitern> rogpeppe: nice!
[10:15] <TheMue> *sigh*
[10:15] <rogpeppe> TheMue: i intend to - we head south to the coast and a hut tomorrow for a week
[10:15] <TheMue> better than the wet 13°  here
[10:15] <rogpeppe> TheMue: well "hut" - it's probably quite ok for modern conveniences...
[10:16] <TheMue> rogpeppe: as long as it has no network ;)
[10:16] <rogpeppe> dimitern, fwereade_: did https://codereview.appspot.com/10684044 make some sort of sense?
[10:16] <rogpeppe> TheMue: indeed!
[10:17] <dimitern> rogpeppe: haven't looked yet; i'm deep in the amazon still, live testing :)
[10:17] <dimitern> rogpeppe: will take a look a bit later
[10:18] <rogpeppe> dimitern: please do - i'll be able to ask questions today, but not later
[10:19] <fwereade_> rogpeppe, only just gave it the most cursory look, but it seems very nice, thanks
[10:19] <rogpeppe> fwereade_: cool
[10:19] <rogpeppe> fwereade_: hopefully someone can take it forward from there.
[10:22] <dimitern> rogpeppe: i looked through it, seems nice
[10:22] <rogpeppe> dimitern: thanks.
[10:23] <dimitern> rogpeppe: how do i get a machiner client facade from the machineagent one?
[10:23] <danilos> how would I best test in jujutest if NewConn is not failing? Calling Status() over API returns non-nil error even if "juju status" returns an error
[10:23] <rogpeppe> dimitern: if you want, you can trivially implement a method on the client machineagent API that returns the machiner API
[10:24] <rogpeppe> dimitern: i'm not entirely sure i'd bother though - not sure
[10:25] <dimitern> rogpeppe: well, because the agent connects to state and has a different facade from its tasks, and the tasks themselves need a different facade (to emulate st *state.State objects)
[10:25] <rogpeppe> dimitern: the agent could keep the api.State around to fetch facades from
[10:26] <rogpeppe> dimitern: because in general you don't need to fetch a facade from a facade (the machineagent case is possibly the only one)
[10:26] <rogpeppe> dimitern: and unitagent, of course
[10:27] <dimitern> rogpeppe: ok, will have a closer look at that
[10:27] <rogpeppe> dimitern: the api.State is kinda like the "facade facade" :-)
[10:28] <dimitern> rogpeppe: i'm thinking wrt the deployer facade i need to implement today
[10:28] <rogpeppe> dimitern: you may well find it more convenient to add a Machiner method to MachineAgent, client-side
[10:28] <dimitern> rogpeppe: i see, yeah so far seems reasonable
[10:29] <rogpeppe> dimitern: func (a *MachineAgent) Machiner() *machiner.Machiner {return machiner.NewState(a.state)}
[10:29] <rogpeppe> dimitern: or something like that
[10:29] <dimitern> rogpeppe: yeah
[10:31] <rogpeppe> dimitern: if you went that way, you'd probably need to add all the facade methods to Machine
[10:31] <rogpeppe> MachineAgent, sorry
[10:32] <dimitern> rogpeppe: hmm.. will see about this - we want to enforce encapsulation at the type level, as agreed
[10:32] <dimitern> rogpeppe: no extra methods callable from outside
[10:32] <rogpeppe> dimitern: i wonder if it might be better just to make MachineAgent implement Call; then the client can just do machiner.NewState(machineagent) for any facade
[10:33] <dimitern> rogpeppe: at client-side?
[10:33] <rogpeppe> dimitern: yes
[10:34] <rogpeppe> dimitern: ISTM that machineagent (and unitagent) are special in that respect - it's ok for an agent to use any call appropriate for an agent, and it can use that to create facades specifically for individual workers.
[10:34] <dimitern> rogpeppe: but we'll still have only the needed methods at server-side, so you cannot call something you're not supposed to (and is used by a different worker on the same agent)
[10:36] <rogpeppe> dimitern: i guess there are two levels of security here - connection security and type security
[10:36] <dimitern> rogpeppe: yes
[10:36] <rogpeppe> dimitern: for connection security, theoretically any worker can call methods designed for any other worker
[10:36] <dimitern> rogpeppe: how so?
[10:36] <rogpeppe> dimitern: because they're all sharing the same connection
[10:37] <dimitern> rogpeppe: ah, right, but that's ok i think
[10:37] <rogpeppe> dimitern: for type security, we can make sure that, by not providing a Call method or the password to a worker, that a worker can't call any methods outside its facade
[10:37] <dimitern> rogpeppe: yeah
[10:38]  * TheMue just deploys our standard sample - via OS X
[10:39] <rogpeppe> dimitern: but the machineagent and unitagent facades are special in that they need to spawn workers themselves. so making them implement common.Caller seems like it might be a nice approach
[10:39] <rogpeppe> dimitern: which avoids the client-side machineagent and unitagent packages depending on all the other facade packages
[10:39] <dimitern> rogpeppe: will look into it
[10:40] <dimitern> rogpeppe: won't that give the agents' facades too much knowledge? i mean from the agent you can somehow screw up a worker or something
[10:41] <rogpeppe> dimitern: the agents can do anything anyway because they made the connection
[10:41] <dimitern> rogpeppe: by calling a method on the worker facade the agent is not supposed to
[10:41] <rogpeppe> dimitern: the agents must be able to create worker facades
[10:41] <rogpeppe> dimitern: so i don't think we'd be giving them any power they don't already have
[10:42] <rogpeppe> dimitern: and it's not like there's malicious code living in cmd/jujud :-)
[10:42] <dimitern> rogpeppe: yeah, but i'm thinking of the future when we'd possiblly have external agents using the api just like ours
[10:43] <rogpeppe> dimitern: i don't see the issue - if we have external agents, they have exactly the same capabilities, surely?
[10:43] <dimitern> rogpeppe: and we may very well need to think how to prevent malicious agents doing too much
[10:44] <rogpeppe> dimitern: if we want to do that, we need to do it at the connection level, not the type level
[10:44] <dimitern> rogpeppe: anyway, this is a bit on the philosophical side for now
[10:44] <rogpeppe> dimitern: what we're talking about here is type-level security, which is trivially circumventable by anyone that can make a direct websocket connection.
[10:45] <rogpeppe> dimitern: and even at the type level, the difference is just: machiner := machiner.New(machineagent) vs machiner := machineagent.Machiner()
[10:45] <dimitern> rogpeppe: not really? do the agents use websockets as well as clients?
[10:45] <rogpeppe> dimitern: yes, of course. what else would they use?
[10:46] <dimitern> rogpeppe: wasn't sure - i thought we only use WS for clients
[10:46] <rogpeppe> dimitern: (we could of course use another more efficient protocol for agents, but for the time being we just use the same thing for everyone - the API is the API)
[10:48] <dimitern> rogpeppe: yeah, we could
[10:48] <danilos> dimitern, mgz: hi, do you perhaps want to have an early stand-up call? (I may need to go out at exactly that time, though maybe not); we can potentially have it later if that suits you better as well
[10:49] <rogpeppe> dimitern: at some point i envisage possibly using encoding/gob and direct TCP connections - that would make things quite a bit more efficient, but we orient everything around json currently.
[10:49] <dimitern> danilos: i'm up for later :)
[10:49] <rogpeppe> dimitern: right, i'm off to lie in the sun :-)
[10:49] <dimitern> rogpeppe: would this lock us onto go-based agents only?
[10:50] <dimitern> rogpeppe: enjoy :)
[10:50] <danilos> dimitern, ok, I'll ping when I come back then :)
[10:51]  * TheMue -> lunch
[10:53] <rogpeppe> dimitern: we'd probably provide both protocols
[10:54] <rogpeppe> dimitern: that's easy to do - just listen on two ports
[10:57] <dimitern> fwereade_: ping
[11:29] <fwereade_> dimitern, pong
[11:30] <fwereade_> dimitern, crap, sorry, I saw that ping but got distracted in between seeing it and answering it
[11:30] <dimitern> fwereade_: my bad :/ I realized my live testing yesterday wasn't done correctly
[11:30] <fwereade_> btw, would someone please do another review of jtv's https://codereview.appspot.com/10500043/ branch?
[11:31] <fwereade_> dimitern, bah, bad luck, what was wrong?
[11:31] <dimitern> fwereade_: i didn't pass --upload-tools to bootstrap (don't know how I thought it won't be necessary and will still use the latest source)
[11:31] <fwereade_> dimitern, haha
[11:31] <fwereade_> dimitern, for compatibility checking that's good though
[11:31] <fwereade_> dimitern, bootstrap plain
[11:31] <dimitern> fwereade_: i found out today when testing the deployer before and after the change and even after the change the upstart files where suspiciously the same :)
[11:32] <fwereade_> dimitern, deploy some units and subordinates
[11:32] <fwereade_> dimitern, juju upgrade-juju --upload-tools
[11:32] <fwereade_> dimitern, cross fingers
[11:32] <dimitern> fwereade_: now i'm testing on the proper version and the good news is the new deployer seems to work ok :)
[11:33] <fwereade_> dimitern, awesome
[11:33] <fwereade_> dimitern, is it live right now?
[11:33]  * TheMue happily just bootstrapped, deployed, exposed and connected from OS X
[11:33] <dimitern> fwereade_: so the scenario is: revert to r1356 (or whatever before the change to deployer); build the scenario (wp+mysql+nrpe on machine 0); upgrade-juju - then what should I look for?
[11:33] <dimitern> fwereade_: it is
[11:34] <fwereade_> dimitern, if so you should be able to check compatibility by stopping the various upstart jobs, renaming a couple to the old format, and starting the jobs up again
[11:34] <dimitern> fwereade_: quick g+ perhaps?
[11:35] <dimitern> i never tried running upgrade-juju before
[11:44] <fwereade_> TheMue, nice!
[12:01] <jtv> Thanks fwereade_
[12:11] <hazmat> have we verified of all our dependency licenses?
[12:11] <hazmat> i just had a round with the gocurl author because there was no license specified (now apache2)
[12:12] <mgz> hazmat: nope
[12:20] <danilos> dimitern, mgz: I am still out and my laptop battery died: I've got CL up that I'd appreciate a review for :) i am on my phone now, so slow to type
[12:20] <dimitern> danilos: ok, i'll take a look shortly
[12:21] <danilos> dimitern, thanks
[12:22] <mgz> okay :)
[12:26] <fwereade_> hey, wasn't there something that shortened the timeouts on the ec2 tests? that seems not to be working, I see what look suspiciously like a bunch of 5s waits
[12:48] <jtv> Could anyone help me out with a review?  There's quite a lot of history to it now, so it may be best to read the discussion in-order before going into the diffs.  https://codereview.appspot.com/10500043/
[12:48] <jtv> allenap or rvba maybe?
[12:50] <TheMue> fwereade_: wonna see an interesting behavior: http://play.golang.org/p/XGf09f7F9v
[12:50] <wallyworld_> fwereade_: 1000th time lucky on that metadata in state branch? sorry for forgetting that client code accesses state.Machine directly. sigh
[12:50] <fwereade_> wallyworld_, bad luck, I hate writing that sort of code
[12:51] <fwereade_> TheMue, that's the nil/nil thing isn't it
[12:51] <fwereade_> TheMue, nastiest example I have yet encountered though
[12:52] <allenap> jtv: I'll give it a go.
[12:52] <TheMue> fwereade_: yeah, I wondered why a change doesn't work
[12:52] <TheMue> fwereade_: so I tried it isolated
[12:52] <allenap> TheMue: That's very surprising behaviour!
[12:53] <dimitern> TheMue: what's surprising about it?
[12:53] <allenap> TheMue: I misread, it's not surprising.
[12:53] <ahasenack> hi guys,
[12:53] <ahasenack> 	imports launchpad.net/juju-core/environs/local: import "launchpad.net/juju-core/environs/local": cannot find package
[12:53] <ahasenack> got this while updating this morning
[12:53] <ahasenack> er
[12:53] <ahasenack> line got cut off, sorry
[12:53] <allenap> TheMue: I misread the err != nil as a test for err == nil.
[12:54] <ahasenack> hm, no, it's that
[12:54] <dimitern> ahasenack: that was moved into environs/localstorage - if you pull trunk tip should be ok
[12:54] <ahasenack> I thought I was doing that
[12:54] <TheMue> allenap: oh, yes, a typo
[12:54] <ahasenack> go get -v -u <stuff>
[12:55] <ahasenack> hm, now it has different output
[12:55]  * ahasenack lets it run
[12:55] <dimitern> ahasenack: or you can just: cd $GOPATH/src/launchpad.net/juju-core/ && bzr pull
[12:55] <dimitern> fwereade_: i have a question
[12:56] <fwereade_> dimitern, oh yes?
[12:56] <dimitern> fwereade_: as the simple context is written, it'll only return stuff which match the deployer tag
[12:56] <fwereade_> dimitern, yeah, I think that's the bit that needs fixing
[12:57] <dimitern> fwereade_: but it must return both new and old ones, right? i.e. unit-wordpress-0:unit-nrpe-0 and 0:unit-wordpress-0 in the new case
[12:57] <dimitern> fwereade_: or machine-0:unit-wordpress-0 in the old case
[12:58] <fwereade_> dimitern, yeah, the new version of list has to return anything on the machine deployed either by itself or an older version of juju
[12:58] <dimitern> fwereade_: ok
[13:01] <fwereade_> dimitern, just a sec though
[13:01] <fwereade_> dimitern, are you using the principal names in the subordinate conf names in the new version as well?
[13:01] <fwereade_> dimitern, or did I misread you ^^
[13:04] <dimitern> fwereade_: here's what I got from live tests: http://paste.ubuntu.com/5807731/
[13:05] <fwereade_> dimitern, you know, I'm seriously questioning the value of those `0:`s
[13:05] <fwereade_> dimitern, would we lose anything if we just forgot about identifying the deployer at all and just used the unit tag directly?
[13:05] <fwereade_> dimitern, would be muuuch nicer, I think
[13:05] <dimitern> fwereade_: you mean jujud-unit-mysql-0.conf instead?
[13:06] <fwereade_> dimitern, yeah
[13:06] <dimitern> fwereade_: how about if we have multiple deployers running on the same machine? or they'll be in containers?
[13:06] <fwereade_> dimitern, the idea is one per machine, full stop
[13:07] <fwereade_> dimitern, local provider won't be a problem because we won't be running uncontainerized units
[13:07] <dimitern> fwereade_: seems reasonable i think
[13:07] <fwereade_> dimitern, yeah, I think that if we end up with multiple machine agents ever running in the same instance the units will be the least of our worries
[13:07] <dimitern> fwereade_: so we can make them jujud-%s.conf where %s is the deployed unit's tag
[13:07] <fwereade_> dimitern, perfect
[13:07]  * fwereade_ food
[13:08] <dimitern> fwereade_: cheers, will do
[13:32] <fwereade_> dimitern, whoa, is the branch without compatibility merged already?
[13:32] <fwereade_> dimitern, I think dave's going to cut a release shortly, we should have both changes or neither in there
[13:32] <fwereade_> dimitern, (I'm up for trying to get it in today if you think there's enough time)
[13:33] <dimitern> fwereade_: i think the release was short-lived anyway - there was some mail about it
[13:33] <dimitern> fwereade_: i'm mostly done anyway
[13:33] <fwereade_> dimitern, but .2 is coming :)
[13:33] <fwereade_> dimitern, cool
[14:02] <dimitern> I already *hate* SimpleToolsFixture!!
[14:04] <fwereade_> dimitern, if it's shit, kill it
[14:04] <dimitern> fwereade_: it's written with one deployer in mind, I have to somehow convince it to create 2 separate fixtures for each one
[14:05] <dimitern> fwereade_: it assumes too much
[14:05] <danilos> dimitern, mgz: heya, if you want to have a (final) call, I am finally back :)
[14:05] <dimitern> shit..
[14:06] <dimitern> fwereade_, TheMue: are doing kanban?
[14:06] <fwereade_> dimitern, yeah
[14:06] <dimitern> sorry, will join now
[14:07] <danilos> dimitern, ok, got the point :)
[14:07] <dimitern> danilos: sorry, but just forgot we have kanban now
[14:08] <danilos> dimitern, no worries, ping me when you are done; I'd still appreciate a review for https://codereview.appspot.com/10733044/ while I am figuring out the livetest failure I am seeing
[14:08] <dimitern> danilos: sure, once i have some time
[14:09] <danilos> dimitern, thanks
[14:32] <frankban> hi dimitern, could you please take another look at https://codereview.appspot.com/10675043/ ?
[14:32] <dimitern> frankban: will do a bit later
[14:32] <dimitern> frankban: I have to land a patch first before the release
[14:32] <frankban> dimitern: cool, thank you
[14:47] <mgz> danilo: answered a query in one of your mps
[14:47] <mgz> will look at it in more detail later
[14:56] <fwereade_> danilos, reviewed
[14:57] <danilos> fwereade_, thanks, I was looking for something like Reset() (was even considering writing Unpoison) but on the storage, not on the provider itself
[14:57] <fwereade_> danilos, np
[15:00] <danilos> fwereade_, btw, do you mean I should isolate all the tests in the livetests as well? (not done for performance reasons, since bootstrapping takes such a long time, but I'd be happy to split them out if that's what you are suggesting)
[15:00] <fwereade_> danilos, sorry, no, just the unit tests
[15:01] <danilos> fwereade_, ack
[15:01] <fwereade_> danilos, our depending on the lack of isolation between the lives tests makes me eel somewhat grubby but it's practical
[15:03] <danilos> fwereade_, well, to be honest, my tests could cause trouble as well (I should probably restore bootstrap-verify to "expected contents", or the VerifyStorage live tests might start failing when the order of execution changes)
[15:04] <danilos> fwereade_, I had that code, but it seemed unwieldy (I was saving the existing contents of the file and then writing it back at the end of the test; perhaps it's good enough to write known-good content at the end of a test, which wouldn't look so ugly and wouldn't detract as much from the code being actually tested)
[15:09] <fwereade_> danilos, I would be +1 on that
[15:10] <fwereade_> danilos, pulling it out into a little deferred helper might not be so bad tough?
[15:12] <danilos> fwereade_, yeah, I'll do that
[15:36] <danilos> fwereade_, updated all as suggested, livetests still pass, 'lbox proposed' again to update the CL :)
[15:42] <fwereade_> danilos, cheers
[15:43] <fwereade_> TheMue, dimitern: https://codereview.appspot.com/10751043
[15:45] <TheMue> *click*
[15:51] <fwereade_> danilos, reviewed again, just a couple of things
[16:03] <dimitern> fwereade_: whew.. done finally with the tests, will propose shortly for you to take a look, if you're still around
[16:04] <fwereade_> dimitern, I've got to go out for a bit now but there's half a chance that if you get another review first I'll be able to land it before dave gets there
[16:04] <fwereade_> dimitern, please mail me and him re status, I'll follow up this evening
[16:04] <dimitern> fwereade_: ok, will talk to dave as well
[16:08] <danilos> fwereade_, hum, I am a bit confused about what you want regarding error status; in one of my previous branches, you mentioned how you prefer functions/methods to return their own errors, instead of propagating returned errors, which is why I did what I did; I am fine with doing what you suggest, though, but explaining my rationale here :)
[16:15]  * dimitern on to reviews now..
[16:15] <dimitern> frankban: reviewed
[16:15] <TheMue> fwereade_: reviewed
[16:19] <dimitern> fwereade_: reviewed
[16:19] <dimitern> danilos: on to yours
[16:29] <danilos> fwereade_, this is getting ugly again (with different errors returned, I am also updating tests to cope, but it means restoring more of the state, and then I need 'restoreBootstrapVerificationFile' in unit tests as well, and...), I'll finish it later I hope (need to go out now)
[16:29] <dimitern> TheMue, fwereade_: https://codereview.appspot.com/10746044/
[16:34] <dimitern> danilos: reviewed
[16:43] <dimitern> TheMue: ping
[17:01] <TheMue> dimitern: pong
[17:01] <TheMue> dimitern: start reviewing
[17:01] <dimitern> TheMue: cheers!
[17:25] <TheMue> dimitern: you've got a review
[17:25] <dimitern> TheMue: tyvm
[17:57] <TheMue> dimitern: so, I'll step out. enjoy next week.
[18:59] <dimitern> rogpeppe: wow enjoyed the sun?
[19:00] <rogpeppe> dimitern: oh yes, had a nice swim too
[19:00] <dimitern> rogpeppe: well rested for a quick easy review ? :)
[19:00] <rogpeppe> dimitern: just came online to add more songs to my spotify playlist for the journey south
[19:01] <rogpeppe> dimitern: no reviews, i'm officially On Holiday and it would not be tolerated :-)
[19:01] <dimitern> rogpeppe: ah :) sure
[19:01] <dimitern> waiting for dave cheney to appear
[19:01] <dimitern> i need to land this shit before the release