| menn0 | davechen1y: np | 00:17 |
|---|---|---|
| mup | Bug #1519190 changed: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190> | 00:48 |
| mup | Bug #1519190 opened: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190> | 00:54 |
| mup | Bug #1519190 changed: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190> | 01:06 |
| mup | Bug #1519190 opened: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190> | 01:09 |
| mup | Bug #1519190 changed: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190> | 01:12 |
| davechen1y | thumper: it feels like the fslock debate is crawling towards stalemate | 01:24 |
| davechen1y | thumper: what do you want to see from the discussion ? | 01:26 |
| thumper | sorry davechen1y, head down with a customer fire right now | 01:27 |
| davechen1y | axw: http://reviews.vapour.ws/r/3238/ | 01:35 |
| davechen1y | can you please review my last comment | 01:35 |
| davechen1y | thumper: my condolences | 01:35 |
| axw | davechen1y: looking | 01:35 |
| axw | davechen1y: I'm not really sure what you mean by that. It's valid for "createAliveLock" to be entered twice | 01:36 |
| axw | davechen1y: (just not concurrently) | 01:36 |
| davechen1y | axw: createAliveFile starts a goroutine who's job is to scrobble in some state file | 01:41 |
| davechen1y | the stanity check fials because that goroutine is being started more than once | 01:41 |
| davechen1y | this is why the original data race existed | 01:41 |
| davechen1y | and I think the bug is still here, which wasn't the data race, that was just a side effect | 01:41 |
| axw | davechen1y: no, before you could have two of those goroutines running at the same time. now you cannot, because of the wait group | 01:42 |
| davechen1y | axw: i don't believ that is true | 01:42 |
| davechen1y | see the sanity check | 01:42 |
| davechen1y | why is createAliveFile being entered more than once | 01:43 |
| davechen1y | why is createAliveFile being entered more than once ? | 01:43 |
| axw | davechen1y: the sanity check shows that it was entered more than once, not that they were both in there at the same time | 01:43 |
| axw | davechen1y: if you close a channel twice, sequentially, it still panics | 01:44 |
| davechen1y | yes | 01:44 |
| davechen1y | axw: ok, so I should be able to fix the sanityCheck by creating a new sanityCheck channel in Unlock ? | 01:45 |
| axw | davechen1y: yep, that would make sense: recreate channel before removing the file | 01:46 |
| axw | directory, whatever | 01:46 |
| davechen1y | i think Unlock is the right place to refresh the sanity check | 01:46 |
| davechen1y | i'm testing that now | 01:46 |
| davechen1y | i don't trust this code | 01:47 |
| davechen1y | i wnt tripple underpants on it | 01:47 |
| cherylj | thumper: for allowing 2.0 upgrades, should I also allow people who've installed a 1.26 alpha to upgrade? or are we just going to assume they need to destroy the env and bootstrap with 2.0? | 03:12 |
| thumper | cherylj: there are two problems here | 03:13 |
| thumper | one is getting a version out for 1.25 that'll work | 03:13 |
| thumper | people with 1.26 will have a 2.0 client to upgrade | 03:13 |
| thumper | so we need to make sure it lands in master too | 03:13 |
| thumper | yes I think 1.26 alpha/beta would be fine for 2.0 upgrades | 03:13 |
| cherylj | thumper: sounds good. I also updated the check to actually query the AgentVersion, not just version.Current | 03:14 |
| cherylj | there will probably be a follow on change to show users that a 2.0 upgrade is available, but never select it for an automatic upgrade. | 03:15 |
| cherylj | well, not automatic. Just never select it when upgrading a 1.25 env, unless explicitly specified | 03:16 |
| thumper | oh ffs | 03:32 |
| thumper | menn0: you around still? | 03:32 |
| thumper | I have questions | 03:32 |
| thumper | ugh | 03:33 |
| axw | wallyworld: I think we need to get rid of the short-circuit removal of relations involving remote services. unless they're not registered | 03:33 |
| * thumper headdesks | 03:33 | |
| axw | wallyworld: otherwise I don't think we can guarantee they'll be unregistered | 03:33 |
| axw | wallyworld: so Destroy should just mark them Dead, and then the worker will see that, unregister, then remove | 03:34 |
| wallyworld | axw: sounds reasonable at first glance | 03:34 |
| menn0 | thumper: still here | 03:43 |
| thumper | menn0: https://github.com/howbazaar/juju-121-upgrades | 03:43 |
| thumper | menn0: and a quick hangout? | 03:43 |
| thumper | menn0: 1:1 hangout? | 03:43 |
| menn0 | thumper: ok | 03:43 |
| davechen1y | lucky(~/src/github.com/juju/juju) % ls /tmp | 03:51 |
| davechen1y | check-5577006791947779410 hugo_cache juju-tools295324784 juju-tools-released484109868 test-mgo611590862 | 03:51 |
| davechen1y | config-err-g4oT3p juju-exec001679756 juju-tools327758394 juju-tools-released817795995 test-mgo998542473 | 03:51 |
| davechen1y | deps.svg juju-exec158644967 juju-tools689131141 t tmux-1000 | 03:51 |
| davechen1y | fileNq80up juju-exec845043821 juju-tools849695094 test-mgo169368628 unity_support_test.0 | 03:51 |
| davechen1y | hsperfdata_root juju-exec855581256 juju-tools891530041 test-mgo562608033 | 03:51 |
| davechen1y | here are all the things juju leaks per test run | 03:51 |
| davechen1y | :( | 03:51 |
| mup | Bug #1501490 changed: juju-local can't bootstrap as root user <bootstrap> <lxd> <juju-core:Expired> <https://launchpad.net/bugs/1501490> | 04:28 |
| * thumper heads for the alcohol | 04:31 | |
| wallyworld | axw: when you have time, ptal http://reviews.vapour.ws/r/3291/ | 07:14 |
| axw | wallyworld: sure | 07:14 |
| wallyworld | ta | 07:14 |
| menn0 | fwereade: ping | 07:38 |
| dimitern | dooferlad, frobware, jam, fwereade, morning :) reviews on http://reviews.vapour.ws/r/3285/ will be appreciated | 08:03 |
| frobware | dimitern, looking | 08:04 |
| dimitern | frobware, ta! | 08:05 |
| menn0 | fwereade: when you have a chance, here's 32 pages of diffs :) http://reviews.vapour.ws/r/3292/ | 08:06 |
| menn0 | fwereade: seriously though, see your email | 08:06 |
| frobware | dimitern, what's the [1:] for on the noDevicesWarning string? | 08:15 |
| dimitern | frobware, so that it doesn't start with a \n | 08:16 |
| dimitern | frobware, thanks for the review | 09:04 |
| fwereade | katco, ericsnow, wwitzel3: in merging master into machine-dep-engine, it looks like component bits have leaked into worker/meterstatus and uniter.Paths; was this intentional? | 12:08 |
| frobware | dimitern, I reopened http://reviews.vapour.ws/r/3285/ as I found a go vet error. | 12:25 |
| mup | Bug #1522001 opened: worker/instancepoller: intermittent data race <juju-core:New> <https://launchpad.net/bugs/1522001> | 12:26 |
| dimitern | frobware, yeah, I caught this while forward porting | 12:30 |
| dimitern | frobware, it will be fixed in master, and I'll propose a 1.25 fix | 12:30 |
| frobware | dimitern, thx. I noticed as I rebased to push my chances. | 12:30 |
| perrito666 | bbl | 12:30 |
| mup | Bug #1522025 opened: juju upgrade-juju should confirm it has enough disk space to complete <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1522025> | 13:44 |
| mup | Bug #1522025 changed: juju upgrade-juju should confirm it has enough disk space to complete <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1522025> | 13:50 |
| mup | Bug #1522025 opened: juju upgrade-juju should confirm it has enough disk space to complete <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1522025> | 13:56 |
| mup | Bug #1519527 changed: juju 1.25.1: lxc units all have the same IP address - changed to claim_sticky_ip_address <openstack> <sts> <uosci> <MAAS:Triaged by mpontillo> <MAAS 1.9:Triaged by mpontillo> <MAAS trunk:Triaged by mpontillo> <https://launchpad.net/bugs/1519527> | 14:32 |
| mup | Bug #1519527 opened: juju 1.25.1: lxc units all have the same IP address - changed to claim_sticky_ip_address <openstack> <sts> <uosci> <MAAS:Triaged by mpontillo> <MAAS 1.9:Triaged by mpontillo> <MAAS trunk:Triaged by mpontillo> <https://launchpad.net/bugs/1519527> | 14:38 |
| mup | Bug #1519527 changed: juju 1.25.1: lxc units all have the same IP address - changed to claim_sticky_ip_address <openstack> <sts> <uosci> <MAAS:Triaged by mpontillo> <MAAS 1.9:Triaged by mpontillo> <MAAS trunk:Triaged by mpontillo> <https://launchpad.net/bugs/1519527> | 14:44 |
| dooferlad | dimitern/frobware/voidspace: PTAL: http://reviews.vapour.ws/r/3294/ | 14:55 |
| mup | Bug #1520380 changed: worker/provisioner: unit tests fail on xenial <juju-core:Fix Released> <https://launchpad.net/bugs/1520380> | 15:14 |
| frobware | dimitern, dooferlad, voidspace: PTAL @ http://reviews.vapour.ws/r/3298/ | 15:26 |
| === JoseeAntonioR is now known as jose | ||
| dimitern | alexisb, hey | 16:09 |
| mup | Bug #1511138 opened: Bootstrap with the vSphere provider fails to log into the virtual machine <bootstrap> <cloud-init> <vsphere> <juju-core:Fix Committed by s-matyukevich> <juju-core 1.25:Fix Released> <https://launchpad.net/bugs/1511138> | 16:35 |
| mup | Bug #1513982 opened: Juju can't find daily image streams from cloud-images.ubuntu.com/daily <streams> <juju-core:Fix Committed by s-matyukevich> <juju-core 1.25:Fix Released by s-matyukevich> <https://launchpad.net/bugs/1513982> | 16:35 |
| === frobware_ is now known as frobware | ||
| frobware | dimitern, voidspace, dooferlad: PTAL @ http://reviews.vapour.ws/r/3300/ | 17:01 |
| === jose is now known as Guest78115 | ||
| mgz | abentley: I have some hacks in assess_jes_deploy.py on master to add logging, I believe your changes should obselete this, but be aware on merging | 17:11 |
| abentley | mgz: My changes to assess_jes_deploy landed on Monday, IIRC. | 17:12 |
| mgz | did you run the thingy as well? maybe they didn't conflict and I actually need to make a working branch for 'em then | 17:13 |
| voidspace | frobware: looking | 17:17 |
| voidspace | frobware: the new api is *almost* the same as the existing facade, but annoyingly needs space provider ids not names | 17:17 |
| voidspace | frobware: and it seems that creating a new facade is probably easier than versioning the existing one and adding the extra info... | 17:17 |
| voidspace | frobware: if that's just a forward port of your previous branch then LGTM | 17:18 |
| perrito666 | bbl | 17:53 |
| natefinch | wwitzel3: I pressume you're making the upload API client something like Upload(service, name string, resource io.Reader) error ? | 19:40 |
| katco | natefinch: why not keep it decoupled? specify the interface you expect and we can adapt w/e wwitzel3 makes to that interface | 19:41 |
| natefinch | katco: I figure we might as well start off with a perfect match if there's no reason not to... if we later need an adapter, we can always do that, but not even trying to make them the same seems like it just adds unnecessary complexity to the code. I'd be looking at the code wondering why the two interfaces were different, and the answer would be ¯\_(ツ)_/¯ | 19:44 |
| wwitzel3 | natefinch: the answer would be because they don't need to be the same? but yes, they are passed in, in the order of the command in the spec. Service, name, blob | 19:45 |
| katco | natefinch: the reason to take in a func or interface is to guard against changes in the future; if the api layers change, your code doesn't have to. only the adapter | 19:45 |
| natefinch | katco: yeah, I was going to take an interface... just might as well make the interface match to start with. If I see someone's written an adapter, and all the adapter does is change the order of the arguments, I'm gonna be annoyed that I had to go read that code | 19:49 |
| katco | natefinch: agreed for order, but not arity | 19:50 |
| davecheney | quick review please ? https://github.com/juju/juju/pull/3882 | 19:53 |
| katco | davecheney: lgtm | 19:59 |
| davecheney | katco: ta! | 20:03 |
| === rharper` is now known as rharper | ||
| menn0 | sinzui, mgz: the machine-dep-engine feature branch CI runs are never actually happening. it's always "Blocked by parallel-streams-publish-aws, build-binary-vivid-amd64, build-revision" | 20:18 |
| menn0 | what's that about? | 20:18 |
| menn0 | abentley too: ^^ | 20:18 |
| mgz | menn0: it needs master merged to get new version | 20:19 |
| mgz | menn0: read http://reports.vapour.ws/releases/3380 | 20:19 |
| abentley | menn0: Build-revision isn't completing successfully, because it hasn't been updated to a new version. | 20:19 |
| menn0 | mgz, abentley: I merged master into the feature branch last night. so it should work next attempt? | 20:20 |
| mgz | yup, at least that initial step | 20:21 |
| abentley | menn0: Yes. If the version in the code is now greater than 1.26-alpha2. | 20:21 |
| menn0 | mgz, abentley: it should be. it was master from yesterday. | 20:22 |
| menn0 | mgz, abentley: Thanks for explaining. I didn't know we had that guard, but it makes sense now that I think about it. | 20:22 |
| sinzui | abentley: I thnk you fell off #juju. To catch you. Up we lost access to HP. I we now have access back, in the meantime. I started to move the last machines from their. I quickstart still sucks. I have a hack in place to use gce. I quadrupled our cpus in gce to deploy landscape tests there. | 20:47 |
| abentley | sinzui: ack. | 20:47 |
| perrito666 | katco: is that kb plastic or rubber? | 21:39 |
| katco | perrito666: plastic i think | 21:42 |
| niedbalski | thumper, ping | 22:12 |
| thumper | niedbalski: hey | 22:15 |
| thumper | niedbalski: I'm downloading the files to my laptop now | 22:16 |
| thumper | niedbalski: although the current logs show more problems than just the db bits | 22:16 |
| thumper | which sucks | 22:16 |
| sinzui | davecheney: I have mixed news. the run-unit-tests-race is now on the new machine and can complete in less than 40 minutes. I think the new speed or the new host has uncovered errors. CI is retesting now. I may make the job non-voting until we get the test stable again | 23:02 |
| katco | sinzui: davecheney: the race flag will only fail tests if it experiences the race, correct? | 23:03 |
| sinzui | katco: In my experience, a failure of a test, or a panic will fail the test | 23:04 |
| katco | sinzui: right, but the test won't fail if it contains a race condition unless that rc is triggered... even with the -race flag. at least that's my understanding | 23:07 |
| sinzui | katco: if go test returns an exit code greater than 0 it will fail. That previous run failed because of panics and fails, I don't see a report of races | 23:09 |
| katco | sinzui: right, i understand what you're saying. what i'm trying to add is that i think whether the tests fail because of races is as non-deterministic as the races themselves. so you may see wildly variable results. | 23:10 |
| sinzui | katco: yeah. | 23:10 |
| katco | sinzui: i.e. the test may not stabalize for a long while | 23:10 |
| mwhudson | davecheney: do you remember what the difference between GOARM=6 and GOARM=7 is? | 23:13 |
| davecheney | https://github.com/juju/juju/pull/3886 | 23:14 |
| davecheney | anyone | 23:14 |
| davecheney | mwhudson: the extra 8 floating point regs in VPFv3 | 23:14 |
| davecheney | what do you they call it, D16 or something | 23:14 |
| mwhudson | oh right | 23:15 |
| davecheney | go defaults to goarm=6 | 23:15 |
| davecheney | that is the right hoice | 23:15 |
| davecheney | choice | 23:15 |
| mwhudson | ok | 23:15 |
| mwhudson | it's what ubuntu builds with too for armhf, apparently | 23:15 |
| davecheney | armv6 vs v7 makes a huge difference in kernel space 'cos the cache model is completely different | 23:15 |
| mwhudson | sounds like that's ok? | 23:15 |
| davecheney | in user space, bugger all difference | 23:15 |
| mwhudson | k | 23:15 |
| davecheney | yes, that is the best choice | 23:15 |
| mwhudson | thanks | 23:16 |
| davecheney | https://github.com/juju/juju/pull/3886 | 23:42 |
| davecheney | anyone, pleaes | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!