[01:58] <hazmat> thumper, how's the proxy support coming? was specifically curious if the charm store downloads (addcharm via api) were using it yet
[01:58] <thumper> hazmat: hey
[01:59] <thumper> ah... wat?
[01:59] <thumper> how would the charm store stuff use proxies?
[01:59] <hazmat> thumper, that's the env downloading charms from the store via proxy
[01:59] <thumper> ah...
[01:59] <thumper> not tested that
[02:00] <hazmat> k
[02:00] <thumper> you know what... not even considered that :-)
[02:00] <thumper> support has been to set the environment for all the charm hooks
[02:01] <thumper> and for juju-run
[02:01] <thumper> but not for juju itself...
[02:03] <thumper> hazmat: ETA would be early next week
[02:09] <hazmat> thumper, cool
[02:51] <waigani> wallyworld: www.youtube.com/watch?v=KTc3PsW5ghQ
[04:45] <davecheney> shit, status is fast!
[08:23] <jamespage> davecheney, still awake?
[08:30] <rogpeppe> TheMue, fwereade: did you see https://codereview.appspot.com/56100043/ ?
[08:38] <TheMue> rogpeppe: just going through your branch
[08:38] <rogpeppe> TheMue: ok
[08:46] <TheMue> rogpeppe: btw, the removed logger package hasn't been by my, it's for watching the logging configuration. I used it first don't knowing the intention, but then moved my stuff into the debugger package.
[08:46] <rogpeppe> TheMue: oh, sorry - they seemed to be related
[08:47] <TheMue> rogpeppe: yeah, had the same wrong thought
[08:47] <TheMue> rogpeppe: fwereade told me then about its intention
[08:48] <rogpeppe> TheMue: so why was logTailer in the debugger package?
[08:48] <TheMue> rogpeppe: because it only is a private helper type for the debugger API
[08:50] <rogpeppe> TheMue: ah, it's kind of weird that "debugger" was separate from "logger", but anyway, i see now
[08:51] <TheMue> rogpeppe: thought so too
[08:55] <TheMue> rogpeppe: some of the changes don't really belong to the logging, don't they?
[08:56] <rogpeppe> TheMue: a couple of changes were forced on me because i couldn't propose without govet passing cleanly
[08:57] <TheMue> rogpeppe: and the code in api/client.go isn't needed anymore
[08:58] <rogpeppe> TheMue: right
[09:01] <TheMue> rogpeppe: so how would a client call that? never worked with with websockets, only implemented direct on IP so far
[09:01] <rogpeppe> TheMue: the same way a client gets a websocket connection to the regular API
[09:01] <rogpeppe> TheMue: (except with a different URL path)
[09:03] <TheMue> rogpeppe: sorry, a bit more practical would be nice, so that I directly can remove my lack of knowledge with you
[09:04] <TheMue> rogpeppe: for the API usage I simply used already existing functionality
[09:04] <rogpeppe> TheMue: ok, so... look at state/api/apiclient.go
[09:05] <TheMue> rogpeppe: yep
[09:05] <rogpeppe> TheMue: the Open function in there makes a new websocket by dialling the API server
[09:06] <TheMue> rogpeppe: ic, ok
[09:07] <rogpeppe> TheMue: the Client.AddLocalCharm method is an example that makes its own http request
[09:08] <rogpeppe> TheMue: so to do the logging stuff, i would factor out some of the logic from Open so it can be reused in another request
[09:08] <TheMue> rogpeppe: hehe, just had the same idea
[09:09] <rogpeppe> TheMue: i wouldn't include any of the retry logic in that
[09:10] <TheMue> rogpeppe: so while the server site gets more simple the client side gets more complex (in the sense of that I've been able to simply reuse API and watcher mechanisms so far)
[09:11] <rogpeppe> TheMue: it shouldn't be much more code at all - most of it just code movement
[09:12] <TheMue> rogpeppe: as long as your sure what to do and this is no new area for you. don't underestimate the learning curve. you're doing all this API and websockets stuff since a longer time.
[09:13] <TheMue> rogpeppe: but gives me the chance to take a deeper look into it too. ;)
[09:13] <rogpeppe> TheMue: i'll sketch out a little more of the client side if you like
[09:14] <TheMue> rogpeppe: only if you've got the room for it, a quick outline. the first hints here already helped a lot
[09:15] <TheMue> rogpeppe: and I need the ok by fwereade
[09:17] <TheMue> rogpeppe: but I like the approach. I only would liked the API able to handle streams of data also by default more
[09:18] <rogpeppe> TheMue: most of our API stuff doesn't work with streams of data, but streams of changing state, which is a different thing
[09:18] <rogpeppe> TheMue: with the latter it's fine to drop intermediate state
[09:18] <TheMue> rogpeppe: I know, but the current way is that every new requirement of streamed data get's an extra way
[09:19] <TheMue> rogpeppe: a more generic implementation once, integrated in the api but different from the watchers today, yes, could then better be reused
[09:19] <rogpeppe> TheMue: you mean another watcher type?
[09:19] <TheMue> rogpeppe: maybe, would have to make more thoughts about it
[09:23] <rogpeppe1> TheMue: something like this for the client side: http://paste.ubuntu.com/6807442/
[09:29] <TheMue> rogpeppe1: is authentication handled with it?
[09:30] <rogpeppe1> TheMue: ah, no, you'll need to set the basic-auth info in the config headers
[09:31] <TheMue> rogpeppe1: could you add it to your branch above, so we can discuss it with fwereade
[09:31] <TheMue> ?
[09:32] <rogpeppe1> TheMue: unfortunately i think that means you'll have to copy the basicAuth function from net/http because it works on a Request not a Header
[09:32] <rogpeppe1> TheMue: ok, will do
[09:35] <TheMue> rogpeppe1: thx
[10:11] <rogpeppe1> TheMue: https://codereview.appspot.com/56100043/diff/40001/state/api/client.go
[10:12] <TheMue> rogpeppe1: already looking
[10:14] <TheMue> rogpeppe1: you know when fwereade is here again?
[10:14] <rogpeppe1> TheMue: no, sorry
[10:16] <fwereade> TheMue, sorry, I have been around, just trying to catch up on some other bits
[10:18] <TheMue> fwereade: ah, ok
[10:18] <TheMue> fwereade: rogers solution looks nice, quite different, but nice
[10:19] <TheMue> fwereade: you should take a look at it
[11:32] <benonsoftware> Hiya, I'm wondering if there's anyway to make juju launch spot instances?
[12:15] <hazmat> benonsoftware, nutshell no. its possible though to use external provisioning with the manual provider and just have juju manage the workload
[12:26] <benonsoftware> hazmat: Ah, okay then. Thanks.
[12:40] <rogpeppe1> would anyone be able to review this, please? https://codereview.appspot.com/54230044/
[12:45] <TheMue> rogpeppe1: taking a look
[12:45] <rogpeppe> TheMue: thanks
[12:46] <rogpeppe> TheMue: we had a discussion about the debug-log stuff, BTW. we're going to talk about it a bit more this afternoon.
[12:46] <TheMue> rogpeppe: great
[13:06] <TheMue> rogpeppe: reviewed
[13:06] <rogpeppe> TheMue: thanks
[13:06] <TheMue> rogpeppe: yw
[13:20] <rogpeppe> dimitern: any chance of a second look at https://codereview.appspot.com/54230044/ please?
[13:20] <dimitern> rogpeppe, looking
[13:20] <rogpeppe> dimitern: ta!
[13:31] <dimitern> rogpeppe, reviewed
[13:31] <rogpeppe> dimitern: ta!
[13:34] <dimitern> niemeyer, hey
[13:34] <niemeyer> dimitern: Yo
[13:35] <dimitern> niemeyer, when you have time, can you please review and possibly comment on the proposed changes we need in goamz (see the mail I've just sent for a link to the document)
[13:37] <niemeyer> dimitern: Definitely
[13:37] <niemeyer> dimitern: Should we have a call next week about it?
[13:37] <fwereade> niemeyer, dimitern, +1, invite me please
[13:37]  * fwereade forgot he has to collect laura, bbl
[13:37] <niemeyer> dimitern: Can you please book it and invite us?
[13:37] <niemeyer> fwereade: Uh oh :)
[13:54] <dimitern> niemeyer, sure and preference for day/time?
[13:55] <niemeyer> dimitern: Wednesday is probably a good day, as it's already filled with meetings
[13:55] <niemeyer> dimitern: 12:30 UTC?
[13:55] <dimitern> niemeyer, will do
[13:58] <dimitern> niemeyer, done - you should receive and invite
[13:58] <niemeyer> dimitern: Thanks
[13:59] <dimitern> fwereade, next wednesday, 12:30 utc
[14:07] <rogpeppe> anyone else see this error occasionally? (this is second time i've seen it today) ... value *net.OpError = &net.OpError{Op:"local error", Net:"", Addr:net.Addr(nil), Err:0x14} ("local error: bad record MAC")
[14:09] <dimitern> rogpeppe, nope
[14:31] <mgz> okay, I'm at the "hey, this should all work, but man I lack tests" stage with the network stuff
[14:42] <rogpeppe> natefinch: i see the replicaset tests fail reasonable often, usually in TestAddRemoveSet
[14:42] <rogpeppe> natefinch: usually with "panic: no reachable servers" (and a very long run time - 167s in this case)
[14:44] <natefinch> rogpeppe: hmm
[14:44] <natefinch> rogpeppe: I think this is just mongo taking forever to come up for some reason
[14:44] <rogpeppe> natefinch: probably
[14:45] <rogpeppe> natefinch: it's a bit worrying though, because maybe it's *never* coming up and perhaps this might make juju HA flaky for real
[14:45] <natefinch> rogpeppe: yeah :(
[15:02] <rogpeppe> natefinch, fwereade: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[15:48] <sinzui> mgz, fwereade, which bug should I be watching to know the rev we want to release as 1.17.1?
[15:53] <mgz> sinzui: sec, I'll attach a couple to the milestone
[15:53] <mgz> bug 1241674 is mine
[15:53] <_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:In Progress by gz> <https://launchpad.net/bugs/1241674>
[15:54] <frankban> core devs: using trunk (revno 2253) I am not able to deploy a local charm in a lxc env. unit logs: http://pastebin.ubuntu.com/6808945/, machine logs include permission denied error responses to CharmArchiveURL requests
[15:55] <sinzui> mgz, oh I didn't realise the issue was that specific bug. I thought the issue was something in a recent change to openstack
[15:55] <sinzui> thank you mgz
[16:03] <fwereade> sinzui, mgz's one is the only really important one, I think
[16:04] <mgz> I'm currently done... apart from I've got some tests losing my new config value and can't work out why
[16:06] <rogpeppe> anyone reasonably familiar with worker/provisioner?
[16:06] <rogpeppe> i'm seen a sporadic test failure, and i can't work out quite what a particular test is supposed to be testing
[16:06] <rogpeppe> s/i'm/i've/
[16:09] <fwereade> rogpeppe, which test?
[16:09] <rogpeppe> fwereade: TestProvisioningSafeModeChange
[16:09] <rogpeppe> fwereade: at the end of it, it ensuredead+removes a machine, and expects the provisioner not to remove the instance
[16:09] <rogpeppe> fwereade: that seems kind of odd to me
[16:10] <rogpeppe> fwereade: it seems like it's relying on the fact that the provisioner hasn't seen the new machine
[16:10] <fwereade> rogpeppe, so, the deal is that because the instance got *removed* the provisioner has no basis for taking down the instance
[16:10] <fwereade> rogpeppe, but ISTM that that's a bad tes
[16:11] <fwereade> rogpeppe, the provisioner should be stopped for those terminal actions on m3, m4, else it could plausibly see m4 when dead, and legitimately remove it
[16:11] <rogpeppe> aw, frick, *another* sporadic failure
[16:11] <rogpeppe> fwereade: exactly
[16:11] <rogpeppe> fwereade: and that's how the test failed
[16:12] <fwereade> rogpeppe, if that's what you see too, though, at least it's one we've found and can fix, I think
[16:12] <rogpeppe> fwereade: but if we stop the provisioner, then what are we testing?
[16:12] <fwereade> rogpeppe, ha
[16:12] <fwereade> rogpeppe, that just reduces to TestProvisionerSafeMode, doesn't it?
[16:14] <fwereade> rogpeppe, and there's the advantage of mocking out the api server
[16:14] <rogpeppe> fwereade: ISTM that a better test would actually add an instance behind the scenes
[16:14] <fwereade> rogpeppe, that sounds good to me
[16:14] <fwereade> rogpeppe, I think that's equivalent
[16:15] <mgz> well, I hate our testing infrastructure
[16:15] <rogpeppe> mgz: it could be better :-)
[16:15] <mgz> I have no clue where it's losing the config value, or how I should actually just write a damn test with a different config value
[16:17] <mgz> okay, finally
[16:17] <mgz> randomly try things till it works joy
[16:29] <rogpeppe> mgz: sorry, i would help but i'm up to my eyeballs currently
[16:29] <mgz> okay, I'm done
[16:30] <mgz> proposing now
[16:30] <mgz> meh, need another goose bump but hey
[16:31] <rogpeppe> oh balls, another sporadic failure. that's four in a row
[16:36] <mgz> goose bump... I just realise that was a pun
[16:41] <mgz> part #1: https://codereview.appspot.com/56670043
[16:41] <mgz> I need that one sort of right now, to land so I can bump dependencies.tsv
[16:42] <natefinch> mgz: I can review
[16:42] <mgz> ta! it's a bit of a cop-out proposal for now
[16:42] <mgz> Ill put the main bit up sans the bump too for reference
[16:44] <rogpeppe> hmm, i think it's wrong that the local provider should have added an authorized key to my ~/.ssh/authorized_keys
[16:44] <rogpeppe> fwereade: would you agree ?
[16:44] <fwereade> rogpeppe, ha! definitely
[16:44] <fwereade> rogpeppe, well spotted
[16:45] <rogpeppe> fwereade: also, trunk is currently producing zillions of errors when you've got a badly formatted key (for instance the FakeConfig auth keys)
[16:45] <fwereade> rogpeppe, and that's causing sporadic failures in jujud tests
[16:45] <rogpeppe> fwereade: (try running "go test -gocheck.f ManageEnviron'$' -gocheck.vv)
[16:45] <rogpeppe> fwereade: yes
[16:45] <fwereade> rogpeppe, thumper came across that last night
[16:46] <rogpeppe> fwereade: i'm just fixing the fake config to have a valid key
[16:46] <fwereade> rogpeppe, <3
[16:46] <rogpeppe> fwereade: but really the authorized keys worker should not be barfing
[16:46] <rogpeppe> fwereade: in fact, i'll just fix that
[16:46] <fwereade> rogpeppe, mmmm I'mmore inclined to say we should be refusing bad input
[16:46] <rogpeppe> fwereade: mebbe
[16:47] <rogpeppe> fwereade: we should probably parse authorized keys on config.New
[16:47] <mgz> part #2: https://codereview.appspot.com/52710048
[16:47] <mgz> fwereade: ^you probably care about this one
[16:48] <rogpeppe> one more barrier, sigh
[16:52] <rogpeppe> ha, not only did it change my authorized_keys, it replaced it with a file owned by root and globally readable
[16:54] <fwereade> mgz, quickly pre-reviewed, trying to finish rog's
[16:55] <mgz> fwereade: ta
[16:56] <fwereade> rogpeppe, reviewed, almost there, I think there may be a commentor two you missed from the earlier one?
[16:57] <fwereade> rogpeppe, maybe actually there
[16:57] <fwereade> rogpeppe, let me know :)
[16:57] <rogpeppe> fwereade: entirely possible
[16:57] <rogpeppe> fwereade: ok
[16:57] <rogpeppe> fwereade: thanks
[16:57] <rogpeppe> fwereade: it's going to take at least another 30 minutes before i can re-propose though, because now i have two prereqs
[16:58] <rogpeppe> fwereade: ah, i hadn't published my reply
[16:58] <rogpeppe> fwereade: my reply was "
[16:58] <rogpeppe> you're right - i was surprised when this worked.
[16:58] <rogpeppe> it's a bug in Machine.Destroy - it doesn't fail
[16:59] <rogpeppe> when the machine only has JobManageState.
[16:59] <rogpeppe> "
[16:59] <rogpeppe> fwereade: and it's the fallout from fixing that that's taken me two days to get over
[16:59] <rogpeppe> fwereade: so you will see that i've fixed that in the latest version, when i can actually propose it :-\
[17:00] <fwereade> rogpeppe, ha, ok, cool
[17:00] <fwereade> rogpeppe, I'm kinda eoding but I'll be in and out
[17:00] <fwereade> rogpeppe, will be interviewing someone this evening so I'll pick it up then if not before
[17:00] <mgz> fwereade: I dont' follow the config omit/,ok comments, is that a new config thing?
[17:01] <mgz> in the providers, we've always just used blanks and defaults
[17:01] <rogpeppe> fwereade: i *think* i've addressed all the issues, (although i kept the bool in effectiveMachineTemplate for reasons i outlined in the comments i've just published)
[17:02] <mgz> okay, goose bits landed, juju-core fix ready to go
[17:02] <fwereade> mgz, I don't think we always have, but I'm pretty unsure about those suggestions
[17:03] <fwereade> mgz, not gonna fight them, just tabling the option in case you feel it fits better
[17:03] <mgz> it may well make sense tweaking some of these things after 1.17.1 - but that should be safe
[17:03] <mgz> I'd not be surprised if something's borked and needs fixing once I've had some people test this better anyway
[17:05] <mgz> if I have a ltm I'll land and crtis can get started
[17:07] <fwereade> mgz, for reasons too complicated to explain quickly I can't do this right now, but I'd LGTM it with a more explicit test for that one with .*s in the error message
[17:07] <rogpeppe> ha, these two strings are different... where? http://paste.ubuntu.com/6809355/
[17:08] <mgz> fwereade: okay, I'll tweak that one a bit
[17:08] <rogpeppe> ha, got it
[17:12] <mgz> okay, I need to go out till later on, feel free to flip that branch to approved in my absence
[17:17] <rogpeppe> ha, some of the tests actually rely on the fact that the authorized_keys used in testing are invalid
[17:17] <rogpeppe> sigh
[17:47] <rogpeppe> fwereade, mgz, natefinch: this fixes the testing auth keys issue: https://codereview.appspot.com/56680043
[17:48] <rogpeppe> i'd very much appreciate a review
[17:56] <rogpeppe> oh well, guess it's not gonna happen
[17:59] <natefinch> rogpeppe: I can do it, was just having lunch
[18:00] <rogpeppe> natefinch: that would be great, thanks - i have to stop now, but if that's approved, i should be able to able to get other branches in
[18:00] <natefinch> rogpeppe: cool
[18:02] <rogpeppe> g'night all
[18:02] <natefinch> g'night rog
[18:55] <hazmat> no upper case chars in services names?
[18:55] <hazmat> seems strange
[19:00] <natefinch> hazmat: keeping them all lowercase does simplify things somewhat, so you don't have to type out people's wEiRd nAMes... though you'd think that just making them case insensitive would work as ewll
[19:03] <hazmat> true.. though theres some other oddity to the naming.. ie. no wierd-1, but okay on wierd-1s
[19:03] <hazmat> not a big deal.. i'm autogenerating service names at the moment was just a surprise
[19:04] <natefinch> hazmat: yeah, I remember seeing that they need to start and end with a letter... don't know offhand why
[19:50] <mgz> sinzui: where are we at?
[19:53] <sinzui> mgz, cursing cannonistack because we have run out of resources to test
[19:54] <mgz> urg
[19:57] <sinzui> mgz, once your work lands, CI will start the tests. I may need to run some manually to cleanup secgroups. If all pass, I will do the release. I can do it ina  few hours. I can do the release in the mornings of the weekend too
[19:58] <mgz> natefinch: can I have a lgtm on my second part if you have a moment?
[20:00] <natefinch> mgz: oh yeah, I thought someone else was looking, but I'll look now
[20:01] <mgz> thanks!
[20:12] <natefinch> mgz: done
[20:12] <mgz> natefinch: thanks!
[20:44] <mgz> sinzui: sending to land now, you should get a notification when it's in
[20:44] <sinzui> mgz: thank you.
[21:06] <sinzui> mgz, I think gobot hates you
[21:07] <mgz> looking
[22:00] <mgz> have tried resubing a couple of times, it may need more unsticking somehow
[22:16] <mgz> sinzui: landed!
[22:16] <sinzui> thank you!