| 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:26 |
| thumper | hi davecheney | 00:27 |
| thumper | I thought we were going to release as 1.11.? and get it hammered by people | 00:27 |
| 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:28 |
| davecheney | thumper: will 1.11.1 become 1.12.0 ? | 00:31 |
| davecheney | ie, should I start a 1.12. branch ? | 00:31 |
| 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:32 |
| 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:33 |
| thumper | we then have the 1.12 release tag in trunk, and working on 1.13 | 00:34 |
| thumper | davecheney: sound sane? | 00:34 |
| * 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:35 |
| 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:39 |
| thumper | davecheney: so effectively tarring up all the deps? | 00:40 |
| 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:41 |
| thumper | me nods | 00:42 |
| * davecheney wonders if lbox can do tags ... | 01:01 | |
| davecheney | aaaah, my local apt mirror is offline | 01:08 |
| 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:17 |
| davecheney | thumper: https://code.launchpad.net/~dave-cheney/juju-core/122-tag-release-1.11.1/+merge/171945 | 01:25 |
| * thumper is back | 01:30 | |
| thumper | sorry, was walking the dog | 01:30 |
| 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:31 |
| davecheney | https://code.launchpad.net/~dave-cheney/juju-core/122-tag-release-1.11.1/+merge/171945 | 01:33 |
| thumper | is says the diff is empty | 01:34 |
| thumper | is it just a tag? | 01:34 |
| davecheney | yes | 01:34 |
| thumper | lgtm | 01:34 |
| davecheney | thanks | 01:35 |
| davecheney | thumper: https://codereview.appspot.com/10725044 << bump dev version to 1.11.2 | 01:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| davecheney | understood | 01:45 |
| * davecheney crickets | 01:58 | |
| davecheney | is the bot broken ? or just slow ? | 01:58 |
| davecheney | wallyworld_: thumper can someone check the bot | 02:09 |
| davecheney | it's been an hour | 02:09 |
| 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:10 | |
| * thumper fixes some dumbness | 02:16 | |
| davecheney | still waiting ... | 02:21 |
| thumper | arse biscuits | 02:25 |
| 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:26 |
| 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:29 |
| thumper | anyone else seen this? PANIC: server_test.go:550: StoreSuite.TestBlitzKey | 02:30 |
| davecheney | i've seen a lot of panics | 02:31 |
| davecheney | that one rings a bell | 02:31 |
| thumper | davecheney: good call using the gofmt | 02:34 |
| davecheney | semantic noop | 02:34 |
| bigjools | apparently Windows 8.1 has something called "charms" ... | 02:45 |
| davecheney | ohh err | 02:46 |
| davecheney | lets call ours Lucky Charms | 02:46 |
| davecheney | oh, wait ... | 02:46 |
| 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:53 |
| thumper | davecheney: what do you need? | 02:54 |
| davecheney | dunno, bot is still be a turd | 02:54 |
| 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:55 |
| bigjools | landing bot for Launchpad | 02:56 |
| bigjools | LP's tests were 40 minutes when I started on LP, by the time I left they were ~5hours IIRC | 02:57 |
| 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:00 |
| wallyworld_ | davecheney: sorry, was eating, missed the ping. is everything resolved? | 03:01 |
| davecheney | yup | 03:01 |
| 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:02 |
| 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:03 |
| * bigjools launches unity-webapps-plugin into the neighbour's yard | 03:04 | |
| 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:10 |
| 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:49 |
| davecheney | super | 03:50 |
| davecheney | wallyworld_: new command, create-machine ? | 04:01 |
| 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:04 |
| 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:14 |
| thumper | ack | 04:24 |
| thumper | davecheney: done | 04:24 |
| * thumper reviews wallyworld_'s branch again | 04:52 | |
| davecheney | SHIT | 04:55 |
| davecheney | the PPA recipe has been using hte old cgo based goayml | 04:56 |
| wallyworld_ | davecheney: add-machine | 05:03 |
| wallyworld_ | it was create machine but someone (forget who) asked it to be changed | 05:04 |
| davecheney | wallyworld_: no probs | 05:06 |
| davecheney | so | 05:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| thumper | hah, not the right branch | 05:15 |
| * thumper EOWs | 05:15 | |
| 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:16 |
| davecheney | later | 05:22 |
| davecheney | gahhh, lp access is so slow | 05:39 |
| davecheney | i'm having to run my scripts in the states | 05:39 |
| wallyworld_ | sadly it has always been a bit slow from aus | 05:59 |
| davecheney | checkout speeds are all over the shop today | 06:00 |
| 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/ | 06:33 |
| === tasdomas_afk is now known as tasdomas | ||
| TheMue | fwereade_: ping | 08:21 |
| 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:28 |
| 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:38 |
| mattyw | fwereade_, all I can do is set it needs review or merged in lp | 08:48 |
| TheMue | fwereade_: one moment, phone ;) | 08:53 |
| fwereade_ | mattyw, ah, sorry, I'll approve it then | 08:53 |
| mattyw | fwereade_, thanks :) | 08:54 |
| fwereade_ | mattyw, done, it should land soonish | 08:54 |
| mattyw | fwereade_, thanks very much | 08:54 |
| 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:58 |
| 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 | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| * TheMue just downloads the whole stuff to OS X to build a client there | 09:10 | |
| === 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/ | ||
| TheMue | Now let's start the dependency hell ... | 09:30 |
| fwereade_ | TheMue, LGTM, just drop the redundant/confusing test (and rearrange the logic if you think it looks like a good idea) | 09:32 |
| 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:34 |
| fwereade_ | TheMue, or do I have the wrong context? | 09:35 |
| TheMue | fwereade_: aargh, no, I've mixed up two CLs | 09:36 |
| TheMue | fwereade_: ;) | 09:36 |
| TheMue | fwereade_: I should read your review before I say anything | 09:37 |
| TheMue | fwereade_: so, read it, thx for your review | 09:39 |
| 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:40 |
| TheMue | fwereade_: this one https://codereview.appspot.com/10507043/ | 09:42 |
| TheMue | Huh, all deps seem to build fine on OS X. | 09:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| fwereade_ | ;p | 09:56 |
| TheMue | *drummroll* | 10:01 |
| TheMue | Will build now ... | 10:01 |
| TheMue | Da fuck *sorry* | 10:04 |
| TheMue | the build is incredible fast (I spend it all 8 cores) | 10:05 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| rogpeppe | dimitern: please do - i'll be able to ask questions today, but not later | 10:18 |
| 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:19 |
| dimitern | rogpeppe: i looked through it, seems nice | 10:22 |
| rogpeppe | dimitern: thanks. | 10:22 |
| 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:23 |
| rogpeppe | dimitern: i'm not entirely sure i'd bother though - not sure | 10:24 |
| 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:25 |
| 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:26 |
| dimitern | rogpeppe: ok, will have a closer look at that | 10:27 |
| rogpeppe | dimitern: the api.State is kinda like the "facade facade" :-) | 10:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| dimitern | rogpeppe: at client-side? | 10:33 |
| rogpeppe | dimitern: yes | 10:33 |
| 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:34 |
| 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:36 |
| 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:37 |
| * TheMue just deploys our standard sample - via OS X | 10:38 | |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:48 |
| 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:49 |
| dimitern | rogpeppe: enjoy :) | 10:50 |
| danilos | dimitern, ok, I'll ping when I come back then :) | 10:50 |
| * TheMue -> lunch | 10:51 | |
| rogpeppe | dimitern: we'd probably provide both protocols | 10:53 |
| rogpeppe | dimitern: that's easy to do - just listen on two ports | 10:54 |
| dimitern | fwereade_: ping | 10:57 |
| fwereade_ | dimitern, pong | 11:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| dimitern | i never tried running upgrade-juju before | 11:35 |
| fwereade_ | TheMue, nice! | 11:44 |
| jtv | Thanks fwereade_ | 12:01 |
| 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:11 |
| mgz | hazmat: nope | 12:12 |
| 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:20 |
| danilos | dimitern, thanks | 12:21 |
| mgz | okay :) | 12:22 |
| 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:26 |
| === wedgwood_away is now known as wedgwood | ||
| 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:48 |
| 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:50 |
| fwereade_ | TheMue, that's the nil/nil thing isn't it | 12:51 |
| fwereade_ | TheMue, nastiest example I have yet encountered though | 12:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 12:58 |
| 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:01 |
| dimitern | fwereade_: here's what I got from live tests: http://paste.ubuntu.com/5807731/ | 13:04 |
| 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:05 |
| 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:06 |
| 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:07 | |
| dimitern | fwereade_: cheers, will do | 13:08 |
| 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:32 |
| 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 | 13:33 |
| dimitern | I already *hate* SimpleToolsFixture!! | 14:02 |
| === danilos__ is now known as danilos | ||
| 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:04 |
| 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:05 |
| dimitern | fwereade_, TheMue: are doing kanban? | 14:06 |
| fwereade_ | dimitern, yeah | 14:06 |
| dimitern | sorry, will join now | 14:06 |
| danilos | dimitern, ok, got the point :) | 14:07 |
| dimitern | danilos: sorry, but just forgot we have kanban now | 14:07 |
| 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:08 |
| danilos | dimitern, thanks | 14:09 |
| 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:32 |
| mgz | danilo: answered a query in one of your mps | 14:47 |
| mgz | will look at it in more detail later | 14:47 |
| === tasdomas is now known as tasdomas_afk | ||
| fwereade_ | danilos, reviewed | 14:56 |
| 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 | 14:57 |
| 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:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| fwereade_ | danilos, I would be +1 on that | 15:09 |
| fwereade_ | danilos, pulling it out into a little deferred helper might not be so bad tough? | 15:10 |
| danilos | fwereade_, yeah, I'll do that | 15:12 |
| danilos | fwereade_, updated all as suggested, livetests still pass, 'lbox proposed' again to update the CL :) | 15:36 |
| fwereade_ | danilos, cheers | 15:42 |
| fwereade_ | TheMue, dimitern: https://codereview.appspot.com/10751043 | 15:43 |
| TheMue | *click* | 15:45 |
| fwereade_ | danilos, reviewed again, just a couple of things | 15:51 |
| dimitern | fwereade_: whew.. done finally with the tests, will propose shortly for you to take a look, if you're still around | 16:03 |
| 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:04 |
| 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:08 |
| * dimitern on to reviews now.. | 16:15 | |
| dimitern | frankban: reviewed | 16:15 |
| TheMue | fwereade_: reviewed | 16:15 |
| dimitern | fwereade_: reviewed | 16:19 |
| === frankban_ is now known as frankban | ||
| dimitern | danilos: on to yours | 16:19 |
| 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:29 |
| dimitern | danilos: reviewed | 16:34 |
| dimitern | TheMue: ping | 16:43 |
| TheMue | dimitern: pong | 17:01 |
| TheMue | dimitern: start reviewing | 17:01 |
| dimitern | TheMue: cheers! | 17:01 |
| TheMue | dimitern: you've got a review | 17:25 |
| dimitern | TheMue: tyvm | 17:25 |
| TheMue | dimitern: so, I'll step out. enjoy next week. | 17:57 |
| dimitern | rogpeppe: wow enjoyed the sun? | 18:59 |
| 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:00 |
| 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 | 19:01 |
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!