/srv/irclogs.ubuntu.com/2015/12/02/#juju-dev.txt

menn0davechen1y: np00:17
mupBug #1519190 changed: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190>00:48
mupBug #1519190 opened: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190>00:54
mupBug #1519190 changed: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190>01:06
mupBug #1519190 opened: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190>01:09
mupBug #1519190 changed: worker/addresser: FAIL: worker_test.go:260: workerEnabledSuite.TestWorkerAcceptsBrokenRelease <juju-core:Opinion> <https://launchpad.net/bugs/1519190>01:12
davechen1ythumper: it feels like the fslock debate is crawling towards stalemate01:24
davechen1ythumper: what do you want to see from the discussion ?01:26
thumpersorry davechen1y, head down with a customer fire right now01:27
davechen1yaxw: http://reviews.vapour.ws/r/3238/01:35
davechen1ycan you please review my last comment01:35
davechen1ythumper: my condolences01:35
axwdavechen1y: looking01:35
axwdavechen1y: I'm not really sure what you mean by that. It's valid for "createAliveLock" to be entered twice01:36
axwdavechen1y: (just not concurrently)01:36
davechen1yaxw: createAliveFile starts a goroutine who's job is to scrobble in some state file01:41
davechen1ythe stanity check fials because that goroutine is being started more than once01:41
davechen1ythis is why the original data race existed01:41
davechen1yand I think the bug is still here, which wasn't the data race, that was just a side effect01:41
axwdavechen1y: no, before you could have two of those goroutines running at the same time. now you cannot, because of the wait group01:42
davechen1yaxw: i don't believ that is true01:42
davechen1ysee the sanity check01:42
davechen1ywhy is createAliveFile being entered more than once01:43
davechen1ywhy is createAliveFile being entered more than once ?01:43
axwdavechen1y: the sanity check shows that it was entered more than once, not that they were both in there at the same time01:43
axwdavechen1y: if you close a channel twice, sequentially, it still panics01:44
davechen1yyes01:44
davechen1yaxw: ok, so I should be able to fix the sanityCheck by creating a new sanityCheck channel in Unlock ?01:45
axwdavechen1y: yep, that would make sense: recreate channel before removing the file01:46
axwdirectory, whatever01:46
davechen1yi think Unlock is the right place to refresh the sanity check01:46
davechen1yi'm testing that now01:46
davechen1yi don't trust this code01:47
davechen1yi wnt tripple underpants on it01:47
cheryljthumper: 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
thumpercherylj: there are two problems here03:13
thumperone is getting a version out for 1.25 that'll work03:13
thumperpeople with 1.26 will have a 2.0 client to upgrade03:13
thumperso we need to make sure it lands in master too03:13
thumperyes I think 1.26 alpha/beta would be fine for 2.0 upgrades03:13
cheryljthumper: sounds good.    I also updated the check to actually query the AgentVersion, not just version.Current03:14
cheryljthere 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
cheryljwell, not automatic.  Just never select it when upgrading a 1.25 env, unless explicitly specified03:16
thumperoh ffs03:32
thumpermenn0: you around still?03:32
thumperI have questions03:32
thumperugh03:33
axwwallyworld: I think we need to get rid of the short-circuit removal of relations involving remote services. unless they're not registered03:33
* thumper headdesks03:33
axwwallyworld: otherwise I don't think we can guarantee they'll be unregistered03:33
axwwallyworld: so Destroy should just mark them Dead, and then the worker will see that, unregister, then remove03:34
wallyworldaxw: sounds reasonable at first glance03:34
menn0thumper: still here03:43
thumpermenn0: https://github.com/howbazaar/juju-121-upgrades03:43
thumpermenn0: and a quick hangout?03:43
thumpermenn0: 1:1 hangout?03:43
menn0thumper: ok03:43
davechen1ylucky(~/src/github.com/juju/juju) % ls /tmp03:51
davechen1ycheck-5577006791947779410  hugo_cache          juju-tools295324784  juju-tools-released484109868  test-mgo61159086203:51
davechen1yconfig-err-g4oT3p          juju-exec001679756  juju-tools327758394  juju-tools-released817795995  test-mgo99854247303:51
davechen1ydeps.svg                   juju-exec158644967  juju-tools689131141  t                             tmux-100003:51
davechen1yfileNq80up                 juju-exec845043821  juju-tools849695094  test-mgo169368628             unity_support_test.003:51
davechen1yhsperfdata_root            juju-exec855581256  juju-tools891530041  test-mgo56260803303:51
davechen1yhere are all the things juju leaks per test run03:51
davechen1y:(03:51
mupBug #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 alcohol04:31
wallyworldaxw: when you have time, ptal http://reviews.vapour.ws/r/3291/07:14
axwwallyworld: sure07:14
wallyworldta07:14
menn0fwereade: ping07:38
dimiterndooferlad, frobware, jam, fwereade, morning :) reviews on http://reviews.vapour.ws/r/3285/ will be appreciated08:03
frobwaredimitern, looking08:04
dimiternfrobware, ta!08:05
menn0fwereade: when you have a chance, here's 32 pages of diffs :) http://reviews.vapour.ws/r/3292/08:06
menn0fwereade: seriously though, see your email08:06
frobwaredimitern, what's the [1:] for on the noDevicesWarning string?08:15
dimiternfrobware, so that it doesn't start with a \n08:16
dimiternfrobware, thanks for the review09:04
fwereadekatco, 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
frobwaredimitern, I reopened http://reviews.vapour.ws/r/3285/ as I found a go vet error.12:25
mupBug #1522001 opened: worker/instancepoller: intermittent data race <juju-core:New> <https://launchpad.net/bugs/1522001>12:26
dimiternfrobware, yeah, I caught this while forward porting12:30
dimiternfrobware, it will be fixed in master, and I'll propose a 1.25 fix12:30
frobwaredimitern, thx. I noticed as I rebased to push my chances.12:30
perrito666bbl12:30
mupBug #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
mupBug #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
mupBug #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
mupBug #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
mupBug #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
mupBug #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
dooferladdimitern/frobware/voidspace: PTAL: http://reviews.vapour.ws/r/3294/14:55
mupBug #1520380 changed: worker/provisioner: unit tests fail on xenial <juju-core:Fix Released> <https://launchpad.net/bugs/1520380>15:14
frobwaredimitern, dooferlad, voidspace: PTAL @ http://reviews.vapour.ws/r/3298/15:26
=== JoseeAntonioR is now known as jose
dimiternalexisb, hey16:09
mupBug #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
mupBug #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
frobwaredimitern, voidspace, dooferlad: PTAL @ http://reviews.vapour.ws/r/3300/17:01
=== jose is now known as Guest78115
mgzabentley: 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 merging17:11
abentleymgz: My changes to assess_jes_deploy landed on Monday, IIRC.17:12
mgzdid you run the thingy as well? maybe they didn't conflict and I actually need to make a working branch for 'em then17:13
voidspacefrobware: looking17:17
voidspacefrobware: the new api is *almost* the same as the existing facade, but annoyingly needs space provider ids not names17:17
voidspacefrobware: and it seems that creating a new facade is probably easier than versioning the existing one and adding the extra info...17:17
voidspacefrobware: if that's just a forward port of your previous branch then LGTM17:18
perrito666bbl17:53
natefinchwwitzel3: I pressume you're making the upload API client something like Upload(service, name string, resource io.Reader) error ?19:40
katconatefinch: why not keep it decoupled? specify the interface you expect and we can adapt w/e wwitzel3 makes to that interface19:41
natefinchkatco: 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
wwitzel3natefinch: 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, blob19:45
katconatefinch: 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 adapter19:45
natefinchkatco: 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 code19:49
katconatefinch: agreed for order, but not arity19:50
davecheneyquick review please ? https://github.com/juju/juju/pull/388219:53
katcodavecheney: lgtm19:59
davecheneykatco: ta!20:03
=== rharper` is now known as rharper
menn0sinzui, 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
menn0what's that about?20:18
menn0abentley too: ^^20:18
mgzmenn0: it needs master merged to get new version20:19
mgzmenn0: read http://reports.vapour.ws/releases/338020:19
abentleymenn0: Build-revision isn't completing successfully, because it hasn't been updated to a new version.20:19
menn0mgz, abentley: I merged master into the feature branch last night. so it should work next attempt?20:20
mgzyup, at least that initial step20:21
abentleymenn0: Yes.  If the version in the code is now greater than 1.26-alpha2.20:21
menn0mgz, abentley: it should be. it was master from yesterday.20:22
menn0mgz, abentley: Thanks for explaining. I didn't know we had that guard, but it makes sense now that I think about it.20:22
sinzuiabentley: 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
abentleysinzui: ack.20:47
perrito666katco: is that kb plastic or rubber?21:39
katcoperrito666: plastic i think21:42
niedbalskithumper, ping22:12
thumperniedbalski: hey22:15
thumperniedbalski: I'm downloading the files to my laptop now22:16
thumperniedbalski: although the current logs show more problems than just the db bits22:16
thumperwhich sucks22:16
sinzuidavecheney: 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 again23:02
katcosinzui: davecheney: the race flag will only fail tests if it experiences the race, correct?23:03
sinzuikatco: In my experience, a failure of a test, or a panic will fail the test23:04
katcosinzui: 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 understanding23:07
sinzuikatco: 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 races23:09
katcosinzui: 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
sinzuikatco: yeah.23:10
katcosinzui: i.e. the test may not stabalize for a long while23:10
mwhudsondavecheney: do you remember what the difference between GOARM=6 and GOARM=7 is?23:13
davecheneyhttps://github.com/juju/juju/pull/388623:14
davecheneyanyone23:14
davecheneymwhudson: the extra 8 floating point regs in VPFv323:14
davecheneywhat do you they call it, D16 or something23:14
mwhudsonoh right23:15
davecheneygo defaults to goarm=623:15
davecheneythat is the right hoice23:15
davecheneychoice23:15
mwhudsonok23:15
mwhudsonit's what ubuntu builds with too for armhf, apparently23:15
davecheneyarmv6 vs v7 makes a huge difference in kernel space 'cos the cache model is completely different23:15
mwhudsonsounds like that's ok?23:15
davecheneyin user space, bugger all difference23:15
mwhudsonk23:15
davecheneyyes, that is the best choice23:15
mwhudsonthanks23:16
davecheneyhttps://github.com/juju/juju/pull/388623:42
davecheneyanyone, pleaes23:42

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!