[00:05] <thumper> wallyworld_: hangout now?
[00:06] <wallyworld_> ok, just let me get my headphones
[00:07] <wallyworld_> thumper: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
[01:57] <thumper> wallyworld_: looking at your create machine branch
[01:57] <thumper> wallyworld_:  surprised at the amount of change
[01:58] <thumper> wallyworld_: wondering why you didn't just add a function: func (st *State) AddMachineWithConstraints(series string, extraCons *constraints.Value, jobs ...MachineJob) (m *Machine, err error) {
[01:59] <thumper> wallyworld_: then there wouldn't be so much change
[01:59] <thumper> wallyworld_: also, putting constraints before the other params seems wrong too...
[02:00] <wallyworld_> thumper: i thought creating machines with constraints would become the norm
[02:00] <thumper> wallyworld_: not in our tests
[02:00] <thumper> it is just noise now
[02:01] <wallyworld_> you also dislike the constraints param before the jobs param?
[02:01] <wallyworld_> it can't go after
[02:01] <thumper> no, before instance and nonce
[02:02] <thumper> strange as it may seem...
[02:02] <thumper> to me it is like pushing in
[02:02] <wallyworld_> i think it (the consraints param)  aligns more closely with the series param
[02:02] <wallyworld_> it is pushing in, but that's deliberate
[02:02] <wallyworld_> series and constraints for of go together to me
[02:02] <wallyworld_> sort of
[02:03] <thumper> perhaps...
[02:03] <thumper> but I think we should have an extra method for adding constraints
[02:03] <wallyworld_> i can look at adding the extra method to reduce the noise
[02:03] <thumper> that means all the tests still look good
[02:03] <wallyworld_> yep, ok
[02:03] <thumper> I'll keep reviewing
[02:04] <thumper> also...
[02:04] <thumper> soy flat white tastes funny
[02:04] <wallyworld_> *soy* why???????
[02:04] <thumper> ran out of milk
[02:04] <wallyworld_> you ran out of milk
[02:04] <thumper> and don't like black coffee
[02:04] <wallyworld_> i would have had a pure expresso
[02:04] <wallyworld_> espresso
[02:04] <thumper> nah
[02:05] <wallyworld_> good coffee, tastes quite nice
[02:05] <wallyworld_> don't you have a shop just up the road?
[02:06] <thumper> sick kids at home
[02:06] <thumper> can't really leave them alone
[02:06] <thumper> and don't want to take them with me
[02:07] <wallyworld_> oh yeah, forgot that
[03:39] <wallyworld_> thumper: thanks for the reviews, i think i've addressed the issues
[03:39] <thumper> ok, will look shortly
[03:42] <wallyworld_> no hurry
[06:02] <dimitern> morning everybody
[07:02] <fwereade> morning all
[07:38] <dimitern> fwereade: morning
[07:42] <fwereade> dimitern, heyhey
[07:58] <dimitern> fwereade: i'll start implementing the necessary stuff to allow agents to connect to the API server first thing today
[07:59] <fwereade> dimitern, great, I'm still catching up on email etc myself
[08:02] <thumper> fwereade: you going?
[08:02] <fwereade> thumper, oh, hey, you're still around? sorry, I didn't check, I thought it'd be unreasonably late for you
[08:02] <kyhwana> fwereade: it's only 20:00
[08:03] <thumper> fwereade: no, it is about 0800UTC which is the time I'm back
[08:03] <thumper> I said that in the email :)
[08:03] <thumper> I came back especially to talk to you and TheMue
[08:03] <thumper> fwereade: so time for the "ah ma gahd" hangout?
[08:03] <fwereade> thumper, cool, thanks, I forgot UTC was 2 hours
[08:03] <thumper> :)
[08:03] <fwereade> thumper, TheMue, I am at your service
[08:04] <thumper> fwereade: I'll chat first, and will grab TheMue after...
[08:11]  * TheMue is listening
[08:43] <dimitern> reviewers? https://codereview.appspot.com/9781044/ - a small step towards having API connection in agents
[08:44] <dimitern> fwereade, TheMue: ^^
[08:55] <thumper> TheMue: ping?
[08:56] <dimitern> yo thumper!
[08:56] <thumper> dimitern: hey there
[08:56] <dimitern> thumper: if you have 5m take a look at that CL? ^^
[08:56] <thumper> sure, while I'm waiting :)
[08:58] <thumper> dimitern: you have one :)
[08:58] <dimitern> thumper: cheers!
[09:02] <TheMue> thumper: pong
[09:02] <thumper> TheMue: hey, care to join the hangout?
[09:40] <dimitern> fwereade: ping
[09:41] <fwereade> dimitern, sorry, meeting
[09:41] <dimitern> fwereade: np, ping me when you have 5m pls
[10:24] <fwereade> dimitern, hey dude
[10:25] <dimitern> fwereade: hey, can you take a look at https://codereview.appspot.com/9781044/ please?
[10:25]  * fwereade looks
[10:26] <fwereade> dimitern, can we g+ a moment? need to read surrounding code and think out loud at you a bit
[10:27] <dimitern> fwereade: sure, i'll start one
[10:27] <fwereade> dimitern, cheers
[10:27] <dimitern> fwereade: https://plus.google.com/hangouts/_/31a0adf406ea37411478622bf93d2c364764ab93?authuser=0&hl=en
[11:33] <danilos> dimitern, hey, joining us?
[11:37] <dimitern> danilos: oops be right there
[12:32] <dimitern> fwereade: https://docs.google.com/a/canonical.com/document/d/1qNSzFUh_r_fnceAUDsIT4SPVJhCH4G8V-YfXpv_GQGA/edit?usp=sharing
[12:41] <fwereade> dimitern, cheers
[12:42] <dimitern> fwereade: actually it looks like you cannot access ping/pong frames directly - they're handled internally
[12:42] <dimitern> fwereade: and the gui guys actually wait for a connection to be dropped and then reconnect
[12:49] <dimitern> fwereade: also, looking at the apiserver implementation, when a connection is dropped the server dies, so that's a possibility to detect
[12:57] <dimitern> fwereade: ping
[13:17] <fwereade> dimitern, heyhey, sorry, meeting again -- g+?
[13:17] <dimitern> fwereade: yeah, just a sec
[13:17] <dimitern> fwereade: https://plus.google.com/hangouts/_/4cdea2d176b825a710dfe5865a1b69ca5bd61944?authuser=0&hl=en
[13:41] <dimitern> fwereade: you just froze and i tried to rejoin
[15:34] <dimitern> fwereade: https://codereview.appspot.com/9811044/
[15:47] <fwereade> dimitern, I'm not sure we should be exposing SetDeadline directly... and I'm becoming unsure whether it's actually what we need, I think my brain was still parsing it as SetTimeout
[15:47] <fwereade> dimitern, it doesn't strike me as very goroutine-safe
[15:47] <fwereade> dimitern, in the service of quick progress I think I'd be fine with just a trivial Ping() method
[15:48] <fwereade> dimitern, if we want to get clever with deadlines I think we need to do it around where we're actually reading/writing on the conn
[15:48] <fwereade> dimitern, sensible?
[15:50] <fwereade> dimitern, and remember, we need to have this turning into a channel close at some point so we can select on it
[15:50] <fwereade> dimitern, ideally all we'd be exposing on State is a method returning that channel
[15:51] <fwereade> dimitern, sorry, gtg, bank
[15:53] <dimitern> fwereade: sgtm, I'll leave Ping() only then
[15:54] <fwereade> dimitern, consider keeping it unexposed on the client, though, I can't think of much reason to use it
[15:55] <fwereade> dimitern, I'm thinking of something like select { <-apist.ConnDead(): ... }
[15:55] <dimitern> fwereade: we can't - how should we call it if it's not exposed on che client
[15:55] <fwereade> dimitern, can't the client keep track internally of the connection's state?
[15:55] <dimitern> fwereade: are we talking about Ping here?
[15:55] <fwereade> dimitern, that's what I'm looking for
[15:55] <fwereade> dimitern, Ping is just a means towards that end
[15:55] <dimitern> fwereade: ok, i'm confused now
[15:56] <fwereade> dimitern, so the server needs it
[15:56] <fwereade> dimitern, but there's little cause for a client of api.State to ever call it
[15:56] <fwereade> dimitern, because a client of api.State cares about whether the conn has gone down
[15:56] <dimitern> fwereade: what then?
[15:56] <fwereade> dimitern, and api.State should be exposing that information
[15:56] <dimitern> fwereade: it's intended to be called by the task monitoring the heartbeat
[15:57] <fwereade> dimitern, I wasn't expecting that to be a task as such... and, sorry, I really must go, I'll ping you when I'm free again
[15:58] <dimitern> fwereade: so you're suggesting to implement a goroutine in the client to periodically ping the server and have a Closed() <-chan error available outside?
[15:58] <dimitern> fwereade: ok, ping me when you're back
[16:30] <mramm> just checking for a few minutes here on my day off -- anobody need anything?
[16:31] <dimitern> mramm: everything is fine :)
[16:31] <mramm> dimitern:  I figured it would be.   You guys are all great.
[16:33] <dimitern> :)
[16:33] <dimitern> i'm off - can't think anymore, need to rest
[19:49] <ahasenack> hm, since default-image-id is now deprecated:
[19:49] <ahasenack> 2013/05/27 16:49:25 WARNING config attribute "default-image-id" (4dade8d2-2b95-4e4c-b947-c5e3ff4a31ea) is deprecated and ignored, use simplestreams metadata instead
[19:50] <ahasenack> and gojuju by itself seems unable to find a suitable image id:
[19:50] <ahasenack> 2013/05/27 16:49:37 ERROR command failed: cannot start bootstrap instance: no "precise" images in lcy02 with arches [amd64]
[19:50] <ahasenack> how do I bootstrap? In this case, it's openstack
[19:50] <ahasenack> (canonistack to be more precise)
[21:26] <fwereade> ahasenack, `juju image-metadata` will generate simplestreams data for a single image as specified, and you can then copy those to your public-bucket
[21:26] <fwereade> ahasenack, I *think* we are expecting simplestreams data to be published for lcy02 before too long, but I'm not really up to speed on that, was on holiday last week
[21:28] <ahasenack> fwereade: ok, got something to play with now
[21:28] <ahasenack> $ juju image-metadata -a amd64 -i 4dade8d2-2b95-4e4c-b947-c5e3ff4a31ea -r lcy02 -s precise -e https://keystone.canonistack.canonical.com:443/v2.0/
[21:28] <ahasenack> Boilerplate image metadata files "index.json, imagemetadata.json" have been written to /home/andreas/.juju.
[21:28] <ahasenack> Copy the files to the path "streams/v1" in your cloud's public bucket.
[21:28] <ahasenack> thanks
[21:28] <fwereade> ahasenack, great
[21:29] <ahasenack> fwereade: it was so simple when all I needed was default-image-id :D
[21:30] <fwereade> ahasenack, it's a bit annoyingly manual at the moment, but it's better than having to assume that the default image id always has the exact required characteristics (regardless of series, arch, etc)
[21:32] <fwereade> ahasenack, default-image-id just enables too many fail cases -- if the tools don't match the image, nothing will work, and the reasons will be desperately unclear... although we kinda dropped the ball on the error message there, the resolution is far from clear. bah.
[21:36] <fwereade> ahasenack, would it have helped if the error message just ended with "(run `juju image-metadata`)"?
[23:40] <wallyworld_> fwereade: another problem which we can discuss tonight (my time) - stale data. there are issues with the tests which mask stale data issues in the domain entities. our code is broken, need to think about how to fix
[23:42] <wallyworld_> right now, some tests pass by fluke. adding code to ensure dirty attribute is properly refreshed causes other tests which rely on the stale data to fail