[00:05] exit eod [00:10] anyone savvy on FacadeCall? [00:12] anyone know how to extract files from a .deb without installing it? [00:12] dpkg -x [00:13] thumper: ^ [00:13] perrito666: ta [00:13] np === liam_ is now known as Guest50977 [00:37] colour me confused... [00:37] menn0: you have done lots of upgrades recently [00:38] I have bootstrapped a 1.18.4 local environment [00:38] /usr/bin/juju is 1.20.11 [00:38] but if I go `/usr/bin/juju upgrade-juju` it says: no upgrades available [00:38] WTF? [00:38] thumper: colour? have you just tried to use irc colors? [00:39] thumper: specifying --version does not help either? [00:39] do I need to go --upload? [00:39] thumper: to be honest i've never tried upgrading to the official releases [00:39] menn0: how do you do it? [00:40] thumper: with --upload-toools [00:40] tools even [00:40] hmm... [00:40] ok [00:40] but i'm pretty sure what you've just tried is supposed to work [00:40] could be a bug [00:41] ok that upgraded [00:42] ok, confirmed that 1.18 local provider upgrading to 1.20.11 breaks juju-run as expected [00:42] not to fix it [00:42] I did just want to confirm that it was doing what I thought it was doing [00:43] thumper: it might be a local provider thing [00:44] thumper: according to the upgrade-juju help output the tools selection behaviour is somewhat provider dependent (e.g. for maas you need to install the tools yourself) [00:44] ah [00:47] SHIT [00:48] why does params.ProvisioningInfo.Jobs take a []state.MachineJob [00:48] ie, and int [00:48] can I change it ? [00:50] thumper: can you have another look at http://reviews.vapour.ws/r/489/ pls? [00:51] thumper: i've created issues for the 2 bits i'd like you to look at [00:51] kk [00:51] thumper: the handling of panics in that defer wasn't quite right IMO. it was swallowing the panic when it should re-panic after cleaning up. [00:52] menn0: to be honest, we don't have any other panic handling like that [00:52] menn0: probably worth asking davecheney if it is worth it [00:53] thumper: the reason it's there is because I did have a panic happening during tests but that was hidden because the state wasn't being closed so instead i got the "dirty sockets" errors [00:53] ah [00:53] davecheney: can you have a look at one of the issues i've marked for http://reviews.vapour.ws/r/489/ [00:54] davecheney: the recover, close, re-panic bit [00:54] davecheney: am i being silly? [00:55] ywah, don't do that [00:55] it'll end up looking like gocheck [00:55] the way it eats the panic [01:05] * thumper wants to stab the person that added the second of "StateServerInfo" and "StateServingInfo" [01:06] thumper: i know [01:06] i think that was me [01:06] i want to get rid of both of them [01:08] davecheney: so what would you recommend? state needs to get closed if something goes wrong [01:08] i have several responses [01:09] none you'll like [01:09] so i'll not suggest them === kadams54-away is now known as kadams54 [01:11] ok, so I've been attempting to run an apiclient call from inside the debughooks cmd, specifically a call to Resolved(), exposed by using a --retry flag on the debug-hooks command. [01:13] is there a way to issue the call from the debughooks session? would it make sense to extend the runserver (juju-run) to accept a resolved retry command? [01:15] because internal to the debughooks / SSH cmd stuff, it does a c.Wait and that makes issuing the client.Resolved call a bit tricky, I can use go routines and select, but then control is returned instead of Waiting since the execution is happening in the go routine. [01:16] axw: standup? [01:17] wallyworld_: can you send me hte link? calendar decided it needed to upgrade [01:17] menn0: can you just let the panic happen ? [01:17] axw: https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand [01:17] * axw taps fingers in google's direction [01:17] ta [01:17] state will be closed anyway when the process dies [01:22] davecheney: I guess so. the reason that panics are being handled was because not closing state there was hiding the real cause of a failure in the tests while I was working on this change [01:22] davecheney: our test cleanup stuff checks if any mgo connections are still open and reports that if they are [01:22] davecheney: and hides the original panic in the process [01:24] davecheney: i might just remove that [01:24] davecheney: regarding your comment about err needing to be passed into the defer func [01:25] davecheney: that doesn't quite work because if err is set after the defer line the defer func doesn't see the error [01:25] davecheney: or perhaps I'm missing something [01:27] davecheney: for example: http://play.golang.org/p/1zKj4v9pQP [01:28] davecheney: but what I want is: http://play.golang.org/p/b-zvXikd-Y [01:30] davecheney: or do you actually want: http://play.golang.org/p/wP2pfIGd4c ? [01:35] ah fuck fuck fuckity fuck [01:35] * thumper glares at the code [01:48] menn0: declare err in the scope of the function by making it a named return value [01:49] menn0: http://play.golang.org/p/NXg0tPrqHq === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [01:58] axw: thanks again for the suggestion; that was really insightful. "time is an external resource". axw: the philosopher engineer. [02:00] axw: http://foomandoonian.files.wordpress.com/2011/11/philosoraptor-time-freeze.png?w=500 [02:00] menn0: sanity check plz? http://paste.ubuntu.com/9083907/ [02:01] menn0: and now for the 'orrible unit tests... [02:01] wallyworld_: see paste above for juju-run fix (in 1.20 branch) [02:03] katco: lol :) [02:03] no worries [02:03] katco: sorry if I lead you astray back in Boston [02:04] axw: oh no not at all. i actually meant that i remembered us addressing this same kind of problem -- you helped [02:04] (again) [02:04] so thank you :) [02:05] cool. I'm wondering whether we should define a time interface somewhere, with an implementation based on the standard time package [02:05] axw: i really don't know. i feel like i need to immerse myself more in that test to form an opinion. but i still don't feel right masking perfectly fine go std libs [02:05] (at the moment) [02:07] katco: yup, fair enough, I struggle with that a bit [02:07] (hence the regular flip flopping) [02:07] hehe [02:07] ah stabby stabby [02:08] (╯°□°)╯︵ ┻━┻ [02:08] * thumper goes to clean the kitchen for a few minutes [02:08] haha [02:08] i'm so glad i met thumper... i can picture this so much better [02:09] katco: if you knew the half of it.... [02:09] * katco laughs [02:12] davecheney: that's very tricky :) === kadams54 is now known as kadams54-away [02:30] oh ffs [02:31] I think I have hit another typed nil bullshit error [02:32] davecheney: help [02:38] waigani: it's not my pattern, william and frank came up with that one [02:38] i'm +/- on it [02:38] i think it's too clever for it's own good most of the time [02:39] * davecheney reaches for curmudgeon hat [02:41] fuckity fuck fuck [02:42] davecheney: http://paste.ubuntu.com/9084574/ line 123 [02:42] [LOG] 0:01.337 INFO juju.upgrade err: , apiErr: *params.Error [02:42] [LOG] 0:01.337 INFO juju.upgrade true [02:43] oh... now I know why the expression was there before... [02:43] stabby [02:44] typed nil strikes again [02:44] god that's horrible [02:44] had to replace the test wth: if err != nil || errResults[0].Error != nil { [02:44] which is what it had before, but I thought I was being clever [02:45] too clever apparently [02:46] damn [02:46] * thumper heads to physio again [02:46] typed nils are bad [02:46] there is only one use of them in the std lib [02:46] in the guts of the net package [02:47] and it's only because not doing it that way would be much worse [02:47] davecheney: right. so the sample you sent me is almost identical the last one I sent you. [02:48] davecheney: is there any technical reason why that's better than http://play.golang.org/p/b-zvXikd-Y ? [02:48] davecheney: i.e. is it just a style thing [02:49] menn0: i guess so [02:49] i don't think this cleverness pays off in general [02:49] i use named return arguments as a clue that the method is doing something clever [02:50] if it's not actualloy doing something clever, then I recommend they are removed [02:50] davecheney: ok. i just wanted to understand if i'm missing some technical aspect. [02:50] davecheney: named return values are a little annoying in this case because there's 2 other return values and if you want to name one of them you have to name all of them. [02:51] davecheney: it uglies up the function a bit [02:51] menn0: use _ [02:51] it should be ugly [02:51] it's a sign that it's complicated [02:51] davecheney: kk you win. I will change it :) [02:51] davecheney: i've already removed the panic handling btw [02:52] cool [02:58] thumper: looking [03:02] thumper: i think line 90 is wrong [03:03] thumper: i think line 90 is wrong [03:03] if stateInfo.SystemIdentity != "" { [03:03] should be == === kadams54-away is now known as kadams54 [03:20] thumper: menn0 today i'm workgin on teasing apart the uses of MachineJobs [03:20] and trying to unpick state.MachineJob.ToParams [03:20] i think that method on that type needs to move somewhere else [03:27] davecheney: sounds good [03:28] it wont' be done today [03:32] waigani: the NewEnvironment tests have landed now so it's a bit easier to set up alternative environments with stuff in them for testing with [03:36] thumper: forgot to say, i looked at your change ages ago but forgot to say that it looks ok [03:36] menn0: whoop whoop [03:37] * LinStatSDR giggles === kadams54 is now known as kadams54-away [03:38] thumper: one thing: did you check whether the "systemidentity" is empty or missing? [03:39] thumper: the assert obviously needs to match whatever happened when that change was made [03:41] thumper: just saw another thing: in the "if stateInfo.SystemIdentity != "" {" shouldn't that be "==" not "!=" ? [03:56] menn0: that's what i said too :-) [03:57] wallyworld_: good :) [04:15] thumper: I have a simple "canary" environment being set up from ConnSuite.SetupTest [04:15] thumper: breaks everything :) [04:16] thumper: which is expected and useful [04:17] thumper: most of the setups for suites in state die because things get confused when trying to create units when there's data for another environment present [04:42] menn0: why do they get confused making units? [04:42] thumper: still figuring it out but one of the asserts is getting tripped up by the data for the canary env [04:43] hmm... [04:43] ok [04:53] thumper: it's the insert into the meterStatus collection [04:53] here's the txn op ids and asserts: [04:53] C:units Id:d48e84dd-0e78-4e05-87ad-8a0a5acf99e8:mysql/0 Assert:d- [04:53] C:statuses Id:d48e84dd-0e78-4e05-87ad-8a0a5acf99e8:u#mysql/0 Assert:d- [04:53] C:meterStatus Id:u#mysql/0 Assert:d- [04:53] C:services Id:d48e84dd-0e78-4e05-87ad-8a0a5acf99e8:mysql Assert:[{Name:life Value:alive}] [04:53] C:constraints Id:d48e84dd-0e78-4e05-87ad-8a0a5acf99e8:u#mysql/0 Assert:d- [04:54] thumper: the canary env also has a mysql/0 so they're colliding [04:54] thumper: not sure if that collection is supposed to have been done yet [04:54] menn0: the meterStatus collection doesn't need it, but it's asserts propably need checking [04:55] thumper: what do you mean it doesn't need "it" [04:55] menn0: the collection's _id field is a uuid already [04:55] * thumper thinks [04:55] I think they are storing the envuuid already [04:55] thumper: doesn't look like that works been done properly [04:56] but the asserts that it uses to check docs probaly need checking [04:56] there's more problems [04:56] see state/meterstatus.go:70 [04:57] thumper: i don't see anything in meterstatus.go that indicates it's using env uuid prefixes [04:57] no, it isn't using env uuid prefixes [04:57] but I was told it didn't need it... [04:58] menn0: can you fix it? [04:58] thumper: sure, I was about to suggest that [04:58] thumper: who told you it wouldn't need it? it might be good to find out why someone thought that in case we're missing something. [04:58] menn0: me [04:58] when I was looking through things [04:59] I have been known to be wrong before :-) [04:59] thumper: really? :-p [05:01] updating the doc and LK then I'm EOD [05:09] fuck fuck fuck fuck [05:09] fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck [05:10] * thumper head desks [05:10] sooooo how's it going? [05:10] pretty sure my upgrade step is writing the new system identity to disk [05:10] and then the machine agent deletes it [05:11] this is horrible [05:17] * axw joins in the head desking [05:17] single collection transactions makes me :( [05:18] * thumper is doing a single collection transaction for the assertion [05:19] * axw is referring to his own problems [05:20] how do we refer to a work in progress in github? [05:20] some people have been putting WIP: in the title [05:21] wallyworld_: https://github.com/juju/juju/pull/1185 for the fix, missing real tests [05:21] wallyworld_: and this is just the 1.20 branch [05:21] looking [05:21] wallyworld_: although the upgrade step will be almost identical for 1.21 [05:21] wallyworld_: there is a race in 1.20 as all the workers start at once [05:22] oh joy [05:22] wallyworld_: so one worker is deleting the system identity that the upgrade step writes [05:22] so I've commented that bit out for 1.20.12 [05:22] it'll be fine [05:22] we can make sure it is still there for 1.21 as the race isn't there [05:22] due to the upgrade synchronisation stuff menn0 did [05:22] but tests will have to wait until tomorrow [05:22] I have tested manually [05:23] going from 1.18.4 -> 1.20.11 -> 1.20.12 [05:23] and juju run works again after failing in the middle [05:23] should also test 1.18.4 -> 1.20.12 [05:23] but not done that yet [05:23] * thumper is done for the day, [05:23] dinner is calling [05:23] and so is the wine [05:24] later folks [06:09] wallyworld_: you're frozen in hangouts [06:14] urulama: up early? [06:30] davecheney: I can't reproduce bug 1394066 on master... are you seeing it consistently [06:30] Bug #1394066: FAIL: action_test.go:254: ActionSuite.TestActionsWatcherEmitsInitialChanges [08:15] jamespage: are you ok for a chat in about an hour's time about charm status changes? [08:54] jam: fwereade_: i had scheduled a juju status meeting to talk with jamespage from a charmer's perspective, but looks like he's not around [08:54] wallyworld_, bother [08:54] fwereade_: you were also not around yesterday for our 1:1 :-) [08:55] i'll try and reschedule [08:55] wallyworld_, sorry, yes, I was up stupidly late and then slept much of the day :( [08:55] np :-) [08:55] fwereade_: jam: was there anything major in the email I sent that was off the mark? if not, i'll update the doc [08:56] wallyworld_: it all looked pretty good to me [08:57] ok, ta will run with that [08:58] fwereade_: it would be great if you could add your 1 penny's worth to the juju-dev thread talking about goal state, unit count, quorums etc [09:00] wallyworld_, bother, one thing I never mentioned, I'm not sure about the agent setting allocating/installing/error in *unit* state? [09:00] wallyworld_, aren't those still agent states? [09:01] fwereade_: I believe they are both, because the unit agent can't set allocating/installing [09:01] fwereade_: i had thought allocating can be considered unit state, but i can also see it does relate to the agent [09:02] i'd like to keep as both [09:02] wallyworld_, auto-setting busy/running if set-status hasn't been used is fine [09:02] that way people can mosylu look just at unit state and get all they need [09:03] wallyworld_, allocating in unit state is fine, I think, because no overlaps [09:03] wallyworld_, in responsibility [09:03] yeah [09:03] wallyworld_, installing feels like a different way of spelling busy that only happens sometimes [09:04] wallyworld_, and I think that error is a can of worms [09:04] wallyworld_, because (1) it's usually a filthy lie [09:04] error on unit state means the hook failed [09:04] wallyworld_, right [09:04] error on agent state means something fucked up in the agent [09:04] wallyworld_, that's not what it means at the moment [09:05] true, but that's what we can make it mean, i think without upsetting people? [09:05] i was hoping to ask james etc [09:05] wallyworld_, that throws away any ability to convey the difference between management failures and software failures [09:06] wallyworld_, a failing hook does not automatically imply non-functioning software [09:06] wallyworld_, in fact it's pretty rare that a hook failure will have *anything* to do with what the software is up to [09:06] depends doesn't it? [09:06] if install hook fails, itsn't it likely the software won't run? [09:07] wallyworld_, won't unit-state already be "busy" then? [09:07] wallyworld_, it's not *meant* to be running after the install hok [09:07] it will be installing [09:07] unless the charm sets it to busy [09:07] unit agent sets unit state to installing just prior to running install hook [09:08] wallyworld_, do you not think that having overlap in values for unit-state and agent-state, that don't even mean the same thing, is asking for trouble? [09:08] it's not meant to be running after install hook, true, but my point is, if install hook fails, then it likely won't ever run [09:08] wallyworld_, right [09:09] wallyworld_, however we spell it, the unit state should *already* reflect that it's not running [09:09] i'm not sure overlap in values is bad or not, i'd like another opinion [09:09] wallyworld_, the thing that's actually *wrong* is that the agent has stopped reacting to changes [09:09] wallyworld_, that is the only thing we know [09:10] sorry, what's the context of "the only thing that is actuall wrong"? [09:11] wallyworld_, in the absence of specific information from status-set, we don't know about the state of hte software [09:11] true [09:11] wallyworld_, what we do know, given an error state, is that the agent has become upset by something the charm did and wants a human to help it out [09:11] the agent guesses though if the unit doesn;t tell it othereise [09:11] * fwereade_ gets to use the zen of python again :) [09:12] wallyworld_, in the face of ambiguity, resist the temptation to guess [09:12] we do now [09:12] if started hook runs, then assume software is functional [09:12] wallyworld_, no argument there, but are you suggesting that's a *good* thing? [09:12] and for old charms, we need to maintain that assumption [09:12] no [09:12] just that we need to continue to do it if the charm doesn't tell us [09:13] wallyworld_, how do old charms come into this? we won't set "running" because we won't progress past the start hook [09:13] morning [09:13] wallyworld_, so, surely, orthogonal? [09:13] we set running for old charms if they don't use status-set during start hook [09:14] wallyworld_, I would add "and the start hook doesn't error"? [09:14] yes, of course :-) [09:14] wallyworld_, so... I still think this is orthogonal to discussions about whether we overwrite unit-state? [09:15] wallyworld_, oh hell [09:15] maybe we take this to a hangout? [09:15] wallyworld_, use of status-set will really not play nicely with charm upgrades, will it [09:15] wallyworld_, yeah, let me grab another coffee, with you in a mo [09:15] morning everyone [09:15] ok [09:16] * wallyworld_ gets a wine [09:16] * TheMue would like to join, but 10am is a bit early :D [09:16] * fwereade_ has a mildly jealous [09:17] well it's after 19:00 here :-) [09:18] fwereade_: https://plus.google.com/hangouts/_/canonical.com/juju-status [09:18] * TheMue will compensate his abstinence now with a fine single malt this evening [10:01] TheMue: dimitern: voidspace: I'll be there in about 2 min [10:01] voidspace, standup? [10:01] dimitern: om2w [10:01] *omw [10:08] morning [10:32] perrito666: morning [10:35] jam: dimitern: yep, if we use ec2.EC2.NetworkInterfaces then the new IP address shows up [10:36] jam: dimitern: so I'll go mark that bug against goamz as invalid [10:37] voidspace, but how about the Instances() output? does it have the IPs? [10:37] dimitern: no, it's Instances that doesn't [10:38] dimitern: you have to get the interface id and fetch it from that [10:39] voidspace, that will work, but I'd rather use the pre-existing Instances() if possible [10:40] dimitern: it is not in the ec2 response [10:40] dimitern: it's not a goamz issue [10:40] voidspace, I mean, if it's a goamz bug due to parsing the output [10:40] voidspace, how did you verify that? what aws api version? [10:40] dimitern: I'll double check, but it's not in the xml response dumped out with debug on [10:41] voidspace, because I think it's due to not using the vpc-aware version or DescribeInstances [10:41] dimitern: I'm using the default version used by goamz - would I need to change that? [10:41] dimitern: and the ec2.Instances call *is* a call to DescribeInstances I believe? [10:43] voidspace, because the ec2 response you're getting will match the response expected by the aws api client using the version specified in the request [10:43] voidspace, e.g. trying to run RunInstances specifying SubnetID and older (non-vpc-aware) version will return an error like "invalid field subnetid" [10:44] note that the Instances call is *definitely* a call to DescribeInstances - the response xml is a [10:44] just trying to see if I can see the request header for the version [10:45] no, it doesn't dump the requests - just the responses [10:45] dimitern: we have a vpcId in the response - so I doubt it's a non-vpc-aware version of the api [10:46] not definitive though [10:47] voidspace, hmm... then it is an ec2 api bug then [10:47] dimitern: looks like it [10:48] dimitern: shall I work on ReleaseAddress for ec2? [10:49] voidspace, yes, please [11:12] i've synced upstream and now build fails due to issues in backups primarily (altho there r others)... [11:12] anyone else seeing this behaviour?.. [11:24] anastasiamac: I cant say I havent [11:24] anastasiamac: could you pastebin the errors? [11:24] perrito666: thnx.. my bad - outdated utils ;-) [11:24] anastasiamac: lol [11:24] happens a lot to me [11:25] like once every pull :p [11:25] perrito666: :-) [12:11] dimitern: ping [12:11] dimitern: actually, you were correct [12:11] dimitern: goamz uses two different aws api versions - a "legacy version" for most things and a "vpc aware" version only for vpc related calls [12:12] ah, dammit [12:12] no -I'm still looking at DescribeNetworkInterfaces [12:12] voidspace, yes, that's why I was asking which one you use :) [12:12] let me check DescribeInstances [12:12] voidspace, I thought you're testing with the ec2 cli [12:12] dimitern: yes, confirmed [12:12] dimitern: nope [12:12] voidspace, right :) [12:12] dimitern: I did a bit - I still find goamz easier [12:13] dimitern: so DescribeInstances *does* show the private ip address when you use the vpc aware api version [12:13] dimitern: http://pastebin.ubuntu.com/9094670/ [12:13] dimitern: that last faragment [12:14] voidspace, sweet! [12:14] The privateIpAddressesSet [12:14] dimitern: well, except we have to work out how to get goamz to use the vpc version of the api for describe instances [12:14] dimitern: is it configurable that you know of? [12:14] voidspace, so we probably should use the vpc-aware version (which is not the very latest btw) for all goamz calls [12:14] voidspace, nope, not globally [12:15] voidspace, when I did those vpc changes to goamz I didn't want to switch *all* calls to use the new version, it seemed risky [12:15] dimitern: vpcAPIVersion = "2013-10-15" [12:15] dimitern: ah, you did those changes [12:15] voidspace, yeah [12:15] dimitern: so you're fairly familiar with the mechanism then... [12:16] voidspace, I was at least :) it's been a while [12:16] dimitern: do you want me to do anything about it right now? [12:16] dimitern: I guess we file the knowledge away for "shortly" when we need it [12:17] voidspace, I think we should file a bug against goamz for DescribeInstances to use the vpc-aware api version [12:20] dimitern: ok, I'll do that [12:21] voidspace, cheers [12:58] dimitern: https://bugs.launchpad.net/goamz/+bug/1394186 [12:58] Bug #1394186: vpc aware aws api should be used for DescribeInstances [12:58] voidspace, ta [12:59] voidspace, I'll pick that up and propose a fix for it later today [12:59] dimitern: cool, thanks [13:01] dimitern, wwitzel3 I've added you both as mods to /r/juju [13:07] ericsnow: you are not around by any chance are you? === kadams54 is now known as kadams54-away [13:07] mattyw, thank you [13:19] Hi marcoceppi, do you plan to release a new amulet to the PPA any time soon? We need some recent changes and getting them via the PPA is the easiest for our charms. [13:20] bac: I was going to do a release on Friday, need something sooner? [13:21] marcoceppi: friday is probably ok, but if you have time and are feeling charitable sooner is better. i'm happy either way. [13:31] bac: ack [14:43] fwereade_: ping? [14:56] natefinch: you need a font with broad unicode support [14:56] I had to install quivira font to see it [14:56] perrito666: ain't nobody got time for that [14:56] lol [14:56] well... except you, evidently :) [14:57] natefinch: installing a font takes a couple of secconds gnome-font-viewer yourfont [14:57] then click install [14:58]