[01:12] evilnickveitch: any significance to the pear and cake? what you happened to be eating at the time you merged? ;) [01:15] axw: heads up. I've added you to a seattle session per alexisb's request as the expert as we got poking at an issue with ssh keys being requires for createEnvironment. Some notes in the doc linked to the session: https://docs.google.com/document/d/1JsVFVx0P6wKdBIPqYPOBiYqYNRpb5kR8ept_NfmkXPw/edit#heading=h.13n2f81u0zpj [01:15] axw: just a heads up in case there's any pre-thought required :) [01:15] rick_h_: thanks [01:23] thumper: fyi https://github.com/gorilla/websocket#gorilla-websocket-compared-with-other-packages [01:33] davechen1y: handy [01:37] hopefully it helps [01:43] http://reviews.vapour.ws/r/2742/, anyone ? [01:46] davechen1y: ship it [01:46] I thought I was the only one changing deps by hand [01:49] Posted 7 minutes from now (Sept. 24, 2015, 11:56 a.m.) [01:49] ^ reviewboard lives in the future [01:50] davechen1y: yes, bleeding-edge technology :P [01:50] perrito666: thanks [01:53] axw: cherylj natefinch-afk you have reviews that have been approved [01:53] please land then [01:54] davechen1y: mine are all blocked [01:55] I would love to land them :) [01:55] axw: blocked on what ? [01:55] are they against master, or a branch ? [01:55] davechen1y: 1.24 and 1.25 are blocked [01:55] those two [01:55] \bummer [01:59] I think I've landed an unblocker for 1.24 [01:59] waiting the bless [01:59] and I'm looking at 1.25 bug [01:59] but missing info [02:03] davechen1y, waigani: team meeting time [02:05] thumper: see you there [02:07] thumper: coming === natefinch-afk is now known as natefinch [02:22] davechen1y: if you spoke spanish I would get you to record my answering machine message [02:22] lol [02:25] thumper waigani: fixed the link. for some reason the event shows up on my calendar twice: one I can edit, one I can't [02:25] axw: nice work :) [02:26] axw: one is your event (it copies when you accept it) the other one is the actual event [02:26] perrito666: ah. [02:42] good god our watcher code needs better documentation [02:51] what's the correct way to watch a collection where I just want a notification whenever anything is added to the collection? Looks like I should use newEntityWatcher or newDocWatcher, but they're both woefully underdocumented as to what "key" is supposed to be, and it is ever so helpfully an interface{} :/ [02:51] natefinch: I have no idea sorry [02:59] hazaah, blessed 1.24 [02:59] yay [03:00] * thumper forward ports to 1.25 [03:03] aka patch or commit [03:05] perrito666: http://www.amazon.com/gp/product/B004UWY4KG [03:09] ok ok,ill buy one [03:10] perrito666: lol [03:11] k ppl gnight [03:12] perrito666: I think I don't have a tron poster, oddly enough. I have several others - star wars (a reproduction), hackers, 5th element... forget what else. I had a dedicated movie room for a long time that I decorated... now they're just in storage. I'll take out the hackers poster and put it next to my desk, though. [03:12] perrito666: night [03:12] natefinch: ill send one of those to the hotel once I figure where it is [03:53] is there any way to go back through the logs of a closed hangout? [03:55] thumper: not to my knowledge [04:08] cmars: ping? [04:08] * thumper is being hopeful [04:10] google says you can retrieve them via gmail [04:11] davechen1y: and if you dn't use gmail? [04:15] well, i couldn't find it in gmail [04:15] it might allso be in the hangouts app on g+ [04:16] * davechen1y tries to help, but hits is knee on the coffee table [04:29] mongo is one shithouse piece of software [04:54] davechen1y: what brought this on? [04:54] * thumper is amused with "shithouse" as Ian uses that too [04:54] must be an ozzie thing [04:55] * thumper back later for TL meeting === thumper is now known as thumper-afk [04:58] thumper-afk: i'm fucking sick of loosing 1 CI run out of 5 because mongo shits itself on startup [06:23] wwitzel3: you're not working, right? I'm going to fix this 1.25 blocker if you're not actively working on it atm [06:45] davechen1y: would you kindly review http://reviews.vapour.ws/r/2745/? fixes the 1.25 blocker [06:55] axw: hiya [06:55] axw: ship it [06:55] davechen1y: ta [06:55] rogpeppe: howdy [06:55] davechen1y, axw: do you know what the procedure is meant to be for merging a feature branch, by any chance? [06:56] rogpeppe: nope. I do know that it has to be blessed by CI first [06:56] other than that, no [06:56] axw: it has (finally!) been blessed [06:56] rogpeppe: nfi [06:56] axw: and i wanna get it merged quickly before it gets loads more conflicts and consequent CI cursing [06:58] rogpeppe: simplest way would be to create a new branch and rebase it onto master, then propose [06:58] axw: i'm not sure that it should be rebased [06:58] rogpeppe: well maybe not "simplest"... but easiest :) [06:58] axw: but in this case, perhaps it should [06:58] axw: 'cos it's only one commit anyway [06:59] axw: ok, i'll give that a go [06:59] rogpeppe: quick, while master's still unblocked :) [06:59] * rogpeppe types like lightning [06:59] it's been a nightmare week for getting stuff merged [07:00] axw: yeah [07:00] axw: my last branch failed because of this error: [07:00] ... value *errors.Err = &errors.Err{message:"", cause:(*net.OpError)(0xc2103e3640), previous:(*errors.Err)(0xc21028a050), file:"github.com/juju/juju/state/open.go", line:114} ("cannot create index: local error: bad record MAC") [07:01] axw: do we know what causes that sporadic failure? [07:01] that old chestnut [07:01] I think it's a mongo WONTFIX [07:01] axw: marvellous [07:01] fixed in 3.0 IIRC [07:01] or maybe 2.6 [07:01] well, let's just change mongo versions! :) [07:01] rogpeppe: perrito666 is working on that, making good progress [07:02] axw: moving to 3.0 ? [07:02] rogpeppe: yup [07:02] \o/ [07:02] there's some fun migration steps required, that's the main issue [07:02] you have to go 2.4 -> 2.6 -> 3.0 [07:03] yay! another day, another bunch of conflicts. [07:03] axw: really? the db format has changed? [07:04] rogpeppe: I don't know why it's necessary [07:04] axw: so any old juju installation needs to go through that upgrade path. that's awkward. [07:05] rogpeppe: yes, but perrito666 is working on making it all automated [07:06] axw: yeah, still awkward and probably error-prone and slow though :) [07:13] axw: any chance of a quick LGTM on this branch please (now officially blessed :]) https://github.com/juju/juju/pull/3275 [07:14] rogpeppe: looking [07:14] axw: ta [07:16] rogpeppe: LGTM [07:16] axw: ta! [07:17] * rogpeppe hits the $$merge$$ button after more than two weeks... [07:19] axw: really hoping that your in-merge-progress branch won't conflict :) [07:20] rogpeppe: mine's to 1.25 [07:20] axw: phew [09:00] dooferlad: frobware: omw to standup - just wrestling firefox [09:02] fwereade, coming to standup? [09:02] frobware, oops, ty [09:18] fwereade: when you have some time could you check the transaction in this updated PR: http://reviews.vapour.ws/r/2593/ [09:18] I *think* it's complete :-) [09:54] fwereade: you around? [09:54] natefinch, yeah, what can I do for you? [09:56] fwereade: I'm trying to set up a watcher that'll notify me whenever anything is added to a collection. Am I right in thinking we don't have a general purpose type/function for doing this yet? [09:56] natefinch, take a look at the action watcher, it's implemented in a couple of layers, I suspect one of them will solve at least half of it for you [09:58] natefinch, newIdPrefixWatcher? [09:58] fwereade: so, let me make sure I'm not going down the wrong path here. This is for the unit assignment worker... when a service is added, I store the unit assignment data as a document in this new collection. then with this watcher I'm building, the worker will get notified and do the assignment [09:59] natefinch, yeah, that sounds entirely sane to me [10:00] natefinch, and notifying only on add is also entirely sane, just make sure you clearly document what the strings it sends actually mean [10:01] fwereade: so, I'm not sure I can properly act on just the information in the ID.... I need the unit name and the placement directive for the unit. dumping that all into the id seems like too much [10:02] natefinch, yeah, definitely, I'd be inclined to just send out the unit ids [10:02] natefinch, then have the worker request the relevant info in bulk [10:04] natefinch, or, indeed, just send the list of units back up -- I doubt you'll have the opportunity to extract the actual assignment logic from state [10:04] fwereade: is the list of units useful? I wasn't even going to bother since I'd have to get the rest of the data from the collection anyway, I was just saying "hey, go run everything in the collection" [10:06] natefinch, I'll cop to it being a bit forward-looking -- you could just have a NotifyWatcher that triggers on any add, and an assign-everything api method [10:07] natefinch, but as it is I think we have way too much detailed assignment logic in state [10:07] natefinch, which responsibility could/should be extracted [10:08] natefinch, so, if anything, I'm thinking the ideal is (1) watcher sends unit list (2) worker requests corresponding assignments in bulk (3) worker requests application of corresponding assignments in bulk [10:12] fwereade: I can do that - it at least keeps the logic of where we get the assignments separate from the actual assignment logic. [10:12] natefinch, because (1) that opens a path towards putting some of the machine-selection/addition logic outside state, and thus towards *consolidating* the various implementations that have grown up around deployer, gui, et al; and (2) assuming we properly separate the "service" from the facade that exposes it, we ensure the assignment service is decoupled from the worker that implements it [10:13] natefinch, awesome [10:14] natefinch, (I mean "service" as in https://github.com/juju/juju/wiki/Managing-complexity ) [10:14] fwereade: btw, is it me, or is idPrefixWatcher a terrible name for that type? [10:14] natefinch, I think you're right [10:15] natefinch, I would not want you to think you should preserve horrible type names just because they happen to exist [10:15] fwereade: ha, no worries there [10:16] ;) [10:18] mattyw: you around? [10:18] natefinch, I am [10:19] natefinch, what can I do for you? [10:19] mattyw: document this better :) https://github.com/juju/juju/blame/master/state/watcher.go#L1488 [10:20] Bug #1499277 opened: api: Client.UploadTools does not use error code [10:20] natefinch, like this https://github.com/juju/juju/blame/master/state/watcher.go#L1474. or is that not good enough [10:21] mattyw: no... wtf is the key in dockey? [10:22] natefinch, I tak you're point - I'll tell you and then turn it into docs [10:23] mattyw: thanks :) [10:23] natefinch, the original watcher just took keys ..string that it would watch for changes. The changes I made was to allow you to do that across collections. so you need to associated each key with a collection. So having those in a struct seemed like the best approach [10:24] natefinch, I'm embarrassed, I thought I documented this much better, I certainly remember wiring something somewhere [10:26] mattyw: luckily easily fixable [10:26] natefinch, do you think that's sufficient documentation? [10:26] natefinch, (what I just typed) [10:27] mattyw: you still haven't explsained what the key is :) [10:27] fwereade: any chance of another review on http://reviews.vapour.ws/r/2685/ later? [10:28] axw, sure [10:28] thanks [10:28] natefinch, the key is actually the id of the document, now that you mention it, it's a terrible name [10:29] natefinch, I was keeping in line with the existing getTxnRevno function which calls that value key, but I probably should have renamed that as well [10:29] natefinch, https://github.com/juju/juju/blame/master/state/watcher.go#L1511 [10:29] mattyw: if it's just an id (which is a string, right?), why is it interface{}? [10:30] natefinch, that's a good question, probably a hangover from whatever was before [10:30] rogpeppe, ping? [10:31] mattyw: pong [10:31] rogpeppe, do you know why the key in this function is an interface{} https://github.com/juju/juju/blob/master/state/watcher.go#L1511 [10:31] mattyw: yes [10:31] mattyw: but i'm not telling you [10:31] rogpeppe, because it's only used to findId, but id will always be a string right? [10:32] rogpeppe, I'll let you win next time we play dominion [10:32] lol [10:33] trying to work out if you're really not going to tell us, or just typing... [10:34] mattyw: it's an interface 'cos theoretically you don't need to use strings [10:34] mattyw: although in practice we only use strings [10:37] rogpeppe, I thought mongo required it to be a string [10:37] rogpeppe, or stringable [10:37] mattyw: i don't think so [10:37] mattyw: it can be an int for example [10:37] * mattyw consults the mongodb he felt forced into buying last week [10:41] rogpeppe, natefinch huh, TIL [10:41] db.foobar.insert("_id": {"foobar":"foo"}) [10:41] { "_id" : { "foobar" : "foo" }, "bar" : "foo" } [10:42] natefinch, I'll improve the docs, is there anything else you need? [10:46] rogpeppe, I reckon getTxnTevno should take id interface{} rather than key [10:46] rogpeppe, natefinch I'm doing that now unless ther are objections [10:47] mattyw: it looks like the word "key" is used more than just there in that file [10:47] mattyw: e.g. newEntityWatcher, docKey, etc [10:47] mattyw: so it might be better to be consistent in the naming there [10:49] mattyw: it would probably be fine to change it all though, docKey -> docId etc [10:49] mattyw: (if you do, please do it as a separate PR) [11:51] did anyone try to bootstrap an env with 1.26 and then bootstrap it again (by mistake) with 1.24.6, reusing the .jenv file? bootstrap will continue and environment set up with 1.26 will get wiped out [11:56] urulama, that sounds nasty - can you open a bug? === psivaa is now known as psivaa-lunch [11:57] mattyw: i'll verify it first, then yes, will do ... [12:06] natefinch, http://reviews.vapour.ws/r/2748/ [12:17] Bug #1499332 opened: "no such host" when bootstrapping manual provider [12:20] Bug #1499332 changed: "no such host" when bootstrapping manual provider [12:26] Bug #1499332 opened: "no such host" when bootstrapping manual provider [12:47] Bug #1499338 opened: charm GET endpoint is not authenticated [12:50] Bug #1499338 changed: charm GET endpoint is not authenticated [12:56] Bug #1499338 opened: charm GET endpoint is not authenticated === psivaa-lunch is now known as psivaa [13:26] Bug #1499356 opened: all units have false hook errors after reboot

[13:32] Bug #1499356 changed: all units have false hook errors after reboot

[13:41] * fwereade collecting laura, bbiab [13:44] Bug #1499356 opened: all units have false hook errors after reboot

[14:08] cherylj: 1.24 is unblocked, you can merge if you were waiting [14:09] sinzui: thanks! [14:36] Bug #1499400 opened: number of disks constraint for maas provider [14:48] Bug #1499400 changed: number of disks constraint for maas provider [14:57] Bug #1499400 opened: number of disks constraint for maas provider [15:06] bootstrapping on ec2 with 1.25 I just got "WARNING expected one instance, got 2." Is this a warning I can/should ignore? [15:22] dooferlad, voidspace: more spaces related issues https://bugs.launchpad.net/juju-core/+bug/1499426 [15:22] Bug #1499426: deploying a service to a space which has no subnets causes the agent to panic

[15:25] frobware: I've tracked down the cause of the bug dooferlad reported [15:25] https://bugs.launchpad.net/juju-core/+bug/1498982 [15:25] Bug #1498982: failed configuring a static IP for container "1/lxc/0": cannot allocate addresses: instId not supported

[15:26] frobware: fixing the new bug you reported should be easy enough [15:26] frobware: but it should be fairly high priority [15:27] voidspace, I think I set it as high - no? [15:27] frobware: yeah [15:27] frobware: I'm also playing with bootstrapping to ec2 - and I'm seeing the "WARNING: expected one instance, got 2" [15:27] frobware: it's probably / possibly because we're both using the account [15:28] voidspace, ahh [15:28] frobware: bootstrapping seems to be successful anyway [15:29] dooferlad: interestingly, deploying a container to ec2 with addressable containers switched on seems to work for me! [15:30] voidspace: what address does it get? [15:30] voidspace, dooferlad: so who wants to pick up which bug? voidspace does it make sense for you to continue with 1498982 [15:30] voidspace: does it manage to assign a static IP? [15:30] dooferlad: it got a 10.0 address, which is correct I think [15:30] voidspace: 10.0.3.* is wrong. [15:31] dooferlad: ah, right [15:31] voidspace: those are from the LXC bridge [15:31] dooferlad: nothing at all in the logs [15:31] dooferlad: I'm confirming the flag is set properly and rebootstrapping [15:31] with a better log level [15:31] frobware: I've assigned 1498982 to myself [15:31] frobware: I think that's a critical regression [15:32] voidspace: all-machines.log doesn't have "failed configuring a static IP for container "0/lxc/0": cannot allocate addresses: instId not supported" in it? [15:32] frobware: I still need my unit address bug completed too though [15:32] voidspace, thanks; yep agreed. the other one I just raised may not happen if I remember to add some subnets to my space [15:32] frobware: we really should have that fixed in 1.25 final though [15:32] frobware: panics are bad!! [15:32] dooferlad: I've blown away the environment and am trying again [15:33] voidspace, yep agreed to unit address bug. which is why I was asking ... [15:33] frobware: just waiting on a review from fwereade [15:33] frobware: so working on the one dooferlad reported in the meantime [15:33] frobware: dooferlad: I know the cause of the bug - just not sure of the best fix [15:34] frobware: dooferlad: implementing ec2 support for instance Id filtering of subnets may be the path of least resistance [15:34] voidspace, frobware: only just started looking; think I'll take you up on that "focus on the txn" thing [15:34] going to look at how the code used to look first [15:34] fwereade: sure, I realise you're a slightly busy man! [15:34] fwereade: I would get dimiter to look at it if he was here [15:35] fwereade: the substantial change is the transaction is completely different - and it's now done on address setting not on preferred address fetching [15:35] fwereade: the rest of the changes are just logical consequences of those changes [15:35] but it still amounts to effectively a complete rewrite of the original PR :-) [15:37] fwereade: the race condition tests fail if you comment out the assert - which makes me believe they are both good tests and that the assert works... [15:38] of course I may well be deluded on both counts... [15:41] voidspace, no, I think it's good [15:41] voidspace, reviewed the state changes, just one naming quibble [15:41] fwereade: thanks, looking [15:42] Bug #1499426 opened: deploying a service to a space which has no subnets causes the agent to panic

[15:42] fwereade: hah, that did occur to me [15:42] fwereade: but I thought getSetPreferredAddressOps was just silly... [15:42] setPreferredAddressOps it is [15:43] voidspace, I think of Ops as being conventional [15:43] cool, thanks [15:44] jw4: you around? [15:46] fwereade: btw, that idPrefixWatcher is surprisingly action-specific: https://github.com/juju/juju/blob/master/state/watcher.go#L2173 [15:47] natefinch: yeah, but otp [15:47] jw4: no worries... lunch just arrived, back in a bit [15:48] natefinch: I believe the idPrefixWatcher is a 'base' type that the action specific code uses? [15:58] if you bootstrap a dev version of juju the toolsversionchecker spams your log with errors [16:04] natefinch, ha, I'd missed that bit [16:04] natefinch, at first glance it looks as though it could be parameterised? [16:07] dooferlad: ok, the error I see (at INFO level!) is the same one you do "machine-0: 2015-09-24 15:56:55 INFO juju.provisioner lxc-broker.go:114 not allocating static IP for container "0/lxc/0": cannot allocate addresses: no interfaces available" [16:07] this is on master [16:07] latest master I think [16:07] so the error you reported as coming from an earlier revision [16:08] dooferlad: I'm going to switch to getting the unit address stuff merged and ported [16:08] dooferlad: then I'll come back to this [16:09] natefinch, fwereade: crap, it's in mergeIds too [16:09] I wonder if that conversion could happen later, when consuming those id's instead [16:10] although... actionNotificationId just passes the original back in harmlessly if the id isn't an actionId [16:11] maybe the name of the function just needs to change to make it less confusing [16:12] I'd be happy to make a quick PR if that seems like an acceptable approach [16:16] cherylj, ping [16:18] wwitzel3, ping [16:19] jw4, fwereade: it definitely looks like it could be pretty easily converted to be more generic. [16:19] jw4: don't change the name... I'm going to change the name and see if I can make those conversions injected rather than hard coded. [16:19] alexisb: what's up [16:19] heya cherylj critical bug on 1.24 came up in the interlock call [16:19] do you have a time to have a look? [16:20] alexisb: sure, what's the bug #? [16:20] https://bugs.launchpad.net/juju-core/+bug/1499356 [16:20] Bug #1499356: all units have false hook errors after reboot

[16:22] voidspace: Just stopping for the day, sorry for missing your message 10 mins ago. I was running from the 1.5 branch with the bug I reported if that helps. [16:24] biab, gonna run home from the office. [16:24] bbiab that is === meetingology` is now known as meetingology [16:24] natefinch: I have (what I think is) a better idea... I'll change the filterFn in the idPrefixWatcher to return a modified if necessary id when running the filter [16:24] that way we can inject the action specific modifier in the action specific constructor call [16:24] jw4: ok, that's cool [16:25] kk.. I'll make a quick PR and you can decide if you like it :) [16:25] jw4: cool :) [16:25] back in like 45 mins. [17:51] bbl [18:45] jw4: btw I think I have most of the changes needed to rework the idprefixwatcher into a generic collection watcher [18:46] natefinch: okay - I'll push up my changes anyway and you can pick and choose at least. I think the actions stuff is more tightly coupled than I thought at first [18:47] just running the final tests [18:47] (and setting up reviewboard again) [18:47] jw4: doesn't look too too bad if you just factor out the actionNotificationIdToActionId into a generic "id conversion" function that gets inserted... but I may have missed something [18:48] natefinch: that's essentially what I'm doing [18:48] I just did a bit of refactoring and cleanup there too for the tests, etc. [18:50] cool [18:54] natefinch: http://reviews.vapour.ws/r/2749/ do with it as you wish [19:09] Bug #1499499 opened: juju-deployer reports that config specifies num units for subordinate when it doesn't

[19:09] Bug #1499501 opened: com_juju_juju_testing.InitCommand / nil pointer dereference

[19:12] Bug #1499499 changed: juju-deployer reports that config specifies num units for subordinate when it doesn't

[19:12] Bug #1499501 changed: com_juju_juju_testing.InitCommand / nil pointer dereference

[19:17] jw4: I know dave had said the var _ foo = thingies should be in tests... but, why? [19:24] Bug #1499499 opened: juju-deployer reports that config specifies num units for subordinate when it doesn't

[19:24] Bug #1499501 opened: com_juju_juju_testing.InitCommand / nil pointer dereference

[20:39] Bug #1499499 changed: juju-deployer reports that config specifies num units for subordinate when it doesn't

[20:40] natefinch: I forget the exact rationale, but I remember that being raised as an issue before. I guess we don't want the interface type assertions in production code. [20:43] Bug #1499499 opened: juju-deployer reports that config specifies num units for subordinate when it doesn't

[20:46] Bug #1499499 changed: juju-deployer reports that config specifies num units for subordinate when it doesn't

[21:10] Bug #1347322 changed: juju ssh results in a panic: runtime error