wrtpdavecheney: what are you working on currently, BTW?04:08
fwereadedavecheney, heyhey06:33
fwereademramm, what part of the world are you in atm? :)08:06
davecheneyi don't think he's real08:07
davecheneyhis internets might have burped08:07
davecheneyit's liek 4am for him08:07
niemeyerGood morning!08:19
fwereadeniemeyer, heyhey08:21
fwereadeniemeyer, goodness, where are you today?08:21
niemeyerfwereade: Nice summary on the upgrade stuff, cheers08:21
fwereadeniemeyer, cool08:21
niemeyerfwereade: Still at home, just alert enough to feel motivated to do something :)08:22
fwereadeniemeyer, well, awesome :008:22
niemeyerOh, hey, we've just moved within the company..08:50
* niemeyer gets the boxes08:50
fwereadeniemeyer, sorry, what happened?08:50
niemeyerfwereade: See email from Jane as of 4mins ago08:50
fwereadeniemeyer, ah, ok08:51
fwereadeniemeyer, well, yay robbie!08:53
niemeyerindeed :)08:53
wrtpfwereade, davecheney, niemeyer: morning!09:06
niemeyerwrtp: Morning!09:06
fwereadewrtp, heyhey09:09
wrtpfwereade: are you sure you were looking at the latest version of https://codereview.appspot.com/6495086/ when you made your most recent comments?09:11
fwereadewrtp, hmm, perhaps not... I just followed the links in your response09:11
fwereadewrtp, aw crap sorry, 2 new revs -- I'll double-cjeck09:11
wrtpfwereade: ah! that would take you to the previous version, i think (unchanged)09:11
wrtpfwereade: no wonder you didn't think it was fixed!09:12
fwereadewrtp, LGTM09:13
wrtpfwereade: phew!09:13
fwereadewrtp, sorry crack :/09:13
wrtpfwereade: that's fine; very easy to do.09:14
fwereadeniemeyer, does anyone actually use upgrade-charm --dry-run? ISTM that it's kinda worthless, because the charm that would be upgraded to when you dry-run is not necessarily the charm that will be upgraded to when you do it for real09:26
niemeyerfwereade: I certainly wouldn't mind leaving the option for a second moment when we understand how it should really behave09:27
fwereadeniemeyer, cool, I'll leave it out of the first attempt then :)09:28
* niemeyer => breakfasting09:48
niemeyerInvites sent11:00
niemeyerwrtp: ping11:02
wrtpniemeyer: pong11:02
niemeyerwrtp: Meeting time11:02
wrtpniemeyer: just quitting apps on my mac so i can use G+11:02
niemeyerAny chance of a quick review on https://codereview.appspot.com/6501114/ so I can consider these bits done and move onto reviews?11:54
fwereadeniemeyer, looking11:54
niemeyerfwereade: Cheers!11:54
fwereadeniemeyer, LGTM, couple of trivial comments, ignore them if you like :)12:10
niemeyerfwereade: THanks!12:12
wrtpniemeyer: a little question: what's the use case for Watcher.Dying?12:15
niemeyerwrtp: See the machine watcher12:18
niemeyerwrtp: It's in use already12:18
wrtpniemeyer: wouldn't Dead be more appropriate?12:19
wrtpniemeyer: Dying kinda seems like it's an internal state transition of the watcher on its way to being dead.12:20
fwereadelunch, bbs12:28
niemeyerwrtp: Yeah, perhaps12:31
niemeyerwrtp: Do you see any edge cases where this might be a problem?12:31
wrtpniemeyer: no. i don't think there's any case when you want to know when a watcher is *about* to die12:32
niemeyerwrtp: Do you see any edge cases where using Dying might be a problem?12:32
wrtpniemeyer: it gives us leeway to change tomb to record more than one error in the future if we like12:33
niemeyerwrtp: Doesn't feel very compelling.. if we change tomb to behave differently, we might also change the watcher to behave differently12:34
wrtpniemeyer: and it just seems like something that doesn't need to be visible - the concept of dead is already there (Wait returns), but Dying is something different12:34
wrtpniemeyer: the tomb isn't part of the watcher interface12:34
niemeyerwrtp: Indeed.. but exposing Dead or Dying mean exactly the same as far as that perspective is concerned12:35
wrtpniemeyer: if we wait for Dead, we don't necessarily have to call Wait for it to die completely.12:36
wrtpniemeyer: if we wait for Dying, we do12:36
niemeyerwrtp: We don't call Wait, and we don't have to as far as I can see12:36
wrtpniemeyer: we call Stop12:36
niemeyerwrtp: Exactly12:36
niemeyerwrtp: Which we must12:36
wrtpniemeyer: even when it's told us it's dead?12:37
niemeyerwrtp: We must call Stop on state.Close, no matter what12:37
niemeyerwrtp: We're not going to be passing information between the watcher and the Close method12:37
niemeyerwrtp: Makes sense?12:40
wrtpniemeyer: i'm trying to think whether there might be a case where the message from, say, Watcher.Alive, might override the underlying error encountered by the presence.Watcher12:41
wrtpniemeyer: but perhaps that's simply an argument for including watcher.tomb.Err in the error message12:43
niemeyerwrtp: Yeah, possibly12:43
niemeyerwrtp: I was on the fence on that, but it does sound like a good idea from that perspective12:44
wrtpniemeyer: actually, Machine.WaitAgentAlive is a better example from that pov12:44
wrtpniemeyer: and if we're going to do that, then i think we *should* have Dead, not dying12:45
wrtpniemeyer: because we'll want to record any error encountered after it's been explicitly stopped.12:45
niemeyerwrtp: Sorry, I lost the leap12:45
niemeyerwrtp: The thing that caused the unit to die is there once Dying kicks12:46
wrtpniemeyer: yes, but the unit might have been explicitly stopped (no useful error message) but then actually encounter an error when shutting down, which we'd want to see12:47
niemeyerwrtp: Exactly, and that was the reason why it returned, and the reason why the cascading watcher was canceled12:47
niemeyerwrtp: It's as honest as it can be12:47
wrtpniemeyer: but if we're watching *Dying*, the error might not have been encountered yet12:47
wrtpniemeyer: because the watcher might only be just reacting to the dying message itself12:48
niemeyerwrtp: That's what I meant12:48
niemeyerwrtp: I'm fine to see a "returning because watcher was explicitly stopped" message if that's what actually happened12:49
niemeyerwrtp: The error from the watcher is an internal error, that will be visible from Close12:49
wrtpniemeyer: it may not12:49
wrtpniemeyer: because we might just have recorded the first error we encountered in a tomb before calling Close.12:50
niemeyerwrtp: Please read the Close method12:50
niemeyerwrtp: It returns the error from Stop from either watcher12:51
niemeyerwrtp: Besides that, to be honest if the watcher errored when terminating, and that error caused nothing to fail except the result of Stop, it's pretty boring error12:52
niemeyerwrtp: Feels a bit like we're hunting witches12:52
wrtpniemeyer: that may be true. but it's so easy to fix (use Dead rather than dying) that i'd rather have it work12:53
niemeyerwrtp: There's nothing to fix, so far12:53
wrtpniemeyer: it's this kind of code i was wondering about: http://paste.ubuntu.com/1198576/12:53
niemeyerwrtp: This is artificial12:53
niemeyerwrtp: There's no such thing as12:53
niemeyerdefer watcher.Stop(t.presenceWatcher, &t.tomb)12:53
wrtpniemeyer: oh, i'm probably misremembering12:53
niemeyer<niemeyer> wrtp: We don't call Wait, and we don't have to as far as I can see12:54
niemeyer<wrtp> niemeyer: we call Stop12:54
niemeyer<niemeyer> wrtp: Exactly12:54
niemeyer<niemeyer> wrtp: Which we must12:54
niemeyer<wrtp> niemeyer: even when it's told us it's dead?12:54
niemeyer<niemeyer> wrtp: We must call Stop on state.Close, no matter what12:54
niemeyer<niemeyer> wrtp: We're not going to be passing information between the watcher and the Close method12:54
niemeyerwrtp: I'm happy to change as it makes no difference, but there's no factual reason that I can see12:54
wrtpniemeyer: slightly more realistic, perhaps: http://paste.ubuntu.com/1198581/12:56
wrtpniemeyer: but tbh nothing is gonna be deliberately closing the state underfoot apart from tests12:57
wrtpniemeyer: another reason to use Dead is it makes the error message more deterministic - w.Err() can change after Dying, but not after Dead.12:58
niemeyerwrtp: It can't in this case12:59
niemeyerwrtp: If there's an error with the watcher alive, it means we have a real error or we screwed up12:59
niemeyerwrtp: watcher.MustErr(st.watcher)13:00
niemeyerwrtp: That's there13:00
niemeyerwrtp: Which means that error won't change13:00
niemeyerwrtp: Ah, not in agent alive, nevermind13:01
niemeyerwrtp: Sure, anyway.. we can change13:01
wrtpniemeyer: i know it's a little thing, but worth doing IMHO13:02
wrtpniemeyer: thanks!13:02
niemeyerwrtp: np, can you do a CL with this?13:10
wrtpniemeyer: sure13:10
niemeyerwrtp: There's Dying both in mstate/watcher and presence13:10
niemeyerfwereade: Just sent a review13:13
fwereadeniemeyer, cheers13:13
niemeyerfwereade: Great stuff, mostly trivials or questions for awereness13:14
fwereadeniemeyer, cool13:14
fwereadeniemeyer, (sometimes it's the questions for awareness that blow the whole thing out of the water, ofc ;))13:14
niemeyerfwereade: LOL13:14
niemeyerfwereade: I don't think that's the case in this instance :-)13:14
fwereadeniemeyer, good-oh :)13:15
fwereadeniemeyer, sent responses, I'll gtw on the non-controversial ones :)13:22
niemeyerfwereade: Re-proposed https://codereview.appspot.com/6501114 too13:30
* fwereade looks13:30
fwereadeniemeyer, ok, about changes in pending -- can a sync happen on a different goroutine?13:33
niemeyerfwereade: nope13:33
niemeyerfwereade: It's all done in a single goroutine13:33
fwereadeniemeyer, ok great :)13:33
niemeyerfwereade: Yeah, it's complex enough without concurrency issues :)13:33
fwereadeniemeyer, the trouble is that it makes sense now, so I can't say what would have made it easier to begin with :)13:34
wrtpfwereade: i think that once you've got used to that kind of pattern, it's fairly easy to spot and verify when you're reading the code.13:35
fwereadeniemeyer, LGTM13:36
niemeyerfwereade: LGTM too (and that's not just an exchange, promise ;)13:40
fwereadeniemeyer, haha13:40
niemeyerfwereade: I'll check the new comment when you submit13:41
niemeyerwrtp: I'm pushing a trivial branch with the suggested s/Dying/Dead/13:47
wrtpniemeyer: ok, thanks, sorry, i'm still debugging a change to the authorize ec2 branch13:48
niemeyerwrtp: np, that's kind of the point.. you're surely doing more interesting stuff and I'd rather unblock you13:48
wrtpniemeyer: that's appreciated, thanks13:48
fwereadeniemeyer, btw, in case you missed it, the one you reviewed is still blocked on https://codereview.appspot.com/6489083/13:48
niemeyerwrtp: np13:49
niemeyerfwereade: I've half-missed it13:49
niemeyerfwereade: I was already reviewing when I noticed it had a pre-req13:49
fwereadeniemeyer, np13:51
niemeyerwrtp: https://codereview.appspot.com/648911113:55
wrtpniemeyer: reviewed13:56
niemeyerwrtp: cHeers13:57
fwereadeniemeyer, re ModeUpgrading: it's perfectly legitimate to enter ModeUpgrading in an error state, and all the hook-error-related logic is now in Uniter itself -- I'm going to just drop mention of errors in the ModeUPgrading comment14:03
niemeyerfwereade: Sounds good, that was my confusion.. it's talking about errors despite it not really doing anything about them, or even needing anything given what you say14:04
niemeyerniemeyer> fwereade: Sounds good, that was my confusion.. it's talking about errors despite it not really doing anything about them, or even needing anything given what you say14:09
niemeyerfwereade: By the way, I had to look over Abide in the dictionary, thanks :-014:10
wrtpniemeyer: a trivial ec2test fix: https://codereview.appspot.com/6501117/14:11
niemeyerfwereade: Seems very appropriate, btw14:12
fwereadeniemeyer, fantastic, I just couldn't get over a feeling that I was being hipster-weirdy, despite not being able to come up with a better term :)14:13
niemeyerfwereade: Steady would be another choice14:13
fwereadeniemeyer, I feel that once I've called it an operation it kinda needs to be a verb14:14
niemeyerfwereade: makes sense14:14
niemeyerwrtp: So what's up there?14:14
wrtpniemeyer: when i wrote ec2test i thought that (as according to the docs) you could not specify source group names without also specifying an owner id.14:15
wrtpniemeyer: that's not true, and it's nice if we can specify a name only.14:15
niemeyerwrtp: Okay, I had the same impression14:15
niemeyerwrtp: LGTM if it reflects reality14:16
wrtpniemeyer: it means we don't need a special-case hack for authorizing self in ec2.environ.ensureGroups.14:16
wrtpniemeyer: and it does seem to work live. perhaps i should include a server test to make sure within the ec2 package itself.14:17
niemeyerfwereade: Sent comment on https://codereview.appspot.com/6489083/14:52
fwereadeniemeyer, great, tyvm14:52
niemeyerwrtp: Sounds good14:52
niemeyerfwereade: np, one point I'd appreciate talking for understanding only, otherwise only boring/trivial stuff14:52
fwereadeniemeyer, the SetCharm/Write/Deploy?14:54
fwereadeniemeyer, my feeling is that because a Deploy is always preceded by a SetCharm, we only need to commit to the upgrade state once we're about to write to the actual deployment directory14:56
fwereadeniemeyer, if we happen to SetCharm twice due to unhelpful process bounces, it's no big deal (in fact SetCharm will just return)14:58
niemeyerfwereade: Why isn't it simply Deploy(u.charm, url), or something similar?14:58
fwereadeniemeyer, ha, good question14:59
niemeyerfwereade: I'm not finding the place where deploy() is called14:59
fwereadeniemeyer, primarily because the sheer amount of code in one method was getting me down, and it seemed like a good idea at the time14:59
* niemeyer looks at the raw diff15:00
fwereadeniemeyer, ModeInstalling is the only place in that tree, I think15:00
fwereadeniemeyer, sorry to be talking about upgrade above, that's the way I tend to think about it -- but, yes, that CL doesn't include any upgrading15:02
niemeyerfwereade: That's certainly fine15:03
wrtpniemeyer: ok, the functionality is now tested live (and a couple of live tests were fixed in the process)15:03
wrtpniemeyer: https://codereview.appspot.com/6501117/15:03
niemeyerfwereade: Why we use the urls that we SetCharmURLs again?15:04
niemeyerwrtp: Cheers15:04
fwereadeniemeyer, sorry, cannot parse15:05
niemeyerfwereade: Trying to figure what we do with the info we give deployer.SetCHarm15:05
fwereadeniemeyer, all we use it for *directly* is to avoid setting the same charm again; indirectly it's also returned from u.charm.ReadURL or whatever it's called15:06
fwereadeniemeyer, which itself is used to compare against service-charm-change events to determine whether or not we care15:08
fwereadeniemeyer, u.charm.ReadCharmURL15:09
niemeyerfwereade: Now that I went looking for them, it seemed slightly surprising to have ReadCharmURL/WriteCharmURL on GitDir..15:09
niemeyerfwereade: We should probably move those to functions later15:09
fwereadeniemeyer, hmm, it *is* a charm.GitDir15:09
fwereadeniemeyer, it seemed like a great idea to me at the time15:10
fwereadeniemeyer, I presume you're seeing an ugliness I'm missing15:10
niemeyerfwereade: GitDir is not about charm at all, except for those two trivial functions, where one of them is a single line15:10
fwereadeniemeyer, well, I'm perfectly happy to move them out, but it feels *slightly* more than coincidental that both GitDir clients find them useful15:11
niemeyerfwereade: Which is great, I'm not complaining about where we are15:11
niemeyerfwereade: These functions should definitely be within charm, and they can easily take a GitDir15:12
fwereadeniemeyer, ok, that SGTM :)15:12
niemeyerfwereade: The logic is the same.. it's just that git has no read-charm command :)15:13
fwereadeniemeyer, true :)15:13
niemeyerfwereade: Anyway, that was a derail, sorry15:13
fwereadeniemeyer, np at all, nice easy trivial for later15:13
wrtpweird bzr behaviour: http://paste.ubuntu.com/1198834/15:14
wrtpi can't make it push the branch15:14
wrtpwhich causes lbox to fail when proposing15:14
wrtpit works if i fork the branch, delete the old one and rename to the old name15:15
wrtpniemeyer: any ideas?15:15
niemeyerfwereade: So, the separation definitely sounds sensible.. my memories were betraying me15:16
niemeyerfwereade: I thought SetCharm was doing something else15:16
fwereadeniemeyer, np, mine do the same quite frequently ;p15:16
niemeyerfwereade: I'm wondering how we can name it in a way that feels like SetCharm and Deploy are complementary operations, that operate on different backing data and do not conflict15:18
fwereadeniemeyer, Prepare/Run perhaps?15:18
niemeyerfwereade: Hmm.. Stage+Deploy?15:18
fwereadeniemeyer, +115:18
niemeyerfwereade: Super15:18
niemeyerwrtp: Looking15:19
niemeyerwrtp: % bzr commit -m 'change to try to force bzr to remember push loc'15:19
niemeyerwrtp: commit doesn't do that15:19
niemeyerwrtp: push --remember does that15:19
fwereadeniemeyer, I think I'll propose a trivial rename branch from trunk for the ones we just discussed15:19
wrtpniemeyer: i tried push --remember - it didn't do anything. so i thought i'd try a source change too.15:20
niemeyerwrtp: Understood, but changing the history has no relation to metadata15:20
wrtpniemeyer: ok, thanks. so ignore that line and you'll see that there's a problem.15:21
wrtpniemeyer: (i think)15:21
niemeyerwrtp: See the .bzr/cobzr/<name>/.bzr/branch/branch.conf file15:22
niemeyerwrtp: and see where it is pointing to15:22
niemeyerfwereade: Cool15:23
niemeyerfwereade: So, regarding the WriteState15:23
fwereadeniemeyer, yes15:23
wrtpniemeyer: push_location = file:///home/rog/src/go/src/launchpad.net/juju-core/.bzr/cobzr/051-authorize-internal-traffic/15:23
wrtpniemeyer: which looks very odd15:24
niemeyerfwereade: now that my mind is not totally wrong :)15:24
fwereadeniemeyer, the underlying idea is to wait as long as possible before we persist the fact that we're upgrading to charm X15:24
wrtpniemeyer: i'll try and reproduce the problem from scratch with lbox -v15:24
fwereadeniemeyer, the motivation for doing so is pretty weak, to be fair15:25
niemeyerfwereade: What is it?15:25
niemeyerwrtp: This isn't about lbox, or even cobzr15:25
niemeyerwrtp: This is plain bzr15:25
wrtpniemeyer: ok15:25
fwereadeniemeyer, very specific situation: uniter falls down having Staged a new charm, and the user pushes a new charm version before it comes up again -- this means that it will see the newest charm and upgrade directly to that15:26
niemeyerwrtp: I don't know why it is misbehaving15:26
niemeyerwrtp: Try to delete the push line there15:26
fwereadeniemeyer, the adverse consequences of just installing the first charm then the second one are pretty minimal to be fair15:26
wrtpniemeyer: when i fork a fresh branch, the push line is gone. but then it reappears.15:26
niemeyerfwereade: Doesn't it also mean it'll download the charm twice on the other scenario?15:27
fwereadeniemeyer, downloads won;t be repeated; stages won;t be repeated15:27
fwereadeniemeyer, it's easy to detect prior completion of each of those15:27
niemeyerfwereade: Cool, I'm happy with the current logic, thanks15:28
fwereadeniemeyer, BundlesDir caches, and Stage checks for the existing charm url15:28
fwereadeniemeyer, sweet15:28
wrtpniemeyer: yeah you're right, it's just bzr. http://paste.ubuntu.com/1198862/15:29
niemeyerwrtp: Very weird, either way15:30
wrtpniemeyer: indeed15:31
niemeyerStepping out for lunch, biab15:34
fwereadewrtp, can I get a LGTM on the trivial I just discussed? https://codereview.appspot.com/648911215:37
wrtpfwereade: LGTM15:39
fwereadewrtp, lovely, thanks15:39
=== hazmat is now known as kapilt
wrtpfwereade: was there a particular reason you didn't make the "run uniter" branch run the upgrader task?17:08
* niemeyer waves17:30
* wrtp waves back to niemeyer17:39
wrtpniemeyer: ec2test fix submitted, thanks.17:39
niemeyerwrtp: Thank you!17:43
wrtpAram: yo!17:44
niemeyerAram: Hi17:44
Aramsorry everybody.17:44
Aramhad internet troubles :(.17:44
Aramniemeyer: have you seen my latest review for machine watcher?17:46
Arammy comment about TxnRevno17:46
niemeyerAram: Yes, just answering it now17:46
wrtpAram: we should all swap mobile numbers so we can have an alternative comms channel when something like that happens17:47
Aramwrtp: agreed.17:47
wrtpniemeyer: it's a good day for bzr oddities: http://paste.ubuntu.com/1199119/17:50
niemeyerAram: Responded17:52
niemeyerwrtp: lp:launchpad.net?17:53
wrtpniemeyer: oh jeeze, i just couldn't see it! thanks. :-|17:54
niemeyerwrtp: I know how it goes18:00
niemeyerwrtp: Sometimes everything just feels broken and it's hard to see even the typos18:01
wrtpniemeyer: yeah18:01
wrtpniemeyer: i kinda new it was something obvious but i just couldn't see it!18:01
niemeyerfwereade: Is there anything I can do on https://codereview.appspot.com/6489083 to help out, or are you working on it still?18:03
wrtpniemeyer: can i put in a small request for a review of https://codereview.appspot.com/6501106/ ? i'm using it as a prereq for quite a lot of stuff.18:05
niemeyerwrtp: Will check it right now18:05
wrtpniemeyer: thanks18:05
niemeyerwrtp: done18:35
wrtpniemeyer: thanks a lot18:37
niemeyerwrtp: My pleasure, glad to see the progress there18:37
wrtpniemeyer: there's also https://codereview.appspot.com/6495086/ which you mostly reviewed about a week ago, but i changed it a bit since then.18:38
wrtpniemeyer: i think you'll like it :-)18:38
niemeyerwrtp: Cheers, I am going through the review list.. if you're not blocked on it, I'll get to it soon18:47
wrtpniemeyer: it is a prereq of another branch which i'm building on in turn, but i wouldn't say i'm blocked on it as such.18:47
wrtpniemeyer: i'm off now. see you tomorrow & have fun.18:56
niemeyerwrtp: have a good one18:58
niemeyer_Not only the queue is clean, but we have 9 branches on the runway to land21:23
=== kapilt is now known as hazmat

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!