=== gary_poster|away is now known as gary_poster [01:38] thumper: Yo [01:39] niemeyer: oh hai [01:39] I had a go question... [01:40] if you have a select and each of the cases are waiting on a channel [01:40] what is happening under the covers? [01:40] and that select is inside a for { } [01:40] like the provisioner [01:40] thumper: An epoll [01:41] thumper: Not sure if that's your question, though? [01:41] niemeyer: I was just wanting to make sure it wasn't doing stupid looping when nothing is happening [01:42] I considered wrting a test app to check, but got busy thinking of something real [01:42] thumper: Ah, no, it will block [01:42] thumper: Unless you have a default in the select loop.. then it would spin like crazy [01:42] * thumper nods [01:43] s/select loop/select clause/ [02:19] thumper: if you have a moment at some point, https://code.launchpad.net/~wallyworld/juju-core/create-machine-command/+merge/165518 [02:19] wallyworld_: sure [02:20] thumper: i didn't update machine state to include a Clean attribute. still not sure if we want that or not [02:20] wallyworld_: I'm about to email the group about my proposed machine state changes as there are a lot of them [02:21] i'm thinking if we do add it, we can change the default assignment policy [02:21] from AssignNew to AssignUnused [02:22] since we can look for a "clean" machine [02:22] right... [02:22] there is more to it though :) [02:22] which I'll be putting in the email [02:22] sure, containers complicate things [02:23] what i say above gives us the same thing as we have now [02:23] since without it, create-machine just wastes resources [02:23] wallyworld_: well, you sould be able to use --force-machine [02:23] wallyworld_: does that work? [02:23] ah,true [02:24] should work [02:24] the machine is created, spun up, and is just sitting there [02:24] with no principal units or anything running [02:24] i'll check it out [02:34] thumper: all works as expected :-) [02:46] wallyworld_: good [02:48] thumper: i think juju status should print out the constraints for the machine [02:48] right now it doesn't seem to do that [02:48] perhaps a flag [02:48] we are getting too much info by default [02:49] much more than is usually useful [02:49] you think? [02:49] i sorta like what's there now [02:50] there's only 5 lines for eacdfh machine [02:50] adding one more for constraints doesn't seem too bad === wedgwood is now known as wedgwood_away [05:25] well, that is me about done for the day [06:32] mornin' all [06:34] evening [06:51] morning [06:51] kyhwana: :-) [06:51] dimitern: hiya [06:53] rogpeppe1: hey [06:54] rogpeppe1: i couldn't finish yesterday because just as i was nearing the end and only a few more test cases were needed, i started getting test failures or panics when running the apiserver tests; but not all the time, like 1 in 10 cases [06:54] dimitern: hmm, that's not entirely surprising for that kind of logic. [06:55] dimitern: have you run it with race detection on? [06:55] rogpeppe1: yes, multiple times - no races [06:56] dimitern: well, not a memory race anyway, eh? :-) [06:56] rogpeppe1: so there are 2 kinds of failures - timeouts for the watchers (always the same - next() returns a stopped error before stopping either the server or the watcher - and in the logs i can see it is indeed getting stopped somehow) [06:58] dimitern: is that one kind of failure or two? [06:58] rogpeppe1: another issue is the pretty long and somehow not very legible panic, usually mentioning PutCharm some 50 frames down and having mgo stuff close to the top [06:58] dimitern: could you paste the panic here? [06:59] rogpeppe1: running them again [07:01] rogpeppe1: http://paste.ubuntu.com/5696111/ [07:01] dimitern: interesting, looks like a runtime bug [07:01] dimitern: you can reproduce this ok? [07:02] rogpeppe1: trying more times [07:03] rogpeppe1: how can you tell is likely a runtime bug? [07:03] dimitern: it's dying during garbage collection [07:04] rogpeppe1: wow :) these kind of things always happen to me :D [07:04] dimitern: so it seems. [07:05] dimitern: please could you try and see if you can reproduce the behaviour using gustavo's new Go-only yaml implementation [07:05] rogpeppe1: it happened again - almost the same, but trace order is changed a bit [07:06] rogpeppe1: http://paste.ubuntu.com/5696122/ [07:06] rogpeppe1: so how to get it? [07:08] dimitern: i'm just looking for it [07:10] rogpeppe1: hmm now it happens on every run - yesterday happened less often.. also it doesn't happen if I run individual tests [07:10] dimitern: https://code.launchpad.net/~niemeyer/goyaml/go-port [07:11] rogpeppe1: so what - delete the goyaml in gopath and get this instead? [07:12] dimitern: yeah - although you'll need to manually branch it into launchpad.net/goyaml [07:12] rogpeppe1: or just remove the files and replace them [07:12] dimitern: yeah, that's probably easier [07:14] morning [07:14] dimitern: fairly trivial CL: https://codereview.appspot.com/9681045 [07:14] TheMue: hiya [07:15] TheMue: hey [07:15] rogpeppe1: looking [07:17] rogpeppe1: LGTM [07:17] dimitern: ta === rogpeppe1 is now known as rogpeppe [07:18] rogpeppe: ha! i happened at first with goyaml-go, but wasn't sure it's clean, so I went in pkg/linux_*/launchpad.net/ and deleted goyaml.a [07:18] rogpeppe: now there's no panic, just some failures [07:19] dimitern: hmm. keep trying [07:19] rogpeppe: http://paste.ubuntu.com/5696153/ [07:20] dimitern: it may still be a runtime bug [07:20] dimitern: just that you're not triggering it any more for some reason [07:20] rogpeppe: oops there is it again: http://paste.ubuntu.com/5696157/ [07:20] dimitern: because i'm not sure the code path you're testing uses yaml much [07:21] dimitern: ah, good. (well, kinda :-]) [07:21] dimitern: could you push the branch - i'll see if i can reproduce [07:22] rogpeppe: sure [07:22] rogpeppe: ha! now all passed [07:22] dimitern: run it in a loop [07:23] *: any probs with the current goyaml? [07:23] rogpeppe: lp:~dimitern/juju-core/041-provisioner-api-calls [07:23] rogpeppe: how do you mean in a loop? [07:25] rogpeppe: it seems it happens in the TestOperationPerm ... except now it happened later + a failure: http://paste.ubuntu.com/5696171/ [07:26] dimitern: while true; do go test; done [07:28] rogpeppe: running [07:31] dimitern: i've just reproduced it [07:31] rogpeppe: cool [07:32] rogpeppe: w/o goyaml-go? [07:33] dimitern: no - i'll just try with non-cgo goyaml [07:34] rogpeppe: ok, if it's indeed a runtime bug now begins the tedious hunting for a minimal case to reproduce i guess.. [07:34] dimitern: yeah. [07:41] rogpeppe: while you're looking at this, i'll finish the rest of the tests, so hopefully if there's a way around the panic it'll be ready for proposing [07:41] rogpeppe: if you don't mind [07:42] dimitern: you could work against 1.0.3 for the time being [07:42] rogpeppe: does it work like that? [07:42] dimitern: it certainly should do [07:43] dimitern: we're trying to keep 1.0.3 compatibility after all [07:43] dimitern: if it doesn't, it's a bug [07:43] rogpeppe: i'm getting 1.0.3 again to try [07:43] dimitern: if you're using go from source, you can just do hg update go1.0.3 [07:44] dimitern: then run all.bash [07:45] rogpeppe: I'll put it in a separate dir and just wipe out the gopath/pkg/*, i messed it up last time i tried to setup multiple go versions + gopaths so i can switch between them easily, i'll be more careful this time [07:45] dimitern: i have an entirely separate tree for working with separate go versions [07:46] dimitern: (which is actually very useful because i can be testing against one branch while developing another) [07:46] rogpeppe: well, I tried having ~/go/ for goroot, and ~/work/go/ for gopath, but then it didn't work with emacs somehow after the raring upgrade [07:47] rogpeppe: (come to think about it, it still doesn't work - i need to run emacs from a terminal rather than from the launcher, otherwise the gopath/root i set in .bashrc are not visible [07:47] dimitern: that's not surprising. emacs won't run .bashrc [07:48] dimitern: did you try putting the settings in your .profile ? [07:48] rogpeppe: but it worked in quantal! now it cannot find gofmt etc. unless run from the shell [07:48] rogpeppe: i tried .profile, .Xsessionrc, /etc/profile, everything.. no joy [07:49] dimitern: try removing it from your .bashrc, adding it to your .profile, logging out and logging in again [07:50] dimitern: .bash_profile might work too [07:50] rogpeppe: tried that as well, just emacs somehow defies all known ways it should cooperate with my environment :) [07:50] dimitern: i'd be surprised. this is an environment-variable/shell issue, not emacs, i think [07:51] rogpeppe: well, that very well maybe, but haven't seen a problem with another app so far [07:51] dimitern: that's probably because no other app needs $GOPATH and $GOROOT [07:52] dimitern: or relies on any setting in your .bashrc, i suspect [07:52] rogpeppe: btw - if i just rm -fr $GOPATH/pkg/ and then run should work, or I should leave pkg empty? [07:52] dimitern: that should work fine. [07:52] dimitern: directories are created on demand [07:55] rogpeppe: hmm apparently goyaml-go uses go1.1 features (function ends without a return statement) [07:55] rogpeppe: switching to goyaml-c [07:55] dimitern: ha [07:59] wallyworld_: ping [07:59] hi [08:00] wallyworld_: hey, looking at create-machine [08:00] thanjs [08:00] wallyworld_: why do we need this at all? why not have an argument to deploy instead? don't we want it to be atomic? [08:00] it's part of the containerisation work [08:01] maybe read tim's email [08:01] wallyworld_: i know; i read it [08:01] wallyworld_: but still now convinced it's a good idea to have a separate command [08:01] the next step is to allow containers to be created inside a machine [08:02] wallyworld_: i see that, ok, but still - using 2 steps to deploy inside a container seems wrong [08:04] ultimately the common operation ie deploy will be atomic. this is a step along the way [08:04] rogpeppe: with go 1.0.3 i see no panics so far, but still some tests failures with the watchers (again, not on every run) [08:04] just constructing the jigsaw peices [08:04] wallyworld_: so you're saying create-machine isn't there to stay? [08:04] not sure yet [08:05] all up for prototyping and discussion [08:05] will aid in testing during the development etc [08:05] plus it ma turn out to be useful longer term, not sure yet [08:06] wallyworld_: yeah, that's just the thing - adding stuff we're not sure we need right now will surely bend the direction in the future to finding ways to use them [08:07] wallyworld_: anyway, just thinking out loud - will take my concerns to tim's email :) [08:08] fair questions. i started this work before the email. it's all very much in a state of flux [08:08] but as a developer, the ability of create machines/containers will be very usrful [08:08] wallyworld_: sure when starting on a big new feature there's always uncertainty where to begin [08:09] eg may want to spin up a few containers ahead of time [08:09] wallyworld_: i agree, but i doubt a command is the necessary for that [08:09] and then scale out later [08:09] how else would it be done if there were no command to so it [08:10] wallyworld_: you see "juju's way" of doing things afaiui is telling it what you need and letting it do it for you [08:10] wallyworld_: what mark (sabdfl) said scaling out a service + containers could be automated [08:11] sure. but having some manual control would be nice too [08:11] wallyworld_: having a service deployed on 1 machine + some containers and this is 1 unit, adding a unit could replicate that and the containers [08:12] wallyworld_: could be, not sure yet, i think it's worth some careful consideration [08:12] think of it like being able to add an existing running machine/vm to the env [08:13] it's just another tool in the kit [08:13] wallyworld_: you could do that with manual provisioning (eventually), but this is just a special case - why complicate things adding more special cases like that? [08:14] dimitern: https://code.google.com/p/go/issues/detail?id=5554 [08:16] dimitern: for me it's a useful tool. ymmv. the command bit is a small portion of the logic. i like having manual control [08:17] rogpeppe: cool! thanks for filing a bug [08:18] dimitern: i'm currently testing against tip. it's possible the problem is already fixed. [08:18] rogpeppe: so with go 1.0.3 more often than not tests pass (1 in 5 failure so far) [08:19] dimitern: i'm sure there's a problem you need to fix too :-) [08:19] dimitern: i'm not looking into it any further for the moment, because there's lots of stuff i want to get proposed today before i go away next week [08:19] rogpeppe: it'll be helpful if i manage somehow to reproduce it consistently [08:19] rogpeppe: sure [08:20] rogpeppe: but I want to propose a split of apiserver.go into multiple submodules [08:20] dimitern: different packages? [08:21] dimitern: if you're just talking about splitting the file, +1 [08:21] rogpeppe: the same package state/apiserver/ but having things like root.go, client.go, machine.go, etc. [08:21] rogpeppe: ok, i'll do it after i finish this [08:21] dimitern: i'd name all the ones implementing the actual api to start with "api" [08:22] dimitern: e.g. apiroot.go, apiclient.go, apimachine.go [08:22] dimitern: so it's easy to see which files implement the core logic [08:22] rogpeppe: also i'd like to split api_test.go into perm_test.go, machine_test.go, client_test.go, etc. [08:23] dimitern: seems reasonable [08:23] rogpeppe: i'm fine with api*.go [08:23] rogpeppe: cool [08:23] dimitern: if you do it, make it a branch which is entirely mechanical - no code changes at all, please. [08:24] dimitern: i'm not seeing any panics against tip, BTW [08:24] rogpeppe: sure, but after i'm done with this; don't want to make it harder for me to merge later [08:24] dimitern: yeah [08:25] rogpeppe: will it impede the run time too much if we split agent and client perm tests into 2 files and 2 tables? [08:26] dimitern: i'm not sure i see the point [08:27] dimitern: the point of those tests is to test permissions against the entire API surface area [08:28] dimitern: you could split the table, i suppose [08:28] rogpeppe: hmm, ok - but only perm checks should be in there; error conversion tests, bad logins, etc should be separate [08:28] dimitern: agreed [08:28] dimitern: i have some vaguely formed thoughts about how we can make the perm checks much smaller and faster [08:30] rogpeppe: oh? [08:30] rogpeppe: (while i'm at splitting stuff i might as well split apiclient to multiple files as well) [08:32] dimitern: that's a fair bit smaller - i wonder if it might be better just as two files - one for the client api and one for the agent api [08:32] dimitern: or actually [08:32] dimitern: it's perhaps good to have a 1-1 file mapping between apiserver and api [08:32] rogpeppe: exactly my point [08:32] dimitern: for the pieces implementing the api [08:32] rogpeppe: good, will do then [08:35] dimitern: i've run the apiserver tests 17 times so far against tip and no panic [08:36] rogpeppe: good! so it seems fixed [08:36] dimitern: or the bug just isn't being tickled any more [08:37] rogpeppe: well, it might also mean someone will recognize it and say it's fixed [08:38] dimitern: yeah. i'm hoping someone will say "ah, we fixed it then", and then they'll issue a new point release [08:38] wallyworld_: ping [08:39] rogpeppe: hi, i'm just about to leave for soccer [08:39] wallyworld_: v quick question [08:39] ok [08:39] wallyworld_: in environs/cloudinit, you did syslogConfigRenderer, right? [08:39] i think so, let me check [08:40] wallyworld_: is there a particular reason why the config is rendered after bootstrap-state is called? [08:40] wallyworld_: because i'm thinking about moving it earlier in the script [08:41] rogpeppe: i think it will be ok to move. i think it was put where it is because that's where some previous logging stuff was initialised [08:41] but i'm not entirely sure [08:41] wallyworld_: ok, cool [08:41] all it does anyway is write a conf file [08:41] so that can go anywhere really [08:42] wallyworld_: that's what i thought; just wanted to check there wasn't anything subtle going on. [08:42] wallyworld_: thanks [08:42] np. === ehg_ is now known as ehg [09:12] rogpeppe: [09:12] dimitern: [09:12] rogpeppe: oops, I have a question :) [09:13] dimitern: go on [09:13] rogpeppe: in this log: http://paste.ubuntu.com/5696381/ [09:14] rogpeppe: is it normal to have an Error response to the Stop request? [09:15] dimitern: i don't see that you are [09:15] dimitern: which line are you thinking is an error response to the stop request? [09:16] dimitern: i am seeing that i need to sort out the rpc logging - it's logging each message twice [09:16] rogpeppe: ah, right - [LOG] 94.86663 DEBUG rpc/jsoncodec: -> {"RequestId":4,"Error":"watcher has been stopped","ErrorCode":"stopped","Response":{}} [09:16] this is the Next response [09:16] dimitern: (i know why) [09:17] dimitern: that's a response to a Next [09:17] dimitern: note the RequestId [09:17] rogpeppe: yeah [09:18] rogpeppe: i think we have a problem with the current watcher implementation in the client, but only the environ config one fails because it needs to do extra work on marshaling/unmarshaling the AllAttrs when receiving a response [09:18] rogpeppe: it seems next should quit as soon as stop was called [09:18] rogpeppe: (the next goroutine in the client, that is) [09:18] dimitern: on the server side? [09:19] dimitern: why's that? [09:19] rogpeppe: because otherwise we have this issue [09:19] rogpeppe: and arguably it's an error to try reading a stopped watcher anyway [09:19] dimitern: perhaps you could try describing the issue and why it's happening [09:20] rogpeppe: well, i *think* as soon as stop is called the next goroutine does not exit immediately and tries to read, getting the error, and then exits, but the error is dispatcher to the client outside [09:21] rogpeppe: but really it shouldn't report that error if it knows for sure the server-side watcher was stopped [09:22] dimitern: isn't that what the ErrStillAlive check is about? [09:23] rogpeppe: if it worked i shouldn't have received anything on the in channel, right? [09:23] rogpeppe: when next encounters a stopped state [09:23] dimitern: ha, yes [09:24] dimitern: it should return after the Kill [09:24] rogpeppe: ah, I think I see the error - after w.tomb.Kill(err) i should return rather than trying the select [09:24] :) [09:24] yeah [09:26] rogpeppe: that fixed it [09:26] dimitern: cool [09:28] rogpeppe: only one things bothers me - i think it's maybe worth panicking when i cannot unmarshal the environ config i got on the in channel, rather than logging an error [09:28] dimitern: i think the watcher should die if that happens [09:29] rogpeppe: it does, but if we got that far something is very wrong, hence a panic is in order i think [09:29] dimitern: can't that happen if the server sends some dubious data back? [09:30] rogpeppe: and where did it get it from? state - so it think it's still worth panicking [09:30] dimitern: definitely not [09:30] rogpeppe: explain? [09:30] dimitern: in general we don't panic when an external data source produces something unexpected [09:30] rogpeppe: hmm [09:30] dimitern: it might be talking to a version of the API with a subtly different interface [09:31] rogpeppe: ok then, i'll leave just the error log [09:31] rogpeppe: fair point [09:31] dimitern: you don't need to log the error - you can kill the watcher with an appropriate error [09:31] dimitern: then it will be picked up as usual by the rest of the logic [09:31] dimitern: causing the agent to die, or whatever [09:31] rogpeppe: i'm killing it, and logging the error [09:32] dimitern: i'm not sure that the log is necessary, but i guess [09:32] rogpeppe: it won't hurt when debugging incompatible api server/client connections, i think [09:33] rogpeppe: btw you copied my branch when you filed the golang issue, right? [09:36] dimitern: yes [09:36] rogpeppe: cool, i'm proposing it soon [09:46] rogpeppe: so with the newly gained understanding of the api internals hopefully, i'll be able to help the other guys next week while you're gone [09:46] dimitern: that would be great, thanks [09:47] dimitern: another small CL: https://codereview.appspot.com/9710044 [09:47] * dimitern looking [09:50] rogpeppe: what's "bootstrap-state" ? [09:50] dimitern: jujud bootstrap-state [09:50] dimitern: the thing that initialises the mongo state [09:50] dimitern: and sets the initial password for the machine agent [09:50] rogpeppe: i see (never heard of it before) [09:52] rogpeppe: LGTM [09:59] rogpeppe: do you think you'd manage adding the agent API connection stuff today? [09:59] dimitern: that's the aim [10:00] dimitern: i have a branch that does it [10:00] dimitern: but there are one or two branches that need to go in first [10:00] rogpeppe: that will be awesome [10:00] dimitern: well, let's sat i have a branch that does it *in theory* :-) [10:01] rogpeppe: i was thinking once i started the api stuff i might as well do most (if not all of it), so others can concentrate on replacing state calls with api calls next week, once we have the connection [10:01] dimitern: that sounds like a good plan [10:01] dimitern: BTW the API connection stuff involved refactoring the machine agent, and it's turned out really quite nice [10:02] rogpeppe: good to hear [10:05] dimitern: did you look at the Runner CL? [10:06] dimitern: i don't think you reviewed it, which was a bit surprising :-) [10:17] rogpeppe: this one? https://codereview.appspot.com/9643043/ [10:18] dimitern: yeah [10:18] rogpeppe: I looked at it briefly, but by the time I got the time to review it it already landed :) [10:18] rogpeppe: https://codereview.appspot.com/9721043/ is ready [10:19] rogpeppe: will look at yours once more more carefully [10:19] dimitern: np. more eyes always appreciated - it's a moderately complex piece of code. [10:20] dimitern: i'm slightly surprised you've done all those api calls in one CL. i thought they might work well as many separate ones. [10:20] dimitern: it's not a particular problem, but i might not get it reviewed today [10:21] rogpeppe: they're closely related - all needed by the provisioner and really most are trivial [10:21] rogpeppe: np, go as far as you can [10:22] dimitern: i guess i just prefer separable changes to be separate :-) [10:22] rogpeppe: i guess watchers and machine calls can be separated [10:22] dimitern: that might be good, if you don't mind too much. [10:23] rogpeppe: uhh.. you're right actually - just now glanced at the diff - it's in excess of 1000 lines [10:23] dimitern: yeah, it's pretty big [10:24] rogpeppe: didn't look like that when i was doing it :) anyway - will try bzr pipes to see if i can split it easily [10:24] dimitern: you might not need pipes too much [10:24] dimitern: most of the changes are orthogonal [10:25] dimitern: if you do the commonWatcher thing first (making the EntityWatcher use it only) then all the rest are likely to be independent [10:26] rogpeppe: good point, will do [10:27] rogpeppe: ok, disregard that CL then, I'll propose it after splitting [10:28] dimitern: thanks [10:34] * dimitern hates bzr diff!!!! [10:35] ? [10:35] you know it takes arguments, right? [10:35] mgz: so i've been in this situation before [10:35] mgz: i have trunk and a branch off it [10:36] mgz: i need to see changes in a particular path between the two branches [10:36] mgz: but none of the suggested args help [10:36] mgz: tried --old trunk while on the new branch; tried -r-2, but i need a path as well, not the changes in the whole tree [10:37] mgz: tried --old trunk --new feature-branch - still frustratingly no results! [10:38] mgz: please help :) [10:39] mgz: (if it makes a difference - both branches are clean - no uncommitted changes) [10:39] hm, I'd expect --old to work [10:40] have you got qbzr intalled? [10:40] mgz: well it doesn't; yes I have qbzr [10:41] mgz: with qdiff is still the same (No changes) [10:41] mgz: all i need here is diff trunk:tip and feature:tip and show me the changes in state/api/ only [10:42] so, it works for me with standalone branches [10:42] mgz: so i can cherry pick some of them and split the feature into multiple smaller ones [10:42] but something seems to be unhappy with native colo [10:43] but, I'd expect if you cd ~ then do `bzr diff --old .../src/real/branch/location/trunk --new .../src/.../feature state/api` it'll work [10:43] mgz: here's what bzr reports: http://paste.ubuntu.com/5696558/ [10:43] mgz: ah, i'll try that [10:44] right, so try --old ~/src/juju-core/trunk --new ~//src/juju-core/041-provisioner-api-calls [10:45] there might be an issue with checkouts, I'll see if we have a bug filed [10:45] mgz: hallelujah! it works like that [10:46] mgz: although i'd expect it to work in a LW checkout as well.. [10:47] looks like bug 596785 plus bad location resolution code in the diff command [10:47] <_mup_> Bug #596785: 'bzr diff --old|new PATH' does silently exists if arg does not exist

[10:48] can you file a new bug with your symptoms please dimitern? [10:48] mgz: a new one or amend this [10:48] a new one [10:48] mgz: sure [10:49] the location code being wrong I don't see any entry for, can do both issues in one merge possibly, but might make sense to do them seperately [10:51] mgz: bzr diff --old/--new does not report and changes with a lightweight checkout of a native repo? [10:51] mgz: as summary [10:51] s/and/any/ and seems reasonable [10:52] and just end after "checkout" [10:52] mgz: not sure i get you - where's the "and" ? [10:52] mgz: ah [10:53] :) [11:01] mgz: bug 1183776 [11:01] <_mup_> Bug #1183776: bzr diff --old/--new does not report and changes with a lightweight checkout of a native repo

[11:01] thanks! [11:04] mgz: any idea how to make my life easier and cherry pick interactively what to merge? rather than having to manually edit the diff and run patch with it [11:09] dimitern, mgz: I need to step out to sign some documentation in the court, likely to not make it for the stand-up [11:09] danilos: ok [11:19] dimitern, TheMue: another small CL: https://codereview.appspot.com/9723043 [11:20] dimitern: use shelve [11:21] rogpeppe: LGTM [11:21]