| === kadams54 is now known as kadams54-away | ||
| axw | anastasiamac: sent you an email with a few links | 01:27 |
|---|---|---|
| anastasiamac | axw: thnx :-0 | 01:29 |
| anastasiamac | axw: in terms of appeal - both content and presentation - I think that katco's spec is the winner :-) | 01:46 |
| anastasiamac | axw: do u know what she used? | 01:47 |
| axw | anastasiamac: yeah. nope, sorry | 01:47 |
| axw | it's certainly more structured than others, which is good for a spec | 01:47 |
| anastasiamac | axw: and I can see that she has used cucmber for user stories (functional testing) | 01:47 |
| anastasiamac | axw: structure but also gr8 visuals | 01:48 |
| menn0 | waigani: doing this automatic env UUID filtering has exposed some things that were missed with the env UUID migrations | 03:00 |
| waigani | menn0: that's good | 03:00 |
| menn0 | waigani: i've just spent a bit of time tracking down why my branch won't land and it's because EnvUUID wasn't being set on minUnitsDoc | 03:00 |
| menn0 | waigani: of course my upcoming branch would fix that automatically but I want to get the query side of things landed first | 03:01 |
| waigani | menn0: do you want me to set EnvUUID on minUnitsDoc? | 03:02 |
| menn0 | waigani: it's ok,. i've just fixed the problem in my branch | 03:02 |
| menn0 | waigani: it would be good to know if the minUnits collection was migrated to use env UUIDs in 1.21 though or if that came after | 03:03 |
| menn0 | waigani: we might need to add an upgrade step in 1.22 that populates env UUID if it's missing | 03:03 |
| waigani | menn0: it was migrated in 1.21 | 03:04 |
| waigani | menn0: adding another catchall upgrade step for missing UUIDs sounds like a good idea | 03:05 |
| menn0 | waigani: definitely | 03:05 |
| menn0 | waigani: I wonder if the existing upgrade step can just be re-run for 1.22? | 03:05 |
| waigani | menn0: I'd have to take a close look when we come to actually doing it | 03:07 |
| waigani | menn0: btw the test for your hack to upgrade state 1.20->1.21 fails with my branch, as state tests now have two states/envs by default. My solution is to destroy the second env and close the second state for that test. | 03:07 |
| menn0 | waigani: which hack is that? | 03:08 |
| waigani | me | 03:09 |
| waigani | menn0: | 03:09 |
| waigani | // StateServerInfo contains a hack that assumes a single environment. This | 03:09 |
| waigani | // hack is executed when environmentDoc is missing the env-uuid field, as | 03:09 |
| waigani | // in the case below. As such, we destroy the other environment and close | 03:09 |
| waigani | // OtherState to emulate the expected single environment state. | 03:09 |
| waigani | menn0: test = TestStateServerInfoWithPreMigrationDoc | 03:09 |
| menn0 | waigani: right. i think what you've done is probably ok. | 03:10 |
| waigani | menn0: it makes that test more ugly, but I think it is better to keep that test the exception and the default to be for two envs to be set up for state tests | 03:12 |
| waigani | as this is the new world that the code needs to work in | 03:13 |
| * menn0 nods | 03:13 | |
| axw | davecheney: I'm going to move state/storage.go to a new package, state/storage, and state/tools.go -> state/storage/tools | 03:48 |
| axw | davecheney: state/toolstorage -> state/storage/tools too | 03:49 |
| axw | (just letting you know because you've been moving bits around in that area) | 03:49 |
| menn0 | waigani: the branch that automatically adds env UUID when querying is in | 04:10 |
| menn0 | waigani: http://reviews.vapour.ws/r/594/diff/ removes many of the docID calls that are now unnecessary | 04:10 |
| menn0 | waigani: can you PTAL? | 04:11 |
| waigani | menn0: just gave it a shipit | 04:12 |
| menn0 | waigani: cheers | 04:13 |
| davecheney | axw: -1 to two new packages | 04:14 |
| davecheney | +0 to state/storage | 04:14 |
| davecheney | as long as state/storage doesn't import state, i'm fine with this | 04:14 |
| davecheney | tools is a shitty pacakge name | 04:15 |
| davecheney | state/storage/storagetools if you must | 04:15 |
| axw | davecheney: state/storage is fine with me. it will not depend on state | 04:16 |
| axw | I'll leave the existing toolstorage one alone then. never was happy with the name, but storagetools sounds like tools for dealing with storage rather than a place to store tools | 04:17 |
| menn0 | davecheney or axw: would you mind quickly looking over http://reviews.vapour.ws/r/594/ ? | 04:19 |
| davecheney | menn0: LGTM | 04:23 |
| davecheney | thank god for tat | 04:23 |
| menn0 | davecheney: and there's a lot more of that kind of thing coming up | 04:24 |
| davecheney | nice | 04:24 |
| menn0 | damn... my last branch (already merged) broke upgrades | 04:44 |
| menn0 | reverting... | 04:45 |
| menn0 | waigani: hmmmm looks like there's no unit test for the pre-migration settings loading hack | 04:52 |
| === kadams54_ is now known as kadams54-away | ||
| menn0 | upgrade problem fixed without reverting. fix merging now. | 05:14 |
| mattyw | menn0, ping? | 05:54 |
| === urulama_ is now known as urulama | ||
| dimitern | jam1, 1:1? | 07:32 |
| jam1 | dimitern: yeah, brt | 07:32 |
| fwereade | jam1, it's a public holiday and I'm going out for breakfast but I should be back for our chat | 07:38 |
| jam1 | fwereade: enjoy | 07:38 |
| fwereade | anastasiamac, likewise, I should be free for ours later | 07:38 |
| menn0 | mattyw: hi. i've got to head out for a bit but i'll be back later on | 08:29 |
| mattyw | menn0, no problem, I'm in gmt+8 at the moment so we can just discuss it tomorrow | 08:30 |
| anastasiamac | fwereade: i'd rather talk tomorrow then :-) enjoy ur holiday! | 09:01 |
| voidspace | jam1: dimitern: standup? | 10:02 |
| dimitern | voidspace, omw | 10:02 |
| jam1 | voidspace: just a few, be there soon | 10:02 |
| === ashipika1 is now known as ashipika | ||
| === kadams54 is now known as kadams54-away | ||
| voidspace | dimitern: when you get a chance http://reviews.vapour.ws/r/596/ | 12:44 |
| dimitern | voidspace, sure, in a moment | 12:44 |
| voidspace | dimitern: I'm taking a break anyway, so no massive hurry | 12:45 |
| dimitern | voidspace, reviewed | 13:23 |
| voidspace | dimitern: thanks | 14:16 |
| dimitern | voidspace, please ping me if something is not clear | 14:17 |
| voidspace | dimitern: I think the major concerns you have are entirely unwarranted :-) | 14:18 |
| voidspace | dimitern: I will try to explain why | 14:19 |
| voidspace | dimitern: after I get coffee | 14:19 |
| dimitern | voidspace, :) ok, I'm listening | 14:19 |
| voidspace | dimitern: I don't think there is any race condition at all | 14:19 |
| voidspace | hmmmm... actually, *maybe* there is | 14:19 |
| voidspace | dimitern: however you're incorrect about state filtering of addresses | 14:20 |
| dimitern | voidspace, exactly - between the time you read the initial list of addresses and you try to add a new one | 14:20 |
| voidspace | dimitern: right | 14:20 |
| voidspace | dimitern: so we need to check the return value of AddIPAddress and retry on failure | 14:20 |
| dimitern | voidspace, that one I rephrased several times - I understand what allocated map is for (name could be better yes) | 14:20 |
| voidspace | dimitern: but TestPickNewAddressIgnoresUnavailableAndAllocated doesn't make sense | 14:20 |
| dimitern | voidspace, well with that test now it will pass when it shouldn't | 14:21 |
| voidspace | dimitern: no, more specifically | 14:21 |
| voidspace | dimitern: see my reply to your comment on line 254 subnets.go | 14:22 |
| voidspace | dimitern: and the for loop doesn't need a max tries - the algorithm guarantees it won't go on forever | 14:22 |
| voidspace | doorbell (and coffee) | 14:23 |
| dimitern | voidspace, yes - the map can be used to track all addresses, regardless of their state | 14:23 |
| dimitern | voidspace, so the allocated map will work fine, just the retrying needs to be in place and the two-step allocation | 14:24 |
| dimitern | voidspace, i.e. find an available address - create it as "unknown" if it still does not exist; if it does (regardless of state) - retry | 14:25 |
| voidspace | yep | 14:26 |
| dimitern | voidspace, sorry, now I realize PickNewAddress shouldn't mark the address as allocated | 14:26 |
| voidspace | dimitern: no, it creates it Unknown for the provider to allocate (or fail) | 14:26 |
| dimitern | voidspace, it should only add is as a placeholder ("Unknown") until tried to allocate it and either got OK (then set it to allocated) or error (set it to unavailable) | 14:27 |
| voidspace | indeed | 14:27 |
| dimitern | voidspace, yeah | 14:27 |
| voidspace | AddIPAddress does this for us anyway | 14:27 |
| sinzui | dimitern, voidspace perrito666 . Win builds broke. I think a win dep is missing: http://juju-ci.vapour.ws:8080/job/win-client-build-installer/1362/console | 14:28 |
| dimitern | voidspace, ok, but it will be helpful to have a comment about it - before AddIPAddress, ideally in the PickNewAddress doc comment as well (... creates an address with AddressStateUnknown..) | 14:28 |
| dimitern | sinzui, looking | 14:29 |
| dimitern | sinzui, it appears the regression occurred quite some time ago - commit https://github.com/juju/juju/commit/99c2bcd0de788321a73d1c32ed5c114dbe9adb89 - Sept, 30 | 14:33 |
| dimitern | sinzui, were the windows builds not tested in a while? | 14:33 |
| sinzui | We test EVERY run | 14:33 |
| sinzui | and that is why we knew the regression from last week was fixed | 14:34 |
| dimitern | sinzui, ok, I'll dig deeper then | 14:34 |
| sinzui | dimitern, http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/win-client-build-installer/1359/console is the last pass from Friday | 14:34 |
| sinzui | I am looking for the candidate revs | 14:34 |
| sinzui | dimitern, This is what we know about the windows failure https://bugs.launchpad.net/juju-core/+bug/1400344 | 14:48 |
| mup | Bug #1400344: Windows dependencies broken <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1400344> | 14:48 |
| dimitern | sinzui, I can't see how a missing dependency can cause this build failure and how it did pass before | 14:54 |
| sinzui | dimitern, okay. For each release tarball, we due a redundant setup for cross compilation on windows for386 and amd64. That is what you may have seen in the log. I think that kind of ensures no one tampered with our go setup between runs. The script then build 386 to make the win client, then builds amd64 to make the win agent | 14:56 |
| dimitern | sinzui, that sounds sensible to me | 14:57 |
| wwitzel3 | fwereade: ping | 14:58 |
| fwereade | wwitzel3, pong | 14:58 |
| wwitzel3 | fwereade: oops, just saw the calendar, you're on holiday I won't bother you :) | 14:59 |
| dimitern | sinzui, i'm still looking for the root cause though | 14:59 |
| bogdanteleaga | stat_t doesn't exist on windows | 14:59 |
| bogdanteleaga | if you're still on that | 14:59 |
| fwereade | wwitzel3, if it's quick it's fine | 15:00 |
| fwereade | wwitzel3, because then I can hit you up for a review of http://reviews.vapour.ws/r/598/ which is directly relevant to your interests | 15:00 |
| fwereade | wwitzel3, ;p | 15:01 |
| wwitzel3 | fwereade: I wanted to chat about min version, probably not likely to be quick | 15:01 |
| wwitzel3 | fwereade: I will take a look | 15:01 |
| fwereade | wwitzel3, ok, natefinch is hopefully circulating it among users for great clarity and sanity | 15:01 |
| dimitern | sinzui, this is the commit that introduced the regression I think - https://github.com/juju/juju/commit/99c2bcd0de788321a73d1c32ed5c114dbe9adb89 (3 days ago) | 15:05 |
| dimitern | katco, ping | 15:05 |
| natefinch | ericsnow: sorry to hear you didn't get the job at Canonical | 15:05 |
| ericsnow | natefinch: lol me too! | 15:05 |
| katco | dimitern: howdy | 15:06 |
| sinzui | dimitern, That is very interesting because there is *another* regression that relates to metadata. I just reported https://bugs.launchpad.net/juju-core/+bug/1400350 | 15:06 |
| mup | Bug #1400350: metadata_test consistently fails in ppc64el unit tests <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1400350> | 15:06 |
| katco | ericsnow: natefinch lol i JUST got the same email | 15:06 |
| natefinch | katco: really? That's hilarious | 15:06 |
| ericsnow | katco: sorry to hear it! | 15:06 |
| wwitzel3 | fwereade: ok, thanks, there must be a doc I haven't seen yet, the doc I have for min version is basically blank :) | 15:06 |
| katco | natefinch: yep. apparently i've outstayed my welcome! (sniff) | 15:06 |
| ericsnow | katco: mine was from Good Luck Jonathan ;) | 15:07 |
| dimitern | katco, can you tell me more info about this commit - https://github.com/juju/juju/commit/99c2bcd0de788321a73d1c32ed5c114dbe9adb89 | 15:07 |
| ericsnow | katco: j/k | 15:07 |
| natefinch | ericsnow, wwitzel3, perrito666 : BRT | 15:07 |
| katco | ericsnow: haha | 15:07 |
| dimitern | katco, it appears it introduced a regression for windows builds | 15:07 |
| katco | dimitern: it looks like ericsnow authored this? | 15:07 |
| katco | dimitern: sorry, am i missing something? | 15:08 |
| dimitern | katco, hmm.. sorry I meant https://github.com/juju/juju/commit/0c7de1a60355b3dfa3b5db23b9b5551680eae76e | 15:08 |
| ericsnow | katco, dimitern: curse you syscall! | 15:08 |
| dimitern | katco, it seems like a backport of some sorty | 15:09 |
| katco | dimitern: ahhh ok | 15:09 |
| dimitern | sort* | 15:09 |
| dimitern | ericsnow, yay, windows :) | 15:09 |
| dimitern | katco, but that seems a merge into some feature branch, not master, 1.21 or 1.20 | 15:10 |
| katco | dimitern: yeah trying to make sense of this. definitely a merge, but into what? | 15:11 |
| natefinch | ericsnow, katco: https://www.youtube.com/watch?v=F4eCd6xUSik | 15:11 |
| dimitern | sinzui, that ppc failure it due to the same thing btw | 15:12 |
| dimitern | ericsnow, was that change necessary just to access the creation time of the backup? | 15:13 |
| sinzui | dimitern, I agree, and jog just noted that the recent failures in run-unit-tests-precise-i386 are about that test | 15:13 |
| katco | dimitern: ok, looks like that was me trying to land my leadership/lease branch. it wouldn't do an automatic merge so i merged locally. | 15:13 |
| dimitern | katco, on master though, or? | 15:14 |
| katco | dimitern: sinzui: do we have a test run from commit https://github.com/juju/juju/commit/216aa121c173b625f6417f3ac3ca8f960c862a38? | 15:14 |
| katco | dimitern: yes on master | 15:14 |
| dimitern | katco, right, thanks for confirming | 15:14 |
| katco | dimitern: is this a regression on master, or 1.21, or? | 15:15 |
| katco | nothing in my branch should have caused a regression unless i merged incorrectly | 15:15 |
| sinzui | katco, I don't think that was the merged rev | 15:15 |
| katco | sinzui: sorry, can you rephrase that? | 15:16 |
| dimitern | katco, it appears it affects only master | 15:16 |
| katco | dimitern: oh, well at least that's good news | 15:17 |
| sinzui | katco, that rev isn't listed because git merged it as a different commit hash. | 15:17 |
| wwitzel3 | fwereade: I went through that code 3 times and I am disappointed to say I couldn't find anything wrong :p | 15:17 |
| dimitern | katco, what you merged actually came from an earlier commit by ericsnow - https://github.com/juju/juju/commit/99c2bcd0de788321a73d1c32ed5c114dbe9adb89 | 15:17 |
| ericsnow | dimitern: yep, that's the one | 15:18 |
| katco | dimitern: right... so... is it my code, or what i merged? | 15:18 |
| * katco is a little slow pre-coffee o.0 | 15:18 | |
| dimitern | ericsnow, and there's a related test - https://github.com/juju/juju/commit/d5044f634bbe569271f589de2f15ba7f3e1fece8 which will fail on non-linux environments | 15:18 |
| sinzui | katco, I am looking at the range, but looking at http://reports.vapour.ws/releases, we can see when 1.22-alpha1 starts to fail | 15:19 |
| dimitern | katco, it appears to me you've merged a bunch of changes, some of them earlier on master, but the merge overwrote some of the hashes or something - that's why it doesn't show the source immediately | 15:19 |
| katco | dimitern: so i have performed the merge incorrectly? | 15:21 |
| sinzui | katco, http://reports.vapour.ws/releases/2152 is the first build with that revision | 15:21 |
| katco | sinzui: so http://reports.vapour.ws/releases/2150 is the more likely candidate? | 15:22 |
| dimitern | katco, I don't think so - you've merged what was on master already - landed with ericsnow's https://github.com/juju/juju/pull/1238 | 15:22 |
| sinzui | katco, There are many regressions in master right now | 15:22 |
| katco | dimitern: ah ok. | 15:22 |
| voidspace | dimitern: I have something that automatically adds new imports when I need them - I almost never do them manually | 15:23 |
| sinzui | katco there we have opened three so far, and we may open more when we know why manual env tests fail | 15:23 |
| voidspace | dimitern: which is my excuse for how they *always* end up in the wrong place... | 15:23 |
| voidspace | dimitern: I need to start checking them in the diff... | 15:23 |
| voidspace | dimitern: sorry | 15:23 |
| katco | voidspace: i have the same problem | 15:23 |
| voidspace | katco: I have a foolproof way of checking them | 15:24 |
| voidspace | katco: get dimitern to review... | 15:24 |
| katco | haha | 15:24 |
| dimitern | voidspace, I know, I use goimports as well - it does screw up sometimes when removing imports it can remove blank lines between groups | 15:24 |
| katco | voidspace: we should really write a linter so these kinds of things don't clog up reviews | 15:24 |
| voidspace | yep | 15:24 |
| voidspace | sounds good | 15:24 |
| voidspace | check for doc comments and a few other stylistic issues | 15:25 |
| katco | yeah | 15:25 |
| dimitern | katco, voidspace, I was actually considering proposing a patch for goimports to fix this, but the process is a bit long | 15:25 |
| katco | that is one of my cardinals rules of reviews, let's not discuss style guidlines we've already agreed upon | 15:25 |
| katco | dimitern: it would be much appreciated | 15:25 |
| katco | dimitern: yeah looking at the diff b/t my fork and master, i don't think this would have caused a regression on other platforms: https://github.com/katco-/juju/commit/a632fb4237a2da1cebfcb136874bed665644d408 | 15:26 |
| katco | same thing from juju/juju perspective: https://github.com/juju/juju/commit/a632fb4237a2da1cebfcb136874bed665644d408 | 15:27 |
| dimitern | katco, it does look fine, although I just had a quick look around - checking for syscall and map comparisons | 15:30 |
| dimitern | ericsnow, alright so you'll be fixing those two related to Stat_t ? | 15:33 |
| katco | dimitern: lmk if i can help at all. otherwise moving onto planned work! | 15:34 |
| dimitern | katco, sure, but if ericsnow is already on it I think it's fine | 15:36 |
| ericsnow | dimitern: I'm going to fix bug #1400350 and I expect that will fix 1400344 too :) | 15:37 |
| mup | Bug #1400350: metadata_test consistently fails in ppc64el unit tests <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged by ericsnowcurrently> <https://launchpad.net/bugs/1400350> | 15:37 |
| katco | ericsnow: your job is on the line apparently! ;) | 15:38 |
| dimitern | ericsnow, :) yeah, it appears so | 15:38 |
| ericsnow | katco: lol, yours too! | 15:38 |
| katco | ericsnow: haha | 15:38 |
| ericsnow | natefinch: for the windows-only file I put "// +build windows" at the top, right? | 15:58 |
| ericsnow | natefinch: and "// +build !windows" for the non-windows file? | 15:58 |
| natefinch | ericsnow: or _windows.go for the windows one (but yes, you need // +build !windows for the non-windows one | 15:58 |
| ericsnow | natefinch: the filename doesn't impact the compilation related to windows, does it? | 15:59 |
| ericsnow | natefinch: I have metadata.go, metadata_windows.go, and metadata_unix.go | 16:00 |
| ericsnow | natefinch: the special-case files just defined the OS-specific functionality as a function that metadata.go calls | 16:00 |
| natefinch | ericsnow: yes it does. _<os/arch>.go will be treated the same as // +build <os/arch> | 16:00 |
| ericsnow | natefinch: (on windows the func is empty) | 16:00 |
| ericsnow | natefinch: sweet | 16:00 |
| natefinch | ericsnow: I prefer the filename version because it's much more obvious... it's fairly easy to miss the build tag at the top of a file | 16:01 |
| ericsnow | natefinch: agreed | 16:01 |
| natefinch | (but you can't do fancy stuff like !windows with the filename version) | 16:01 |
| ericsnow | natefinch: got it | 16:01 |
| ericsnow | natefinch: if you got a sec, take a look: http://reviews.vapour.ws/r/599/ | 16:04 |
| katco | to be entertained: traceroute 216.81.59.173 | 16:05 |
| ericsnow | katco: nice! | 16:11 |
| natefinch | traceroute isn't installed by default? Geez, even windows has that preinstalled. | 16:24 |
| natefinch | Also.... awesome. Though they should slow down the ping times between them to give a more dramatic effect :) | 16:25 |
| katco | natefinch: lol not sure if it's an actual network they need to work | 16:25 |
| natefinch | katco: "damn, the web server is pegged again, go reboot 'against.the.evil.Galactic.Empire'" | 16:26 |
| katco | natefinch: rofl | 16:26 |
| voidspace | dimitern: about to finish this | 16:26 |
| voidspace | dimitern: do you have something else I can move onto? | 16:26 |
| voidspace | dimitern: I'm asking now so I catch you before you EOD | 16:27 |
| dimitern | voidspace, just a sec | 16:27 |
| voidspace | dimitern: sure | 16:27 |
| voidspace | dimitern: I still need to write a test for the race | 16:27 |
| voidspace | dimitern: although it's fixed | 16:27 |
| voidspace | as are the other issues | 16:27 |
| dimitern | voidspace, nice! | 16:27 |
| dimitern | voidspace, there is one thing that comes to mind | 16:29 |
| dimitern | voidspace, I believe we have what's necessary to implement Subnets() on ec2 | 16:29 |
| voidspace | dimitern: do we not have it? | 16:30 |
| voidspace | dimitern: I thought we did | 16:30 |
| voidspace | dimitern: Subnets(instanceId) | 16:30 |
| dimitern | voidspace, I still see it as returning notimplementedf | 16:31 |
| voidspace | dimitern: indeed, me too | 16:31 |
| voidspace | I thought we had it | 16:31 |
| dimitern | voidspace, we have it for maas | 16:31 |
| voidspace | ok | 16:31 |
| dimitern | voidspace, it should be quick and easy - returning all subnets (there will only be default vpc subnets for now, but that's fine) | 16:32 |
| voidspace | dimitern: ok, do you know the ec2 call off the top of your head? | 16:32 |
| voidspace | if not I can look into it and shout if I get stuck | 16:32 |
| dimitern | voidspace, one quirk though - AllocatableIPLow and AllocatableIPHigh need to be set so we respect AWS limits | 16:32 |
| dimitern | voidspace, the api call is DescribeSubnets, but in goamz it's called Subnets | 16:32 |
| voidspace | right | 16:33 |
| voidspace | dimitern: so we need to extend network.BasicInfo to include that info I think | 16:33 |
| voidspace | dimitern: then possibly adjust the maas implementation to fill this in too | 16:33 |
| dimitern | voidspace, the aws docs says the first 4 and the last ip in a subnet cidr are reserved I think | 16:33 |
| voidspace | ok | 16:33 |
| voidspace | I'll check on that | 16:33 |
| dimitern | voidspace, but please double check | 16:33 |
| voidspace | ok | 16:33 |
| dimitern | voidspace, well we'll need to add the high/low range to network.BasicInfo anyway | 16:35 |
| voidspace | dimitern: ok | 16:35 |
| dimitern | voidspace, maybe even rename that to SubnetInfo ? | 16:35 |
| voidspace | dimitern: I'll see how it's used elsewhere | 16:36 |
| voidspace | dimitern: that sounds better for us | 16:36 |
| voidspace | better in general | 16:36 |
| dimitern | voidspace, yeah, I think it sounds better in the face of recent changes :) | 16:36 |
| ericsnow | sinzui: two of the backups blockers should be fixed now (1400344 and 1400350) | 16:54 |
| ericsnow | sinzui: (same fix) | 16:54 |
| sinzui | thank you ericsnow | 16:55 |
| ericsnow | natefinch: i've updated http://reviews.vapour.ws/r/557/ | 17:09 |
| ericsnow | natefinch: FYI, you're the only one who hasn't recused themself from a LGTM :) | 17:09 |
| ericsnow | natefinch: if you don't feel up to it I'll see if axw will tackle it | 17:10 |
| lazyPower | is there a way to specify the hookenv you want to execute a juju run command in? juju run -h doesn't say | 17:40 |
| lazyPower | reason being, i'd like to see what was sent otw without entering debug hooks if i can get away with it - hackedbellini is experencing an issue wrt some data being sent by postgres and it seems really cumbersome to have to deploy a second unit, attach debug hooks, and step through an entire deployment to get at that data. | 17:41 |
| marcoceppi | wwitzel3: ^ | 17:42 |
| wwitzel3 | lazyPower: no, not currently. | 17:47 |
| wwitzel3 | lazyPower: in master we have the ability to do that with juju-run | 17:47 |
| lazyPower | wwitzel3: ack, i figured that was the case for now. | 17:48 |
| wwitzel3 | natefinch: I'm going to grab lunch, want to talk gce when I get back? | 17:53 |
| lazyPower | wwitzel3: wait - i just saw a drop in #juju from stub about juju run -r relation:id - is this the current trunk capability? | 18:02 |
| ericsnow | natefinch: could you take a quick look at http://reviews.vapour.ws/r/600/ (for CI blocker) | 18:19 |
| natefinch | ericsnow: looking | 18:22 |
| ericsnow | natefinch: ta | 18:22 |
| * natefinch gives ericsnow a ship it with a moral quandry. | 18:28 | |
| ericsnow | natefinch: k | 18:28 |
| katco | have to run to the dr. bbiab | 18:30 |
| natefinch | Dr Bbiab must have a hard time with people misspelling his name. | 18:31 |
| natefinch | sorry his/her ... don't want to presume | 18:31 |
| voidspace | g'night all | 18:40 |
| wwitzel3 | lazyPower: yes, -r is in trunk for juju-run, but not juju run | 18:51 |
| natefinch | wwitzel3: re: gce, yes, in a couple minutes | 18:56 |
| wwitzel3 | natefinch: sounds good, just ping me when you're ready | 18:56 |
| === fuzzy_ is now known as Fuzai | ||
| natefinch | wwitzel3: I'm in moonstone | 19:36 |
| wwitzel3 | natefinch: omw | 19:37 |
| ericsnow | natefinch, wwitzel3 mind if I join in? | 19:48 |
| ericsnow | natefinch, wwitzel3: I'm going to assume not :) | 19:50 |
| === kadams54 is now known as kadams54-away | ||
| alexisb | natefinch, on the hangout when you are ready | 20:34 |
| wwitzel3 | alexisb: we are wrapping up some google provide hand off stuff, he'll be right there :) | 20:35 |
| alexisb | wwitzel3, heh no rush | 20:35 |
| alexisb | I have plenty to keep me occupied in the meantime | 20:35 |
| menn0 | does anyone know how to get the landing bot to look at a branch again when a previous merge attempt was manually cancelled? | 20:37 |
| menn0 | thumper: ^ | 20:37 |
| thumper | menn0: try the merge magic string again? | 20:38 |
| menn0 | thumper: I did that | 20:38 |
| * thumper shrugs | 20:38 | |
| menn0 | thumper: I think previously wallyworld had to do something | 20:38 |
| menn0 | thumper: it's something to do with the bot not seeing it's own fail message in the conversation | 20:39 |
| menn0 | I wonder if I just copy a failure from elsewhere... | 20:39 |
| thumper | ah... sorry don't know what to do there | 20:39 |
| menn0 | thumper: I'm trying a few things. it's academic anyway since CI is blocked. | 20:41 |
| menn0 | thumper: that totally worked though :) I just copied a "Build failed..." message from elsewhere and then the bot was happy to consider the branch again. | 20:42 |
| menn0 | thumper: of course it didn't get anywhere due to CI being blocked | 20:42 |
| thumper | haha | 20:42 |
| natefinch | alexisb: hi, sorry, coming | 20:44 |
| ericsnow | could I get a second opinion on http://reviews.vapour.ws/r/557/#comment5998? | 20:45 |
| menn0 | is anyone looking at bug 1400348? | 20:50 |
| mup | Bug #1400348: Azure deployment broken <azure-provider> <bootstrap> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1400348> | 20:50 |
| === kadams54-away is now known as kadams54 | ||
| thumper | menn0: I have noticed a few intermittent failures in jujud around logging in during upgrade | 21:01 |
| thumper | menn0: have you seen these? | 21:01 |
| menn0 | thumper: yep. there's a ticket for that which I plan on getting to soon. | 21:02 |
| thumper | kk | 21:02 |
| thumper | mramm: chat time? | 21:02 |
| mramm | sure thing, I'm in the hangout | 21:03 |
| thumper | mramm: so am I | 21:04 |
| thumper | dumb googld | 21:05 |
| thumper | menn0: care to look at that azure bug? | 21:43 |
| menn0 | thumper: I was thinking about it. i've already sent axw some questions for when he starts | 21:44 |
| menn0 | thumper: do we have a company account to access azure that I can use? | 21:44 |
| katco | any lxc experts? could use some help debugging an issue in canonical/#juju | 21:44 |
| menn0 | thumper: or should I set up my own? | 21:44 |
| thumper | menn0: could ask sinzui | 21:44 |
| menn0 | thumper: actually... I think I know where some creds might be | 22:04 |
| sinzui | menn0, I can help | 22:05 |
| menn0 | sinzui: great | 22:06 |
| menn0 | thumper: I have what I need from sinzui so I'll start on that bug now | 22:14 |
| thumper | menn0: thank you | 22:28 |
| katco | axw: ping you on yet? | 22:40 |
| anastasiamac | katco: it's about 7am where andrew is... | 22:44 |
| anastasiamac | he usually jumps in in around 3hrs... just before our standup... | 22:44 |
| anastasiamac | katco: well in about 2hrs now... :-) | 22:45 |
| katco | anastasiamac: yeah just thought i'd check. do you recall if ian was working on an issue with certs and simple streams? | 22:45 |
| katco | anastasiamac: it's ringing a bell but i can't place it | 22:45 |
| anastasiamac | katco: both ring a bell | 22:45 |
| anastasiamac | katco: i thought that he landed the cert stuff... | 22:45 |
| katco | anastasiamac: i'm wondering if i'm thinking of this: https://bugs.launchpad.net/juju-core/+bug/1397909 | 22:45 |
| mup | Bug #1397909: State server certificate has empty SAN list <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1397909> | 22:46 |
| anastasiamac | katco: sounds rite... | 22:46 |
| anastasiamac | katco: Merge pull request #1241 from wallyworld/update-server-certificate | 22:51 |
| anastasiamac | katco: about 3 days ago... | 22:52 |
| katco | anastasiamac: thanks, but if that's what i'm thinking of then it's not appropriate | 22:52 |
| anastasiamac | katco: k :-) | 22:52 |
| menn0 | thumper: I can easily duplicate that problem but I'm having a hard time understanding why it's azure specific | 23:07 |
| menn0 | thumper: trying on ec2 now as a sanity check | 23:07 |
| menn0 | thumper: then will try to narrow down the commit but I'm pretty sure it's wallyworld's credupdater worker | 23:07 |
| anastasiamac | katco: well done for solving that issue on #juju | 23:16 |
| anastasiamac | katco: thnx for the email too | 23:16 |
| anastasiamac | katco: emacs... | 23:17 |
| === urulama_ is now known as urulama | ||
| katco | anastasiamac: mwhudson helped a lot | 23:17 |
| anastasiamac | katco: team work is amazing :) | 23:18 |
| katco | anastasiamac: np about the email. yes, i agree mentioning the word emacs brings calm and joy to an irc chatroom ;) | 23:18 |
| katco | unlike the editor which shall not be named! | 23:18 |
| mattyw | morning all | 23:34 |
| katco | good morning mattyw | 23:35 |
| mattyw | katco, what time is it for you? | 23:35 |
| katco | mattyw: 17:35 | 23:35 |
| anastasiamac | katco: m sure it thinks of itself as IDE not an editor | 23:37 |
| katco | anastasiamac: what, emacs? | 23:37 |
| anastasiamac | katco: IDEA | 23:37 |
| katco | ah | 23:37 |
| anastasiamac | katco: but m not racist and m happy to try emacs | 23:38 |
| katco | what would be the correct term for one who discriminates against editors? | 23:38 |
| katco | editorist? | 23:39 |
| mattyw | katco, foolish? | 23:40 |
| katco | mattyw: lol, yes i'd say so. | 23:40 |
| mattyw | anastasiamac, what do you use at the moment? | 23:40 |
| mattyw | anastasiamac, also - hi! | 23:40 |
| anastasiamac | mattyw: hi :-) | 23:40 |
| anastasiamac | katco: considering E in IDE is an environment = environmentalist? | 23:41 |
| anastasiamac | mattyw: IntelliJ | 23:41 |
| katco | haha | 23:41 |
| katco | environmentalist, i like that | 23:41 |
| anastasiamac | katco: :) | 23:41 |
| anastasiamac | katco: but neither u nor I r that | 23:41 |
| anastasiamac | katco: i just live conflict resolution GUI in IntelliJ | 23:42 |
| katco | anastasiamac: absolutely not. i support everyone's right to use a totally-worse-than-emacs editor :) | 23:42 |
| katco | </snark> | 23:42 |
| anastasiamac | katco: m glad u clarified :-) | 23:42 |
| menn0 | thumper: so the CI blocker was definitely introduced by the 009aef5 merge | 23:47 |
| === kadams54 is now known as kadams54-away | ||
| menn0 | thumper: it's a pretty big change which introduces a new jujud worker | 23:49 |
| menn0 | thumper: git log 009aef5~..009aef5 | 23:49 |
| menn0 | thumper: do I try to rip the whole thing out or try to fix the issue? | 23:50 |
| menn0 | thumper: I've ripped it out (only one conflict) and am running tests | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!