=== amithkk is now known as Guest39143
fwereadeTheMue, rogpeppe1, mornings08:15
TheMuefwereade: Hiya08:15
fwereadeTheMue, rogpeppe1: I have a philosophical uncertainty, perhaps one of you can explain why we distinguish between dead and not found08:16
TheMuefwereade: In a fresh pulled trunk, is go test in .../cmd/jujud working for you?08:17
TheMuefwereade: Dead IMHO already has existed while not found may not be yet there.08:18
fwereadeTheMue, it was last night, let me doublt check08:18
TheMuefwereade: Thx08:18
TheMuefwereade: I pulled a fresh one too due to remaining errors and have those errors with the password changing there too.08:19
fwereadeTheMue, but I don't see what the justification *is* for distinguishing those cases08:19
fwereadeTheMue, still works for me :(08:19
fwereadeTheMue, take remove-unit08:20
fwereadeTheMue, if a unit is Dying/Dead it's fine to "remove" it again08:20
TheMuefwereade: Hmm, strange. Standard mongo or a special one?08:20
fwereadeTheMue, but there's a specific point at which that becomes invalid08:20
rogpeppe1fwereade: morning08:20
fwereadeTheMue, I think I'm using the usual special mongo -- is there maybe a more-recently built one that you have but I don't?08:21
TheMuerogpeppe1: Heyhey08:21
fwereaderogpeppe1, heyhey08:21
rogpeppe1fwereade: do you think we should return not found when something's dead?08:21
TheMuefwereade: That may be the reason.08:21
TheMuefwereade: *gnarf* I can't remember where to get the special one.08:22
rogpeppe1TheMue: the URL is in environs/cloudinit/cloudinit.go :-)08:22
fwereaderogpeppe1, heh... the trouble is, not *always*... but the number of cases in which we do want to return dead enitities is vanishingly small08:22
TheMuerogpeppe1: Well hidden documentation. ;)08:22
rogpeppe1fwereade: when *do* we want to return dead entities?08:22
fwereaderogpeppe1, deployers are responsible for removing dead units; provisioners are responsible for removing dead machines08:23
fwereaderogpeppe1, I *think* that's an exhaustive list08:23
rogpeppe1fwereade: well, those are two reasons we *do* need to distinguish between dead and not found...08:24
fwereaderogpeppe1, they seem to me to be very special cases08:25
rogpeppe1fwereade: what do you think we should do in the other cases?08:26
fwereaderogpeppe1, the trouble is that I don't know08:28
fwereaderogpeppe1, but remove-unit is making me a bit suspicious08:28
fwereaderogpeppe1, why is it ok to remove a Dying or Dead unit, but not one that doesn't exist?08:28
rogpeppe1fwereade: i'd be happy if we did the same thing for a dead unit as we do for a unit that doesn't exist08:29
rogpeppe1fwereade: you're just implementing remove-unit, i presume08:30
fwereaderogpeppe1, looking at it in order to disallow direct subordinate removal, yeah08:31
rogpeppe1fwereade: you mean destroy-unit, presumably :-)08:31
fwereaderogpeppe1, yeah ;p08:31
fwereaderogpeppe1, so, ok, why allow removal of Dying units?08:32
rogpeppe1fwereade: the issue, i suppose, is that if you don't distinguish the cases, you can do destroy-unit dsknslv/345 and it'll work08:32
fwereaderogpeppe1, ISTM that "each entity may only be destroyed once" makes sense08:33
fwereaderogpeppe1, in which case Dying should also be disallowed08:33
rogpeppe1fwereade: that would be reasonable too, i suppose08:33
fwereaderogpeppe1, *or* that destroy-unit should be seen as almost declarative -- "I require that no unit name burble/123 exist -- make it so"08:33
rogpeppe1fwereade: i wouldn't mind a different error message when killing a dying unit vs killing a dead or removed unit though08:33
fwereaderogpeppe1, if no so named unit exists, nbd, why complain?08:34
rogpeppe1fwereade: yeah, they're both reasonable approaches08:34
fwereaderogpeppe1, but we're kinda mixing them :(08:34
rogpeppe1fwereade: yes, i agree that's probably wrong08:34
rogpeppe1fwereade: the problem is if you make a typo trying to remove a unit - you won't get told if you get it wrong.08:35
rogpeppe1fwereade: (with the declarative approach)08:35
fwereaderogpeppe1, yeah... but with the other approach a perfectly sensible destroy request can be borked by a parallel destroy request for just one of the units you're trying to destroy08:37
rogpeppe1fwereade: yes, but perhaps that's as ok as it is when removing files08:38
fwereaderogpeppe1, mmmaybe :)08:38
rogpeppe1fwereade: pity we've already got --force and it means something different, otherwise we could have -f mean "don't complain if it's already gone" like rm08:41
fwereaderogpeppe1, yeah, I think you're right08:41
fwereaderogpeppe1, actually we *don't* have --force yet08:42
rogpeppe1fwereade: but we will08:42
fwereaderogpeppe1, yeah, but it doesn'thave a named already baked into reality, so we're a lot more free to tweak it now ;p08:42
rogpeppe1fwereade: doesn't the python version have --force?08:43
fwereaderogpeppe1, hm, I didn't think it did08:43
fwereaderogpeppe1, I think python just removes the node and hopes the unit agent can pick up the pieces08:43
rogpeppe1fwereade: maybe it doesn't. but anyway, we know roughly what semantics we want from --force, i think, and just silencing not-found errors isn't as useful...08:44
fwereaderogpeppe1, if we do everything right, --force will not be useful at all08:44
rogpeppe1fwereade: isn't the point of --force that it can work if a node is isolated or hung up and can't take itself down?08:45
fwereaderogpeppe1, the point of --force is to decref refs that are not being decced due to hopelessly broken code, I think08:46
rogpeppe1fwereade: that's what i mean08:46
fwereaderogpeppe1, if the node is isolated it will not respond to being Dead any better or worse than it will to Dying08:46
fwereaderogpeppe1, ah, probably, sorry08:46
rogpeppe1fwereade: "hopelessly broken" might be "i poured some water on the machine"08:47
rogpeppe1fwereade: but anyway, that's a much more useful semantic than ignoring not-found errors08:47
TheMuerogpeppe1: Found that I already had downloaded the special mongo, but seem to have been interrupted when installing it. I still had the original package.08:49
fwereaderogpeppe1, if it's just that the hardware is a smoking crater, we can handle that08:49
rogpeppe1fwereade: really? how do we do that?08:50
fwereaderogpeppe1, assuming the provider knows about it, the PA will redeploy the unit to a fresh instance08:50
rogpeppe1fwereade: really? how does it know when it's appropriate to do that?08:52
fwereaderogpeppe1, when there's no actual instance for a machine with an instance id set08:53
fwereaderogpeppe1, doesn't it?08:53
rogpeppe1fwereade: the instance may well be still around08:53
rogpeppe1fwereade: depends on the failure mode08:53
TheMuerogpeppe1: Could you send me your init script for mongod? Would be faster. ;)08:53
rogpeppe1TheMue: my init script?08:53
fwereaderogpeppe1, yeah, but its ability to cause trouble is strictly curtailed by the fact that the PA will set a new password08:54
TheMuerogpeppe1: Or how do you start mongod locally?08:54
fwereaderogpeppe1, (btw what happens if your password changes mid-connection? do you get kicked off?)08:54
fwereaderogpeppe1, (I presume not)08:54
fwereaderogpeppe1, (hmm)08:54
rogpeppe1TheMue: the test suite starts mongod08:54
fwereadeTheMue, I just have the fancy mongo in ~/bin and have that at the front of my $PATH08:55
rogpeppe1fwereade: i don't think you do get kicked off, though i remember having that question before and i can't quite remember for sure the answer08:55
fwereaderogpeppe1, ah! you don't I'm sure08:55
fwereaderogpeppe1, we set new passwords in jujud and just keep going08:55
fwereaderogpeppe1, haven't spotted even long-running agents falling over as a result08:56
fwereaderogpeppe1, bah08:56
rogpeppe1fwereade: anyway, the question is how the provisioner can tell that a unit is borked when the provider can't tell that08:56
fwereaderogpeppe1, that said, that's something that can be handled by the API I guess08:56
TheMuerogpeppe1: Ah, interesting, because I didn't had that, only the standard mongo running by the standard init script at boot time (may be the cause for the troubles too). And the test suit never complained.08:56
rogpeppe1TheMue: the test suite always starts its own mongod08:56
fwereaderogpeppe1, it does indeed depend on the failure mode08:57
rogpeppe1TheMue: it runs it from your $PATH08:57
rogpeppe1fwereade: so that's the common use case i see for destroy-unit --force08:57
TheMuerogpeppe1: Yes, and it doesn't cares if it is the special version or not.08:57
rogpeppe1TheMue: it can't tell08:57
rogpeppe1TheMue: (maybe it should actually - it could probably find out)08:58
fwereaderogpeppe1, forgive my slowness this morning... please describe a specific use case that you are thinking of08:58
fwereaderogpeppe1, or restated -- "what classes of borkenness we are concerned with re --force"?08:59
TheMuerogpeppe1: Yes, so one reminder to me to finish started installations. ;)08:59
rogpeppe1fwereade: some machine hangs up (a common enough occurrence if my laptop is anything to go by). the provider can't tell this has happened, so the deployer can't, so we need destroy-unit --force, no?09:00
fwereaderogpeppe1, hmm, if a machine hangs up I think that's a job for destroy-machine --force, and some tricky questions re reqssignment of units09:00
fwereaderogpeppe1, maybe it's ok to require manual forced unit removal before allowing the forced machine removal? not sure09:01
rogpeppe1fwereade: hmm, yes. i dunno.09:02
rogpeppe1fwereade: i think destroy-machine --force should probably do all it can to remove everything on the machine and the machine itself09:02
rogpeppe1fwereade: maybe don't need destroy-unit --force09:03
fwereaderogpeppe1, yeah that sounds sane actually09:03
fwereaderogpeppe1, at least while we don't have any control over unit assignment09:03
rogpeppe1fwereade: i'm not sure about the whole idea of reassigning units tbh09:04
fwereaderogpeppe1, yeah, nor am I09:04
fwereaderogpeppe1, ok, I think we're off in the weeds09:04
rogpeppe1fwereade: yup!09:04
fwereaderogpeppe1, I'm going to start complaining about destruction of anything non-alive09:04
rogpeppe1fwereade: sounds good09:04
fwereaderogpeppe1, that's the closest match to python behaviour09:05
fwereaderogpeppe1, now I come to think of it :) ^^09:05
fwereaderogpeppe1, thanks :)09:05
jamrogpeppe1: /wave09:20
rogpeppe1jam: yo09:20
rogpeppe1jam: shall we?09:20
jamrogpeppe1: I think martin also wanted to sit in, and I don't see him around yet.09:20
jam(which is a bit surprising, but maybe we'll see him shortly)09:20
rogpeppe1jam: ah yes, that's worth doing09:20
jamweird, I see w7z disconnect 3 hours ago, but nothing about things reconnecting. So we might as well have our chat. Let me set up a hangout09:32
rogpeppe1anyone else fancy talking about go package versioning?09:33
jamrogpeppe1, dimitern https://plus.google.com/hangouts/_/472c54386502b014c99e35ebd97a6b172f13c02b?authuser=2&hl=en#09:34
jamthough dimitern is grabbing some food for 15 min09:34
jamso we can take it slow :)09:34
=== TheMue_ is now known as TheMue
=== _mup__ is now known as _mup_
TheMuerogpeppe1: I'm getting crazy! *grmplfx*09:46
TheMuerogpeppe1: Now I removed the standard mongo and installed the special mongo in the hope that it may be one reason.09:46
dimiternjam, rogpeppe1: I'm ready - joininh09:47
TheMuerogpeppe1: First test run afterwards, Machine password change passed, but Unit failed.09:47
TheMuerogpeppe1: Second run, Machine failed, Unit passed.09:47
TheMuerogpeppe1: Third run, both failed. *aaaaaaaaaaaaaargh*09:48
TheMuerogpeppe1: And all on a fresh pulled trunk (808).09:48
* TheMue loves those kind of errors.09:49
TheMuerogpeppe1: Even more strange, when MachineSuite.TestChangePasswordChanging fails there are two different asserts from run to run while UnitSuite.TestChangePasswordChanging always fails at the same point (in bootstrap_test.go, like one of the two MachineSuite failures).10:02
rogpeppe1TheMue: on a call10:03
jammgz: https://plus.google.com/hangouts/_/472c54386502b014c99e35ebd97a6b172f13c02b?authuser=2&hl=en#10:03
TheMuerogpeppe1: ok10:03
jamif you want to chat about the versioning stuff.10:03
mgzjam, ta10:04
TheMuerogpeppe1: and I now know which one. ;)10:04
fwereadeaw, bugger, I thought it was weird that Unit.EnsureDying didn't need changes... of course it does10:19
jammgz: where did you go?10:34
rogpeppe1TheMue: you're sure that you're using the proper version of mgo10:34
mgzdidn't run upstairs quite fast enough :)10:35
TheMuerogpeppe1: Now yes, because I removed the original one I once had installed with apt.10:35
TheMuerogpeppe1: I'm especially wondering about this non-deterministic behavior.10:36
rogpeppe1TheMue: you've checked with the which command, yes?10:36
rogpeppe1TheMue: that does seem odd, right enough10:36
rogpeppe1TheMue: could you paste an error log from when the tests fail?10:37
TheMuerogpeppe1: yep, and there is only the version i just fetched with wget from the localtion in cloudinit.10:37
TheMuerogpeppe1: sure, one moment.10:37
rogpeppe1TheMue: sounds like the problem isn't with mgo then... probably :-)10:38
TheMuerogpeppe1: hehe, mongo as source has been my hope, but no10:38
rogpeppe1TheMue: it's weird that nobody else seems to be able to reproduce the same problems10:39
TheMuerogpeppe1: and it's no side effect of my changes, they are in a different branch and i'm here testing on fresh pulled trunks to just get rid of those errors10:39
TheMuerogpeppe1: maybe the reason is in my environment as i'm running it in a vm10:40
rogpeppe1TheMue: i'm wondering about that10:40
TheMuerogpeppe1: http://paste.ubuntu.com/1512321/10:41
TheMuerogpeppe1: here both fail the same way. i'll try to reproduce the other failure for the MachineSuite10:41
fwereaderogpeppe1, quick sanity check: I was planning to make unit.EnsureDying cause the subordinates to become Dying too, but that's actually annoyingly complex10:43
fwereaderogpeppe1, I think it's smarter to add to the uniter filter such that subordinates keep a watch on their principal and set themselves to Dyingwhen it becomes Dying10:44
fwereaderogpeppe1, with the caveat that I am not thinking about remove-unit --force at this time10:44
fwereaderogpeppe1, sane?10:44
rogpeppe1fwereade: i think that seems reasonable10:45
rogpeppe1TheMue: could you change the places in the code i suggested yesterday to print out the passwords when connecting and changing them?10:46
TheMuerogpeppe1: the other one is http://paste.ubuntu.com/1512325/10:46
TheMuerogpeppe1: yep10:47
fwereaderogpeppe1, actually, better yet: principal sets its own subordinates to Dying once it knows it's Dying10:50
rogpeppe1fwereade: yes, that's better.10:50
rogpeppe1fwereade: and works nicely in the face of crashes10:51
fwereaderogpeppe1, yep -- cool, thanks10:51
TheMuerogpeppe1: http://paste.ubuntu.com/1512352/ now has debug statements for the password setting in it11:06
fwereaderogpeppe1, TheMue: https://codereview.appspot.com/705806111:07
TheMuefwereade: *click*11:07
rogpeppe1TheMue: could you also add a debug statement in State.Open saying what entity name and password are being connected with?11:07
TheMuerogpeppe1: will change it, the pw is already in11:08
TheMuerogpeppe1: eh, entity name?11:09
rogpeppe1TheMue: info.EntityName11:09
TheMuerogpeppe1: oh, yes, missed it.11:10
TheMuerogpeppe1: this time i also had again the different machine fail -> http://paste.ubuntu.com/1512362/11:12
mgzjam: put the bucket for mongo things in the readme as well as you suggested, want to double check it and approve the mp?11:12
mgzor the rietveld version of the same...11:12
jammgz: I'm not seeing the MP11:13
jamnm, I think I saw it11:14
jammgz: btw, you need to run 'lbox propose' again to update the reitveld data, you can't just 'bzr push' to launchpad.11:15
jam(lbox propose will do the push for you, if you only want 1 step)11:15
mgzran it without -cr11:16
mgz's see what happens...11:16
mgz403... wonder if I just tyoped the password11:17
mgznope, worked fine with same creds re-ran with -cr11:18
TheMuefwereade: you've got a lgtm11:20
rogpeppe1TheMue: try putting this log statement after the ReadFile in the openState function in cmd/jujud/agent.go11:27
rogpeppe1log.Printf("agent open state, initial password %q; password in file: %q",  conf.InitialPassword, data)11:27
TheMuerogpeppe1: ok11:27
rogpeppe1TheMue: it looks like the agent isn't changing the password as it should be, and i'm not sure why11:28
TheMuerogpeppe1: hehe, this time machine worked, but unit still failed: http://paste.ubuntu.com/1512425/ (changed it from printf to debug btw).11:31
rogpeppe1TheMue: which is the line that i suggested above?11:33
rogpeppe1TheMue: or isn't it showing up?11:34
TheMuerogpeppe1: oh, seen it in a first run. will repeat it.11:34
rogpeppe1TheMue: (i'm not sure what you mean by changing from printf to debug)11:34
TheMuerogpeppe1: only that i used Debugf instead of Printf11:35
TheMuerogpeppe1: http://paste.ubuntu.com/1512450/11:36
TheMuerogpeppe1: wife just called me to lunch, back in a few moments11:36
TheMuerogpeppe1: so, back again11:58
rogpeppe1TheMue: try this branch and see what it prints: lp:~rogpeppe/+junk/jujud-debug12:03
TheMuerogpeppe1: ok, will do12:04
rogpeppe1TheMue: (it works fine on my machine, but i'm presuming it'll fail on yours)12:04
TheMuerogpeppe1: and i sadly think you're right :)12:04
rogpeppe1TheMue: that's good, actually. at least the bug is reproducible12:05
TheMuerogpeppe1: here we are, as expected: http://paste.ubuntu.com/1512566/12:09
rogpeppe1TheMue: that's a bit bizarre - i don't see any of the printfs from within openState in agent.go12:11
TheMuerogpeppe1: that "agent open state, initial …"?12:12
rogpeppe1TheMue: yes12:13
rogpeppe1TheMue: i don't see that in the log output, but i'd expect to12:13
rogpeppe1TheMue: have you tried removing the pkg directory from the gopath root and rebuilding? i'm starting to suspect some kind of build anomaly12:13
TheMuerogpeppe1: took a look, found it in the source.12:13
TheMuerogpeppe1: will do12:14
TheMuerogpeppe1: but it shows me the recompilation each time12:14
rogpeppe1TheMue: yeah, i dunno.12:14
rogpeppe1TheMue: but i can't understand why i wouldn't see those log messages12:15
TheMuerogpeppe1: so, next run, removed it and also looked into /tmp12:15
rogpeppe1TheMue: what's the value of your $GOPATH, and what's your current directory?12:17
TheMuerogpeppe1: look, first and second run are different, and i changed nothing inbetween => http://paste.ubuntu.com/1512599/12:18
TheMuerogpeppe1: and here are path, dir and command => http://paste.ubuntu.com/1512608/12:20
rogpeppe1TheMue: try pulling and running again12:25
rogpeppe1TheMue: same branch12:25
rogpeppe1TheMue: (i'm pretty sure i've found the problem and the fix)12:26
TheMuerogpeppe1: ok12:26
TheMuerogpeppe1: *thumbsPress*12:26
rogpeppe1TheMue: i thought we'd fixed this issue ages ago - perhaps the branch never got through to completion12:27
TheMuerogpeppe1: for true { hug(rogpeppe1); }12:28
rogpeppe1TheMue: cool12:28
TheMuerogpeppe1: three times, no failure!12:28
rogpeppe1TheMue: i'll submit a CL12:29
TheMuerogpeppe1: great, you're a fantastic guy12:29
TheMuerogpeppe1: ah, the old version of the for loop may cause that runOnce() is never called?12:33
rogpeppe1TheMue: yup12:33
rogpeppe1TheMue: because the tomb is killed before we get to the loop. (that's the racy bit)12:33
TheMuerogpeppe1: that's itchy :D12:34
rogpeppe1TheMue: it's not a race that matters for anything other than the tests...12:34
TheMuerogpeppe1: interesting that it happened only here12:35
rogpeppe1TheMue: yeah, that'll be because of your VM12:35
TheMuerogpeppe1: so thankfully to Daves reject of my Firewaller change i stumbled over it ;)12:36
rogpeppe1TheMue: i'm surprised you weren't seeing the issue before - it's nothing new.12:37
rogpeppe1TheMue, fwereade: https://codereview.appspot.com/706705612:38
TheMuerogpeppe1: i have to admit that i'm not very often run the whole suites. but now i'll do it more.12:38
rogpeppe1TheMue: you should always run the whole suite :-)12:38
rogpeppe1TheMue: and the live tests too, if what you're doing might impact them12:38
TheMuerogpeppe1: sure12:39
fwereaderogpeppe1, click; but, whoops, late:12:48
* fwereade => lunch12:49
=== Guest39143 is now known as amithkk
=== Aram2 is now known as Aram
=== TheMue_ is now known as TheMue
fwereaderogpeppe1, dimitern: if either of you are interested, https://codereview.appspot.com/7058061/ is up14:42
* dimitern looking14:49
fwereaderogpeppe1, dimitern: and I think https://codereview.appspot.com/7065061 may be trivial14:54
dimiternfwereade: done14:54
dimiternfwereade: that's the same CL14:54
dimiternfwereade: oops, i'm blind :) sorry14:55
fwereadedimitern, ;p14:55
fwereademramm, may I skip the kanban meeting? I need to keep half an eye on laura for a bit,I suspect it will become complex14:55
fwereademramm, I will update my cards right now ;)14:55
mramm fwereade: that's fine14:56
dimiternfwereade: the other one is done as well14:57
mrammyou sent a status update e-mail, and updated the cards -- I think that is sufficent!14:57
fwereadedimitern, <314:57
dimiternmramm: I want to pop in to the kanban meeting to listen14:58
mrammdimitern: sure.   I'll send you the hangout invite...14:58
fwereademramm, cheers14:59
dimiternmramm: 10x14:59
fwereadedimitern, concur trivial on the latest?15:20
dimiternfwereade:  708061 ?15:21
dimiternthat's 75806115:21
dimiternaaagr 7058061 :)15:21
dimiternfwereade: it still looks good and trivial to me15:22
fwereadedimitern, cheers15:23
TheMuerogpeppe1: your hint with the password is good. it is changed twice on a machine, but the opening of the entity is done with the first one. so i'll now find out where it is set the first time and where the second time.16:04
fwereaderogpeppe1, TheMue, dimitern: https://codereview.appspot.com/7063055 is basically trivial I think16:20
rogpeppe1fwereade: reviewed16:24
fwereaderogpeppe1, tyvm16:29
=== mohits1 is now known as mohits
=== amithkk is now known as mechanobot
TheMuerogpeppe1: may you help me with some stack output? i now have found how a machine pw is set twice, but the older one shall be used.16:38
rogpeppe1TheMue: sure. do you want my little function?16:38
TheMuerogpeppe1: I first sho you my output, maybe it's enough for you, otherwise yes, thank you.16:38
TheMuerogpeppe1: http://paste.ubuntu.com/1513480/16:40
TheMuerogpeppe1: interesting are lines 1, 46 and 61. first set and used correctly, then set again, but then still try to use the former pw.16:41
rogpeppe1can you push the branch that this happens on, please? (so i can see the code the stack trace is referring to)16:42
rogpeppe1TheMue: ^16:42
TheMuerogpeppe1: sure16:42
TheMuerogpeppe1: here it is lp:~themue/+junk/firewaller-integration16:45
rogpeppe1TheMue: it looks like it's the same instance id problem to me16:48
TheMuerogpeppe1: huh, the instance id is set (i hope i haven't looked into the wrong version).16:49
rogpeppe1TheMue: the problem is at line 4616:49
rogpeppe1TheMue: it's setting machine 0's password16:50
TheMuerogpeppe1: yes16:50
rogpeppe1TheMue: and if you look at the stack, that's happening within Provisioner.processMachines - startMachines(pending)16:50
rogpeppe1TheMue: and pending can only be added to if the machines have no instance id16:50
rogpeppe1TheMue: hmm, i wonder if there's a race here. perhaps you're adding a machine while the provisioner is active.16:51
rogpeppe1TheMue: you could use InjectMachine16:52
fwereaderogpeppe1, I don;t think there's a mystery -- if the machine doesn't have an instance ID the provisioner is justified in provisioning one for it16:52
fwereaderogpeppe1, regardless of the fact that the provisioner is actually running on that machine16:52
rogpeppe1fwereade: we are setting an instance id for the machine, immediately after adding it.16:52
TheMuefwereade: but we're settign it16:52
rogpeppe1TheMue: i think you should use State.InjectMachine16:52
rogpeppe1TheMue: which doesn't have the same add-then-set race possibility, so the provisioner can't grab it16:53
TheMuerogpeppe1: i'll take a look16:53
fwereaderogpeppe1, TheMue: if you're setting it before starting the provisioner that surely indicates a provisioner bug?16:54
rogpeppe1fwereade: yes16:54
rogpeppe1fwereade: but i'm not sure that's the case16:54
fwereaderogpeppe1, ah ok16:55
TheMuerogpeppe1: huh, it seems that setting the id has gone when pulling it. *gnarf*16:55
TheMuerogpeppe1: just compared it to my backuped code.16:55
TheMuerogpeppe1: aaaaaaargh, please don't listen to me anymore. i'm wearing sackcloth and ashes. *sigh*16:58
rogpeppe1TheMue: found the problem?16:58
TheMuerogpeppe1: mixed up my branches.16:58
fwereaderogpeppe1, I have a thought that may be crack16:59
TheMuerogpeppe1: yes, it has been the instance id, as you said. but i looked before into the saved branch. so i have been sure it is in.16:59
fwereaderogpeppe1, one of the things that is getting me down about removing AUST entirely is the hassle of having to set a unit address before a RelationUnit can enter scope17:00
rogpeppe1TheMue: nonetheless, it might be sensible to use InjectMachine17:00
TheMuerogpeppe1: no i set it again properly in addMachine() and everything is fine.17:00
rogpeppe1fwereade: AUST?17:00
fwereaderogpeppe1, AddUnitSubordinateTo17:00
rogpeppe1fwereade: of course, sory17:00
fwereaderogpeppe1, and ISTM that it might be defensible to have EnterScope(setting map[string]interface{}) error17:01
fwereaderogpeppe1, but the intended semantics take a bit of thought17:01
rogpeppe1fwereade: what would it do?17:02
fwereaderogpeppe1, iff a scope document is created, overwrite the settings doc with the contents of the supplied settings17:02
fwereaderogpeppe1, (or create it)17:03
fwereaderogpeppe1, (that is the proposal, anyway; other schemes make make sense)17:03
fwereaderogpeppe1, doing this saves about 100 lines in the tests, because I can just do EnterScope(nil) where I had EnterScope ;p ;p17:05
hazmatfwereade, are there any vol manage docs extant?17:06
fwereadehazmat, nothing17:06
hazmatfwereade, ack, just fielding some questions from ops17:06
fwereadehazmat, crap -- the plan was always that niemeyer and I would sit down and hash something out... well, round about now, but it's pushed back by an unknown amount17:07
rogpeppe1fwereade: why is it a particular hassle to set a unit address?17:07
fwereaderogpeppe1, it's 2 lines of code that is totally irrelevant to the purpose of the test, repeated all over the place17:08
fwereaderogpeppe1, at best it's irritating, at worst it's confusing17:08
hazmatfwereade, mramm so its likely on the at risk for moving past 13.04 re vol?17:08
TheMueinteresting, now i've got no more hanging code and in 9 of 10 runs it passes (the one test function), but then one assert fails.17:09
hazmatfwereade, no worries, just trying to get clarity about what we're ack is on the roadmap for 13.0417:09
hazmatwe're acking17:09
fwereadehazmat, I think a definitive answer to that will emerge during the austin sprint17:09
mrammfwereade: hazmat: we will probably have to trim the 13.04 list somewhere17:09
mrammfwereade: hazmat: we will probably have to trim the 13.04 list and austin is where we decide exactly where we trim17:10
rogpeppe1fwereade: so your idea is that EnterScope would change the unit's settings?17:10
mrammfwereade: hazmat: and perhaps how we re-allocate resources to best meet our goals17:10
fwereaderogpeppe1, no -- just the relation unit settings, as it already does17:10
fwereaderogpeppe1, my proposal leads it in a slightly less crackful direction17:11
fwereaderogpeppe1, ATM, first enter scope will set private-address and never touch it again17:11
fwereaderogpeppe1, with this change a fresh entry to scope (ie returning after leaving) will clear outdated settings17:12
rogpeppe1fwereade: i'm afraid i'm not entirely clear on the relationship between unit settings (is there such a thing) and relation unit settings17:12
fwereaderogpeppe1, ah ok -- I thought you meant "contents of the unit doc itself"17:12
rogpeppe1fwereade: ah, i think i see.17:13
fwereaderogpeppe1, yes, units only have "settings" in the context of a relation17:13
rogpeppe1fwereade: you want to make private-address less special17:13
fwereaderogpeppe1, yes -- it's still special, but its specialness should happen in uniter instead of in state17:13
rogpeppe1fwereade: and provide a general facility to have settings that are available immediately a relation is created17:13
fwereaderogpeppe1, exactly17:13
rogpeppe1fwereade: emphatic +1 to that17:13
fwereaderogpeppe1, sweet, tyvm17:14
rogpeppe1fwereade: because we may very well provide other settings that are always available, in the future17:14
fwereaderogpeppe1, indeed so17:15
rogpeppe1fwereade: just a thought, looking at the code:17:16
rogpeppe1fwereade: isn't it a bit potentially problematic, in EnterScope, that we do readSettings, then add an op that asserts docMissing only if that's true?17:17
rogpeppe1s/that's true/they weren't found/17:17
rogpeppe1fwereade: do relation settings persist from leaving a scope to entering a scope again?17:18
fwereaderogpeppe1, I think they shouldn't17:21
fwereaderogpeppe1, but they currently do17:21
rogpeppe1fwereade: ah17:21
fwereaderogpeppe1, there's no actual facility for re-entering scope ATM17:21
fwereaderogpeppe1, but I have rough agreement with niemeyer that there's no good reason to forbid it17:22
rogpeppe1fwereade: in that case the logic should be simpler - just create the doc with the right settings17:22
fwereaderogpeppe1, *however*, if the unit is re-entering any settings from the previous bunch of hooks should, I think, be presumed to be invalid17:22
rogpeppe1fwereade: surely the settings should be removed when leaving the scope?17:22
allenapmramm: Hi there, can Red Squad (allenap, rvb, julian-edwards, jtv) join the ~juju team?17:22
fwereaderogpeppe1, the wrinkle is that a unit that has ever entered a scope must retain *some* settings forever17:23
rogpeppe1fwereade: orly?17:24
rogpeppe1fwereade: which ones?17:24
fwereaderogpeppe1, yeah -- any other unit might be running late on hook processing and have a perfectly legitimate reference to that unit according to its own timeline17:25
fwereaderogpeppe1, if it doesn't have cached settings, it will want to get them17:25
fwereaderogpeppe1, (to be explicit, the ones it must retain are the latest known legitimate settings)17:27
rogpeppe1fwereade: is there such a thing as an illegitimate setting?17:27
fwereaderogpeppe1, yes: IMO, once we re-enter scope, old settings are illegitimate17:28
fwereaderogpeppe1, say you create a new random password on relation-joined17:28
fwereaderogpeppe1, when we enter, we're expecting to run a relation-joined, and it seems much better not to have a bad value lying around: it makes it much harder for the units on the other side17:29
rogpeppe1fwereade: so you want to overwrite any existing settings, creating the doc if necessary17:29
fwereaderogpeppe1, yes -- if and only if I'm also creating the scope doc that txn17:29
fwereaderogpeppe1, otherwise we assume that the hooks will handle whatever changes need to be made17:30
fwereaderogpeppe1, still sounding sane?17:34
rogpeppe1fwereade: sounds reasonable, although i don't understand all the implications17:35
rogpeppe1fwereade: assuming it's not too hard to do in a transaction17:35
fwereaderogpeppe1, I don't think it's any more complex than the existing EnterScope, just different17:36
rogpeppe1fwereade: cool17:36
* rogpeppe1 is off for the night. nght all.18:24
hazmatrobbiew, forwarded you an email that was a cause to the thread on the juju list (which i'm also writing up a reply to)22:07
davecheneymramm: ping22:30
mrammdavecheney: pong22:30
fwereadedavecheney, ping22:30
davecheneymramm: g+ or skype ?22:31
fwereadedavecheney or mramm: very briefly, is there a way I can get a list of the bugs fixed in juju-core since the last release?22:31
mrammdavecheney: I'm in the G+ but I don't mind skype22:31
davecheneyfwereade: i looked at the 1.9.6 milestone, nothing useful there22:31
fwereadedavecheney, likewise -- I guess I should have been retargeting my bugs to that as I did them22:32
fwereadedavecheney, I'll try to be cleverer22:32
davecheneyfwereade: bzr log after rev 796 will be the best solution22:32
davecheneymramm: g+ sucks balls22:36
davecheneyyou are never online for me22:36
davecheneyis there another mark ramm I dont' know about ?22:36
mrammwell, there is mark canonical ramm-christensen22:37
mrammthe hangout I'm in is https://plus.google.com/hangouts/_/8135680b0c8e4091160281dd5651402e2bec713322:37
mrammwhich is linked in the meeting22:37
davecheneythat one invites the wrong dave cheney22:38
davecheneyscrew it, skype is easier22:39
davecheneyfwereade: will do release notes this morning and send them to you22:42
fwereadedavecheney, I'm noting subordinate state down for you22:42
fwereadedavecheney, I just wanted to check whether I'd done anything else worth mentioning22:42
davecheneyyou can explain what works and what doesn't work22:43
fwereadedavecheney, sent; let me know if it needs clarification, I'm not sleeping *quite* yet22:54
davecheneyfwereade: thank you22:57
davecheneydont' worry, i'll do the release over the weekend so there is no rush22:57
fwereadedavecheney, offhand, do you know how to express "completely replace the contents of this document" in mgo/txn?22:57

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