[00:26] hello [00:26] starting the release process now [00:26] can anyone tell me what the new release number shold be ? [00:27] hi davecheney [00:27] I thought we were going to release as 1.11.? and get it hammered by people [00:28] and if that was good, release the same thing as 1.12 [00:28] so until we make the decision to go with 1.12 [00:28] I'd increment whatever the third number is [00:28] 1.11.2? [00:28] thumper: yes, that is what I understood [00:28] we'll release 1.11.1, bump to 1.11.2 [00:28] ack [00:28] +1 [00:31] thumper: will 1.11.1 become 1.12.0 ? [00:31] ie, should I start a 1.12. branch ? [00:32] 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] and yes, if the release is good, 1.11.1 will be rebuilt as 1.12.0 [00:32] so branch off the 1.11.1 release tag, change the version number, rebuild [00:32] push to lp:juju-core/1.12 [00:32] actually [00:32] probably not [00:32] but tag as 1.12 [00:33] merge into trunk [00:33] and bump to 1.13.0 [00:33] we are then working on 1.13 in trunk [00:33] that is how I'd do int [00:33] s/int/it/ [00:34] we then have the 1.12 release tag in trunk, and working on 1.13 [00:34] 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] but decides not to swallow that footgun [00:39] thumper: here is what I am thinking [00:39] tag release [00:39] then a script checks out the tag and all the other deps at thatpoint in time [00:39] and produces a tagball [00:39] that is what we push to lp [00:40] davecheney: so effectively tarring up all the deps? [00:41] so go install with that tar ball is repeatable? [00:41] as long as we ignore the core libraries? [00:41] 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] me nods [01:01] * davecheney wonders if lbox can do tags ... [01:08] aaaah, my local apt mirror is offline [01:17] and the answer to the previous question [01:17] lucky(~/src/launchpad.net/juju-core) % lbox propose [01:17] error: Failed to run "bzr push": exit status 3 [01:17] ----- [01:17] bzr: ERROR: These branches have diverged. See "bzr help diverged-branches" for more information. [01:25] thumper: https://code.launchpad.net/~dave-cheney/juju-core/122-tag-release-1.11.1/+merge/171945 [01:30] * thumper is back [01:30] sorry, was walking the dog [01:31] np [01:31] looks like lbox totally choken on a tag [01:31] davecheney: how did you create the branch? [01:31] my first attempt ? [01:31] it was my trunk branch [01:31] it may not have been clean [01:31] try this fresh mp [01:33] https://code.launchpad.net/~dave-cheney/juju-core/122-tag-release-1.11.1/+merge/171945 [01:34] is says the diff is empty [01:34] is it just a tag? [01:34] yes [01:34] lgtm [01:35] thanks [01:40] thumper: https://codereview.appspot.com/10725044 << bump dev version to 1.11.2 [01:41] thumper: question: if i'm writing a release script to build the full $GOPATH for a release [01:41] why don't I just write it in a way to checkout all the deps at a specific revision [01:42] davecheney: that would be great if you did that [01:42] just becuase the go tool doesn't support that, doesn't mean we can't manage this ourselves [01:42] * thumper nods [01:42] thumper: understood [01:42] we talked about having a requirements.txt in root of trunk [01:42] which listed revnos/hashes etc for dependencies [01:42] yeah, that never went anywaywhere [01:43] thumper: will the bot process approcals/merges in order ? [01:43] or should I wait til the tag branch lands ? [01:43] um... [01:43] I'm not actually sure on how it handles ordering [01:43] to be safer I'd wait [01:45] understood [01:58] * davecheney crickets [01:58] is the bot broken ? or just slow ? [02:09] wallyworld_: thumper can someone check the bot [02:09] it's been an hour [02:10] davecheney: did you set a commit message? [02:10] that is the normal blocker [02:10] * davecheney goes to set a commit message [02:16] * thumper fixes some dumbness [02:21] still waiting ... [02:25] arse biscuits [02:26] davecheney: I wonder if tarmac thinks that there is nothing to do. [02:26] davecheney: you may want to do a pointless commit [02:29] davecheney: 'bzr commit -m "Tag 1.11.1 release" --unchanged [02:29] davecheney: then bzr push [02:29] third times a charm [02:29] then go and reapprove to get the last revision [02:29] davecheney: may want to move the tag to that revision too [02:29] to avoid confusion :-) [02:30] anyone else seen this? PANIC: server_test.go:550: StoreSuite.TestBlitzKey [02:31] i've seen a lot of panics [02:31] that one rings a bell [02:34] davecheney: good call using the gofmt [02:34] semantic noop [02:45] apparently Windows 8.1 has something called "charms" ... [02:46] ohh err [02:46] lets call ours Lucky Charms [02:46] oh, wait ... [02:53] thumper: https://code.launchpad.net/~dave-cheney/juju-core/123-set-development-version-to-1.11.2/+merge/171946 [02:53] ^ can I get an approver ? [02:53] bigjools: what do windows charms do? [02:53] NFI [02:54] davecheney: what do you need? [02:54] dunno, bot is still be a turd [02:55] davecheney: you only approved it 6 minutes ago [02:55] sometimes the bot takes 10-15 [02:55] thumper: it's like PQM all over again [02:55] bigjools: slow tests is all [02:55] but yes. [02:55] PQM ? [02:56] landing bot for Launchpad [02:57] LP's tests were 40 minutes when I started on LP, by the time I left they were ~5hours IIRC [03:00] bigjools: atlassians' tests took longer than a work day to run [03:00] committing fixes was an expontential time to completion [03:00] the ultimate "compiling?" [03:01] davecheney: sorry, was eating, missed the ping. is everything resolved? [03:01] yup [03:02] wallyworld_: should be [03:02] thanks mate [03:02] speaking of eating [03:02] it is 13:00 local, time for carbohydrates [03:02] liquid carbs? [03:03] bigjools: oh my, is it friday already [03:03] 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] 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] wallyworld_: ok, I'll look in a few minutes [03:10] no hurry. thanks [03:49] wallyworld_: did you land the goose fix you mentioned on the call yesterday ? [03:49] davecheney: sure did. i added the bug to the release notes at the same time [03:50] super [04:01] wallyworld_: new command, create-machine ? [04:04] wallyworld_: create machine doesn't appear to be part of the juju cli [04:04] just wondering if I shuld call it out in the release notes [04:14] thumper: would you be a dear and delete this https://code.launchpad.net/~thumper/+recipe/juju-core-daily [04:14] ^ it's no longer needed [04:24] ack [04:24] davecheney: done [04:52] * thumper reviews wallyworld_'s branch again [04:55] SHIT [04:56] the PPA recipe has been using hte old cgo based goayml [05:03] davecheney: add-machine [05:04] it was create machine but someone (forget who) asked it to be changed [05:06] wallyworld_: no probs [05:06] so [05:07] add-machine can be used to prepopulate an environment with blank machines ? [05:07] yes, or containers [05:07] add-machine /lxc [05:07] creates a new instances with a lxc container on it [05:07] add-machine 1:/lxc [05:07] thumper: that tag didn [05:07] adds a lxc container to machine 1 [05:07] didn't tag [05:08] :-( [05:08] I don't know why [05:08] bzr tags is empty [05:08] davecheney: I would ask jam, but he is working Sun->Thu now [05:08] or not empty [05:09] davecheney: you could always poke on #bzr for some help [05:09] oh well, we'll tag it again another time [05:09] thumper: what is the bzr word for tip ? [05:09] tip [05:09] bzr branch -r tip doens't do what I think [05:09] ah... [05:09] heh [05:10] um.. by default it does tip [05:10] bzr branch foo bar # takes tip of foo [05:10] -r -1 refers to the last one [05:10] thanks that'll do [05:12] FUCK [05:12] https://code.launchpad.net/~dave-cheney/+recipe/juju-core [05:12] ^ spot the problem with this build receipe [05:12] hit, tarmac [05:12] hint [05:15] hah, not the right branch [05:15] * thumper EOWs [05:16] see ya people [05:16] wallyworld_: you have your review [05:16] thumper: \o/ [05:16] and I've put a few skeleton ones up for local provider [05:16] have a good weekend [05:16] ok [05:22] later [05:39] gahhh, lp access is so slow [05:39] i'm having to run my scripts in the states [05:59] sadly it has always been a bit slow from aus [06:00] checkout speeds are all over the shop today [06:33] gah [06:33] going to go home and try a different internet connection [06:33] LP is so slow i cannot download the debs from PPA [06:33] https://codereview.appspot.com/10676046/ === tasdomas_afk is now known as tasdomas [08:21] fwereade_: ping [08:28] 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] TheMue, pong [08:38] mattyw, we're using tarmac now [08:38] mattyw, set the commit message and approve it in LP [08:38] fwereade_, got it, thanks! [08:48] fwereade_, all I can do is set it needs review or merged in lp [08:53] fwereade_: one moment, phone ;) [08:53] mattyw, ah, sorry, I'll approve it then [08:54] fwereade_, thanks :) [08:54] mattyw, done, it should land soonish [08:54] fwereade_, thanks very much [08:58] fwereade_: aargh, half an hour administrative call *sigh* [08:58] fwereade_: just pinged you because of a method in charm/config.go [08:59] TheMue, no worries :) which method? [08:59] fwereade_: there is a FilterSettings(), which is only used in state/service.go changeCharmOps() [08:59] TheMue, yep [09:00] TheMue, what's the issue with it? [09:00] fwereade_: I changed in config.go the ReadConfig() that it now allows a default with empty string [09:01] fwereade_: tests are also fine (you can see it in the CL) [09:01] fwereade_: but in the test of the FilterSettings() an input of an empty string filters that setting to nil [09:02] TheMue, as it should, you're just fixing the default bug today [09:02] fwereade_: and I'm not sure if that's correct (dimiter pointed me to that behavior) [09:02] TheMue, if defaults are making it into FilterSettings I think we're Doing It Wrong somewhere [09:02] fwereade_: ah, fine, than I interpreted it correctly [09:02] TheMue, cool [09:03] fwereade_: so then the CL waits for your review *smile* [09:03] TheMue, when we figure out the nice way to promote "" to equality everywhere that stuff will have to change sometime [09:03] TheMue, cool; link please? [09:03] fwereade_: https://codereview.appspot.com/10682043/ [09:10] * TheMue just downloads the whole stuff to OS X to build a client there === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: - | Bugs: 7 Critical, 84 High - https://bugs.launchpad.net/juju-core/ [09:30] Now let's start the dependency hell ... [09:32] TheMue, LGTM, just drop the redundant/confusing test (and rearrange the logic if you think it looks like a good idea) [09:34] fwereade_: thx. the one tests uses a pre-created .juju dir, the other not, that's the difference [09:34] TheMue, huh, sorry? [09:34] TheMue, why do we hit .juju in ReadConfig? [09:35] TheMue, or do I have the wrong context? [09:36] fwereade_: aargh, no, I've mixed up two CLs [09:36] fwereade_: ;) [09:37] fwereade_: I should read your review before I say anything [09:39] fwereade_: so, read it, thx for your review [09:40] 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] fwereade_: this one https://codereview.appspot.com/10507043/ [09:48] Huh, all deps seem to build fine on OS X. [09:49] TheMue, nice [09:49] TheMue, about that CL you just linked [09:49] TheMue, ISTM that the two tests you wrote could just as easily be one [09:49] TheMue, (that checks both dir and file permissions) [09:50] 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] 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] TheMue, quite so [09:51] TheMue, but that's not tested that I can see [09:52] fwereade_: a pre-existing file will be overwritten [09:52] TheMue, yes, I think you're telling me what I told you..? [09:53] TheMue, the behaviour is fine but the tests don't exercise that path [09:53] fwereade_: eh, no, i'm only wondering, because we never tested that a file is overwritten [09:53] fwereade_: the tests only check the right, as this is the only changed feature [09:54] TheMue, I think that now we're messing with permissions we need to write tests that actually cover all the relevant cases [09:54] fwereade_: what's indeed untested is the logging. have to see how this can be tested. [09:54] TheMue, pre-existing lack of coverage is an opportunity to improve, not a straitjacket ;) [09:55] TheMue, I'm pretty sure LoggingSuite will do the trick [09:55] TheMue, c.GetTestLog() [09:55] fwereade_: ok, will change (even after your first lgtm *smile*) [09:56] ;p [10:01] *drummroll* [10:01] Will build now ... [10:04] Da fuck *sorry* [10:05] the build is incredible fast (I spend it all 8 cores) [10:14] fwereade_, dimitern: ping [10:14] rogpeppe, heyhey, sorry I missed you last night [10:14] rogpeppe: heyhey [10:14] yo! [10:14] rogpeppe: hey, the norway guy [10:14] rogpeppe: you shall relax and recreate [10:14] rogpeppe: is it cold out there? [10:15] dimitern: not bad - about 18 degrees and reasonably sunny [10:15] rogpeppe: nice! [10:15] *sigh* [10:15] TheMue: i intend to - we head south to the coast and a hut tomorrow for a week [10:15] better than the wet 13° here [10:15] TheMue: well "hut" - it's probably quite ok for modern conveniences... [10:16] rogpeppe: as long as it has no network ;) [10:16] dimitern, fwereade_: did https://codereview.appspot.com/10684044 make some sort of sense? [10:16] TheMue: indeed! [10:17] rogpeppe: haven't looked yet; i'm deep in the amazon still, live testing :) [10:17] rogpeppe: will take a look a bit later [10:18] dimitern: please do - i'll be able to ask questions today, but not later [10:19] rogpeppe, only just gave it the most cursory look, but it seems very nice, thanks [10:19] fwereade_: cool [10:19] fwereade_: hopefully someone can take it forward from there. [10:22] rogpeppe: i looked through it, seems nice [10:22] dimitern: thanks. [10:23] rogpeppe: how do i get a machiner client facade from the machineagent one? [10:23] 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] dimitern: if you want, you can trivially implement a method on the client machineagent API that returns the machiner API [10:24] dimitern: i'm not entirely sure i'd bother though - not sure [10:25] 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] dimitern: the agent could keep the api.State around to fetch facades from [10:26] 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] dimitern: and unitagent, of course [10:27] rogpeppe: ok, will have a closer look at that [10:27] dimitern: the api.State is kinda like the "facade facade" :-) [10:28] rogpeppe: i'm thinking wrt the deployer facade i need to implement today [10:28] dimitern: you may well find it more convenient to add a Machiner method to MachineAgent, client-side [10:28] rogpeppe: i see, yeah so far seems reasonable [10:29] dimitern: func (a *MachineAgent) Machiner() *machiner.Machiner {return machiner.NewState(a.state)} [10:29] dimitern: or something like that [10:29] rogpeppe: yeah [10:31] dimitern: if you went that way, you'd probably need to add all the facade methods to Machine [10:31] MachineAgent, sorry [10:32] rogpeppe: hmm.. will see about this - we want to enforce encapsulation at the type level, as agreed [10:32] rogpeppe: no extra methods callable from outside [10:32] 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] rogpeppe: at client-side? [10:33] dimitern: yes [10:34] 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] 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] dimitern: i guess there are two levels of security here - connection security and type security [10:36] rogpeppe: yes [10:36] dimitern: for connection security, theoretically any worker can call methods designed for any other worker [10:36] rogpeppe: how so? [10:36] dimitern: because they're all sharing the same connection [10:37] rogpeppe: ah, right, but that's ok i think [10:37] 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] rogpeppe: yeah [10:38] * TheMue just deploys our standard sample - via OS X [10:39] 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] dimitern: which avoids the client-side machineagent and unitagent packages depending on all the other facade packages [10:39] rogpeppe: will look into it [10:40] 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] dimitern: the agents can do anything anyway because they made the connection [10:41] rogpeppe: by calling a method on the worker facade the agent is not supposed to [10:41] dimitern: the agents must be able to create worker facades [10:41] dimitern: so i don't think we'd be giving them any power they don't already have [10:42] dimitern: and it's not like there's malicious code living in cmd/jujud :-) [10:42] rogpeppe: yeah, but i'm thinking of the future when we'd possiblly have external agents using the api just like ours [10:43] dimitern: i don't see the issue - if we have external agents, they have exactly the same capabilities, surely? [10:43] rogpeppe: and we may very well need to think how to prevent malicious agents doing too much [10:44] dimitern: if we want to do that, we need to do it at the connection level, not the type level [10:44] rogpeppe: anyway, this is a bit on the philosophical side for now [10:44] 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] dimitern: and even at the type level, the difference is just: machiner := machiner.New(machineagent) vs machiner := machineagent.Machiner() [10:45] rogpeppe: not really? do the agents use websockets as well as clients? [10:45] dimitern: yes, of course. what else would they use? [10:46] rogpeppe: wasn't sure - i thought we only use WS for clients [10:46] 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] rogpeppe: yeah, we could [10:48] 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] 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] danilos: i'm up for later :) [10:49] dimitern: right, i'm off to lie in the sun :-) [10:49] rogpeppe: would this lock us onto go-based agents only? [10:50] rogpeppe: enjoy :) [10:50] dimitern, ok, I'll ping when I come back then :) [10:51] * TheMue -> lunch [10:53] dimitern: we'd probably provide both protocols [10:54] dimitern: that's easy to do - just listen on two ports [10:57] fwereade_: ping [11:29] dimitern, pong [11:30] dimitern, crap, sorry, I saw that ping but got distracted in between seeing it and answering it [11:30] fwereade_: my bad :/ I realized my live testing yesterday wasn't done correctly [11:30] btw, would someone please do another review of jtv's https://codereview.appspot.com/10500043/ branch? [11:31] dimitern, bah, bad luck, what was wrong? [11:31] 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] dimitern, haha [11:31] dimitern, for compatibility checking that's good though [11:31] dimitern, bootstrap plain [11:31] 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] dimitern, deploy some units and subordinates [11:32] dimitern, juju upgrade-juju --upload-tools [11:32] dimitern, cross fingers [11:32] fwereade_: now i'm testing on the proper version and the good news is the new deployer seems to work ok :) [11:33] dimitern, awesome [11:33] dimitern, is it live right now? [11:33] * TheMue happily just bootstrapped, deployed, exposed and connected from OS X [11:33] 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] fwereade_: it is [11:34] 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] fwereade_: quick g+ perhaps? [11:35] i never tried running upgrade-juju before [11:44] TheMue, nice! [12:01] Thanks fwereade_ [12:11] have we verified of all our dependency licenses? [12:11] i just had a round with the gocurl author because there was no license specified (now apache2) [12:12] hazmat: nope [12:20] 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] danilos: ok, i'll take a look shortly [12:21] dimitern, thanks [12:22] okay :) [12:26] 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 === wedgwood_away is now known as wedgwood [12:48] 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] allenap or rvba maybe? [12:50] fwereade_: wonna see an interesting behavior: http://play.golang.org/p/XGf09f7F9v [12:50] fwereade_: 1000th time lucky on that metadata in state branch? sorry for forgetting that client code accesses state.Machine directly. sigh [12:50] wallyworld_, bad luck, I hate writing that sort of code [12:51] TheMue, that's the nil/nil thing isn't it [12:51] TheMue, nastiest example I have yet encountered though [12:52] jtv: I'll give it a go. [12:52] fwereade_: yeah, I wondered why a change doesn't work [12:52] fwereade_: so I tried it isolated [12:52] TheMue: That's very surprising behaviour! [12:53] TheMue: what's surprising about it? [12:53] TheMue: I misread, it's not surprising. [12:53] hi guys, [12:53] imports launchpad.net/juju-core/environs/local: import "launchpad.net/juju-core/environs/local": cannot find package [12:53] got this while updating this morning [12:53] er [12:53] line got cut off, sorry [12:53] TheMue: I misread the err != nil as a test for err == nil. [12:54] hm, no, it's that [12:54] ahasenack: that was moved into environs/localstorage - if you pull trunk tip should be ok [12:54] I thought I was doing that [12:54] allenap: oh, yes, a typo [12:54] go get -v -u