[01:50] davecheney, the newer samsung ssds (830?) are 7mm [01:51] hazmat: yeah, i'll have to get one of those [01:51] hazmat: for a moment I considered taking the metal case off my sandforce [01:51] but only for a moment [06:30] davecheney, fwereade, rogpeppe: Morning. [06:30] TheMue, heyhey [06:30] and everyone else :) [06:32] fwereade: o/ [06:33] bigjools, heyhey [06:33] who do I bug to get my branches reviewed today? :) [06:34] bigjools, consider me bugged, I'll do that now :) [06:34] tip top, thanks [06:43] bigjools, one minor on https://code.launchpad.net/~julian-edwards/juju/maas-provider-non-mandatory-port/+merge/107577 [06:43] yup? [06:43] bigjools, just _s for unused vars [06:44] bigjools, otherwise both LGTM [06:44] hazmat, ping [06:44] fwereade: is that some juju convention? [06:44] (for reference) [06:45] bigjools, my heart says it is, but I couldn't point you to a document saying so [06:45] heh [06:45] fwereade: so: _s, port, _s = connect_call.args [06:45] ? [06:46] bigjools, soory, _ [06:46] bigjools, I should have said `_`s or something [06:46] right, makes more sense now! [06:47] fwereade: ok change pushed up, thanks muchly [06:47] bigjools, also I'm not sure what the current datekeeper rules are for python; I'll have a word with hazmat when he's around and either extract more approves if required, or just merge them [06:47] you will land them right? [06:48] gatekeeper [06:49] bigjools, (I should probably just land them but I'm reluctant to come charging back into the python without checking) [06:49] * bigjools nods [06:59] bcsaller, ping [07:00] fwereade, pong [07:14] fwereade: rogpeppe TheMue does anyone have any comments about testing commands and package main_test ? [07:15] hazmat, sorry: what are the current landing requirements for juju? bigjools has a couple of patches I'm happy with myself... what else should be done before landing? [07:16] fwereade, the sru just landed [07:16] for the connect args, i think in this case its actually more helpful to have the args documented.. its a completely mocked situation [07:17] davecheney, I'm not sure my own preferences are useful... main_test seems to me like the obvious and sane thing to do but if it's flaky I guess we should do things differently [07:17] hazmat, heh, sorry [07:17] fwereade, and those params are never checked anywhere else in the codebase [07:17] davecheney: Not yet. So far I had no main commands to test. [07:17] so its completely unclear what they are if their ellidded [07:17] bigjools, ^ sorry [07:19] bigjools, actually i'd take the reverse notion.. and actually verify those values [07:19] fwereade: for a long time gotest didn't work with main packages [07:19] since their not really checked otherwise [07:19] which is the root cause of this bug [07:20] as they are the end of the line, dependency wise [07:20] all the other code i've found that does test main, tests it inside package main [07:20] i don't think there is a problem doing unit tests inside the package you are testing [07:20] * hazmat checks tests_auth [07:21] davecheney, putting the tests in the package you're testing feels icky to me; but like I said, if main_test is flaky and not expected to be fixed any time soon, I guess we should just change them [07:23] fwereade: you aren't putting them in the same package, well, only when testing, but there is no other way to test unexported functions [07:24] anyway, i've got to go [07:24] i'll see you on the flip side [07:26] fwereade, trunk is green for this fix [07:26] fwiw [07:29] hazmat, ok then, I'll land them both once the change you asked for is done [07:29] hazmat, cheers [07:29] fwereade, thanks [07:36] fwereade, TheMue, hazmat: mornin' all [07:37] rogpeppe, heyhey [07:37] g'night all [07:45] hazmat: ok I'll reverse the last commit [07:45] I did think it was rather odd to remove useful variable names :) [07:46] when their well known and unused, we do tend to elide them.. but this is a special case.. since their effectively unknown. [07:47] well they are test case logs [07:47] the other ones are tested elsewhere [07:48] hazmat: ok pushed up [07:48] bigjools, are they? :-) [07:48] bigjools, i couldn't find anywhere else where args was looked at [07:49] bigjools, thanks [07:50] I t hought I'd seen it somewhere [07:50] my brain ceased to function 30 minutes ago, it's been a long day [07:51] hazmat: ah just saw your paste, I'll poke that in too, one sec [07:53] cool [07:53] * hazmat gives up on going back to sleep [07:53] and pushed [07:54] * bigjools looks forward to a merge email [08:53] bigjools, shouldn't this also do port 443 for https? [08:58] fwereade: i've been looking at CL 6244060. i *think* that having multiple zk Servers sitting around in dummy isn't a good idea. [08:59] rogpeppe, I'm somewhat ambivalent, but I think in practice that when one is added we will remember to defer a removal as well [08:59] fwereade: i think we want to reuse the zk server regardless of the name that the test gives to the environment [09:00] fwereade: how do we remove a server? [09:00] rogpeppe, I guess doing it this way does effectively force us to use one dummy env name per package, which prevents us from encoding any helpful context in there [09:00] rogpeppe, SetZookeeper("foo", nil) [09:00] fwereade: that too [09:01] fwereade: and if we're going to do that, why bother allowing multiple zk servers [09:01] ? [09:02] there's an alternative, actually [09:02] rogpeppe, it seemed sensible to do that regardless... I think the issues are orthogonal? [09:02] go on [09:04] fwereade: hmm, another thought: why do we bother with SetZookeeper. why don't we let the dummy environ start its own zk? [09:04] fwereade: then the dummy environ can manage the server "cache". (it could keep just one server around after a Reset) [09:05] rogpeppe, hmm, how do we know when to shut the servers down? [09:05] fwereade: oh yeah, good point. *that* was why :-) [09:07] fwereade: anyway, i *think* we want to be able to reuse a zookeeper regardless of the name of the environ. [09:08] rogpeppe, tbh that was my initial preference but we do seem to have multiple storages (right?) and consistency seems sensible [09:09] fwereade: storage is *much* lighter weight than zk. and we trash all the storages after Reset. [09:09] fwereade: i think the 10s startup overhead of zk means we will never want to start up two [09:11] rogpeppe, my instinct says that indeed we won't, and that it will be much easier to note this and remove the capacity at some point in the future than it will to get into heavy discussions with niemeyer about it right now [09:11] rogpeppe, my primary consideration, sad to say, is getting it merged so I can get to work on deploy without it being at the end of a looong pipeline of CLs under discussion ;) [09:12] Good mornings! [09:12] niemeyer, heyhey! [09:12] fwereade: i'm concerned that this kinda breaks the dummy environs model [09:12] niemeyer: yo! [09:12] niemeyer: just expressing mild concern about SetZookeeper taking an environ name [09:13] niemeyer: we want the zk to be reused regardless of the name of the environment that's opened, i think. [09:13] fwereade, rogpeppe: No need to get into heavy discussions.. it was just an opinion.. happy to be shown the other side of it :) [09:13] rogpeppe: So what's the point of having environment names in the dummy provider? [09:13] niemeyer, my personal view is that the cost of either approach is dwarfed by the cost of talking about it for more than 20s ;) [09:14] rogpeppe: Environment names explicitly enable talking to completely different environments [09:14] niemeyer: so we can open multiple environments. but Reset should reset everything [09:14] rogpeppe: If we have two different environments that have different internal representations but that in fact are the same ZooKeeper state, isn't it the same environment? [09:14] rogpeppe: Agreed, but if we have a single ZooKeeper state, it's not multiple environments [09:14] niemeyer: we weren't allowing that [09:15] niemeyer: we weren't going to allow multiple zk environments [09:15] niemeyer: because i don't think we'll ever actually want that [09:15] rogpeppe: There's no such thing as a "zk environment".. an environment contains a ZooKeeper [09:15] niemeyer: lots of tests use the dummy env without requiring zk [09:15] rogpeppe: If we have two environments with one zookeeper, we don't have two environments [09:16] rogpeppe: Yep, that sounds fine [09:16] niemeyer: what sounds fine? [09:16] niemeyer: lots of tests use the dummy env without requiring zk [09:17] fwereade: Do we have a use case for opening two environments with a single ZooKeeper? [09:17] niemeyer, I don't think so [09:17] niemeyer: at the same time, you mean? [09:17] fwereade: So what's the concern? [09:18] fwereade: I'm concern we're modeling something unrealistic in the dummy environment [09:18] niemeyer: we don't want to restart zk every time we start a test. [09:18] fwereade: But doing dummy.SetZooKeeper("name", zk) vs dummy.SetZooKeeper(zk) execute in the same amount of test [09:18] erm [09:18] of time [09:18] niemeyer, from my perspective, that it's just more bookkeeping... I expect to run a bunch of sequential tests, each of which uses a dummy env, and which in practice may as well all use the same ZK [09:18] rogpeppe: Yep.. agreed [09:19] fwereade: Sounds fine too? [09:19] niemeyer, doing this effectively means we either need multiple zookeepers, or to explicitly set multiple envs to use the same one, if we ever want to use different env names [09:20] niemeyer, but I really have no horse in this race, I think the cost is minimal either way and I'm happy enough with either approach [09:20] fwereade: The cost is zero if we're never doing that.. and if we ever do it we can consciously choose to assign to the same ZooKeeper, right? [09:21] fwereade: I guess I'm still lacking what's the argument against making the interface of the dummy provider a bit more realistic in terms of what happens [09:21] fwereade: We're debating about SetZooKeeper(name, zk) vs. SetZooKeeper(zk), right? [09:22] niemeyer: i like the fact that dummy.Reset forgets all environ names [09:22] niemeyer, the cost is (1) a little bit of extra bookkeeping code and (2) consciously choosing to set up extra zookeepers in the package test function [09:22] rogpeppe: Sure, so continue doing that.. (?) [09:22] niemeyer: but if we add SetZooKeeper(name, zk) that name remains around [09:22] niemeyer: even after Reset [09:22] niemeyer, like I say, not enough for me to worry about [09:23] rogpeppe: I don't get it.. are you suggesting that Reset() won't reset what SetZooKeeper does? That sounds weird [09:23] niemeyer: if it does reset it, then we'll need to call SetZooKeeper on every test [09:23] niemeyer, ah, hmm, so Reset() should clear all zookeepers and each test should explicitly set one at the start? [09:23] niemeyer, that does feel heavyweight to me [09:23] niemeyer: perhaps that's what we should be doing i guess [09:24] niemeyer, having the magic test ZK in python felt like a win to me tbh [09:24] fwereade: Assigning an entry to a map sounds heavyweight? [09:24] fwereade: Reset resets everything else in Dummy.. why is it not acting on what SetZooKeeper does? [09:24] niemeyer, keeping track of the zookeeper in each test package, rather than just in the package setup func [09:25] niemeyer, Reset trashes the content of every active zookeeper [09:25] niemeyer, what I'm trying to avoid is starting a fresh ZK for every test [09:25] fwereade: You don't have to start a fresh zookeeper.. trashing content != starting zookeeper [09:25] niemeyer: the idea behind SetZooKeeper was "here is a zookeeper server; use it for a zk environment whenever it's opened" [09:25] fwereade: Each test *should* get a zeroed out zookeeper, right? [09:25] niemeyer, agreed; and it does [09:26] fwereade: Ok, so I misunderstand your point [09:26] niemeyer, what rogpeppe said^^ [09:26] rogpeppe, fwereade: Sure.. how does that change what was just pointed out, thought? [09:26] niemeyer, I think that allowing different ZKs for different envs is fine; I'm not sure we'll use it much in practice [09:27] fwereade: Agreed.. I'm not arguing that we use it.. I'm arguing that we don't have unrealistic scenarios for testing [09:27] fwereade: Two different environments in a configuration, with different names, will have different backing ZooKeepers [09:28] niemeyer, and I can get behind that; I've proposed a CL that, I think, does make the scenario more realistic as you suggest, and I'm perfectly happy with it :) [09:28] niemeyer: if we have Reset clear out all the zk servers too, then every test will need to call SetZooKeeper, which means that every test suite will need a zk server field. if we have just a single zk server instance, then we can do the setup exactly as we do in state.TestPackage [09:29] niemeyer: will we ever want to have two different environments concurrently with different zookeepers? [09:29] niemeyer: it's a heavy weight test and one i can't really see a reason for doing [09:29] niemeyer, I'm not so keen on the idea of having a zkServer package var for every test package, and explicitly setting it as the dummy zookeeper in every test; is that what you're proposing? [09:30] niemeyer: if you never want to do that (and you can make it panic if that ever happens accidentally) then the scheme is not unrealistic - it's indistinguishable, i think. [09:30] rogpeppe: fwereade: Two different environments in a configuration, with different names, will have different backing ZooKeepers [09:30] rogpeppe: That's how environments work for real [09:31] niemeyer: yes, but will we *ever* want to open two such environments *at the same time* in a test? [09:31] rogpeppe: If we're creating a dummy provider that works in a different way, it sounds like we're doing something wrong.. [09:32] rogpeppe: You were the one changing the dummy package so it could take multiple environments with different names.. (!?) [09:32] niemeyer: that's for basic tests that don't require zk. [09:32] niemeyer: yes, but will we *ever* want to open two such environments *at the same time* in a test? [09:33] rogpeppe: That does answer your own question [09:33] niemeyer: by "such environments" i meant environments with a backing zk instance [09:34] rogpeppe: We're going in circles. I've already pointed out the reasoning behind that. You can agree or disagree. [09:34] niemeyer: the approach i'm suggesting is the same one taken by state, for instance - we have a single zk instance that is reused in each test. [09:34] rogpeppe: That's where our conversation started. [09:35] niemeyer: so... should Reset forget the servers registered with SetZooKeeper? [09:36] rogpeppe: That was my expectation, but I guess the dummy package is being used in a different way than what I expected [09:37] niemeyer: if so, i could live with that. it's another line in each test or suite that opens a zk environ, but the zookeeper.Server could live in a global var just like state.TestingZkAddr. [09:37] rogpeppe, fwereade: So far we set up the dummy package on each suite, I think [09:38] niemeyer, ATM we set it up per package [09:38] niemeyer, following the model in state [09:39] fwereade: The dummy package? Do you have an example where we set it up per package I could look at in the current source? [09:40] cmd/juju/cmd_test.go sets it up per test [09:41] Right, I meant an example where we use the dummy provider on a package context, rather than per test or suite [09:41] niemeyer, only in https://codereview.appspot.com/6243067/ which technically doesn't exist yet [09:42] niemeyer, (that's calling SetZookeeper in the package test func; did you mean something different?) [09:42] fwereade: Right, so that's why I was assuming a given way of using it, which doesn't match what you had in mind.. not saying either is right or wrong, but part of the argument originates there [09:42] niemeyer, I'm just monkey-see-monkey-doing what we did for state wrt zookeepers; seems to work ok ;) [09:43] * fwereade wonders whether "following established conventions" is a better way of putting that ;) [09:43] fwereade: Yeah, you could have monkey-see-monkey-done what the dummy package currently do now as well, though :-) [09:44] niemeyer, so it seems; state is the one I already knew :0 [09:44] fwereade: "blindly following over a cliff"? [09:44] rogpeppe, if all your friends jumped off a cliff and it all seemed to be going just fine... [09:45] fwereade: come on in, the water's lovely! [09:46] fwereade: Ok, let's just move back to the SetZooKeeper you had then.. it's very straightforward and will get you going [09:46] niemeyer, the cost of setting up a ZK was a contributing factor... if that weren't a consideration I'd happily do everything per-suite [09:46] anyway, to get back to the point. i think i'd be happy with either: one zk instance, reused automatically, as originally; or an explicit SetZookeeper required after Reset [09:46] niemeyer, ok, cool [09:46] niemeyer, cheers :) [09:46] fwereade: I'm happy to delay my preciousism in the design (if that's even a word) to a second moment [09:46] niemeyer, and a panic if anyone tries to SetZookeeper while one is already set? [09:47] fwereade: The fact it matches what's being done with zookeeper now in terms of the test suite is what makes me more comfortable [09:47] niemeyer, fwereade: thanks for bearing with me. i feel like i've been the precious one :-) [09:47] fwereade: i don't see why we shouldn't allow SetZookeeper twice. [09:48] fwereade: Not sure.. how do you plan to reset the zk? [09:48] rogpeppe, ah ok, perhaps I misremembered an earlier comment of yours [09:48] fwereade: as in, how do you plan to unset the package variable [09:48] niemeyer, `defer SetZookeeper(nil)` in the package test func; clear contents on Reset() or Destroy() [09:48] fwereade: Ah, ok.. so accept nil, but not another zk [09:48] Anyway, I have to move rooms [09:48] niemeyer, yeah [09:49] Which means I have to shutdown [09:49] :( [09:49] brb [09:50] fwereade: what bad thing might happen if you allowed setting another zk? [09:50] rogpeppe, having two zookeepers around :p [09:50] rogpeppe, if someone comes up with a legitimate use case removing the panic is not hard [09:51] rogpeppe, but trying to do so indicates to me that something is likely to be being Done Wrong [09:52] fwereade: i'm not sure i see the big difference between { SetZookeeper(nil); SetZookeeper(anotherZk)} and SetZookeeper(anotherZk) [09:53] fwereade: but i don't mind actually. require the SetZookeeper(nil) if you prefer. [09:53] rogpeppe, in either case, assuming package-level setup, either you need to keep track of the original package ZK *or* someone has failed to clear it out from a previous package [09:54] fwereade: i can't see how that would happen. we only test one package at a time, right? [09:55] rogpeppe, and if a server from a previous package is still there, someone's ballsed something up [09:55] fwereade: so it would only happen if we happened to call SetZookeeper twice in the same package. which could happen, i guess, but i don't see it as an easy-to-find failure mode. [09:55] rogpeppe, fair enough :) [09:55] fwereade: how could a server from a previous package still be there? they're different programs? [09:55] s/\?$// [09:56] * fwereade waves his hands vaguely, then runs out of steam and slinks off lokking embarrassed [09:56] :-) [10:06] rogpeppe, should Destroy be clearing out the appropriate key in providerInstance.state (and closing the listener)? [10:07] fwereade: erm, zookeeper.Server.Destroy? [10:07] rogpeppe, sorry, dummy.environ.Destroy [10:08] fwereade: i don't see that method. do you mean Reset? [10:08] oh! [10:08] rogpeppe, Reset clears them all [10:08] just grepped the wrong dir [10:09] i don't *think* so [10:09] fwereade: it's not like s3 goes away when you destroy an environment [10:10] fwereade: i think it's ok for Reset to do that job [10:11] Aram: yo! [10:11] morni g all. [10:11] rogpeppe, I'll read some more, see if I can figure out why your proposed tweak to open panics... that was just a half-formed hypothesis [10:12] Aram: Hi [10:12] fwereade: it could be that something's not calling Reset [10:12] Aram, heyhey [10:14] rogpeppe, HAHA DISREGARD THAT I wrote the code in the wrong place :/ [10:14] * rogpeppe disregards it [10:50] fwereade, TheMue, niemeyer: i'm wondering about the way that we manage the state with watchers. if i'm watching something, i'll get a notification that something has happened to it (because its config node changed, for example) but then i have to re-read the same info from zk if i want to find out attributes of the object. but the info might have changed - the info i see might not be consistent with what i'm told [10:51] i'm wondering if a model where each kind of thing (Unit, Service, Machine) caches the info that was known when it was created. [10:51] s/if a/about a/ [10:51] rogpeppe: Typically the specialized watchers return the needed info. [10:52] rogpeppe: So in your case a watcher returns an info but you need a different one depending on it? [10:52] TheMue: i'm looking at doing a unit watcher. the obvious thing to do is have the channel sending *Units that have been added or removed. [10:52] rogpeppe: That's what the machine watcher does.. [10:53] TheMue: but if i want to get any info out of those units, i have to reread it [10:53] niemeyer: yeah, and i'm a bit concerned about it [10:53] rogpeppe: No, you're not re-reading.. you're reading.. the information out of those units wasn't read before [10:53] rogpeppe: There are different ways to model that problem for sure [10:54] rogpeppe: And perhaps the model we have in place today isn't the best one, but changing it will incur in other issues [10:54] niemeyer: ah, that's true. the info *about* the units is in the topology, but the info *of* the units is in the unit's config node, right? [10:54] rogpeppe: Yep [10:54] rogpeppe: So, in either case, I suggest not modifying that today so that we can move forward [10:54] rogpeppe: Nice description, yes. [10:56] rogpeppe: I do think eventually we'll want to cache more than we do, but that can't be done without pondering further about the algorithms [10:56] niemeyer: it doesn't seem that that's entirely true. i'm looking at AssignedMachineId and it reads the topology. to find new units, i'm going to need to watch the toplogy. so i'll be reading the toplogy for every unit as well. [10:57] niemeyer: The test of store fails for me due to a not matching error message in lpad_test.go:42:. Is that only here or well known? [10:57] rogpeppe: Yeah, it's a mix of both [10:59] TheMue: Certainly not well known by me.. trunk should never be broken [11:00] a possible model to consider for the future: each object acts as a local cache of some state. it only goes to zk when it doesn't already hold that state. an Update method could be implemented on each type to fetch new values from zk. [11:00] rogpeppe: Yeah [11:00] TheMue: tests all pass for me [11:01] niemeyer: Ah, found the error. It's the locale. So bzr returns a German message here while an English one is expected in the test. (sigh) [11:01] niemeyer: that way most methods could lose their error return perhaps - the only place returning an error would be on Update. [11:01] rogpeppe: See above, it's my locale. [11:02] TheMue: ah. useful to have someone in a different language locale! [11:02] rogpeppe: Yes. While our own messages are all English the ones of external tools may vary. [11:03] rogpeppe: and then all writes have to be cached as well? That would mean the flush operation could fail, and we wouldn't know why.. which means we'd have to implement retry points that don't really know what is being retried [11:03] rogpeppe: etc [11:04] niemeyer: no, i think writes would just write through [11:04] rogpeppe: It's a different model.. worth thinking about at some point.. not obviously better [11:05] rogpeppe: As long as we don't have any problem with re-reading I won't do an application based caching. This may be task of the backend (like ZK, Mongo, whatelse). [11:09] niemeyer: it's this kind of thing that concerns me: client A watches units. client B changes unit 1 to X. client A observes change X. client B changes unit 1 to Y. client A reads Y. client A observes change Y. client A reads Y. [11:10] rogpeppe: How's that an issue? [11:11] niemeyer: it's very inefficient, particular when we're observing the topology and it's getting large. [11:11] niemeyer: maybe i shouldn't worry about efficiency here though. [11:12] rogpeppe: Yeah, let's make it work first [11:12] rogpeppe: Reliably [11:13] rogpeppe: Note that, in your example, even if we cached the data and client B read X instead, there would be a second notification [11:13] niemeyer: it's reliability i'm concerned about too. working on a slightly newer version than we've just been told about. maybe it's not an issue, but it seems potentially problematic. [11:13] rogpeppe: We haven't been told about anything.. we have simply been notified that a changed happened [11:13] niemeyer: yeah, there are two changes, so there would be two notifications [11:14] niemeyer: we've been told that some new units have been created, for example. [11:14] rogpeppe: Yes, we have, but that's unrelated to your example [11:14] niemeyer: and we *did* know some info about those units, but we've thrown it away [11:14] rogpeppe: Yes, but that's unrelated to reliability [11:16] the caching model seems to me like it has less potential for odd race conditions. [11:18] niemeyer: anyway, food for thought. [11:18] rogpeppe, agreed it is inefficient [11:19] rogpeppe, the other options are to have some notion of logical transactions that the topology records for [11:19] not nesc. the 3.4 multi-node txn, but a logical one where we carry the topology across multiple ops [11:19] just to be clear its not a race condition per se that its avoiding, its the spurious notifications caused by every state change, that may actually compose a larger logical op [11:20] but really the largest source of spurious notifies, is everything listening to the topology, getting hit by notifications they don't care about [11:20] hazmat: yeah that's true [11:21] rogpeppe: Indeed, I do think those are good ideas, and that there's something there for us to evolve towards [11:21] hazmat: but it doesn't help when we've been listening to the topology, we're told that it's changed and what it changed to, and then we do a round trip just to fetch it again. [11:22] rogpeppe: We quickly did that when we started.. but didn't quite work well [11:22] Luncnh time [11:22] niemeyer: did what, sorry? [11:23] as an alternative i think we either need to carefully devolve into multiple topo indexes, and/or starting using multi-node transactions.. [11:23] rogpeppe, that's the nature of watches [11:24] rogpeppe, oh.. we got told what it changed to? [11:24] hazmat: ah, no, of course. in this case we're doing a round trip to fetch it. and then another round trip to fetch it again. [11:25] rogpeppe, ah [11:26] rogpeppe, we did briefly experiment with an up to date object cache, but lacking transactions or pub/sub events (from watches), it ended up just being more complexity imo. [11:27] rogpeppe, but if you could interject into the watch channel to an object cache invalidation protocol it might have some value, but effectively anything in cache would need to be watched [11:27] else it could be stale [11:27] hazmat: i wasn't thinking of a global cache, just a local cache for an object when you read it. [11:27] alternatively work with an operation context, like a transaction scope [11:27] er. scoped cache [11:28] hazmat: and a way of saying "please update" [11:28] rogpeppe, yeah.. that makes sense, but speaking of race conditions ;-) [11:28] its unavoidable i suppose, the local cache gives a consistent view at least [11:28] hazmat: yeah, that's my thought [11:28] we always have to consider the possibility of state change [11:29] hazmat: indeed. [11:29] but if we go to modify a cached obj, we have to reconcile current state and modifications, not cache state and mods [11:29] hazmat: but it can change when we ask it to [11:29] ie. capture versions [11:29] at a min or use retry change utilities [11:29] hazmat: i'd be happy with a write-through cache [11:30] hazmat: it doesn't solve all the problems, but it alleviates the worst [11:30] niemeyer, are you in uk? [11:30] hazmat: he is [11:30] * hazmat notes its not lunch time yet ;-) [11:30] rogpeppe, cool, is there a gojuju sprint going on? [11:30] hazmat: nope [11:31] hazmat: niemeyer's at some sprint in london [11:31] we should get a juju sprint going on [11:31] i can't even remember the last sprint we had [11:31] like august of last year maybe.. [11:31] hazmat: +1 [11:32] hazmat: i haven't done a sprint yet [11:32] we should fix that.. [11:32] rogpeppe, hazmat: Isn't something planned when Mark is on board? [11:32] i dunno [12:52] rogpeppe: ping [12:53] niemeyer: pong [12:53] rogpeppe: Yo [12:53] rogpeppe: Are you game to come tomorrow and return on Friday? [12:53] niemeyer: i think so [12:53] rogpeppe: Awesome, sorting out hotel [12:53] niemeyer: will just have a word with carmen [12:53] rogpeppe: Cheers [12:57] rogpeppe, any particular reason StorageReader.URL doesn't return a url.URL? [12:58] niemeyer: eager to meet you tomorrow! [12:58] anyone else there? [12:58] Aram: Looking forward too [12:58] Aram: Lots of people, but no jujuers unfortunately [12:59] Aram: rog should come, thogh [12:59] though [12:59] great. [13:35] rogpeppe: Are we good to go? [13:51] niemeyer, do I recall you saying we should revisit the way we handle unit placement in python? [13:51] niemeyer, because we're aproaching the point at which we should be considering it :) [13:51] fwereade: Hmm.. not that I remember off hand [13:52] niemeyer, jolly good then -- if it crosses your mind again, do let me know (I didn't see anything wrong with it myself, but...) [14:04] niemeyer: I now start the go test with a temporary locale en_US. But now I've got this error: http://paste.ubuntu.com/1014818/ [14:06] niemeyer: yes. [14:06] niemeyer: sorry about the wait. got into an involved discussio.n [14:07] rogpeppe: COol, thanks [14:07] rogpeppe: Moving forward then [14:07] fwereade: there's no need for it to be a parsed URL. http.Get doesn't take a url.URL as an argument. [14:07] TheMue: Sorry, can't look at that now [14:08] niemeyer: OK, no problem so far and doesn't hinder state development. ;) [14:08] fwereade: a string seems a fine representation of a URL to me if you don't need to be looking inside it. [14:09] rogpeppe, ah, ok; in that case the question becomes: TheMue, is there any particular reason AddCharm takes a url.URL? [14:10] fwereade: Have to think back. IMHO because I'm getting it from an API call. One moment, I'll take a look. [14:10] TheMue, thanks [14:10] fwereade, TheMue: it looks like it could as well be a string, as all it does is call String on it... [14:11] fwereade, TheMue: and charmData.BundleURL is a string [14:11] rogpeppe, concur [14:15] fwereade: Don't know the reason anymore, it became a URL during the discussion. [14:16] TheMue, rogpeppe: any reason not to make it a string again? [14:16] fwereade: Are there any problems with URL? [14:16] TheMue: it's worth using the same representation for the same thing throughout, i'd say [14:16] TheMue, just that it seems kinda silly to turn a string into a url just to turn it back into a string a few us later :) [14:17] fwereade: +1 [14:18] rogpeppe: Same representation for the same thing: yes. A URL is a URL. ;) [14:18] rogpeppe: But it's ok for me. [14:19] rogpeppe: Can parse it to URL if access to the parts is needed. [14:19] TheMue: yeah [14:19] rogpeppe: The only thing is: URL verifies the URL to have a valid scheme. [14:21] TheMue: i don't think so [14:21]