* davecheney starts to salivate01:08
niemeyerdavecheney: Wow, sweet indeed01:23
* mramm2 has no love for my ISP today -- but they are sending out the second tech support person in 2 days tomorrow morning03:42
davecheneyhello, is there an mstate.Open ?06:45
davecheneyi can't find it, i must be dumb06:45
TheMuegood morning07:04
davecheneyTheMue: good morning07:06
davecheneydo you know if there is an mstate.Open method ?07:06
TheMuehiya dave07:06
TheMuedavecheney: sorry, don't know if it already exist07:07
davecheneyTheMue: that is sad07:07
davecheneyis there an mstate.Info ?07:07
TheMuedavecheney: dunno too, i've just started with lifecycle and test completion07:08
TheMuedavecheney: so you just have to scan the code07:08
davecheneyTheMue: cool07:08
davecheneyi'll ask aram07:08
TheMuedavecheney: at least in trunk they don't exist07:14
davecheneyTheMue: does mongo have anything like the concept of zookeepers' fallover addresses ?07:14
TheMuedavecheney: and aram currently focusses on txn and watchers07:14
TheMuedavecheney: afaik the concept is different, see http://www.mongodb.org/display/DOCS/Sharding+and+Failover. but here i'm not deep enough into both systems.07:27
davecheneyTheMue: ta07:31
=== TheMue_ is now known as TheMue
rogpeppefwereade, TheMue: morning08:09
fwereaderogpeppe, heyhey08:09
TheMuerogpeppe: hi, had a nice day off (spending your time on wedding photos)?08:10
TheMuefwereade: hello08:10
rogpeppefwereade: any chance you could run a very brief live test for me? i can't work out if i've mucked up my amazon stuff or if our code has gone wrong08:10
fwereadeTheMue, heyhey :)08:10
rogpeppeTheMue: yes thanks08:10
fwereaderogpeppe, heh, ok, sure; in 5 mins?08:10
rogpeppefwereade: np08:10
fwereaderogpeppe, ok, that wasn't 5 mins, but maybe it actually will be in 5 more mins -- would you let me know what I need to do now?08:29
rogpeppefwereade: go test -amazon -gocheck.vv launchpad.net/goaws/ec208:30
rogpeppefwereade: (assuming you've got valid AWS_ environment variables set up)08:30
rogpeppeoops again08:33
rogpeppefwereade: go test launchpad.net/goamz/ec2 -amazon -gocheck.vv08:33
rogpeppeflags after packages, but only for go test :-)08:33
fwereaderogpeppe, failures: http://paste.ubuntu.com/1171358/ (I managed to figure that bit out at least)08:34
rogpeppefwereade: interesting, but not the failures i was looking for :-)08:34
rogpeppefwereade: i'm seeing signature failures08:35
fwereaderogpeppe, ha, sorry :(08:35
rogpeppefwereade: the weird thing is that the python juju works ok.08:36
rogpeppefwereade: time to make a minimal failing example, i think08:36
fwereaderogpeppe, something's scratching at my mind about signed urls, I'll let you know if it turns into anything real08:39
rogpeppefwereade: ta. it's really odd - some test example code works.08:39
TheMuehi Aram08:58
rogpeppefwereade: one last test, just to make doubly sure: could you make sure you've got the latest goamz version (cd $GOPATH/src/launchpad.net/goamz; bzr pull) and run this program, with the auth details i gave you earlier substituted as appropriate.. http://paste.ubuntu.com/1171398/09:03
rogpeppefwereade: i'm finding it all a bit weird09:03
rogpeppefwereade: or just say bugger off if you're too busy... :-)09:04
fwereaderogpeppe, huh, sorry, looks like I wasn't up to date :/09:04
fwereaderogpeppe, and np at all I'm watching other tests atm, did something stupid :)09:05
fwereaderogpeppe, bingo, signature does not match09:05
rogpeppefwereade: and if you use your own credentials?09:05
fwereaderogpeppe, doing that now09:06
fwereaderogpeppe, yep, same failures09:08
fwereaderogpeppe, sorry about that :(09:08
rogpeppefwereade: lovely thanks09:08
rogpeppefwereade: no, that's good!09:08
rogpeppefwereade: and when i reverted to revision 8, it all works09:08
fwereaderogpeppe, nah, just sorry about the dumb version thing to begin with09:08
rogpeppefwereade: np, i'd've done the same09:09
rogpeppefwereade: the three line change between r8 and r9 is the culprit09:10
TheMueAram: just to get sure, the agreement has been that all reads on one or all entities with a lifecycle returns them regardless if of their life state, isn't it?09:12
AramTheMue: yes.09:13
TheMueAram: ok, i'm currently doing services and machines and will change that too where needed09:14
rogpeppefwereade: i think i've found the problem09:21
fwereaderogpeppe, oh yes?09:21
rogpeppefwereade: the urls don't end with a slash09:21
fwereaderogpeppe, ha!09:21
fwereadeaaaaaaaaaaaaaaaaaaaaand we have a (rudimentary) Uniter merged :D09:23
rogpeppefwereade: right, now i can have some breakfast09:23
rogpeppefwereade: yay!09:23
rogpeppefwereade: i will eat muesli in celebratory mood!09:24
fwereaderogpeppe, heh, I should probably do the same in a mo :)09:24
fwereadesorry guys, need to pop out for a bit, bbs09:49
fwereadeheya davecheney10:52
davecheneyhas everyone got their UDS invite yet ?10:55
davecheneyffs, i told michelle that there was a problem, but she didn't believe me10:55
davecheneyeventbrite has this web bug they put on their email, so they claim it has been 'opened'10:55
davecheneylike that could ever be wrong10:55
AramI do have an invite, now that you made me look10:55
Aram14 days ago, actually10:56
AramUbuntu Developer Summit - R10:57
Aramwhat's the 'R'?10:57
fwereadeAram, letter after Q10:57
davecheneyit's the next letter after Q10:57
* fwereade gesticulates wildly but emits no sound10:58
davecheneyfwereade: !10:58
fwereadesorry guys 2 mins10:58
davecheneyat an old workplace, the IRC bot had a !jynx command10:58
davecheneyone guy spent far to much time teaching it levenshtein distances so it could figure out who to mute10:59
TheMuehiya niemeyer11:02
niemeyerAnyone has the invites out yet11:03
rogpeppeniemeyer: yo!11:07
rogpeppeniemeyer: meeting, i guess11:07
* rogpeppe goes to fetch the other computer11:08
davecheneyWhoop whoop!11:23
niemeyerdavecheney: I'm not sure if you want to talked to talk a bit more about the problem11:54
niemeyerdavecheney: Do you wanna brainstorm on it for a moment?11:54
davecheneyniemeyer: sure11:54
niemeyerdavecheney: Cool, so I'll pick the code to follow alone11:54
niemeyerWow.. interesting typo11:55
davecheneyis the hangout still active ?11:55
niemeyerdavecheney: Would you rather use G+? Cool.. I've sent it again11:56
davecheneyjynx! so have I11:56
davecheneyniemeyer: https://plus.google.com/hangouts/_/649cd97bfeb012132fd9f58aeaf998dfd90329b211:57
davecheney^ does that work ?11:57
davecheneyniemeyer:         svc, err := s.Conn.AddService("test-service", charm)12:05
davecheney        c.Assert(err, IsNil)12:05
davecheney        err = svc.SetExposed()12:05
davecheney        c.Assert(err, IsNil)12:05
davecheney        units, err := s.Conn.AddUnits(svc, 1)12:05
davecheney        c.Assert(err, IsNil)12:05
davecheney        err = units[0].OpenPort("tcp", 999)12:05
davecheney        c.Assert(err, IsNil)12:05
rogdavecheney, TheMue: i think the firewaller probably needs to be changed so that it only adds machines to the machineds map when the machine has an instance id.12:07
rogdavecheney: or, better perhaps, the firewaller could keep the set of current instances, and change it when a machine's instance id changes12:08
TheMuerog: InstanceId() of machine already returns an error if unset and that is caught in firewaller line 20212:09
rogTheMue: yes, but this is something that happens in the normal course of things. we don't want the provisioner to be restarted each time it happens.12:10
rogTheMue: i'm not sure that retry logic is the right fit here either12:10
rogTheMue: hmm, mind you perhaps retry is ok here, in a kinda hacky sort of way, because we know that the firewaller is in the same process, so it will be seeing the same changes and be reacting pretty quickly.12:12
TheMuerog: if we don't have an instance id retrying to open them doesn't help ;) so indeed there may be a need for (a) watching for the instance id12:12
rogTheMue: that's what i'm thinking12:12
rogTheMue: (we already have a watcher that can do that)12:12
TheMuerog: sadly i don't see the according error message in the log. here i'm wondering12:15
TheMuerog: ah, found, looked too high12:16
rogTheMue: looking at the code, i don't think it would be too hard.12:17
rog... maybe12:17
TheMuerog: depends on the strategy12:20
TheMuerog: wait there less or more good wrapped but blocking12:20
rogTheMue: syntax error :-)12:20
TheMuerog: or start a kind of async port opener in an extra goroutine12:20
TheMuemore or less12:21
rogTheMue: i didn't understand that first sentence, but i don't think the latter is a good idea12:21
rogTheMue: if we let ourselves be led by the model, a Machine's instance id can change at any time, and we should track that.12:21
TheMuerog: 1st sentences is a kind of instanceId, err := machined.machine.WaitInstanceId()12:22
rogTheMue: i don't think that's a great idea either12:22
TheMuerog: no, because it blocks the fw12:22
rogTheMue: i'm thinking we should maintain another map inside the Firewaller12:22
rogTheMue: that maps machine id to instance id12:22
rogTheMue: or to environs.Instance, better perhaps.12:23
rogTheMue: there's something i'm trying to understand about the current firewaller; maybe you can explain12:23
TheMuerog: i'll try12:23
rogTheMue: it never calls Instance.Ports, so if the firewaller is restarted, how can it know what ports to close on an instance?12:24
TheMuerog: afaik we once talked about it. i just pass the instance the ports i want have opened or close, regardless if they are alredy open or closed12:26
rogTheMue: that's fine for opening ports (open is idempotent, and when we start, we assume no ports are open), but i think it fails for closing ports.12:27
davecheneysorry lads, wasn't watching what you were writing12:27
davecheneywas talking to gustavo12:27
niemeyerTheMue: Please leave that to davecheney12:28
TheMuerog: why does it fail?12:29
TheMueniemeyer: ok12:29
rogTheMue: because when you start up, you need to close any ports that are currently open but that are not mentioned in the state12:29
rogTheMue: but unless you call Instance.Ports, you can't know what those are12:30
davecheneywhy does LP not have a 'report a bug' link on the milestone page12:30
davecheneyI spend my life on that page and there is no bloody link to create a _new_ bug for this milestone12:30
rogdavecheney: think of daisies, la la la12:31
TheMueniemeyer: is rog with this fw-startup-port-closing right? if so we should file a bug.12:32
davecheneyrog: please file a bug12:33
davecheneyrog: also, is there a bug for the AMZ breakage12:33
rogdavecheney: yes, someone else had already filed one12:34
davecheneyI have a shittone of 'doesn't work in XYZ region' bugs that I am working through12:34
rogTheMue: interestingly, this was an issue that we didn't have in the code sketch that i originally proposed for the firewaller12:34
rogTheMue: (well, perhaps... :-])12:35
rogdavecheney: i'll write a test that breaks first, then i'll file a bug :-)12:37
davecheneyrog, you've done this before :)12:37
rogdavecheney: yup, test fails as expected12:43
davecheneyniemeyer: https://bugs.launchpad.net/juju-core/+bug/104271712:44
davecheneydoes this capture (part) of the discussion we just had12:44
rogdavecheney: i think AllInstances only returns running instances12:45
rogdavecheney: (or pending)12:45
niemeyerdavecheney: As far as terminology goes, I suggest stopped vs. terminated12:45
niemeyerdavecheney: That's what EC2 uses12:45
davecheneyya'all can edit the ticket, please have at it12:45
mramm2sorry all12:46
davecheneymramm2: did my text make it ?12:46
mramm2and my phone was right next to me12:46
davecheneymramm2: if you wanna have a quick catchup now while everyone is online, lets do it12:46
mramm2but I slept through it12:47
niemeyerdavecheney: Looks good12:47
niemeyerdavecheney: I was wondering a bit about (2)12:47
niemeyerdavecheney: Do we need it right now?12:48
rogdavecheney: what do you think we should do with a stopped machine? its agent will appear dead.12:48
rogniemeyer: ^12:48
davecheneyrog: discuss with niemeyer, he dug up that corpse12:48
roghmm, yeah, it might be problematic if we find we're running two unit agents for the same unit12:49
rogbut i suppose that's a problem with a down network connection too12:50
niemeyerTheMue: Sorry, I did read the discussion, but it's not clear to me what problem is being fixed, or why we should change something there12:50
davecheneyniemeyer: this one is a bit pithier12:50
rogniemeyer: the problem is that the firewaller sees a new machine and tries to change its ports, but the machine hasn't yet been allocated an instance.12:50
niemeyerdavecheney: Which one?12:50
davecheneyniemeyer: https://bugs.launchpad.net/juju-core/+bug/104272112:51
davecheneypaste fail12:51
rogniemeyer: so the firewaller dies12:51
niemeyerrog: I've discussed this with davecheney already.. there's zero reason to change ports for an instance that doesn't exist12:51
rogniemeyer: indeed12:51
rogniemeyer: which means the firewaller should watch each machine to see when its instance id changes, i think12:51
niemeyerrog: I don't get the leap12:52
rogniemeyer: when should the firewaller open the ports for a new instance?12:52
niemeyerdavecheney: +112:52
davecheneyniemeyer: my only question is12:52
davecheneywhich ports are we talking about, the ones in the state, or the ones in the security group of the provider ?12:53
niemeyerrog: When it gets an open port watcher firing for an instance within it and its service was exposed, in either order12:53
niemeyerdavecheney: State12:53
rogniemeyer: open port watchers fire for machines, not instances12:53
niemeyerdavecheney: We've agreed back then that StartInstance never gives back something with ports open12:53
niemeyerrog: It fires for units, actually12:53
rogniemeyer: sure12:54
davecheneyniemeyer: ok, then in the pathological case, all the units' machines have been replaced12:54
niemeyerrog: Which live within an instance when they are running12:54
davecheneyand the service is now offline12:54
niemeyerrog: No instance, no unit12:54
rogniemeyer: but when you see that state change, you haven't necessarily got an instance to change the ports on12:54
niemeyerrog: Impossible12:54
rogniemeyer: really?12:54
niemeyerrog: The unit lives within the instance.. if there's no instance, there's no uniter, and thus no open ports12:55
davecheneyniemeyer: ahh, and you just answered my question, when the instance is replaced, the new uniter will react to 'exposed' and do what it needs12:55
rogniemeyer: ah...12:55
rogniemeyer: i'd forgotten that rub12:55
rogniemeyer: brilliant!12:55
TheMuethe missing piece12:55
rogniemeyer: so the test is wrong.12:55
rogit's all my fault :-)12:56
mramm2I setup a hangout: tps://plus.google.com/hangouts/_/0fbf3a66c1e6ee955123854516a78f947aa621cb12:56
niemeyerdavecheney: Yeah, or in install/start whatever.. it's free to run open-port in any hook12:56
mramm2not required, but if you want to chat12:56
mramm2feel free to join12:56
niemeyerrog: Well, kind of.. as discussed with davecheney, the test is also right12:57
niemeyerrog: It's just a different unit tests12:57
niemeyerrog: It shouldn't blow up in such a state12:57
davecheneyrog: it's wrong in the way a hat made of bacon is wrong12:57
rogdavecheney: are you dissing my bacon hat?12:57
rogniemeyer: should it just ignore the error?12:59
rogniemeyer: the firewaller, that is12:59
niemeyerrog: Yeah, if the instance is gone, it can ignore it.. the provisioner will close ports in state, fire a new instance, assign to it, and the new uniter will open it back again13:00
rogniemeyer, davecheney: so this should fix that particular test: http://paste.ubuntu.com/1171742/13:01
davecheneyniemeyer: me looks13:03
davecheneyniemeyer: that should work _almost_ work13:04
rogdavecheney: almost?13:04
davecheneythere is a race between the call to dummy.StartInstance() returning and the intance id hitting the state13:04
davecheneyit is a much smaller window than currently exists13:05
rogdavecheney: shit yeah13:05
rogdavecheney: i knew about that before13:05
rogdavecheney: just forgotten it13:05
* rog is groggy today13:05
davecheneyrog: http://codereview.appspot.com/6482081/13:05
davecheneyyour thoughts would be appreciated13:05
davecheneynote, setting a value higher than about 10ms will cause jujud tests to hang13:06
niemeyerdavecheney: Huh.. a good one to inspect later :)13:07
davecheneyrog: niemeyer : booohhh https://bugs.launchpad.net/bugs/104254513:07
rogdavecheney: why bother putting the delay time in the environState if it's actually global?13:10
davecheneyrog: TheMue requested that we be able to change it13:10
rogdavecheney: ah13:10
davecheneyso in theory, we could change it by type aserting to dummy, then reaching in and changing the value on a per test basis13:10
rogdavecheney: not really13:11
rogdavecheney: it's all unexported13:11
rogdavecheney: i'd prefer a possible entry in the dummy environ configuration attributes.13:11
rogdavecheney: if we wanted an override13:11
davecheneyrog: good point13:13
niemeyerrog: Yeah, that sounds sensible13:13
niemeyerI've suggested a function in the dummy package, but an attribute setting seems even nicer13:13
niemeyerenvironment setting13:13
rogniemeyer, davecheney: i'm not sure about it though (an override that is)13:13
niemeyerdavecheney: That said, I still think there's value in having a flag to enable the delay globally13:14
rogwhen would it be appropriate to use the override?13:14
niemeyerdavecheney: May be done with a command line flag, though13:14
niemeyerdavecheney: as suggested in the review13:14
rogniemeyer: i think on balance i prefer the environment variable, as it means it's easy to run all tests with the delay enabled.13:14
niemeyerrog: -dummy.delay 10s is just as easy13:15
niemeyerI'd prefer to stay out of the business of env variables13:15
rogniemeyer: i can't do: go test launchpad.net/juju-core/... -dummy.delay 10s13:15
niemeyerFor that purpose13:15
davecheneyniemeyer: that doesn't work when you do: go test launchpad.net/juju-core/...13:15
davecheneywhat rog said13:15
niemeyerHmm.. okay13:16
Aramwe'll put it in a SOAP web service that the tests query using CORBA.13:16
davecheneyAram: don't forget perl, you'll need lots of perl13:17
niemeyerdavecheney: Okay, so why all the fanciness? var delaySecs = os.Getenv("..."); func delay() { if delaySecs != "" { time.Sleep(...) } }?13:18
davecheneyniemeyer: TheMue requested that it be changable13:19
rogniemeyer: +1 (assuming we don't allow delay overriding with the config)13:19
niemeyerdavecheney: Ah, we have time.ParseDuration actually13:19
davecheneywhich I now realise didn't work13:19
TheMueAram: i'm missing the JEE server in the middle receiving the requests and writem the via mqseries into an oracle where we could fetch them13:19
rogTheMue: why do you want the delay overridable?13:20
niemeyerWhich you're already using13:20
davecheneyniemeyer: rog so if in principle you are in favor, I'll resubmit that CL tomorrow with something simpler13:20
davecheneyenv var -> delay()13:20
niemeyerdavecheney: Yeah, definitely13:20
niemeyerdavecheney: we can also improve it in the future as we see necessary13:20
rogdavecheney: i think it's a good idea. i don't think we want a configurable delay - i can't think when it would ever be appropriate to use it.13:20
niemeyerdavecheney: Potentially approaching the mgo/txn's Chaos stuff13:20
rogniemeyer: +113:21
niemeyerdavecheney: But it's not worth it for now13:21
TheMuerog: just has been a quick idea after dave mentioned the topic to test different ranges13:21
TheMuerog: if the implementation concept now makes it useless it's fine for me13:21
davecheneyall: i agree, i just need a way to make dummy slow down to better simulate a real provider13:21
rogdavecheney: +113:21
TheMuedavecheney: +113:22
niemeyerdavecheney: +113:22
davecheneyright, i'll try out your test sugggestion tomorrow niemeyer13:22
niemeyerdavecheney: Cheers man13:23
davecheneyniemeyer: thanks for the discussion, i can see a straightforward way for the PA to implement those two tickets we discussed13:23
niemeyerdavecheney: Superb, thanks for finding the issue!  Glad to see these bugs being fleshed out.13:30
niemeyerOkay, so reviews, and then presence13:35
niemeyerTheMue: ping13:40
TheMueniemeyer: pong13:40
niemeyerTheMue: We'll need to fix the Kill methods.. they're changing the cached state to Dying irrespective of previous state13:40
niemeyerTheMue: We shouldn't do Dying > Dead13:40
TheMueniemeyer: ouch13:41
niemeyerTheMue: Adding a comment13:41
TheMueniemeyer: oh, yes, now i see it13:41
niemeyerTheMue: It's fine to move on as they are for the moment, and fix all of them at once in a follow up13:41
TheMueniemeyer: both new ones for service and machine are like the ones for unit and relation13:42
niemeyerTheMue: Yeah, it's all good13:42
niemeyerTheMue: We can have a new CL that follows up on that and fixes all three at once13:42
niemeyerTheMue: (with a test!)13:42
rogfwereade: could you just quickly give a high level overview of how constraints work? in particular, who solves the constraints? the PA or the client? I'm presuming the former, but just need to check.13:42
TheMueniemeyer: when i've got your ok i'll change it i'll do the followup13:43
TheMueniemeyer: +113:43
niemeyerTheMue: Cool13:43
fwereaderog, well, "solve" is frankly a bit of a strong word -- we basically match against a list of instance types, sort by cost, and pick the first13:43
rogfwereade: yeah, but until that's done we don't know the architecture that's going to be used for the new unit, right?13:44
rogfwereade: or series13:44
rogfwereade: but that "solving" is done by the PA?13:44
fwereaderog, ok, the series is known before we even start on constraints13:44
fwereaderog, that's defined by the charm13:44
fwereaderog, in every existing case, arch defaults to amd64 but can be set to i386 if desired13:45
fwereaderog, but remember this is pretty ec2-specific13:45
rogfwereade: yeah, i don't want to do anything provider-specific here13:45
rogfwereade: so am i right that the PA does the matching?13:46
fwereaderog, and -- well, *probably* it should be up to the PA, but at present no it is not13:46
rogfwereade: ah, so the add-unit command works out the architecture etc then adds the new unit with those set?13:46
fwereaderog, but I know niemeyer is -1 on this, and we hashed it out last UDS, so... yes, it is up to the PA13:46
fwereaderog, er, IYSWIM13:46
fwereaderog, yeah, that was what it did13:47
rogfwereade: thanks, that's useful13:47
fwereaderog, the reasons for it doing so are not especially interesting, and the actual choice procedure shouldn't really be any different13:47
rogfwereade: it makes a difference for upgrading, interestingly13:48
rogfwereade: i'm writing a little description of my current problem13:48
niemeyerTheMue, Aram: ping13:49
fwereaderog, ah, ok :)13:49
niemeyerAram, TheMue: Can we quickly talk about the last point here: https://codereview.appspot.com/6495043/13:49
TheMueniemeyer: pong, sorry, have been afk for a moment13:49
TheMueniemeyer: yes13:49
Aramniemeyer: what point, this? mstate/service.go:45: s.doc.Life = Dying13:50
niemeyerAram: The last one in the review13:51
rogniemeyer, fwereade: here's a description of my current upgrading difficulty: http://paste.ubuntu.com/1171829/13:51
TheMueniemeyer: currently RemoveUnit() would run on an error if the units are not dead13:51
TheMueniemeyer: but it has to be put into a complete txn later13:51
niemeyerrog: Sorry, I'm covering a different issue right now13:51
rogniemeyer: that's fine. but when you have a moment, i'm blocked on this.13:51
niemeyerTheMue: That's unrelated to transactions13:51
niemeyerTheMue: This is about the lifecycle behavior13:52
TheMueniemeyer: otherwise we start to remove relations, remove unitts and may beak before deleting the service13:52
Aramniemeyer: I thought we had agreed that units should listen for their service and delete/die themselves.13:52
niemeyerTheMue: RemoveService is abruptly *removing units from state*, despite whatever state they're in13:52
TheMueniemeyer: ok, reducing it to lifecycle the solution should be to let all units die if Die() is called on a service13:53
TheMueniemeyer: today it's not working this way13:53
niemeyerTheMue: Of course it's not.. that's why we're doing the lifecycle stuff in the first place :)13:53
niemeyerTheMue: Which is why I'm asking what's the plan13:53
niemeyerAram: Yes13:54
niemeyerAram: Not delete13:54
Aramyes, only die.13:54
niemeyerAram: Kill themselves, actually13:54
niemeyerAram: and then die, you're right13:54
niemeyerAram: The deletion is the bit that is done outside13:54
niemeyer(by the machine agent)13:54
Aramniemeyer: cool, we're on the same page. it hasn't been done yet because we were lacking watchers, I haven't forgoten about it.13:55
niemeyerAram: Still, there's a problem in that RemoveService implementation.. doesn't look like that's what we want13:55
Aramwell no, now it isn't.13:55
Arambut the plan is to change it after we have watchers.13:55
niemeyerAram: Okay, I'm wondering because we're changing it now to claim lifecycle integration,13:56
niemeyerAram: and it feels quite bogus from a lifecycle perspective13:56
Aramnah, the claim is wrong. it's a step, but not the final step.13:56
Aramthere's more work to be done.13:56
niemeyerAram: Cheers13:57
TheMueniemeyer: how should "kill themselves" happen?13:58
niemeyerTheMue: The uniter will monitor the service13:58
niemeyerTheMue: If the service gets to Dying, the units kills itself13:59
niemeyerTheMue: There's also a refcounter in the service to tell how many units are alive or dying (and not Dead yet)13:59
TheMueniemeyer: so they don't kill themselves, the uniter kills them, ok13:59
niemeyerTheMue: The service stays dying meanwhile13:59
niemeyerTheMue: Heh.. the uniter is the implementation of the unit13:59
niemeyerfwereade: Btw, are you in sync with this ^^^14:00
niemeyerfwereade: last 5 sentences14:00
TheMueniemeyer: had been at the unit state, not at the unit implementation14:01
fwereadeniemeyer, had half an eye on it; looks pretty sensible to me14:02
fwereadeniemeyer, same model as relations, really14:02
niemeyerfwereade: Yeah14:03
fwereadeniemeyer, one more thing to watch, maybe in a couple of places, which might be a little tedious14:03
fwereadeniemeyer, but well actually, no, I might only need to watch it when I'm started14:03
niemeyerfwereade: Well, not really.. the service can die at any point14:04
niemeyerfwereade: It's an entry for the "steady" select loop, I suppose14:04
fwereadeniemeyer, yeah, still thinking it through14:04
niemeyerTheMue: Okay, you got a +1 on all the lifecycle stuff14:05
niemeyerrog: So, what' sup?14:05
TheMueniemeyer: cheers14:05
rogniemeyer: just booking flights 4 uds, 1 mo14:06
fwereadeniemeyer, I *think* that impending service death is not a good enough reason to interrupt anything else the unit is doing (including, say, waiting for hook error resolution)14:06
niemeyerrog: np, reading the paste meanwhile14:06
niemeyerfwereade: Uh, that's awkward14:06
niemeyerfwereade: The guy said *kill the whole thing*14:06
niemeyerfwereade: Why we'd we go "Oh, btw, I have a small issue here?"14:07
niemeyerfwereade: Hmm14:07
niemeyerfwereade: I'm trying to think of scenarios where we'd actually want to wait for the error to be resolved14:07
niemeyerfwereade: Did you have something in mind?14:08
niemeyerfwereade: Well, at the same time, it doesn't feel like a big deal to wait, to be honest14:08
niemeyerfwereade: An argument could be enabling debugging of such issues14:09
niemeyerfwereade: "juju resolved" would always enable the service to die either way, I suppose?14:09
niemeyerfwereade: Sorry, clearly I'm brainstorming..14:09
fwereadeniemeyer, yeah, that was my thinking -- that in general we want smooth and steady shutdown of everything14:09
rogniemeyer: flight booked14:10
rogniemeyer: did the issue make sense to you?14:10
niemeyerfwereade: Sounds sensible, sorry for the derail.. should have talked to a bear before14:10
fwereadeniemeyer, by my gut I'm -1 on any sudden-death mechanisms beyond remove-unit --force14:10
fwereadeniemeyer, haha np14:10
niemeyerrog: Not yet.. digesting it still14:12
niemeyerrog: Why would add-unit *guess* tools?14:15
rogniemeyer: because it doesn't know what architecture the new unit is going to run on yet14:15
niemeyerrog: Hmm14:16
niemeyerrog: So that's not right14:16
rogniemeyer: unless we say that constraints are solved by the client14:16
niemeyerrog: We shouldn't set tools before that's decided14:16
rogniemeyer: we don't14:16
niemeyerrog: Well, if we *guess*, we do14:16
niemeyerrog: If it's decided, we dont' guess14:17
rogniemeyer: that's only with solution 214:17
rogniemeyer: which i'm not keen on, but i thought it might a possibility14:17
niemeyerrog: Solution 1 feels a bit like a derail..14:17
rogniemeyer: yeah, i'm not too keen on that either14:18
rogniemeyer: which might mean that the whole proposed tools architecture is misguided14:18
niemeyerrog: Heh14:18
niemeyerrog: Let's keep the bby14:18
niemeyerrog: I'm still digesting the issue, just a moment14:20
niemeyerrog: You know what's interesting.. a unit may have to run on a different Ubuntu release than the machine agent that starts it14:29
niemeyerrog: This is theoretically quite feasible14:30
rogniemeyer: yes, that's true.14:30
niemeyerrog: and probably practically too14:30
niemeyerrog: For a constrained selection of series at least14:30
rogniemeyer: oh... unit14:30
niemeyerrog: So we need three details to be able to start a unit:14:31
rogniemeyer: interesting. i thought the LXC stuff always used the same series as the main instance14:31
niemeyerI actually meant14:31
niemeyerrog: So we need three details to be able to assign tools to a unit:14:31
niemeyer- The series14:31
niemeyer- The version14:31
niemeyer- The arch14:31
niemeyerWe can tell the series from the service14:32
niemeyerThe version should probably be inherited from the provisioning agent14:32
niemeyerThe arch must match the machine being deployed in14:33
niemeyerrog: People deploy different series in *chroots*14:33
niemeyerrog: LXC has better isolation than chroots even14:33
rogniemeyer: uh huh. and i guess we can take advantage of that.14:34
niemeyerrog: Yeah14:34
rogniemeyer: the above stuff seems to imply that you think the PA should assign the tools to a unit14:34
rogniemeyer: is that right14:34
niemeyerrog: No.. so far it's just brainstorm.. just trying to figure what comes from where, so we find the proper hook point14:35
rogniemeyer: ok14:35
niemeyerrog: It feels like there are two possible cases:14:36
niemeyerrog: 1) Unit assigned to existing machine14:36
niemeyerrog: 2) Unit assigned to undeployed machine14:36
rogniemeyer: +114:36
rogoff the top of my head, maybe the PA should assign units to machines, rather than doing it client-side. that would solve this issue, at any rate.14:37
niemeyerrog: For (1), AssignToMachine may ensure the proper set of agent tools based on the machine agent tools, and potentially the service some day when we do support the distinction14:37
rogniemeyer: i'm not sure that's true actually14:38
niemeyerrog: Oh?14:38
rogniemeyer: what if the machine agent gets upgraded in the meantime?14:38
rogniemeyer: i suppose it comes down to what semantics we want from upgrade14:41
niemeyerrog: Actually, hmm..14:41
niemeyerrog: What if ProposedTools() defaulted to the machine tools?14:41
niemeyerrog: When the setting is missing entirely14:42
rogniemeyer: interesting14:42
rogniemeyer: what about machine proposed tools?14:42
niemeyerrog: Meaning?14:43
rogniemeyer: what does Machine.ProposedAgentTools default to?14:43
niemeyerrog: That's an easy one.. we need tools to start the machine agent in the first place14:43
rogniemeyer: but we don't need tools to create the Machine14:44
niemeyerrog: Indeed, but we need tools to start the machine agent in the first place14:44
rogniemeyer: sure. but i don't see how this gets us out of the race that i described14:44
niemeyerrog: Well, there's no way to avoid it if we're allowing for anything concurrent to pick agent tools14:46
rogniemeyer: solution 1 avoids the race, at some cost.14:47
niemeyerrog: It doesn't..14:47
niemeyerrog: Unless you sit down and wait for all upgrades to finish14:47
niemeyerrog: Before continuing to upgrade14:47
rogniemeyer: you have to sit down and wait for parent agent upgrades to finish, yeah14:47
niemeyerrog: and even that has a race, if you assume that new parent agents may be starting14:48
rogniemeyer: they'll be started by another agent, so we'll always be able to upgrade that first14:48
rogniemeyer: essentially we percolate upgrades down from the root14:49
niemeyerrog: That's a long derail14:49
rogniemeyer: here's another possibility:14:49
niemeyerrog: and complex too..14:49
rogniemeyer: agents are responsible for ProposingTools on their children.14:49
rogniemeyer: (not sure i like that much either)14:50
niemeyerrog: Hmm14:50
niemeyerrog: It sounds like we're introducing a lot of cost for the benefit of features that won't exist for quite a while..14:51
niemeyerrog: I wish we had noticed that before :(14:51
rog[15:18:34] <rog> niemeyer: which might mean that the whole proposed tools architecture is misguided14:51
niemeyerrog: state.ProposedVersion() ? :-)14:52
rogniemeyer: that has its own down sides, and i can't quite remember them right now...14:52
niemeyerrog: Mainly we can't do selective upgrading, which is what I was referring to above14:53
rogniemeyer: what happens if we don't have versions for every architecture we need?14:53
niemeyerrog: We find the closest possible version available, and if there's none, we put an error in the state pointing out we can't deploy said resource14:55
niemeyerrog: I think the version setting can actually be part of the config.Config type14:56
rogniemeyer: what do you mean by "closest version"?14:57
rogniemeyer: i think perhaps we should make it exact or nothing14:58
niemeyerrog: $MAJOR.0.0 <= $CLOSEST_VERSION <= $MAJOR.$MINOR.$PATCH14:58
niemeyerrog: That's unnecessary.. we have to handle compatibility within majors anyway.. there's no reason to prevent that from happening purposefully14:59
niemeyerrog: This will be handy when there's an upgrade in one architecture but not in another14:59
rogniemeyer: so nothing later than the proposed version.14:59
niemeyerrog: Yeah15:00
rogniemeyer: state.ProposedVersion() (version.Number, error) right?15:00
niemeyerrog: I was thinking that it'd be easier to have that in config.Config15:00
niemeyerrog: and thus state.EnvironConfig()15:00
niemeyerrog: So we can use existing infrastructure to deal with it15:00
* rog thinks15:00
niemeyerrog: E.g. we already have env watches, already have means for reading and writing this setting, etc15:01
niemeyerrog: There's one handy pre-req which is making state deal with config.Config rather than ConfigNode on EnvironConfig and the watch15:03
niemeyerrog: Which is something I've been trying to do since Lisbon15:03
rogniemeyer: this means that the providers would have to know about proposed tools, right?15:04
niemeyerrog: Why?15:04
rogniemeyer: because they're created with config.Config attributes, no?15:05
niemeyerrog: Not that I see a problem upfront, but just wondering what you have in mind15:05
niemeyerrog: No provider should break if config.COnfig has an attribute that it doesn't know about15:05
rogniemeyer: ah, i didn't know that15:05
niemeyerrog: The generic config.Config will handle it15:05
rogniemeyer: another question occurs to me15:06
rogniemeyer: when we do "juju upgrade-juju", how do we choose what version to propose in the state?15:07
rogniemeyer: do we look through all the agents and see what architectures they're running, then choose the best version that is provided for all of them? or do we just choose the best version for any architecture?15:07
niemeyerrog: We can use the functionality you've already put in place to find max(version with current major)15:08
rogniemeyer: for which architecture?15:08
niemeyerrog: I'd say any15:08
niemeyerrog: If we use the logic prevoiusly mentioned, that'd be fine15:08
niemeyerrog: Agents may simply not be able to catch up immediately15:09
rogniemeyer: the functionality currently in place looks for tools for a given arch and series15:09
niemeyerrog: But with the retry logic that should exist anyway (download may fail, etc), we'd catch that15:09
rogniemeyer: but i could remove that restriction15:09
niemeyerrog: Ah, I see.. this is still useful15:10
niemeyerrog: We'll want to use that when within the agent figuring what to run15:10
rogniemeyer: indeed15:10
rogniemeyer: i could provide BestBinaryTools or something15:10
niemeyerrog: We just need to be able to disable the flag15:10
niemeyerrog: Yeah15:10
rogniemeyer: i wonder, if an agent can't find the exact version, perhaps it should keep on polling the available tools until the version is availab.e15:11
niemeyerrog: I think it's fine to run something else that is closer to the proposed version15:12
rogniemeyer: but what happens if we later upload the required version? how can we ask the agents to upgrade?15:12
niemeyerrog: Reality will have that kind of scenario due to arch and series discrepancies15:12
niemeyerrog: We shouldn't have to15:12
niemeyerrog: The agent itself should note that it's still out of date in comparison to the proposed version15:13
rogniemeyer: it'll know that, but what should it do about it?15:13
niemeyerrog: It should check to see if the available tools are now available15:13
niemeyerrog: It should check to see if the proposed tools are now available15:13
rog[16:11:52] <rog> niemeyer: i wonder, if an agent can't find the exact version, perhaps it should keep on polling the available tools until the version is availab.e15:14
rogniemeyer: that's what i was suggesting.15:14
niemeyer<niemeyer> rog: I think it's fine to run something else that is closer to the proposed version15:14
niemeyerrog: That's my counterproposal :-)15:14
niemeyerrog: The "exact" word in there is the disagreement15:14
niemeyerrog: It should continue polling, but if it finds something closer, it should upgrade too15:15
niemeyerrog: and continue polling15:15
rogniemeyer: definitely.15:15
rogniemeyer: ah, sorry, i thought you were disagreeing with the idea of polling15:15
niemeyerrog: No, that's nice15:15
* rog hopes that he doesn't have to throw away *too* much code :-)15:16
niemeyerrog: I was thinking about that as went through, I *think* it's mostly ok15:16
rogniemeyer: that's my inclination too15:16
niemeyerrog: The whole upgrading logic is gold, just needs to watch something else15:16
rogniemeyer: yeah15:17
rogniemeyer: i think it's mainly the watchers in state15:17
niemeyerrog: Interestingly, there's a bunch of code going away, which is nice15:17
niemeyerTheMue: ping15:17
rogniemeyer: at the expense of flexibility of course, but maybe we'd never really want to deliberately deploy different versions.15:18
TheMueniemeyer: pong15:18
niemeyerrog: I'm feeling better about this aspect, to be honest.. I prefer we make things more complex to implement the fancy scenarios when we do need it, than to have it complex by default15:18
niemeyerTheMue: Heya15:18
niemeyerTheMue: I think we might use your help on this one15:19
rogniemeyer: yeah, i think i agree.15:19
niemeyerTheMue: Not sure about rog's plan, so we have to brainstorm for a sec15:19
TheMueniemeyer: ok, will read the last lines.15:19
niemeyerTheMue: There's some work that is on my plate for a while, and I never got to it15:19
niemeyerTheMue: No need, I'll explain15:19
rogniemeyer: i'd rip out all the current ProposedAgentTools stuff from state15:19
TheMueniemeyer: ok, listening mode = on15:19
rogTheMue: ^15:20
niemeyerTheMue: We need EnvironConfig() to return config.Config15:20
niemeyerTheMue: and also the respective watche15:20
niemeyerTheMue: I think all the stars are now aligned for this to be relatively easy, but this is a blocker for rog15:20
niemeyerTheMue: Would you mind to put that at the front of the queue, on CL for state, then another one for mstate?15:21
niemeyers/on CL/one CL/15:21
niemeyerrog: Not sure if you agree, or if you'd like to do that yourself?15:21
rogniemeyer, TheMue: that would be great15:21
niemeyerTheMue: We'll need a counterpart for State.EnvironConfig: State.SetEnvironConfig15:22
niemeyerTheMue: Since config.Config is read-only15:22
niemeyerTheMue: But it all sounds quite straightforward15:22
TheMueniemeyer: yes, first look seems so15:22
rogTheMue: if you do state.SetEnvironConfig, i'll do the ProposedAgentTools stuff.15:23
niemeyerTheMue: Can you help us on that, with some priority?15:23
TheMueniemeyer: sure15:23
niemeyerTheMue: Thanks a lot15:23
TheMueniemeyer: yw15:23
niemeyerTheMue: There are quite a few things that are touched by that (provisioner, etc), but I suspect it will be rather pleasing. This is the last piece of the puzzle of config.Config, so I expect it to fall into place correctly in all cases.15:24
* rog goes for a bite of lunch15:24
TheMueniemeyer: so EnvironConfig() (*ConfigNode, *ConfigWatcher, error)?15:24
niemeyerTheMue: Uh?15:25
TheMueniemeyer: or two calls?15:25
niemeyerTheMue: We already have an environ watcher15:25
niemeyerTheMue: The idea is just to make EnvironConfig() and the respective watcher operate with config.Config, rather than ConfigNode15:25
niemeyerTheMue: We have proper helpers for everything15:26
TheMueniemeyer: aargh, read it wrong, sorry15:26
niemeyerTheMue: np15:26
TheMueniemeyer: already wondered15:26
niemeyerTheMue: State.EnvironConfig and the watch will both use config.New, and SetEnvironConfig will use Config.AllAttrs15:27
TheMueniemeyer: ok15:28
niemeyerI'll head to lunch15:32
TheMuerog: to get it right, state don't uses a persisted config anymore. it is in mem set with SetEnvironConfig()?15:45
rogTheMue: i'm not sure what you mean15:46
TheMuerog: today the config that is returned by EnvironConfig() is fetched from ZK15:47
TheMuerog: from the environment path15:48
TheMuerog: ah, explain helps15:48
TheMuerog: it's just a differrent return type, source of the data stays the same15:48
rogTheMue: +115:50
TheMuerog: had been confused for the moment due to the late jump into the discussion15:50
rogTheMue: np15:51
fwereadeTheMue, rog, Aram: when one upgrades a charm, and gets a conflict, and marks it resolved, I don't see any way for us to verify whether or not the user has actually done anything sensible with the conflicted data; does this sound like a problem to you, or a "just don't be an idiot" situation?15:55
rogfwereade: the latter15:56
SpamapShow might a charm upgrade cause a "conflict" ?15:56
rogfwereade: ^ you might wanna explain :-)15:58
fwereadeSpamapS, ah, sorry15:59
fwereadeSpamapS, short version: we're versioning charms16:00
fwereadeSpamapS, so we maintain a git repo of charms-used-by-this-unit, which just gets its contents overwritten neatly when we upgrade; and *then* we pull from that repo into the actual charm dir, which is itself a git repo16:01
fwereadeSpamapS, which then means that weird directory structure changes and the like will at least be *caught* when we try to upgrade16:01
SpamapSnice to see we're abandoning bzr whole-heartedly :)16:01
fwereadeSpamapS, haha, I wanted to use bzr, but it has an ugly crash in the precise situation that prompted this idea16:02
SpamapSfwereade: I feel like you can be way more heavy handed than this with a charm upgrade. If I say "give me version X" .. I don't mean "merge it into what I have now" .. I mean *X*16:02
SpamapSalso I feel like we need to (soon) make the charms readonly and enforce a data storage area for charms that want to write data.. but I keep forgetting to file a bug on that :p16:03
fwereadeSpamapS, ha, I would like that solution most of all, but my personal reading was that the writing-to-charm-dir genie was out of the bottle; is that completely wrong?16:04
SpamapSits out of the version 1 bottle16:05
SpamapSor rather, format: 1 bottle16:05
SpamapSformat: 2 is still unsettled...16:05
* fwereade makes very loud HMMMMM sounds16:05
SpamapS(and has actually never been discussed on the public mailing list.. which is a HUGE problem)16:05
SpamapSfwereade: why git tho. Why not just rsync?16:07
fwereadeSpamapS, (to briefly return to what you said before, the trouble is that without separate data storage we actually *are* always saying "merge with what I have")16:07
fwereadeSpamapS, er, because I didn't consider it, and when I thought "detect conflicts" I thought "VCS"16:07
SpamapSsee I don't think detecting conflicts is at all important16:08
SpamapSapplying delta tho.. that is..16:08
SpamapSrsync would fail for this..16:08
SpamapSand you're right, we are stuck w/ merging until we ditch the writable charm dir16:08
fwereadeSpamapS, ok; I was concerned that an un-thought-through upgrade from version X to version X+3, for example, could easily end up (say) blindly replacing a data dir with a file, and this seemed like unfriendly behaviour16:10
SpamapSfwereade: that must be thought through in upgrade-charm, not juju16:10
fwereadeSpamapS, but by the time upgrade-charm runs, the damage is done16:11
SpamapSfwereade: all I'd like to see is deltas applied sanely. VCS does make sense for that.16:11
SpamapSfwereade: its not "damage" if the author does something stupid16:11
SpamapSfwereade: authors *must* be cautious of exactly that situation.16:11
fwereadeSpamapS, (the other advantage, which feels like a nice help when writing/debugging charms, is that we can actually maintain a complete per-unit history of the charm dir)16:12
fwereadeSpamapS, in my mind this is indeed more targetted at authors than at users16:12
fwereadeSpamapS, if a user hits this situation the author has screwed up16:12
SpamapSauthors will have their own VCS16:12
SpamapSfwereade: feels very much like "trying to do too much"16:12
SpamapSWhat I really care about is that you try to apply all the delta from the shared base.. a straight "merge" problem.16:13
SpamapSIf I have created a 'data' dir in charm, and the new charm has a static data dir.. then yes, thats a conflict.16:13
fwereadeSpamapS, heh, I am not immune to this disease; I think niemeyer will be back from lunch soon, and I would like to involve him in this discussion16:14
fwereadeSpamapS, another benefit of merging is that (eg) deleted hooks actually get deleted16:14
SpamapSfwereade: I think its fine to do as you've suggested. Merge.. report conflict when they happen. I get it now.16:14
fwereadeSpamapS, cool16:15
SpamapSand I'm even wondering if thats actually more straight forward than trying to disallow writing16:15
fwereadeSpamapS, I think it is a pretty neat solution (which I totally can't take credit for)16:16
fwereadeSpamapS, although I was pleased with myself for then realising that we can commit charm dir state after every hook, which could be quite the debugging aid -- do you forsee any issues there?16:17
SpamapSfwereade: no, I don't think it should be a problem...16:18
SpamapSfwereade: some charms download lots of code into the charm dir on config-changed .. some even have git repos embedded.. so you have to be mindful of that.16:19
fwereadeSpamapS, ha, good wrinkle, hadn't thought of that16:23
fwereadegents, I need to be off; I'll try to get back on later16:24
fwereadetakes care all16:24
Aramniemeyer: your email mentioned a ChangeLog function, but: http://paste.ubuntu.com/1172117/16:35
Aramwhere is it? :).16:36
Aramor did you mean something else?16:36
niemeyerAram: Yo16:47
niemeyerAram: No, that was it really16:48
niemeyerAram: Are you not finding it after pull?16:48
Aramas you can see, no.16:49
Aramis my tip revision there correct?16:49
niemeyerAram: Let me check16:50
niemeyerAram: There's something awkward going on16:52
niemeyerAram: That revision is the one that introduced the ChangeLog function16:53
niemeyerAram: Try to run this: bzr diff -r 168..16916:53
TheMueAram: my godoc shows Runner.ChangeLog()16:53
niemeyerAram: Try to "bzr revert" perhaps16:53
niemeyerAram: To get the tree back in shape16:54
Aramniemeyer: it's in the diff.16:54
AramI'll do a revert16:54
Arammaybe this is the problem16:54
Aramwhite:txn$ bzr st16:54
Aramworking tree is out of date, run 'bzr update'16:54
Aramhow did that happen though?16:54
AramI didn't make any changes to it.16:54
Arambzr revert didn't do anything, bzr update solved it though16:55
niemeyerAram: I can't tell how you got there, but there are a number of ways this can happen16:56
Aramperhaps a go get -u did this?16:56
niemeyerAram: Quite possible16:57
niemeyerAram: Since it'll have to update backwards16:57
niemeyerAram: (the tag is not in the latest revision)16:57
niemeyerfwereade: ping17:15
fwereadeniemeyer, pong17:19
niemeyerfwereade: Do you have a moment for a call?17:23
niemeyerfwereade: I know it's late for you, so "no" is a fine answer17:23
fwereadeniemeyer, just a sec...17:23
fwereadeniemeyer, yeah, can we keep it down to 15 mins or so though please?17:24
fwereadeniemeyer, shall I invite? you and..?17:26
niemeyerfwereade: Let's go then17:27
niemeyerfwereade: You and me, for the moment17:27
fwereadeniemeyer, sent17:27
rogniemeyer: ping18:14
niemeyerrog: Yo18:14
rogniemeyer: i sent a response to your review18:14
rogniemeyer: only point of contention is 0666 vs 060018:15
rogniemeyer: i vote for former as it's standard18:15
rogniemeyer: and what threat are we protecting against?18:15
niemeyerrog: 0600 is the usual for files that contain credentials.. if it doesn't work with that file mode, it's broken18:15
rogniemeyer: ah, i see.18:16
niemeyerrog: re. 40ms, awesome!18:16
rogniemeyer: though i can't see how it could make any difference18:16
rogniemeyer: 4ms is probably when there's nothing to remove. and it is using my SSD device18:17
niemeyerrog: Sure, if it makes no difference, then 0600 is fine18:17
rogniemeyer: sure, ok.18:17
rogniemeyer: it'd probably be even faster if i wasn't running it -gocheck.vv18:18
niemeyerrog: Ah, most certainly18:19
rogniemeyer: a very useful program BTW: http://paste.ubuntu.com/1172299/18:19
rogniemeyer: i call it "timestamp"18:19
rogniemeyer: so i did (in state) go test -gocheck.vv 2>&1 | timestamp18:20
rogniemeyer: to find the timings18:20
niemeyerrog: Curious18:20
niemeyerrog: Clever, actually18:21
rogniemeyer: sample output: http://paste.ubuntu.com/1172303/18:21
niemeyerrog: This is awesome18:21
rogniemeyer: it's incredibly useful sometimes18:21
niemeyerrog: Well, curiously gocheck is also showing the timestamps in that one case18:23
rogniemeyer: unfortunately gocheck's timestamps wrap18:23
rogniemeyer: i've had a proposal in for ages to fix that18:23
niemeyerrog: Where's it?18:23
* rog looks18:24
rogniemeyer: https://codereview.appspot.com/5874049/18:25
niemeyerrog: I see.. I'd be glad to fix the wrapping, but requires some more thinking indeed18:26
niemeyerrog: It should at least be a consistent unit and length18:27
niemeyerrog: The length can of course vary on extremely long cases, but the sample output there is a bit awkward18:27
rogniemeyer: yeah.18:27
rogniemeyer: i've found that the output from "timestamp" works quite well.18:28
rogniemeyer: but that's probably because i'm used to it!18:28
niemeyerrog: What is it? min/sec/ms?18:28
rogniemeyer: yeah18:28
niemeyerrog: It looks reasonable to me as well actually..18:29
rogniemeyer: and i guess it doesn't matter so much if it wraps after an hour18:29
niemeyerrog: I'm actually more concerned on the lower side, but 1ms might be enough resolution18:30
rogniemeyer: it could be 04:05.000 i suppose18:30
niemeyer(to debug races)18:30
niemeyerrog: =118:30
rogniemeyer: yeah. i think that less than 1ms and stuff like the latency of locks around the logging starts to have an effect.18:30
niemeyerrog: mutexes should run well under that18:31
niemeyerrog: As in, several orders of magnitude below it18:31
rogniemeyer: true.18:32
rogniemeyer: if something is within a millisecond, then it deserves a closer look. but if i'm trying to debug a race, it's generally sensitive to the scheduler and i'll use println not Printf.18:33
* rog is not sure that those two sentences are in any way related18:35
niemeyerrog: :)18:35
niemeyerrog: I've used gocheck's output to debug races quite successfully in the past18:35
rogniemeyer: and sub-millisecond timing was important to that?18:36
rogniemeyer: the other weird thing about the current log time stamps is that they don't start from zero...18:38
niemeyerrog: It can help.. sometimes the timing tells how much apart the two events were18:43
niemeyerrog: I can't recall how much the under ms helped, though18:44
rogniemeyer: yeah. that was where my "if something is within a millisecond, then it deserves a closer look" statement came from.18:44
niemeyerrog: Since it was just there, I was considering it without realizing18:44
niemeyerrog: Well, that's too late18:44
niemeyerrog: If you're debugging a race, "deserves a closer look" is exactly what the log is for18:45
rogniemeyer: we could print microseconds too. i don't mind too much. i just want it not to wrap.18:45
niemeyerrog: I think ms is fine to begin with, to be honest18:47
niemeyerrog: If we ever miss resolution we can increase it18:47
rogniemeyer: sounds good. milliseconds is nice and human-friendly :-)18:47
niemeyerrog: I'd also do M:SS18:47
niemeyerrog: Rather than MM18:47
niemeyerrog: Or even SSS, I guess18:49
rogniemeyer: i vote for M:SS18:49
niemeyerrog: Works for me18:50
rogniemeyer: i think that makes the units marginally more obvious18:50
niemeyerrog: Yeah18:50
rogniemeyer: i'll repropose the CL18:51
niemeyerrog: Thanks a lot18:53
rog done19:52
rogniemeyer: CL reproposed19:52
rogi'm off now. see y'all tomorrow.19:52
mrammWow, 3 different Uverse technicians have been out to my house in the last 36 hours to try to fix my internets!22:04
mrammand finally I think we have got it resolved.22:05
mrammapparently "squirrels ate the wires"22:05
niemeyermramm: That's great22:22
niemeyerAram: Btw, I was wondering that maybe we could have an unbounded log22:22
niemeyerAram: Rather than a capped collection22:22
niemeyerAram: The difference is pretty minimal either way22:22
niemeyerAram: So we can tweak this22:22

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