[00:47] davecheney, the pa needs a lock around a the ma [00:47] er. around the machine state its processing [00:47] to allow for concurrent pa [00:49] hazmat: yes [00:49] hazmat: even simpler the PA stores the provider instance id into the state once it is known [00:49] * hazmat tries to catch up the on the conversation [00:49] which can be used as a sentinal to say 'hey, at least I started this vm, it might be dead now, but I tried' [00:50] davecheney, sure.. that's what it does currently [00:50] that would be problematic with multiple PA's all racing to provision machines [00:50] TBH, i haven't thought about how to solve that yet [00:51] its just a per machine lock op lock, or a even a queue.. [00:51] hazmat: would that be implemented in ZK ? [00:51] davecheney, sure [00:52] finger in the air, maybe that could be done with a new content node /machines/machine-X/state [00:52] there's recipes for building all of these structures for zk on the zk wiki.. the py zk lib (txzk) has several implemented.. [00:52] i;ll go check that out [00:52] /machines/machine-x/lock i would think [00:52] but i'll have to moderate that with gustavo's desire to not be too closely tied to SK [00:52] or even /machines/provisioning-queue/ [00:52] ZK [00:53] hazmat: sounds like maildir [00:53] * hazmat giggles [00:53] well he wants to maintain the current client api [00:53] so assuming the guarantees are the same, the principles should carry over.. [00:54] mongo is consistent and has atomic ops.. [00:54] it's on my pondering queue, but right now we have 0 PA's, so i'm not really focusing on having N PA's yet [00:54] doing locks, and queues with it is straight forward [00:54] sure.. [00:54] hazmat: that might be simpler [00:54] the goal seems to be to get to the parity.. [00:54] in mongo, when the client disconnects, do the locks go away ? [00:54] and then flip the bits ;-) [00:54] my concernt with lock files and shit is recovering from a stale lock [00:54] davecheney, you record the client and a timestamp on the lock.. [00:54] davecheney, have a look at the store code.. [00:55] it has some locking [00:55] i'll do so [00:55] hazmat: in python, what was the result of the tcp connection to zookeeper going away ? [00:56] did the agent exit, or did you try to recover ? [00:58] davecheney, it recovers [00:58] davecheney, there's a connection wrapper that basically creates an immortal connection [00:58] where is that handled ? in the zk library, by trying other replicas ? [00:58] ahh right [00:58] davecheney, it handles transient disconnects and session expirations [00:59] for transient disconnect the reconnection is handled by the libzk [00:59] for session expirations its handled by the wrapper [01:00] also triggers watches on session reconnect, its a fairly straightforward impl.. http://bazaar.launchpad.net/~juju/txzookeeper/trunk/view/head:/txzookeeper/managed.py [01:06] re mongo.. here's a simple queue impl i wrote with locking.. effectively each client has to be cooperative about breaking stale locks.. their easy to detect.. and the breaking is just part of the queue impl. [01:06] rog's upgrade solution is odd.. [01:07] i guess that makes sense.. ma responsible for code upgrade, others sync on that [01:14] hazmat: what if the tools were a .deb, upgrades would be as simple as something running an apt-get upgrade on every machine [01:18] davecheney, debs are frought with problems in this context [01:19] davecheney, across multiple versions of the distro... needs an apt repo maintenance.. [01:19] hazmat: sure, i guess that was a nieve solution [01:19] the actual download isn't a huge problem [01:19] its just trying to ensure the coordination around it [01:19] i'm just wondering if we're reinventing dpkg hooks [01:20] davecheney, how does apt handle multiple versions avail.. [01:20] it picks the latest.. [01:20] indeed [01:20] by default anyways.. [01:20] dpkg hooks aren't really about cross machine coordination [01:21] the whole thing becomes much more interesting, and indeed.. simpler when you consider it from a db upgrade perspective [01:21] no, really just for poking upstart [01:21] 'Everyone! Switch to version X! [01:21] where you need to everything having the new code ready.. you do a centralized db upgrade.. and then restart everything.. [01:21] i like the use of the state for signalling things like that [01:27] indeed.. that's why we have zk.. [06:43] davecheney: morning! [06:43] TheMue: yo! [06:43] davecheney, wrtp, fwereade: Morning. [06:43] fwereade: hey! [06:48] wrtp: TheMue fwereade Aloha! [06:48] wrtp: TheMue I have questions about the state [06:48] who is sober enough to answer them ? [06:49] davecheney: woke up with a head full of crack after last night's recursive agent discussions... [06:49] davecheney: Let's try it. [06:49] davecheney: i'm sober enough but i might not know the answers [06:50] so, in the latest propose for the PA, gustavo had this concern [06:50] https://codereview.appspot.com/6250068/diff/5004/cmd/jujud/provisioning.go#newcode37 [06:50] TheMue: wrtp after trying all day, I can't actually make the state break, that is, ever return an error [06:50] nor can I observe any of the watchers close on me through rough handling of the zookeeper server [06:51] davecheney: that's true currently, but might not be in the future, when we're not talking directly to zk (or zk is actually mgo under the covers) [06:52] wrtp: yup, after talking to hazmat he said that in python they also have a wrapper than makes the state immortal and can cope with transient disconnections from the server [06:52] davecheney: that's controversial... [06:53] wrtp: TheMue my intention was to add a state.IsValid() method somewhere so that the PA could drop out of the loop, make another state connection and try again [06:53] but without the ability to ever make the damn thing crap itself, it's hard [06:53] davecheney: what would IsValid test? [06:53] davecheney: isn't that what the channel returned from zk.Dial is supposed to do? [06:53] wrtp: my idea was it would be set to false it an error (of the sort that GetW or ExistW give) [06:53] wrtp: Yes, good question. [06:54] but as I can't get it to generate an error ... [06:54] wrtp: IsValid is supposed to detect the 'broken' Gustavo spoke of in that comment [06:55] davecheney: That's depending on todays gozk. But as Roger said this will change (or at least wrapped as a first step). [06:56] davecheney: In case of a broken connection the state is not invalid. It's "only" a connection error. Indeed the watcher may be notified if we don't have a mechanism to automatically reestablish it. [06:56] TheMue: yup, i'm always planning that ZK has a limited shelf life [06:56] davecheney: But reading and writing of the state is always life. [06:57] davecheney: i think fwereade did some experiments around breaking zk connections, but i may remember wrong [06:57] TheMue: so here is the logic, something is receiving from the watcher channel, and it detects channel closed, so we call Stop on the watcher to clean up [06:57] then before going back into the loop, i need someting like state.IsValid or !isClosed() to say 'don't try this again, it won't do any better this time' [06:58] davecheney: isDisconnected() or something like that, but please not IsValid(). [06:58] davecheney: Because the state in ZK is still valid. [06:59] davecheney: you should get an error from the watcher's Stop method, i think [07:00] wrtp: yes, that is another way to do it, but is fraught with difficulties as the error might be wrapped [07:00] wrtp: but if you're saying on _any_ error from stop we should consider the state disconnected and tear everything down [07:01] davecheney: we should make sure that we make *sure* that a fatal error from zk is passed through in a recognisable way to the Stop return value [07:01] wrtp: can you elaborate on what you mean by recognisable way [07:02] davecheney: i mean that it should have a known type or a known value [07:03] (probably the former, so we can encapslate the actual zk error) [07:03] wrtp: that is what I was thinking too, rather than error, state.Error [07:03] davecheney: well, *state.Error returned as an error. [07:03] gotta go to breakfast [07:04] wrtp: of course [07:08] btw, did aram write Doozer ? [07:14] hey all [07:15] has anyone been able to sign up to the HP cloud ? [07:15] I tried twice today, with my canonical and personal email addresses, but I haven't got a confirmation email back yet :( [07:17] davecheney: i haven't tried [07:18] wrtp: i emailed jorge to see if he could reach out to a tech contact there [07:21] davecheney: gustavo says "sign up, give them your credit card details, then send me the account id and the tennant id" [07:21] wrtp: i'm blocked at the 'sign up' stage [07:21] davecheney: (but obviously that might be hard if they won't let you sign up!) [07:21] it never sends me the confirmation email [07:22] jynx! [07:23] OT: at mailguard, our bot would mute someone if you call jynx [07:23] it used a levenstein computation to see who to mute [07:25] davecheney: cool [07:26] further proof that with enough time and perl you can achieve even the most useless of things [07:26] davecheney: i wonder if there's a go package for computing levenstein distance [07:28] wrtp: wouldn't be hard, i don't think its very complicated to do in code [07:29] davecheney: agreed. it's nice to be able to take stuff off the shelf though [07:32] ask uriel [07:37] davecheney: gotta go. have fun. [07:37] wrtp: cya [08:12] Hellos! [08:29] Aram, niemeyer: it'd be nice to be able to talk, eh? [08:29] heh, yeah [08:29] rog: Yeah.. well.. I'm just responding to Dave's email, and then we can move elsewhere to chat as well [08:42] fwereade: ping [08:42] niemeyer, pong [08:42] fwereade: Heya, good morning [08:43] niemeyer, and yourself :) [08:43] fwereade: Do you have the RT# for the juju-dev ML? [08:43] niemeyer, it was set up this morning [08:43] fwereade: Oh [08:43] niemeyer, I appear to be an administrator, which I guess I should have expected :/ [08:43] fwereade: Yeah :-) [08:43] niemeyer, something wrong? [08:44] fwereade: No, I want to use it :) [08:44] fwereade: Have you subscribed people to it? [08:44] niemeyer, not yet [08:44] fwereade: Ok, would you mind to do that so we can start using it? [08:44] niemeyer, on it [08:44] fwereade: Subscribing the obvious candidates, and then mailing juju@ should do it [08:45] fwereade: Thanks a lot [08:45] I'll hold off sending the email to Dave to send it to the list instead [08:50] niemeyer, added [08:50] * fwereade worries that he's forgotten someone who will be mortally offended [08:52] fwereade: juju-dev@lists.ubuntu.com? [08:52] niemeyer, yeah [08:52] fwereade: Send an email to juju@ inviting people.. no body will be offended [08:52] nobody [08:53] fwereade: Is Aram in? [08:53] niemeyer, yeah [08:53] fwereade: Superb [08:53] fwereade: Thanks a lot for taking care of this [08:53] Sending first email [08:53] niemeyer, a pleasure :) [08:54] Done [08:54] Let's see if email still works these days ;-) [09:08] * TheMue has the mail in his folder for this list, nice. [09:48] TheMue: ping [09:49] niemeyer: pong [09:49] TheMue: I spent some time yesterday with rog and aram [09:49] TheMue: around the concept of relations and how they were inverted [09:50] niemeyer: I'm listening. [09:50] TheMue: We got to the conclusion that the original design was actually more future proof that what we have in place in the CL now [09:50] TheMue: It's very hard to imagine that we'll have a single service participating in a single relation with two roles [09:52] TheMue: But it's not so much of a stretch to imagine that two services may participate in a relation with the same role [09:52] niemeyer: IC [09:52] TheMue: E.g. a master with two slaves, two peers, etc [09:52] TheMue: The new design makes that unfeasible [09:53] niemeyer: Hmm, a change from map[role]serviceKey to map[role][]sericeKey wouldn't help (as a quick thought)? [09:54] niemeyer: With all depending changes naturally. [09:54] TheMue: Sounds worse than just doing what we had [09:54] TheMue: map[service key]stuff [09:55] niemeyer: OK [09:55] TheMue: That said, hold on a moment [09:55] TheMue: I'll re-review the latest state of that branch.. I'm hoping we can integrate the current version, and then refactor it over [09:56] niemeyer: The idea of William and me has been to move away from seperate AddRelation() and AddEndpoint(). So that the risk of having a relation w/o EP or only a provider or requirerer is lower. [09:58] niemeyer: Maybe following the current model but with a new API could do this too. [10:08] TheMue: I don't see how that's related to the point above [10:09] niemeyer: It's only the motivation how the change started. The model change has then rised out of a discussion (as it seems sadly with a wrong direction). [10:10] niemeyer: So maybe the model could now better stay as it is in Py, but the API changes to reduce the risk of adding illigal relation sinks. [10:17] TheMue: Agreed, not suggesting further changes.. just the topology has to be adapted to invert the map [10:20] niemeyer: OK, start a new branch based on the zk to topo renaming to change the topology first. Afterwards new branches for AddRelation() and RemoveRelation() while the two current open ones will be abandoned. [10:21] TheMue: Please hold on [10:21] TheMue: What are you abandoning? [10:23] niemeyer: The AddRelation() and the RemoveRelation() branches. They have older branches as prerequisites. [10:24] niemeyer: I don't know how good the newer refactoring branch then works with those two. [10:24] TheMue: No, please don't drop them [10:24] TheMue: We've spent a lot of time polishing those branches [10:24] TheMue: Let's get them in, and have the change on top of them [10:24] niemeyer: Merging is now problem? [10:25] TheMue: Me not understand [10:25] niemeyer: Ah, but I understand you now. You want to get both in the trunk first before I start refactoring. [10:26] TheMue: Yeah [10:26] niemeyer: Am I right? [10:26] niemeyer: Good. [10:26] niemeyer: Otherwise I would have kept the source and then bring it in with new branches. [10:28] niemeyer: The "new" RemoveRelation() propose will come in in a few moments, just testing. [10:28] TheMue: Ah, cool [10:35] niemeyer: Aaargh, it's in, but again with a lot of file too much in the review list. [10:36] TheMue: Ok, can you please clean it up so I can review and unblock you? [10:37] niemeyer: Will try. It depends on the AddRelation() proposal. [10:37] Aram: https://launchpad.net/mgokeeper [10:37] Aram: bzr branch lp:mgokeeper and profit :) [10:38] TheMue: The pre-requisite is merged.. it's the same problem you had last time, and the same solution as well [10:39] niemeyer: Yep [10:56] TheMue: "Today this isn't done. I would like to do it in a new small branch after this [10:56] and RemoveRelation() are in." [10:57] TheMue: Ok, but please note that down as the next task after fixing the topology details [10:57] new 'juju-dev' mailing list? [10:57] niemeyer: Hmm, merged, pushed, proposed, everything is there. But also still those files not part of the branch. It's only that they are with one delta in rietveld while the changed file have two. [10:58] TheMue: You have to push the pre-req after merging trunk in it, as you did last time [10:58] niemeyer: I've done. [10:58] TheMue: The diff is the diff that bazaar generates [10:58] TheMue: So whatever is being pushed is the actual diff between the two branches [10:59] niemeyer: I have to digg deeper. [10:59] TheMue: That's all that there is to it really [10:59] TheMue: If you merge trunk on the pre-req, push it to Launchpad, merge trunk on the follow up, repropose, it should wokr [10:59] niemeyer: Why the quotes around the sentence above? "Today this …" [10:59] TheMue: Because it's your sentence [11:00] hazmat: Yeah, William sent a note to juju@ [11:01] TheMue: The task should not be lost.. a few times we've said something was going to be done as a follow up and it ended up going missing [11:02] TheMue: So please write down to keep track this should be in the queue after the current branch and the topology changes [11:02] We really need an organized bug tracker that we can look at [11:02] Hmm.. maybe we should create a juju-core project in Launchpad [11:03] niemeyer: Yep, missing that. Workied with it since the 90s and introduced it in several projects. It's indeed helping. [11:04] TheMue: LOL.. yeah :) [11:04] TheMue: We have a bug tracker.. it's just a mess because of the mix up of juju py [11:05] niemeyer: So time for juju go? [11:05] TheMue: Hm? [11:05] TheMue: So, do you know the task I'm talking about above? [11:07] niemeyer Not yet, will look into the logs. Right now I'm fighting with bzr. It says in the prerequisite as well as in the current branch that there's nothing to merge from the trunk and in the prerequisite that there's nothing to push. [11:07] niemeyer: Drives me mad. [11:07] TheMue: Ok.. I'll file a bug and assign to you. [11:07] niemeyer: Thx [11:08] TheMue: Have you merged trunk onto the pre-requisite? [11:08] niemeyer: Yes. [11:09] niemeyer: Just tried again, nothing to do. *sigh* [11:09] niemeyer: Same in my branch. [11:10] niemeyer: And bzr push says that there is nothing to push. [11:11] TheMue: Merge the pre-req onto your branch now [11:12] niemeyer: Oh, something new, a warning about criss-cross, but everything merged successful. [11:12] TheMue: Yep.. that's the problem [11:13] TheMue: Try pushing the new content [11:13] and proposing it [11:13] I hope that works [11:15] niemeyer: Ah, yeah, better now. Thank you. [11:15] TheMue: Woohay! [11:17] niemeyer: Worked too long w/o branching. But by now I've also started to branch my private software. ;) [11:24] TheMue: I see you're renaming from zkRelation to topoRelation.. are tests broken at the moment without that? [11:25] niemeyer: Without renaming it has been broken. [11:25] niemeyer: Yes. [11:25] TheMue: Ok :( [11:26] TheMue: Trunk is being broken way too often :( [11:26] 382 t.RemoveRelation(relation.key) [11:26] 383 return nil [11:26] TheMue: Is RemoveRelation returning no errorr? [11:27] niemeyer: No, it's only removing inside a map. Today it's also not checked at that point if it exists in that dir. [11:28] TheMue: OK [11:28] / Relation returns the relation with key from the topology. [11:28] func (t *topology) Relation(key string) (*topoRelation, error) { [11:28] if t.topology.Relations == nil || t.topology.Relations[key] == nil { [11:28] return nil, fmt.Errorf("relation %q does not exist", key) [11:28] TheMue: We don't want the user to be getting this error message [11:29] niemeyer: Oh, please wait.Just seen an assert_relation there. Will add it too. [11:29] TheMue: The relation key is completely uninteresting as far as a user is concerned [11:30] TheMue: The state method should verify the state in those cases, and error early with a sensible message [11:30] niemeyer: OK [11:30] TheMue: If we get an Relation from relation we should display prefixed with something saying that an unexpected action happened while doing whatever [11:31] TheMue: In which case the relation key might go out, but we have no idea about why it was failing since we've checked it early [11:31] TheMue: So it's debugging rather than something we'd like the user to be commonly looking at [11:31] niemeyer: IC. Do you note it in the review? [11:31] TheMue: I'll copy & paste what I just said [11:31] niemeyer: I have to break for lunch, wife is calling. [11:31] niemeyer: Yes, thx. [11:32] TheMue: Sure, I'll see you on Monday, have a good lunhc [11:35] fwereade: Have you added andrewmelina? [11:35] fwereade: To the list? [11:44] niemeyer, sorry, no I didn't [11:45] fwereade: no problem, I thought we might have missed it [11:46] niemeyer, is that the same person as andrewsmedina at gmail? [11:46] niemeyer, can do that now [11:46] fwereade: Yeah, I suspect so [11:47] fwereade: Thanks! [11:50] TheMue: https://bugs.launchpad.net/juju-core/+bug/1007373 [11:56] TheMue: https://codereview.appspot.com/6223055/ is still dirty [12:07] niemeyer: So, 6223055 is cleaned up. [12:09] TheMue: Thanks [12:09] niemeyer: Same problem with its prerequisite again. [12:09] TheMue: Yeah, I do apologize for the problem.. I should have fixed it already [12:13] niemeyer: Gna, it's also my inexpertness with branching. So don't mind. The more often I have this problem the better I learn how to avoid it. ;) [12:20] TheMue: It's not actually your fault.. the pre-req support in lbox should handle that case correctly without you having to worry about it [12:21] niemeyer: So I'm happily awaiting the next release. [12:22] TheMue: Review delivered, and you have a LGTM with a few trivial comments [12:23] niemeyer: Just reading them. [12:23] niemeyer: Thanks. [12:33] fwereade: You got a LGTM too [12:33] niemeyer, sweet tyvm [12:34] fwereade: it's on the smaller branch, though :( [12:34] * niemeyer <= cheater [12:34] * niemeyer <= hungry too [12:34] We'll step out for lunch [12:34] niemeyer, no worries :) [12:34] LGTMs invariably LGTM ;p [12:34] Hehe :) [12:34] SGTM! ;) === chuck__ is now known as zul [13:07] rog, is DefaultSeries making its way somewhere that's accessible via a juju.Conn? [13:07] bah, that was a *we*'ll step out for lunch, wasn't it? [13:09] fwereade: Looks like. [13:33] fwereade: You've got another LGTM.. hopefully it's sensible [13:33] fwereade: (the comments, I mean) [13:34] fwereade: Regarding DefaultSeries, yeah, CurrentSeries is going to be available [13:36] niemeyer, cool, thanks [13:36] niemeyer, is that going to be directly on Environ? [13:37] niemeyer, CurrentSeries^^ [13:37] fwereade: No, it's a global based on the current machine IIRC [13:38] fwereade: So should be usable from elsewhere, as long as we have no loops [13:38] niemeyer, hmm, ok; I presume it will be an env setting at some stage soon, though? [13:38] fwereade: Ah, yep [13:38] fwereade: That's something else, sorry, I misunderstood [13:39] fwereade: DefaultSeries coming from the env config will certainly be accessible via Conn, since it's stored in the State [13:39] niemeyer, I have a feeling that rog and dave are both circling that general area so I'm rather reluctant to start implementing that sort of stuff [13:39] fwereade: I don't *think* either of them are looking at it now [13:40] niemeyer, hm, ok, I though I saw a CL from dave that was State.Environment [13:40] niemeyer, just a ConfigNode for now but clearly a start [13:40] fwereade: Uh.. maybe I missed it [13:40] * niemeyer looks at review queue [13:40] add-environment.. suspect.. looking [13:40] niemeyer, https://codereview.appspot.com/6261055/ [13:41] fwereade: Yep, looks good [13:43] fwereade: Hmmm [13:43] fwereade: I'm a bit sad that we'll be poking at that configuration manually [13:43] fwereade: For well-known keys [13:44] niemeyer, I was a bit uncertain about it; trying to remember the discussion we had at UDS [13:44] fwereade: Wondering if DefaultSeries + SetDefaultSeries are reasonable [13:44] fwereade: and whether they should be adding to that same setting, or living outside [13:44] fwereade: These settings will be common for all providers, I suspect [13:45] niemeyer, I'm hoping for a separate type for common env settings that we can manipulate nicely [13:45] fwereade: I'd like that too [13:45] fwereade: We don't even need a separate type, I suppose.. state.DefaultSeries() might work [13:46] niemeyer, hmm... DefaultSeries and Constraints are both common env settings, and PlacementPolicy may end up becoming one too... with 3 candidates for that sort of thing I'm reluctant to tack it directly onto State [13:47] fwereade: Why? What do we get by injecting them in another type? [13:47] TheMue, fwereade, niemeyer: here's how it looks when we store units inside services rather than as a global thing. https://codereview.appspot.com/6247066 [13:47] niemeyer, it's just that State feels big enough already :) [13:48] fwereade: It does, because indeed it has a lot of stuff.. but I'm not sure that having to do state.EnvironSettings().SetDefaultSeries(...) is any better [13:48] niemeyer, yeah, maybe so [13:49] fwereade: can DefaultSeries be modelled as a constraint? [13:50] fwereade: Maybe the fact we can change multiple things at once and then flush might justify having a separate type [13:50] rog, IIRC I couldn't quite find a clean way to do so [13:50] rog, but it's clearly that species of kidney from a certain perspective [13:50] fwereade: do you remember why, by any chance? [13:51] rog: Ah, no, it's actually not part of the constraint, and there's a good reason [13:51] rog: It's part of the charm URL [13:51] rog, I think it's that it's the only thing that's a charm constraint as well as a machine constraint [13:51] rog, so it ends up feeding into the constraints [13:52] rog, but it isn't really one itself [13:53] fwereade, niemeyer: couldn't we just take it from the constraints anyway? if we have no constraints, then we'll need to decide somehow and then that will have to be an instance constraint, presumably [13:54] rog, IMO that is likely to end up a bit convoluted [13:54] rog, we've already decided, based on the charm, before other constraints really come into play [13:55] fwereade: so does it ever make sense to have a "series" constraint that doesn't match DefaultSeries? [13:55] rog: No, can't come from the constraints, because the charm has a URL [13:55] rog: That's where the decision comes from [13:55] rog, juju deploy oneiric/wordpress [13:56] fwereade: so maybe one way of looking at it is that the *charm* implies some constraints. [13:56] rog, absolutely so [13:57] rog, ubuntu-series is a computed constraint that's never exposed in the UI but is used in picking image [13:59] fwereade: I'm tempted to suggest we just state.SetDefaultSeries => state.EnvironConfig().Set("default-series", ...) [13:59] fwereade: Or maybe not even that, actually.. it's not clear we'll ever set this value through the API outside of environment changes [14:00] fwereade: Given that the client API is actually "juju set-env default-series=oneiric" [14:00] fwereade: Right? [14:00] fwereade: Or did you have something else in mind? [14:00] niemeyer, yeah, I think so [14:00] fwereade: The reading aspect seems to make sense, though [14:01] fwereade: I mean [14:01] niemeyer, all I'm really saying is that I'll want to know how to read it at some point soon :) [14:01] fwereade: Having state.DefaultSeries() => EnvironConfig().Get("default-series") [14:01] fwereade: jinx [14:01] ;) [14:01] niemeyer, :p [14:01] sounds good to me [14:13] niemeyer, btw, ty for Resolve review; ok to sumbit if I err out on empty local path (and make the other changes ofc ;))? [14:16] rog, btw, the unit path change looks really nice to me [14:16] rog, is this something we've agreed to go with or just something you're throwing out there for discussion? [14:17] rog, if the former I'll give it a more detailed look :) [14:28] fwereade: Yeah, that's implied by the LGTM [14:28] fwereade: If you think something might be done differently, or disagree with one of the points, a new review makes sense, otherwise a change+submit is fine on LGTM [14:29] niemeyer, cool, cheers, wasn't quite sure how to interpret the "should we" ;) [14:30] fwereade: just been discussing with gustavo [14:30] Very warmly.. I feel sorry for Aram :) [14:30] fwereade: couple of changes coming up in a mo [14:30] We agree, though, as usual [14:34] OKAY! [14:34] Time to head home [14:35] A good weekend to all, and wish me luck on hiding the big aluminum cigar [14:35]