| katco | ericsnow: if you're around, looks like review board isn't picking this up? https://github.com/juju/juju/pull/1931 | 00:12 |
|---|---|---|
| katco | ericsnow: oh shoot and i know why. | 00:12 |
| katco | ericsnow: i recently changed my github username: katco- to kat-co | 00:12 |
| ericsnow | katco: that would do it :) | 00:13 |
| katco | ericsnow: any way to move my account and get that PR up? | 00:13 |
| ericsnow | katco: I should be able to do that real quick | 00:13 |
| katco | ericsnow: you are a gentleman and a programmer. | 00:14 |
| ericsnow | katco: done; hopefully it works ;) | 00:16 |
| katco | ericsnow: account looks good, but PR still isn't there? | 00:17 |
| katco | rbt post is asking for a pw | 00:17 |
| katco | ericsnow: and the instructions you sent out last year aren't working for me =/ | 00:26 |
| katco | axw: wallyworld_: https://github.com/juju/juju/pull/1931 until it gets onto RB. i have to go take care of some things. | 00:28 |
| wallyworld_ | ty | 00:28 |
| davecheney | boom, gccgo bug is fixed upstream | 00:34 |
| davecheney | now ... PAPERWORK! | 00:34 |
| thumper | davecheney: \o/ | 00:39 |
| davecheney | yeah, lynn's patch was submitted this morning | 00:40 |
| davecheney | ok, that joy was short lived, our other fix that went into gccgo 4.9 needs to be forward ported to 5.0 | 00:53 |
| davecheney | i'll raise another bug | 00:53 |
| davecheney | win12 | 01:06 |
| thumper | wallyworld_: got a minute? | 01:22 |
| wallyworld_ | sure | 01:22 |
| thumper | 1:1 hangout? | 01:22 |
| === kadams54 is now known as kadams54-away | ||
| fwereade | holy crap, that mostly works | 02:08 |
| fwereade | right, going to bed | 02:09 |
| ericsnow | katco: if you're still around, try killing that PR, go to RB, log out, log back in, and then re-submit the PR over on github | 02:22 |
| ericsnow | thumper: ping | 04:29 |
| axw | wallyworld: FYI, I've proposed the environ-storageprovisioner and dynamic EBS branches -- http://reviews.vapour.ws/r/1258/ and http://reviews.vapour.ws/r/1259/ | 04:38 |
| axw | wallyworld: I guess I'll work on volume-backed filesystems now | 04:38 |
| axw | wallyworld: FYI, I've proposed the environ-storageprovisioner and dynamic EBS branches -- http://reviews.vapour.ws/r/1258/ and http://reviews.vapour.ws/r/1259/ | 04:41 |
| axw | wallyworld: I guess I'll work on volume-backed filesystems now | 04:41 |
| wallyworld | axw: great ty, will look soon. volume backed fs sounds good | 04:42 |
| ericsnow | wallyworld: does this sounds familiar (relative to state log pruning): "failed to retrieve log counts: no such cmd: scale" | 05:19 |
| bradm | anyone know what the error "juju.rpc server.go:554 error writing response: EOF" in machine-0.log means? the juju environment isn't very healthy, juju sets aren't triggering the appropriate config-changed hooks | 05:47 |
| urulama | wallyworld: the sessions added, alexisb notified. | 06:45 |
| wallyworld | axw: off to soccer for a couple of hours, reviews done | 06:55 |
| axw | wallyworld: thanks | 06:56 |
| axw | later | 06:56 |
| mup | Bug #1436191 was opened: gce: bootstrap instance has no network rule for API <firewall> <gce> <juju-core:New> <https://launchpad.net/bugs/1436191> | 07:17 |
| mattyw | morning all o/ | 07:24 |
| dimitern | axw, ping | 08:30 |
| dimitern | axw, I'm +100 on moving replicaset out of the main repo, but will this reduce the tests run time for core? | 08:31 |
| axw | dimitern: hey sorry, was afk. this change will not. this change is just preparing to move it out of core | 08:59 |
| axw | and to generate discussion | 09:00 |
| dimitern | axw, right, so a step in the right direction :) | 09:00 |
| axw | yup | 09:00 |
| axw | dimitern: in case I misunderstood - the change on RB atm won't reduce test time, but moving replicaset out of core will | 09:03 |
| axw | unless of course CI starts running tests for all the github.com/juju packages | 09:03 |
| dimitern | axw, yep, got it | 09:04 |
| dimitern | axw, well, that happening at some point certainly won't hurt | 09:04 |
| axw | it'll hurt the run time ;) I think we should do it, not sure about as part of the merge gating, maybe just as a voting CI job | 09:05 |
| dimitern | axw, no no - definitely not part of the merge gating :) | 09:05 |
| natefinch | wallyworld, dimitern, axw, anyone else: I'm getting a "no reachable servers" trying to connect to state, which then causes all the workers to shut down... but jujud hangs around, and doesn't restart or retry or anything. Why is that? Shouldn't it retry? This is on a machine that I've converted from a regular server to a state server in a replicaset. | 09:22 |
| natefinch | It's a bummer, because I think it's just that mongo is slow, and if I kill jujud, it restarts and is able to connect. | 09:22 |
| axw | natefinch: not sure off hand, I'll have a look at the code and see if I can think of a reason... | 09:22 |
| dimitern | natefinch, I'm not quite sure why, but it should retry | 09:22 |
| dimitern | natefinch, maybe some worker / runner is hanging instead of exiting | 09:23 |
| natefinch | dimitern: ahh, hmm, yeah, that's a good point | 09:23 |
| axw | natefinch: only reason I can see that would explain that is if the state-serving info in the agent config changed | 09:31 |
| axw | i.e. from having it to not having it | 09:31 |
| axw | not sure if that's even possible | 09:32 |
| dimitern | wow that's a first - http://paste.ubuntu.com/10676289/ - build failure in the net-cli branch - anyone seen something like that with the gc compiler? | 09:33 |
| axw | dimitern: did you update your go compiler? | 09:34 |
| axw | I've seen that sort of thing when there's version mismatch | 09:34 |
| dimitern | axw, no - still go 1.2.1 amd64 from trusty | 09:34 |
| natefinch | try deleteing your gopath/pkg directory and rebuild | 09:36 |
| dimitern | weird.. so I've wiped out my /tmp and $GOPATH/pkg/* dirs, rebuilt and now it's fine | 09:36 |
| natefinch | yep | 09:36 |
| dimitern | natefinch, yep, cheers | 09:36 |
| natefinch | some weird mismatch.. maybe gccgo or something? | 09:37 |
| dimitern | I did have both gccgo and gc binaries/object files in pkg | 09:37 |
| dimitern | in separate subdirs, but still | 09:38 |
| natefinch | oh right forgot they're in separate dirs... well, I dunno, I've had it happen once in a blue moon | 09:38 |
| dimitern | yeah | 09:39 |
| dimitern | (as they say quite often lately around here - "putin is most likely behind this" :D) | 09:40 |
| axw | lol | 09:40 |
| natefinch | haha | 09:40 |
| dooferlad | Anyone around who could help with a test failure due to an unexpected receive? http://paste.ubuntu.com/10676354/ | 09:42 |
| dooferlad | This seems to happen if I am running the entire suite sometimes, but never if I just run that one test. | 09:42 |
| dimitern | dooferlad, oh, I know that one | 09:42 |
| dimitern | dooferlad, it's known to be flaky, esp. under load | 09:42 |
| dooferlad | dimitern: *sigh* | 09:43 |
| dimitern | dooferlad, I did try fixing it, but gave up because it wasn't easy without refactoring the way the filter uses watchers | 09:43 |
| TheMue | I love our tiny logs. ;) | 09:43 |
| dimitern | dooferlad, our SpaceTag caused quite a stir apparently | 09:47 |
| dooferlad | dimitern: do you remember what caused the problem? (filter tests) | 09:47 |
| dooferlad | dimitern: yea, I expect that will be renamed at some point! | 09:48 |
| dooferlad | network-group maybe | 09:48 |
| natefinch | is spacetag anything like freeze tag? sounds like fun ;) | 09:48 |
| dimitern | dooferlad, the problem is synchronization between the apiserver, api, and state watchers | 09:49 |
| dimitern | natefinch, it's more like a space cake I guess :D | 09:49 |
| dimitern | dooferlad, TheMue, standup? | 10:00 |
| TheMue | dimitern: yes. *lol* | 10:01 |
| voidspace | dimitern: so I fixed the first test problem (only a new worker sees the broken provider) | 10:39 |
| voidspace | dimitern: for the second test issue I've pushed a failing test | 10:40 |
| voidspace | dimitern: when we start the worker we have two dead addresses 0.1.2.4 and 0.1.2.6 | 10:40 |
| voidspace | dimitern: I'm expecting to see two ReleaseAddress calls, one for each | 10:40 |
| voidspace | dimitern: what I *actually* see is *three* calls | 10:40 |
| voidspace | dimitern: two for the first address and one for the second | 10:40 |
| voidspace | dimitern: I'm looking into it | 10:40 |
| dimitern | voidspace, hmm weird | 10:40 |
| voidspace | dimitern: I have a test that reliably passes asserting those three calls... | 10:41 |
| dimitern | voidspace, do the first 2 calls have the same args? | 10:42 |
| voidspace | dimitern: well, the OpReleaseAddress we get is the same | 10:42 |
| voidspace | so yes | 10:42 |
| voidspace | same subnetid etc | 10:42 |
| voidspace | they're the same address | 10:42 |
| voidspace | dimitern: I'll add some logging to see why | 10:43 |
| dimitern | voidspace, yeah | 10:43 |
| dimitern | voidspace, it might be the last call comes from Handle() | 10:43 |
| dimitern | voidspace, oh, no actually.. if the first 2 are the same maybe the first one does | 10:43 |
| dimitern | voidspace, make sure you check the addresses you get in Handle are both dead and not gone | 10:44 |
| voidspace | dimitern: I check that | 10:46 |
| voidspace | dimitern: I think I found a bug, not sure how it can be the cause | 10:46 |
| voidspace | dimitern: or how the code worked at all | 10:46 |
| voidspace | dimitern: I have a select that removes the dead addresses - but it is a single select it doesn't loop | 10:47 |
| voidspace | dimitern: so it should only do the first address | 10:47 |
| voidspace | so how I'm seeing three releases is a real mystery... | 10:49 |
| voidspace | running with logging | 10:49 |
| dimitern | voidspace, good catch then | 10:49 |
| voidspace | dimitern: right, I see two attempts for each address | 10:49 |
| voidspace | from the logging | 10:49 |
| dimitern | voidspace, I guess one from SetUp and one from Handle ? | 10:50 |
| voidspace | let me add to Handle to check that | 10:50 |
| voidspace | dimitern: it's possible that the removal triggers the watcher too - but inside Handle I'm specifically checking if the address exists | 10:50 |
| wallyworld | fwereade: you around? | 10:50 |
| voidspace | dimitern: if it's *already* been removed we should fail to fetch it from State | 10:50 |
| fwereade | wallyworld, heyhey | 10:51 |
| voidspace | dimitern: it looks like the removal succeeds, triggering the watcher and then we *successfully* pull the address back out of state | 10:51 |
| voidspace | dimitern: race condition due to transactions? | 10:51 |
| voidspace | is that possible | 10:51 |
| dimitern | voidspace, hmm | 10:51 |
| dimitern | voidspace, it is possible | 10:51 |
| wallyworld | fwereade: if you had time, i'd love a quick pre-impl chat | 10:51 |
| voidspace | dimitern: I'm going to confirm that this is the case (one attempt from Handle and one from SetUp) | 10:51 |
| dimitern | voidspace, that's the thing with JujuConnSuite | 10:51 |
| fwereade | wallyworld, will be in our hangout in 5 mins | 10:51 |
| dimitern | voidspace, we have 2 states there - State and BackingState - the latter is the real one used by the apiserver, the former is the state used by the api client | 10:52 |
| wallyworld | sure | 10:52 |
| dimitern | voidspace, and they're not synced wrt watchers | 10:52 |
| dimitern | voidspace, try calling s.BackingState.StartSync() before each assert on the watcher | 10:53 |
| voidspace | dimitern: what i'm seeing on start is Handle called with every address | 10:56 |
| dimitern | those were exactly the same issues that lead to flaky tests | 10:56 |
| voidspace | dimitern: so the initial SetUp is trying to remove them at the same time as Handle | 10:56 |
| dimitern | voidspace, yeah, that's what I suspected | 10:56 |
| voidspace | I thought State and BackingState were the same these days, we fixed it by just having one State? | 10:57 |
| voidspace | I'll try the extra sync anyway | 10:57 |
| dimitern | voidspace, so you might not need to do the out-of-bound goroutine in setup perhaps? | 10:57 |
| voidspace | dimitern: maybe not | 10:57 |
| voidspace | dimitern: I read a docstring saying "Initial" was only the alive entities for a lifecyclewatcher | 10:58 |
| voidspace | that maybe out of date | 10:58 |
| voidspace | dimitern: I'll read the lifecycle watcher code | 10:58 |
| voidspace | I maybe able to just delete the SetUp | 10:58 |
| voidspace | well, most of it anyway | 10:58 |
| fwereade | voidspace, I think it has to include dying ones as well and frequently the dead ones | 10:59 |
| fwereade | voidspace, consider something like a provisioner | 10:59 |
| fwereade | voidspace, it needs to know about its dead machines so it can remove them | 10:59 |
| voidspace | fwereade: "frequently"... I'd quite like a deterministic result :-) | 10:59 |
| voidspace | fwereade: right, I was just going off some docstring that said "initial()" was called with only alive entities | 11:00 |
| fwereade | voidspace, ok, lifecycle watchers should return everything in their initial results, including dying and dead | 11:00 |
| dimitern | voidspace, fwereade, so the lifecycle watcher is smarter than I thought :) | 11:00 |
| voidspace | fwereade: I'll dig it out | 11:00 |
| voidspace | that's great | 11:00 |
| voidspace | removes some code | 11:00 |
| fwereade | voidspace, cool | 11:00 |
| voidspace | The first event emitted will contain the ids of all non-Dead entities | 11:01 |
| voidspace | state/watcher.go line 136 | 11:01 |
| voidspace | fwereade: so in lifecycleWatcher.initial it fetches the whole collection, *stores* the ids of "non-dead" entities, but returns *all* ids | 11:03 |
| voidspace | I'll update the docstring | 11:03 |
| voidspace | dammit, I should no better never to trust a docstring | 11:03 |
| fwereade | voidspace, yeah, that sounds right | 11:03 |
| fwereade | voidspace, thanks | 11:03 |
| voidspace | fwereade: we need to go back to calling them lies... | 11:03 |
| voidspace | *know better* | 11:04 |
| voidspace | dimitern: so if I just delete that code in SetUp the test passes... | 11:06 |
| voidspace | dimitern: which is good | 11:06 |
| dimitern | voidspace, only one comment on your review | 11:07 |
| dimitern | voidspace, great! | 11:07 |
| dimitern | voidspace, I'll wait for the changes around SetUp and will re-review it | 11:07 |
| voidspace | dimitern: that select is gone | 11:08 |
| voidspace | dimitern: ah, no it's not | 11:08 |
| voidspace | dimitern: that's iin the test, fine I'll fix that | 11:08 |
| voidspace | dimitern: SetUp change pushed | 11:08 |
| dimitern | voidspace, looks nice and red :) | 11:09 |
| voidspace | :-) | 11:09 |
| * dimitern steps out for ~2h | 11:12 | |
| wallyworld_ | ericsnow: here's a trivial fix for an intermittent failure on ppc64 http://reviews.vapour.ws/r/1261/ | 12:17 |
| frankban | ocr" could anyone please take a look at http://reviews.vapour.ws/r/1263/ ? thanks! | 12:43 |
| * dimitern is back | 12:51 | |
| * fwereade omw uk for a bit, will be around again later but was up until 3 last night so might be a bit relaxed about it | 13:09 | |
| dimitern | voidspace, hey | 13:39 |
| dimitern | voidspace, the releaser looks much better now, thanks! | 13:40 |
| dimitern | voidspace, you have a review with a provisional "ship it!" and mostly minor changes suggested. | 13:40 |
| ericsnow | jw4: ping | 13:45 |
| jw4 | ericsnow: ola | 13:45 |
| ericsnow | jw4: could you take a look at this log from CI: http://data.vapour.ws/juju-ci/products/version-2478/run-unit-tests-vivid-amd64/build-289/consoleText | 13:46 |
| jw4 | ericsnow: that should be fixed? | 13:47 |
| ericsnow | jw4: it shows a failure that you fixed the other day with the log pruning stuff | 13:47 |
| jw4 | right | 13:47 |
| jw4 | did that error occur recently? | 13:47 |
| ericsnow | jw4: I'm trying to figure out why | 13:47 |
| ericsnow | jw4: Tuesday | 13:47 |
| ericsnow | (yesterday) | 13:48 |
| jw4 | ericsnow: ah, look at the documentation for the mgo http://godoc.org/labix.org/v2/mgo#Database.Run | 13:48 |
| ericsnow | jw4: right, but I thought you fixed this already | 13:49 |
| jw4 | ericsnow: yeah, I'm looking to see if there's another call to Database.Run | 13:50 |
| ericsnow | jw4: good point | 13:50 |
| dimitern | ericsnow, jw4, I did see that patch replacing bson.M with bson.D land, but maybe the dependencies.tsv was not updated after? | 13:50 |
| jw4 | dimitern: there should be no dependencies.tsv update | 13:51 |
| dimitern | jw4, oh, right - that's in state only | 13:51 |
| jw4 | ericsnow: weird I don't see any other call | 13:52 |
| jw4 | ericsnow: I see that run was testing a version before my fix landed: Testing gitbranch:master:github.com/juju/juju 0752a4bc | 13:53 |
| ericsnow | jw4: ah, never mind then :) | 13:54 |
| jw4 | :) | 13:54 |
| ericsnow | (I was just checking that) | 13:54 |
| * ericsnow promises himself not to try to reason about problems late in the evening | 13:54 | |
| jw4 | hehe | 13:54 |
| jw4 | (but aren't you in Mountain Time? 8 AM now?) | 13:55 |
| natefinch | well, ha --to 1,2 works now, though I have to use a hack to get jujud to restart after the StateWorker errors out from not being able to connect to state. I gotta figure out why the damn workers aren't shutting down. | 13:58 |
| voidspace | dimitern: cool, thanks | 14:02 |
| voidspace | dimitern: you want me to use the envtesting package in the worker itself? | 14:02 |
| voidspace | dimitern: in fact, I don't think envtesting.ShortAttempt exists, which is why I was using the other one in the tests | 14:03 |
| dimitern | voidspace, ah | 14:03 |
| voidspace | dimitern: I'm pretty sure you've hallucinated its existence | 14:03 |
| dimitern | voidspace, let me double check | 14:03 |
| voidspace | dimitern: and I didn't want a dependency on a test package in the production code | 14:03 |
| dimitern | voidspace, oh, you're right | 14:04 |
| dimitern | voidspace, so then use common.ShortAttempt in both the worker and the tests? | 14:05 |
| voidspace | dimitern: it's in the provider package, but ok | 14:06 |
| voidspace | well, provider/common | 14:06 |
| dimitern | voidspace, yeah | 14:06 |
| voidspace | seems like a weird dependency | 14:06 |
| voidspace | dimitern: and I dropped one of your issues - you slightly misunderstood the test | 14:06 |
| voidspace | dimitern: the rest are good and I'll fix them, thanks | 14:06 |
| voidspace | dimitern: after a break... | 14:07 |
| dimitern | voidspace, ok, cheers | 14:08 |
| TheMue | Yeeeeeeeeeeeeeeeeeeeeeeeeeeeeeehaw! Local vMAAS acquiring works. *phew* | 14:12 |
| dimitern | TheMue, awesome! | 14:13 |
| TheMue | Needed some patches/changes in their hack, but now the first node started as wanted. | 14:13 |
| dimitern | TheMue, does it stop as well? :) | 14:14 |
| TheMue | dimitern: Yeah, will pass this information to the MAAS team. Maybe they are interested in adding it too. | 14:14 |
| TheMue | dimitern: Oh, good question. one moment. | 14:14 |
| TheMue | dimitern: Hehe, yeah, it does. *dancingThroughTheRoom* | 14:16 |
| dimitern | TheMue, great! then you can have a look at that bug 1427814 :) | 14:17 |
| mup | Bug #1427814: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814> | 14:17 |
| dimitern | TheMue, in order to reproduce it, you'll need to remove the lshw output for a node (or all nodes) from maas db | 14:18 |
| TheMue | dimitern: shit, I should have been quiet *lol* | 14:22 |
| dimitern | TheMue, :) | 14:22 |
| TheMue | dimitern: so, assigned to me and will add a card. but let me provision my fresh nodes first | 14:23 |
| dimitern | TheMue, sure, np | 14:23 |
| dimitern | TheMue, there's already a card btw | 14:23 |
| TheMue | dimitern: ah, ok, then I'll grab it | 14:24 |
| dimitern | TheMue, cheers, ping me if anything is unclear | 14:24 |
| TheMue | dimitern: yep, will do | 14:24 |
| sinzui | ericsnow, I have bug 1435974 into something we can do. In short, the license files don't have copyrights...the owner of the licence is not clear the owner of the code | 14:43 |
| mup | Bug #1435974: Copyright information is not available for some files <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435974> | 14:43 |
| ericsnow | sinzui: ah, that makes sense | 14:45 |
| ericsnow | sinzui: so does that mean we should have a separate top-level COPYRIGHT file? | 14:45 |
| sinzui | ericsnow, no it means stop cargo-culting licenses. just put the copyright and meaningful paragraph in the LICENCE file. see my comment int the bug | 14:46 |
| ericsnow | sinzui: got it; I'll take a look | 14:48 |
| ericsnow | sinzui: should I get someone to write up patches or were you planning on it? | 14:52 |
| sinzui | ericsnow, I think core staff are best suited to it since they have to change the project, then the juju 1.22.1 dependencies.tsv | 14:53 |
| ericsnow | sinzui: sounds good | 14:53 |
| dimitern | ericsnow, hey | 14:58 |
| ericsnow | dimitern: hi | 14:59 |
| dimitern | ericsnow, any idea why I'm getting this with GCE ? Bootstrap failed, cleaning up the environment. | 15:00 |
| dimitern | 2015-03-25 14:58:45 ERROR juju.cmd supercommand.go:430 there was an issue examining the environment: retrieving auth token for <my client email from the json key file>: Invalid Key | 15:00 |
| ericsnow | dimitern: I'm guessing your key is invalid <wink> | 15:00 |
| dimitern | ericsnow, I've followed the instructions, registered for a gce free trail, generated a client id as instructed | 15:00 |
| dimitern | ericsnow, and the gce provider is not liking it for some reason - triple checked I pasted it ok | 15:01 |
| ericsnow | dimitern: it may be, as axw said, that it's simply not clear what to put into environments.yaml | 15:01 |
| natefinch | ericsnow, sinzui: yeah, just slapping a copyright line on the license seems to be the easiest way to do it | 15:01 |
| natefinch | dimitern: you probably have to put it in quotes | 15:02 |
| dimitern | ericsnow, should the private-key setting be a patch to the json file I downloaded? | 15:02 |
| ericsnow | natefinch: as sinzui indicates in the bug, we should also simplify the license file | 15:02 |
| dimitern | ericsnow, s/patch/path/ | 15:02 |
| ericsnow | dimitern: nope, though that is basically what axw suggested (good idea too) | 15:02 |
| dimitern | ericsnow, ah, so it needs to be the verbatim contents of the file then? | 15:03 |
| ericsnow | dimitern: you have to copy-and-paste stuff out of that JSON file | 15:03 |
| sinzui | I think QA can change the tarball scripts to check for copyrights in LICENSE/LICENCE file so we don't get these surprises from Ubuntu | 15:03 |
| dimitern | ericsnow, oh, well, I'll try this | 15:03 |
| ericsnow | dimitern: also, I've put better instructions in the 1.23 release notes | 15:04 |
| dimitern | ericsnow, I'll check there as well then, thanks | 15:05 |
| natefinch | dimitern: something like this: https://pastebin.canonical.com/128327/ | 15:05 |
| natefinch | (replace <tons of garbage> with your actual key) | 15:05 |
| ericsnow | dimitern: BTW, where did you get that JSON file? | 15:05 |
| natefinch | ericsnow: google's site creates it for you | 15:06 |
| ericsnow | natefinch: right, but at what point? during the project creation process? I don't remember | 15:06 |
| dimitern | ericsnow, from the GCE web ui - API & auth | 15:07 |
| ericsnow | dimitern: k | 15:07 |
| ericsnow | dimitern: I remember now, thanks | 15:07 |
| Muntaner | hi devs | 15:13 |
| Muntaner | I have a question about charm distros | 15:13 |
| Muntaner | I need to be free in what distro I launch with my charms: CentOS, Kali, etc... can I actually do that with juju? | 15:13 |
| ericsnow | dimitern: thanks for looking at the bug, BTW | 15:13 |
| dimitern | ericsnow, np, looked like a relatively easy fix and a chance for me to try the gce awesomeness :) | 15:14 |
| ericsnow | dimitern: haha | 15:14 |
| alexisb | Muntaner, currently juju supports deploying Ubuntu and Windows workloads | 15:19 |
| alexisb | Muntaner, we will soon have support of Centos | 15:19 |
| alexisb | but it is not currently available | 15:19 |
| Muntaner | alexisb, so I'm not able to choose the distro in my charm? | 15:20 |
| Muntaner | alexisb, maybe by writting my own metadatas? | 15:21 |
| natefinch | Muntaner: you definitely can create your charm for a specific distro... it just has to be a version of Ubuntu or Windows right now | 15:22 |
| marcoceppi_ | Muntaner: charm distro isn't specified by metadata.yaml, it's defined by where you push the charm to lp or to a local repo. So if you create ~/charms/win2012r2/charm-name then juju deploy --repository ~/charms local:win2012r2/charm-name Juju will attempt to create a VM with Windows Server 2012r2 | 15:26 |
| marcoceppi_ | Muntaner: but that series, which defines distro (trusty, precise, win2012r2, etc) | 15:26 |
| mup | Bug #1436390 was opened: GCE provider config should support extracting auth info from JSON file <gce-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1436390> | 15:27 |
| mup | Bug #1436397 was opened: map-order sensitive test in md/juju/storage needs to be fixed <map-order> <juju-core:Triaged> <juju-core 1.23:New> <https://launchpad.net/bugs/1436397> | 15:27 |
| Muntaner | marcoceppi_, there is no way that allows me to use other distros atm? | 15:27 |
| marcoceppi_ | Muntaner: no, because Juju has to know how to handle that distro and that distro needs to have an image spun up with cloudinit running. Juju is doing the machine setup so if it can't speak to that distro it won't work. | 15:28 |
| dimitern | \o/ gce is bootstrapping now | 15:29 |
| marcoceppi_ | Muntaner: We're adding support for other distros all the time though, the more distros we add support for the easier juju becomes to port to other platforms | 15:29 |
| Muntaner | marcoceppi_, where can I find a list of the usable distros? | 15:29 |
| marcoceppi_ | Muntaner: right now it's Ubuntu and Windows, with support for CentOS underway | 15:30 |
| ericsnow | sinzui: FYI, this last run of 1.23 (2482) had only 1 unit test fail :) | 15:30 |
| natefinch | Muntaner: CentOS support will be submitted pretty soon, in a matter of weeks. As for current distros, it's just Ubuntu (precise or later) and Windows... I would have ot look to see which versions of windows we support. Just the server versions for the most part, and I think 2012 or later. | 15:30 |
| sinzui | ericsnow, \0/ | 15:32 |
| aisrael | Does anyone know the status of this critical bug? https://bugs.launchpad.net/juju-deployer/+bug/1421315 | 15:34 |
| mup | Bug #1421315: subordinate service not appearing in watch output <api> <juju-gui> <oil> <regression> <juju-core:Triaged> <juju-core 1.22:Incomplete> <juju-deployer:Triaged> <https://launchpad.net/bugs/1421315> | 15:34 |
| dimitern | ericsnow, bootstrap fails now -I did 2 attempts, the first one waited for a while, then I stopped it, the second failed right away with RESOURCE_NOT_READY when trying to start the instance | 15:39 |
| ericsnow | dimitern: do you see an instances or other resources in the GCE [web] console for the project? | 15:41 |
| dimitern | probably because I'm using region europe-west1 | 15:41 |
| mattyw | folks - is there a way I can open an api connection acting as the state server in JujuConnSuite? | 15:41 |
| dimitern | ericsnow, I did see a deprecation warning for zone europe-west1-a | 15:41 |
| mattyw | ^^ seems like there must be a way - but I can't find it | 15:41 |
| dimitern | ericsnow, now I've switched to us-central1, and so far no errors, it's trying to connect with ssh | 15:42 |
| dimitern | mattyw, you need to log in as a machine with JobManageEnviron | 15:42 |
| alexisb | Muntaner, did you get your question answered? | 15:43 |
| dimitern | ericsnow, it worked this time - bootstrapping is mostly done | 15:43 |
| mattyw | dimitern, yeah, I'm trying to access an api that is looked to machines with JobManageEnviron | 15:43 |
| mattyw | dimitern, but I can't create a new machine with OpenAPIasNewMachine because I'm not allowed to start machines with that job | 15:44 |
| ericsnow | dimitern: oh good :) | 15:44 |
| dimitern | mattyw, what do you mean not allowed? you're getting an error from state.AddMachine? | 15:44 |
| mattyw | dimitern, correct | 15:45 |
| mattyw | dimitern, I can do a quick screen share if you like | 15:45 |
| Muntaner | alexisb, yes, I don't know what to do now ;( | 15:45 |
| Muntaner | I should instantiate automatically subnets with different OS | 15:45 |
| ericsnow | could I get a volunteer to work on lp:1436407? | 15:45 |
| dimitern | mattyw, hmm, let me look in a few places first | 15:46 |
| ericsnow | it's a blocker for 1.23 | 15:46 |
| Muntaner | connected between them... and I wanted to use juju bundles | 15:46 |
| dimitern | #1436407 | 15:46 |
| mup | Bug #1436407: certSuite.TestNewDefaultServer failed on vivid <ci> <juju-core:Invalid> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1436407> | 15:46 |
| alexisb | cmars, if you sill have someone available ^^ | 15:46 |
| dimitern | ericsnow, I do believe one of the patches you've reviewed should fix that - I've left a comment | 15:46 |
| ericsnow | dimitern: ah, cool | 15:47 |
| dimitern | mattyw, so is the machine you're adding the first one? | 15:47 |
| mattyw | dimitern, I tried s.OpenAPIAsNewMachine(c, state.JobManageEnviron) | 15:48 |
| ericsnow | dimitern: yep, http://reviews.vapour.ws/r/1261/ | 15:48 |
| mattyw | dimitern, but that fails because I'm not allowed | 15:48 |
| dimitern | mattyw, ok, let me have a look at your code? | 15:48 |
| dimitern | ericsnow, that's the one | 15:48 |
| voidspace | dimitern: ah, can't use worker.AssertStop as worker.Worker doesn't implement Stop | 15:49 |
| ericsnow | dimitern: thanks for remembering :) | 15:49 |
| dimitern | ericsnow, lucky catch I guess :) | 15:49 |
| voidspace | statetesting.AssertStop I mean | 15:49 |
| dimitern | voidspace, well, how about defer worker.Stop(w) then ? | 15:49 |
| voidspace | dimitern: don't need the func call around it as it's a single liner I guess | 15:51 |
| ericsnow | all, we also need someone to work on #1435974, which should be pretty simple but will involve patches to most of our repos | 15:51 |
| mup | Bug #1435974: Copyright information is not available for some files <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435974> | 15:51 |
| alexisb | cherylj, are you working anything critical?? | 15:51 |
| ericsnow | that one is needed before Ubuntu will take 1.22, so it is pretty important | 15:51 |
| alexisb | if not can you take a look at 1435974 | 15:52 |
| frankban | dimitern: what's the goal of the revision updater? is it just for juju status? | 15:57 |
| voidspace | dimitern: nope, needs wrapping | 15:59 |
| voidspace | dimitern: http://play.golang.org/p/4N_ydeMKEB | 15:59 |
| voidspace | dimitern: the *first* panic is triggered inside the defer - never get to the second | 15:59 |
| voidspace | dimitern: which is why we wrap in a function call! | 15:59 |
| dimitern | voidspace, sorry, will get back to you in a bit | 16:02 |
| voidspace | dimitern: no problem, just an interesting observation | 16:03 |
| voidspace | dimitern: I can't change the defers as you suggested | 16:03 |
| mup | Bug #1436415 was opened: vivid local template container "juju-vivid-lxc-template" did not stop' <ci> <lxc> <vivid> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1436415> | 16:03 |
| voidspace | dimitern: I made all the other changes and now one test is failing for no discernable reason [yet] | 16:03 |
| mup | Bug #1436421 was opened: juju panics after upgrade from 1.18.4 to 1.20.11 <juju-core:New> <https://launchpad.net/bugs/1436421> | 16:03 |
| voidspace | dimitern: will fix and ship | 16:03 |
| dimitern | voidspace, I guess you're not looking your PMs :) | 16:15 |
| ericsnow | dimitern: do you know if wallyworld's cert expiry patch needed to be forward-ported to master? | 16:32 |
| dimitern | ericsnow, no, I don't off hand, but check if the bug is | 16:35 |
| dimitern | ..affecting both master and 1.23 | 16:35 |
| ericsnow | dimitern: I'm pretty sure it either doesn't apply to master or was already fixed :) | 16:37 |
| ericsnow | dimitern: I'll ask wallyworld when he's around | 16:37 |
| ericsnow | dimitern: I do have a question about networking, if you have a minute | 16:37 |
| dimitern | ericsnow, shoot | 16:38 |
| ericsnow | dimitern: for the vmware provider (from alteros) it looks like the low-level API does not support managing much networking details for instances (in this case virtual machines) | 16:39 |
| dimitern | ericsnow, really? that's a bit surprising | 16:40 |
| dimitern | ericsnow, but shouldn't matter much anyway - networking features are optional | 16:40 |
| ericsnow | dimitern: so opening/closing ports and assigning internal/external IP addresses is not supported and must be handle manually | 16:40 |
| ericsnow | dimitern: I'm talking about for the core firewall functionality of a provider | 16:40 |
| ericsnow | dimitern: for supporting juju expose/unexpose | 16:41 |
| ericsnow | dimitern: though that is certainly related | 16:41 |
| dimitern | ericsnow, right, ok | 16:41 |
| ericsnow | dimitern: I'm going off the information I have about the capability of the "vSphere" API that we're using | 16:42 |
| dimitern | ericsnow, so you're saying the provider will need to do some manual steps to open/close ports on each instance | 16:42 |
| ericsnow | dimitern: so I wanted to get your thoughts on what might be the best approach to take in this situation | 16:42 |
| ericsnow | dimitern: right | 16:42 |
| ericsnow | dimitern: and to manage internal/external IP of an instance | 16:43 |
| dimitern | ericsnow, what sort of management? | 16:43 |
| ericsnow | dimitern: (just for the sake of juju's networking needs) | 16:43 |
| ericsnow | dimitern: not talking about the juju networking API | 16:43 |
| TheMue | aaargh, shitty yaml again, disliking a tab :( | 16:43 |
| dimitern | ericsnow, well, not having support for open/close port is not uncommon - the provider can just return an error | 16:45 |
| ericsnow | dimitern: so what might be the most sensible approach for the provider to manually set these things | 16:45 |
| dimitern | ericsnow, but I need to understand a bit better the issue around internal/external IPs you mention | 16:45 |
| ericsnow | dimitern: really? how does juju handle that when handling an expose call? | 16:46 |
| dimitern | ericsnow, expose triggers calling OpenPort on the environ via the firewaller | 16:46 |
| ericsnow | dimitern: right | 16:46 |
| ericsnow | dimitern: so what happens when OpenPort returns an error saying it isn't supported? | 16:47 |
| dimitern | ericsnow, the firewaller logs an error/warning and that's it | 16:48 |
| ericsnow | dimitern: but then the unit doesn't get exposed, right? | 16:49 |
| ericsnow | dimitern: that seems like a show-stopper for any provider | 16:49 |
| dimitern | ericsnow, no | 16:50 |
| dimitern | ericsnow, so first, the service is exposed or not, not its units | 16:51 |
| ericsnow | dimitern: right | 16:51 |
| dimitern | ericsnow, then, "exposed" is just a flag, it doesn't guarantee access, it declares intent | 16:51 |
| ericsnow | dimitern: got it | 16:52 |
| dimitern | ericsnow, whether a given unit is accessible after exposing the service - that's where the firewaller comes into play | 16:52 |
| dimitern | ericsnow, so if it fails to open the port - too bad; however this is not an issue for *some* providers | 16:52 |
| dimitern | ericsnow, e.g. local doesn't have (or assume) restrictive firewall rules so even without exposing a service, once it's running you can access it | 16:53 |
| dimitern | ericsnow, now, if the provider does not allow you to control access (egress/ingress), I'm not sure you can do much about it | 16:54 |
| mbruzek | wwitzel3: Can I get a review of this go code? https://github.com/mbruzek/virtualservices/blob/master/parse_endpoint.go | 16:57 |
| mup | Bug #1436407 was opened: certSuite.TestNewDefaultServer failed on vivid <ci> <juju-core:Incomplete by wallyworld> <juju-core 1.23:Fix Committed by ericsnowcurrently> <https://launchpad.net/bugs/1436407> | 16:57 |
| mbruzek | wwitzel3: https://github.com/mbruzek/virtualservices | 16:57 |
| ericsnow | dimitern: so to summarize: OpenPort/ClosePort isn't critical as long as there is still external access to the port on the instance | 17:05 |
| ericsnow | dimitern: what specifically does juju require regarding internal IP addresses? | 17:08 |
| dimitern | ericsnow, that's correct | 17:24 |
| TheMue | dimitern: any idea why bootstrapping fails with "You may want to use the 'agent-metadata-url' configuration setting to specify the tools location." even if the configuration setting is done? | 17:30 |
| === anthonyf is now known as Guest6628 | ||
| dimitern | ericsnow, sorry, got in another call | 17:49 |
| ericsnow | dimitern: no worries :) | 17:49 |
| dimitern | ericsnow, re internal IP addresses | 17:49 |
| dimitern | ericsnow, there's no special requirement - just that an instance can talk to the apiserver | 17:50 |
| dimitern | ericsnow, on its published cloud-local address | 17:50 |
| ericsnow | dimitern: k | 17:50 |
| dimitern | TheMue, have you imported the boot images? | 17:50 |
| ericsnow | dimitern: it seems like communication between charms via the cloud-local address is pretty common, so that should be a factor, right? | 17:51 |
| TheMue | dimitern: you mean "--sync-tools" into a local directory? | 17:52 |
| dimitern | ericsnow, yes, all charms inside the environment use the private address of the unit (which in turn comes from the unit's assigned machine) | 17:52 |
| dimitern | TheMue, no, I mean does your maas have any images you can see in the web ui? | 17:52 |
| ericsnow | dimitern: got it; thanks for all the clarification :) | 17:53 |
| TheMue | dimitern: yes, 14.04 and 14.10 | 17:53 |
| dimitern | ericsnow, np, I hope I was helpful :) | 17:53 |
| ericsnow | dimitern: totally | 17:53 |
| TheMue | dimitern: but I get an error when doing juju bootstrap | 17:53 |
| dimitern | TheMue, and you're bootstrapping with --upload-tools --debug? | 17:54 |
| TheMue | dimitern: so far w/o debug, will try again | 17:54 |
| dimitern | TheMue, might be helpful, yeah | 17:55 |
| TheMue | dimitern: hmm, currently not directly. but will ping you tomorrow morning | 17:56 |
| cherylj | alexisb, ericsnow, I can take bug 1435974 | 17:56 |
| mup | Bug #1435974: Copyright information is not available for some files <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435974> | 17:56 |
| dimitern | TheMue, ok, paste a dump of the bootstrap log along with it | 17:57 |
| alexisb | cherylj, thank you! | 17:57 |
| ericsnow | cherylj: awesome, thanks! | 17:57 |
| * dimitern steps out | 17:57 | |
| * TheMue too | 18:00 | |
| === kadams54 is now known as kadams54-away | ||
| ericsnow | cherylj: make sure to assign the bug to yourself and mark it as in progress | 18:24 |
| cherylj | ericsnow: done | 18:25 |
| ericsnow | cherylj: thanks :) | 18:25 |
| mup | Bug #1434437 changed: juju restore failed with "error: cannot update machines: machine update failed: ssh command failed: " <backup-restore> <maas-provider> <juju-core:Invalid> <juju-core 1.22:Incomplete by ericsnowcurrently> <https://launchpad.net/bugs/1434437> | 18:27 |
| natefinch | I think turning up logging to show DEBUG logs fixed my problem... | 18:31 |
| cherylj | ericsnow, sinzui: Just to sanity check: http://reviews.vapour.ws/r/1264/ | 18:41 |
| cherylj | I'll modify that text to reflect which license is used in the other packages. | 18:42 |
| sinzui | cherylj, perfect, and the diff shows the comedy that happened | 18:44 |
| cherylj | ah, yeah | 18:44 |
| cherylj | sinzui: should I go back in and add that one line package description too? | 18:45 |
| ericsnow | cherylj: a friendly reminder that the patch will also need to be applied to 1.22 and 1.23 :) | 18:46 |
| cherylj | ericsnow: I haven't had to apply changes to a non-master branch yet. Is there an easy way to do it? | 18:50 |
| ericsnow | cherylj: you should probably be able to just create a new pull request with a different target branch (I expect it will apply cleanly on all branches) | 18:51 |
| ericsnow | cherylj: but you *may* need to rebase your branch to the target and force-push it before the new PR will apply cleanly | 18:52 |
| cherylj | ericsnow: yeah, I think I do | 18:52 |
| ericsnow | cherylj: not the funnest dance | 18:52 |
| cherylj | hehe | 18:52 |
| ericsnow | cherylj: be sure to land it in each branch before moving on to the next branch | 18:53 |
| ericsnow | cherylj: to be honest, I think we could make this easier by null-merging older branches up the chain and then strictly forward-porting from there | 18:54 |
| ericsnow | cherylj: if I understand it right that would eliminate the need to rebase for each PR | 18:55 |
| ericsnow | cherylj: it would also mean the forward port would be accomplished by merging the older branch into the newer one (e.g. 1.22 -> 1.23 -> master) | 18:55 |
| ericsnow | cherylj: however, that isn't the state of things at the moment so you'll have to go the rebase-then-PR route :) | 18:56 |
| cherylj | ericsnow: now that you've gotten me really confused, I should just go back and do the first thing? ;) | 18:57 |
| ericsnow | cherylj: sorry, I was afraid of that :) | 18:57 |
| mup | Bug #1436495 was opened: sporadic test failure: storeManagerStateSuite.TestStateWatcher <ci> <juju-core:New> <https://launchpad.net/bugs/1436495> | 18:57 |
| ericsnow | cherylj: do what you were doing 1. land your PR against master, 2. rebase your branch against 1.23 3. force-push it 4. create a new pull requrest from your branch to 1.23 5. repeat 2-4 for 1.22 | 18:59 |
| cherylj | ericsnow: that I can do :) Thanks | 18:59 |
| ericsnow | cherylj: (and land the PR from 4 before moving on to 5) | 19:00 |
| ericsnow | cherylj: there are other ways to do this too, perhaps even simpler, but I've already muddied the waters a bit :) | 19:01 |
| cherylj | ericsnow: for a package description (from your RB comment), should I add something like "This package contains the core functionality for juju"? | 19:03 |
| ericsnow | cherylj: that sounds fine to me | 19:04 |
| ericsnow | sinzui: ^^^ | 19:04 |
| ericsnow | cmars: intermittent(?) test failure possibly related to your team's work: #1436507 | 19:06 |
| mup | Bug #1436507: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <juju-core:New> <https://launchpad.net/bugs/1436507> | 19:06 |
| cmars | ericsnow, will take a look | 19:07 |
| ericsnow | cmars: thanks | 19:07 |
| ericsnow | cmars: I'm trying to get the vivid unit tests passing in CI :) | 19:07 |
| cmars | ericsnow, it just so happens I have a vivid instance ready for action | 19:07 |
| mup | Bug #1436507 was opened: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <juju-core:New> <https://launchpad.net/bugs/1436507> | 19:10 |
| ericsnow | sinzui: looks like run-unit-tests-vivid-amd64 just passed on vivid :) | 19:12 |
| ericsnow | sinzui: on 1.23 | 19:12 |
| sinzui | ericsnow, yeah | 19:14 |
| ericsnow | sinzui: master is close (maybe just intermittent failures) | 19:15 |
| sinzui | ericsnow, I am whipping the precise aws upgrade job. I think aws + precise is experiencing unreliability this week and it is hurting the test results | 19:15 |
| ericsnow | sinzui: I've opened bugs for recent failures and noted all related bugs in #1433577 | 19:16 |
| mup | Bug #1433577: Vivid unit tests need to pass <ci> <test-failure> <vivid> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1433577> | 19:16 |
| sinzui | ericsnow, I saw :) | 19:17 |
| ericsnow | sinzui: now if only I could get the vivid deploy test to pass :( | 19:18 |
| mup | Bug #1436507 changed: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <juju-core:New> <https://launchpad.net/bugs/1436507> | 19:19 |
| === kadams54-away is now known as kadams54 | ||
| ericsnow | what changed, mup? are you just making this up? | 19:21 |
| ericsnow | natefinch: were you going to be able to give me a review on http://reviews.vapour.ws/r/1234/? | 19:22 |
| natefinch | lol: return newStorageWorker("", api, api, api, api) | 19:22 |
| ericsnow | natefinch: obviously :) | 19:23 |
| natefinch | ericsnow: yeah, sorry, got distracted by getting my HA stuff working | 19:23 |
| ericsnow | natefinch: hey, I'm okay with that | 19:23 |
| natefinch | api/converter/converter.go: needs merge | 19:27 |
| natefinch | apiserver/converter/converter.go: needs merge | 19:27 |
| natefinch | worker/converter/converter.go: needs merge | 19:27 |
| natefinch | You must edit all merge conflicts and then | 19:27 |
| natefinch | mark them as resolved using git add | 19:27 |
| natefinch | $ git mergetool | 19:27 |
| natefinch | No files need merging | 19:27 |
| natefinch | ffffff..... | 19:27 |
| mup | Bug #1436507 was opened: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <juju-core:New> <https://launchpad.net/bugs/1436507> | 19:28 |
| sinzui | ericsnow, I paused CI. I am going to restart vivid-slave-b and give it one more try with 1.23 | 19:38 |
| ericsnow | cherylj: looks like godeps (really a flaky code hosting service) is making your merge fail :( | 19:56 |
| cherylj | ericsnow: I was wondering what was causing that. Is there anything I can do other than keep retrying? | 19:57 |
| ericsnow | cherylj: I just ran godeps on my local host and it took a looooong time (and CI is less patient) | 19:57 |
| natefinch | ericsnow: weird, what host is being slow? | 19:58 |
| ericsnow | cherylj: wait for launchpad (or whoever) to speed back up | 19:58 |
| ericsnow | natefinch: not sure | 19:58 |
| ericsnow | natefinch: it wasn't clear which, though it *seemed* to correspond to gopkg.in | 19:59 |
| ericsnow | natefinch: which doesn't tell me much | 19:59 |
| ericsnow | cherylj: also, keep in mind that I enabled the reviewboard webhook on a number of our github repos the other day but not all of them | 20:10 |
| ericsnow | cherylj: so if no review request shows up it probably means there's no hook and it will have to be reviewed on github | 20:11 |
| ericsnow | cherylj: if you bump into that please let me know so I can double-check the webhook is set up right | 20:12 |
| cherylj | ericsnow: will do | 20:14 |
| cherylj | davecheney: If you could take a look today :) http://reviews.vapour.ws/r/1239/ | 20:33 |
| davecheney | cherylj: sure thing | 20:39 |
| === kadams54 is now known as kadams54-away | ||
| dpb1 | rick_h_: how do I download a bundle from the store from the command line? | 20:48 |
| rick_h_ | dpb1: curl https://api.jujucharms.com/v4/mongodb-cluster/archive/bundle.yaml ? | 20:48 |
| dpb1 | ok | 20:48 |
| rick_h_ | dpb1: though that's the new format, so you'll need a not-yet-released deployer to use it | 20:49 |
| rick_h_ | dpb1: or quickstart I think will do that | 20:49 |
| dpb1 | rick_h_: https://jujucharms.com/u/landscape/landscape-dense-maas/ | 20:49 |
| dpb1 | rick_h_: why is that preview blank? | 20:49 |
| dpb1 | rick_h_: (sorry for the rapid fire questions). :) | 20:49 |
| rick_h_ | dpb1: looking | 20:49 |
| rick_h_ | dpb1: no gui annotations for positions | 20:50 |
| rick_h_ | dpb1: we've got a todo to add a default layout algo to the svg generator | 20:50 |
| dpb1 | rick_h_: OK, I'll export something from the GUI and see if I can figure it out. Thanks, that is probably enough to go on | 20:51 |
| dpb1 | rick_h_, Makyo, I'm giving the branch a final test now, things looking much better test coverage wise. Thanks. | 20:53 |
| rick_h_ | dpb1: awesome, ty for bearing through us with it. | 20:53 |
| Makyo | dpb1, seconded, thanks a ton | 20:53 |
| rick_h_ | dpb1: big chunk of work to move forward the new bundle story and such | 20:53 |
| dpb1 | np, sorry it's taken a while, other prios came up. | 20:54 |
| rick_h_ | and hopefully we can iterate on it to smooth it out as a nice useful feature | 20:54 |
| dpb1 | rick_h_: agreed | 20:54 |
| rick_h_ | dpb1: understand, unfortunately it's not really anyone's day job :) | 20:54 |
| ericsnow | natefinch: so about that review :) | 20:54 |
| === kadams54-away is now known as kadams54 | ||
| ericsnow | cmars: did that bug end up being related to your stuff? | 21:34 |
| ericsnow | cherylj: would you mind targeting 1.22 first? It's the key one we need to get fixed first. | 21:34 |
| alexisb | cherylj, thumper, the bug cherylj is working is very time sensitive, so we will want to pass that off to another team member at eod for cherylj | 21:37 |
| cherylj | ericsnow: yes, I can do that | 21:37 |
| ericsnow | cherylj: thanks | 21:38 |
| thumper | alexisb: ack | 21:40 |
| alexisb | thumper, cherylj thank you! | 21:40 |
| cmars | ericsnow, i seriously doubt it. nothing is stable on vivid afaik on my instance | 21:42 |
| cmars | ericsnow, mongo sockets left open, all kinds of timeouts, etc. | 21:44 |
| ericsnow | cmars: lovely | 21:56 |
| cmars | ericsnow, still poking at it | 21:56 |
| ericsnow | cmars: please keep a list of everything you notice needs fixing on vivid :) | 21:57 |
| cmars | ericsnow, will do | 21:57 |
| ericsnow | cmars: thanks! | 21:57 |
| === kadams54 is now known as kadams54-away | ||
| cmars | wallyworld, could this be related to storage? what might cause this timeout? https://bugs.launchpad.net/juju-core/+bug/1436507/comments/1 | 22:09 |
| mup | Bug #1436507: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <intermittent-failure> <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1436507> | 22:09 |
| cherylj | ericsnow, sinzui: For the juju/cmd case, there is an exception to the license noted, so I just added the copyright information and left the rest of the LICENSE file intact: http://reviews.vapour.ws/r/1269/ | 22:12 |
| ericsnow | cherylj: sounds good | 22:13 |
| cherylj | ericsnow: can you merge the juju/cmd PR? | 22:13 |
| ericsnow | cherylj: sure | 22:13 |
| cherylj | thanks | 22:13 |
| wallyworld | cmars: not the new storage feature - the storage in the error is the environment blob store where charms and tools are saved (instead of cloud storage) | 22:14 |
| cmars | wallyworld, ok, got it | 22:14 |
| wallyworld | cmars: for whatever reason, the mongo db used for that storage became disconnected - i/o timeout | 22:14 |
| wallyworld | it attempts to rollbacl failed operations, but the rollback failed too | 22:15 |
| cmars | wallyworld, ah, that's *very* consistent with other errors i'm seeing | 22:15 |
| cmars | wallyworld, i'm running mgo tests now | 22:15 |
| ericsnow | cherylj: did you try adding a merge comment? the landing bot was added to a number of repos recently and I believe cmd is one of them | 22:15 |
| wallyworld | cmars: maybe on a busy system things can't keep up? not sure | 22:16 |
| wallyworld | but for whatever reason, juju->mongo is not happy | 22:16 |
| cmars | so i decided to run mgo.v2's tests. http://paste.ubuntu.com/10680888/ | 22:18 |
| cmars | this is on canonistack. i'll try a kvm locally for a second opinion | 22:19 |
| ericsnow | cmars: yikes | 22:36 |
| cmars | ericsnow, that might be a red herring.. i get the same error on trusty | 22:41 |
| cmars | ericsnow, which is a different sort of yikes | 22:42 |
| ericsnow | cmars: :) | 22:42 |
| ericsnow | cmars: at least that package isn't important to juju <wink> | 22:42 |
| cmars | yeah, i mean, close enough, right? http://paste.ubuntu.com/10680988/ | 22:45 |
| cmars | that's an mgo.v2/txn test, which I just ran on trusty | 22:46 |
| ericsnow | cmars: bank error *not* in your favor :) | 22:47 |
| cmars | ericsnow, just curious, does the vivid torrent work for you? i'm getting a tracker error | 22:52 |
| cmars | ericsnow, http://cdimage.ubuntu.com/ubuntu-gnome/releases/vivid/alpha-1/ | 22:53 |
| cmars | oh, i should probably get beta-1 | 22:53 |
| cmars | nevermind | 22:53 |
| ericsnow | cmars: don't know | 22:53 |
| cmars | beta-1 works | 22:53 |
| ericsnow | cmars: lesson learned :) | 23:00 |
| cherylj | ericsnow: no, I hadn't, the last time I made changes to cmd it was still a manual merge repo | 23:05 |
| ericsnow | cherylj: well, I tried it and nothing happened :) | 23:05 |
| cherylj | ericsnow: I also see that charm doesn't trigger RB | 23:05 |
| ericsnow | cherylj: charm is one for which I did not add the hook | 23:05 |
| ericsnow | cherylj: I'll push the merge button on cmd | 23:06 |
| cherylj | ericsnow: thanks :) | 23:06 |
| cherylj | Can you also review the 1.22 change? http://reviews.vapour.ws/r/1268/ | 23:06 |
| ericsnow | cherylj: be sure to target 1.22 with your PRs (you have to manually change the target brach from master) | 23:07 |
| ericsnow | cherylj: you bet | 23:07 |
| ericsnow | cherylj: I see you're a step ahead of me :) | 23:07 |
| cherylj | hehe :) It took me a little bit of time to figure out how to actually do the changes / PR for 1.22 | 23:08 |
| cherylj | I haven't contributed to most of these repos before, so I have to so all the initial steps to get things set up first | 23:10 |
| ericsnow | cherylj: sorry about that; I really appreciate that you are working on this :) | 23:25 |
| cherylj | ericsnow: It's no problem at all. | 23:26 |
| davecheney | alexisb: oh shit, sorry i'm late | 23:35 |
| alexisb | davecheney, nws | 23:35 |
| alexisb | I am on the hangout when you are ready | 23:35 |
| davecheney | alexisb: jumping in the hangout now | 23:35 |
| axw | wallyworld: can you please create github.com/juju/replicaset when you have a moment. I can't do that, but I'll do the rest | 23:47 |
| wallyworld | sure | 23:48 |
| wallyworld | axw: mongo-replicaset perhaps? | 23:48 |
| wallyworld | or is that too wordy | 23:48 |
| wallyworld | or tautological | 23:49 |
| axw | I'd rather just go with replicaset as that's what it's called now, we can rename it later if we need to | 23:49 |
| axw | wallyworld: ^ | 23:50 |
| wallyworld | ok, i was thinking replicaset on its own was ambiguous | 23:50 |
| wallyworld | but we can rename if needed | 23:50 |
| wallyworld | axw: that's done, i've also added the bots as collaborators so we can automate landings if needed | 23:54 |
| wallyworld | s/automate/gate | 23:54 |
| axw | wallyworld: thanks | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!