[02:17]  * thumper takes kid to sports
[02:29] <jam>  wallyworld: I'm probably not going to make our 1:1 today, my son has his "Winter Musical" this morning
[02:29] <wallyworld> ok
[02:29] <wallyworld> enjoy :-)
[04:05] <wallyworld> thumper: hey. i added fingerprint support to the ssh utils
[04:05] <thumper> wallyworld: cool
[04:05] <wallyworld> had to call out to ssh-keygen
[04:06] <wallyworld> i couldn't find a Go implementation
[07:44] <thumper> jam: I'm actually around now
[07:45] <thumper> if fwereade_ is too
[07:45] <jam> thumper: I'm around as well, not sure about fwereade_
[07:45] <thumper> I had another call at 0800UTC, but it has been moved
[07:47] <jam> thumper: well, william responded to one of my emails at 11pm last night, so it may be that he's going to be a bit later today
[07:54] <wallyworld> thumper: don't forget to look at my ssh branch again :-) tomorrow first thing your time will be fine :-)
[07:57] <thumper> wallyworld: ack
[07:58] <wallyworld> thanks
[08:00] <fwereade_> jam, thumper: if you're both here let's chat now
[08:07] <jam> fwereade_: I'm just chatting with dimiter for a bit, and then I'll be right with you guys
[08:12] <thumper> sorry, was making a coffee
[08:12] <thumper> fwereade_: , jam (when you're ready): https://plus.google.com/hangouts/_/7ecpitcov2peobbk7u31s52nn0?hl=en
[09:03] <rogpeppe> mornin' all
[09:06] <jam> hey rogpeppe, just in another call, will be there in a sec
[09:16] <jam> rogpeppe: I'm in now, whenever you're available
[09:58] <jam> mgz: good morning!
[09:59] <jam> I'm just about to go make a coffee, and then I'll be around, mumble or hangout is fine for me.
[09:59] <mgz> jam: sure
[10:10] <jam> mgz: I'm back, mumble or hangout?
[10:10] <mgz> jam: mumble!
[10:11] <jam> mgz: I'm already there
[10:11] <jam> mgz: you're completely unintelligible
[10:11] <mgz> it's unhappy...
[10:11] <jam> he-e-e-l-l-l-o-o-o-o-o
[10:12] <mgz> that's how you're coming through for me
[10:45] <jam> time to stand up, raisin' the roof
[10:45] <jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[10:45] <jam> rogpeppe: fwereade_, TheMue ^^
[10:45] <jam> dimitern: ^^
[10:48] <natefinch> can someone give me the meeting link? my chrome is acting up
[10:48] <mgz> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[11:42] <wallyworld> fwereade_: for later when you are free, i renamed "credentials" package to "keyupdater" https://codereview.appspot.com/37570043
[12:29] <mgz> dstroppa: dimitern mentioned you want to run `go fmt ./...` on lp:gojoyent
[12:29] <mgz> and the others are also taking a look at the cl
[12:30] <dstroppa> thanks, will do that
[12:30] <mgz> if we did it all correctly, you should be able to make changes then run the same lbox command to update the review
[12:31] <dimitern> dstroppa, mgz, thanks!
[12:58] <rogpeppe> jam: i updated the firmware on my router and it seems to have fixed the issue
[12:59] <rogpeppe> jam: (even though the firmware update notes contained no mention of the bug)
[13:31] <dimitern_> rogpeppe, jam, fwereade_, mgz, et al - just letting you know ^^
[13:31] <rogpeppe> dimitern_: just letting us know what?
[13:31] <dimitern_> ah, sorry
[13:31] <dimitern_> * dimitern_ needs to be off for a while, the electrician came to change the wires and i won't have power for at least 1 hour
[13:32] <dimitern_> ( though I managed to send it, but apparently not)
[13:32] <mgz> dimitern: good luck :)
[13:32] <dimitern_> mgz, cheers :)
[17:10] <mgz> rogpeppe: query about doing providery things from inside the apiserver
[17:10] <rogpeppe>  mgz: go on
[17:11] <mgz> to actually recreate status as it exists currently, I'd need to do provider Instances() to get instance statuses
[17:11] <mgz> this is something the apiserver doesn't actually want to do... how can I get around that for now without borking things?
[17:11] <rogpeppe> mgz: if we can avoid that, we should
[17:12] <mgz> currently the output is just different...
[17:12] <rogpeppe> mgz: eventually, we probably want a worker that keeps the instance status in the state up to date
[17:12] <rogpeppe> mgz: for the time being, perhaps you can't avoid it
[17:12] <mgz> one option is to leave some of that client-side for now
[17:12] <rogpeppe> mgz: let's not do that
[17:13] <mgz> but that makes api-status less fun
[17:13] <rogpeppe> mgz: that loses a lot of the bonus of client-side status
[17:13] <rogpeppe> s/client-side/API-based/
[17:13] <mgz> right
[17:14] <mgz> so, it's not completely unsafe to construct and use a provider inside an api call? I note some make one to look at config stuff
[17:14] <rogpeppe> mgz: no, it's notr
[17:14] <rogpeppe> mgz: and some calls currently do that, i think
[17:14] <mgz> but nothing seems to actually use the provider to do and cloud-operations, so I'm a little scared
[17:15] <rogpeppe> mgz: well, currently the deploy API call (whatever it's called) does
[17:15] <rogpeppe> mgz: it puts stuff into provider storage
[17:15] <mgz> ah, I'll have a look at that, a grep didn't turn it up
[17:15] <rogpeppe> mgz: look for ConnFromState
[17:16] <rogpeppe> mgz: yeah, looks like it's just charm putting
[17:17] <rogpeppe> mgz: i think that for the time being, we should probably just move the provider Instance calls into the API.
[17:17] <mgz> rogpeppe: okay, thanks, I'll have a play around
[17:18] <rogpeppe> mgz: but...
[17:18] <rogpeppe> mgz: if we can, we should avoid iterating when the instance doesn't exist
[17:18] <rogpeppe> mgz: and we should make only one provider call if possible to get all the instances
[17:19] <rogpeppe> mgz: that way the overhead's not too bad
[17:19] <mgz> well, my current scheme is just to bung everything behind one single call
[17:19] <mgz> not split the instance fetching and machine fetching at all
[17:20] <rogpeppe> mgz: i'm talking about the implementation of the Client.Status call
[17:21] <rogpeppe> mgz: ah, looking at the current implementation, that's what it does anyway,
[17:21] <rogpeppe> mgz: so that's fine
[17:22] <mgz> right, in the cmd status it just lists everything once then sticks in in a struct to do further work on
[17:24] <rogpeppe> mgz: yeah - that's just fine
[17:25] <rogpeppe> mgz: the place we want to be a bit more intelligent is in the address updater, but that's a different discussion
[18:07] <hazmat> jam, fwereade_ re the manual provider support in 1.16.. does that effect the api ongoing for 1.18/trunk?
[18:41]  * rogpeppe is done for the day
[18:45] <jam> hazmat: inasmuch as we want to be backwards compatible to what we had in 1.16 (fallback to direct DB access), it does, but I don't think it is massively deep. A couple hours for me to finish making 1.17 compatible with the 1.16 manual provisioning steps.
[18:45]  * jam is off to bed
[18:46] <mgz> night jam!
[18:48] <hazmat> jam.. ic. so no api changes per se to 1.18/trunk?
[18:48] <hazmat> jam, g'night.. i just want to avoid non go clients from contemplating tool lookup, the current machine config api does that nicely.
[22:20] <thumper> any one know if the result from os.Pipe() is serializable over net/rpc ?
[22:21] <thumper> just considering options in testing...
[22:21] <thumper> but I suppose I can test it now...
[22:21]  * thumper pokes