/srv/irclogs.ubuntu.com/2015/09/25/#juju-dev.txt

perrito666thumper: I could kiss you .... and also kill you00:00
axwanastasiamac: when you're back, could you please review http://reviews.vapour.ws/r/2736/ for me?01:13
mupBug #1499570 opened:  public no address <backup-restore> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1499570>01:22
mupBug #1499571 opened: Restore failed: error fetching address <backup-restore> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1499571>01:22
anastasiamacaxw: looking :D01:26
anastasiamacaxw: lgtm :)01:30
axwanastasiamac: thanks01:30
mupBug #1499570 changed:  public no address <backup-restore> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1499570>01:34
mupBug #1499571 changed: Restore failed: error fetching address <backup-restore> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1499571>01:34
mupBug #1499570 opened:  public no address <backup-restore> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1499570>01:43
mupBug #1499571 opened: Restore failed: error fetching address <backup-restore> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1499571>01:43
mupBug #1499573 opened: TestString failed on windows <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core feature-proc-mgmt:Triaged> <https://launchpad.net/bugs/1499573>01:52
cheryljis there anyone around who's familiar with envworkermanager?02:10
thumperdavecheney: you have multiple versions of go handy right?02:33
thumperI was testing a bug backport to 1.2202:34
thumperbut golang 1.5 really doesn't seem to like it, even with GOMAXPROCS=102:34
thumperI was wondering if I could get you to see if you can get the tests to pass with a different version02:35
thumperhttps://github.com/howbazaar/juju/tree/ignore-machine-addresses-1.2202:36
anastasiamacaxw: series from version translation in utils :D PTAL if u have a chance http://reviews.vapour.ws/r/2751/03:04
axwanastasiamac: before I review, can you show me where you need it? since we've not needed until now...03:06
anastasiamacaxw: sure, in https://github.com/juju/juju/blob/master/apiserver/imagemetadata/metadata.go#L21003:08
anastasiamacin files, image metadata has versions03:08
anastasiamacbut we are storing series in structured image metadata03:08
anastasiamachence we need a translation03:09
anastasiamacapiserver is the first place... another place will be03:09
anastasiamacwhen we are caching cutom images03:09
anastasiamacsince this is clearly a util, it should belong in centralasied, logical location not apiserver where i have originally implemented it03:10
anastasiamacin addition, it's counter-intuitive that we can go one way and not the othe... i guess the need did not arise until now03:10
thumperaxw: cheers for finding the service config problem, how'd you identify the issue?03:56
axwthumper: nps. I looked through the commits listed as suspects, and that was the only likely candidate. then I repro'd exactly as described in the bug (took me a few goes because I picked the wrong bundle to start with)03:57
thumperaxw or anastasiamac: I'm after a favour from someone05:12
anastasiamacthumper: on firday avo?05:12
thumperI need someone with an earlier golang to run the unit tests for a 1.22 potential fix05:12
thumpergolang 1.5.1 hates 1.2205:12
thumperanastasiamac: yeah, it is pretty easy though05:13
thumperI have this https://github.com/howbazaar/juju/tree/ignore-machine-addresses-1.2205:15
thumperwhich I think isolates and backports a 1.24 fix into the 1.22 branch05:15
thumperbut I can't run the tests here successfully05:15
thumpernot at all05:15
thumperI even tried to downgrade golang, but then go failed for other reasons05:15
thumperand I couldn't get it working05:15
thumperand at the end of friday, I'm losing the will05:15
anastasiamacthumper: :( i know the feeling - it being friday and all...05:16
axwthumper: I'll give it a shot05:16
thumperaxw: ta05:16
thumperso if you start from a fresh 1.2205:17
axwthumper: any particular tests?05:17
thumperand pull in that branch05:17
axwmk05:17
thumperaxw: no, just all of them :)05:17
thumperit touches a few places05:17
thumpermachiner worker05:17
thumperstate05:17
thumperand apiserver05:17
thumpercould probably get away with: api, apiserver, cmd/jujud, state, worker/machiner05:17
thumperif you wanted to limit it05:17
axwthumper: apiserver is happy. I'll run the lot and let you know05:20
thumperI've never been so tempted to spend 2.5kUSD https://glowforge.com05:21
thumperaxw: ta05:21
thumperaxw: what would the differences be in the binary created between me compiling with golang 1.5.1 and what you are using (which I'm assuming is an earlier one) ?05:23
thumperI know that golang 1.5 changed the default GOMAXPROCS05:23
thumperbut does that impact the binary created?05:23
axwthumper: yes, the runtime is linked in statically. I'm using 1.4.2.05:24
axwthumper: couldn't tell you the differences without poring over the release notes05:24
thumperah05:25
thumperin which case, can I get you to upload the built juju and jujud binaries to chinstrap somewhere?05:25
thumperI'll propose the backport, but I'm going to see if we can get some confirmation that it actually helps first05:26
axwthumper: sure05:28
axwthumper: tests are just hanging.. nfi what they're doing05:36
thumperbugger05:36
axwthumper: anyway, binaries hare at https://chinstrap.canonical.com/~axw/ignore-machine-addresses-1.22.tgz05:38
thumperaxw: ta05:38
axwthumper: giving up on tests now, they don't appear to be doing anything05:39
thumperkk05:39
thumperwhich ones hung?05:39
axwthumper: I think it was in the cmd/juju package05:41
thumperaxw: or they were just taking ages?05:42
axwthumper: maybe, hard to tell. it was going on for quite a long time (didn't have timestamps but around 10 mins?)05:42
thumperhmm...05:43
thumperaxw: fyi https://bugs.launchpad.net/juju-core/+bug/146430406:03
mupBug #1464304: Sending a SIGABRT to jujud process causes jujud to uninstall (wiping /var/lib/juju) <sts> <juju-core:Triaged> <https://launchpad.net/bugs/1464304>06:03
thumperaxw: I wonder if we should move the manual cleanup / removal code to SIGUSER1 or 2 rather than SIGABRT06:04
axwthumper: yes, I think so06:04
thumperaxw: for some unknown reason, various folks have hit this06:04
axwthumper: main problem is how to change it while still being able to destroy old environments06:05
thumperyeah... always a problem06:05
thumperhere's my suggestion06:05
thumperwe fix it in 1.25 / master06:05
thumperin 1.25, when the api client connects, it stores the server version in the client api06:06
thumperso we can ask the server "what version are you"06:06
thumperthen switch based on known version06:06
thumperor alternatively06:06
thumperask for the environ config agent version06:06
thumperwhich is probably technically more correct06:06
thumperas the api says what version the server is06:07
thumpernot what version the environment is06:07
axwthumper: that doesn't work when there's no API connection though. we still have to support --force06:07
axwthumper: probably could just "jujud --version" instead06:07
thumperdoes that work?06:07
thumperyep06:07
thumperit does06:07
thumperI think that would be a good start06:08
axwthumper: I believe we're on bugs next week, I'll fix it then. trying to finish up some ceph-related storage changes atm06:08
thumperkk06:08
thumperhave a good weekend06:08
thumperchat next week06:08
axwthumper: cheers, you too06:08
mupBug #1499613 opened: Windows device path mismatch in volumeSuite.TestListVolumesStorageLocationBlockDevicePath <ci> <test-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1499613>06:26
mupBug #1499617 opened:  juju machine add --constraints arch=i386 says machine created, then doesn't create machine <juju-core:New> <https://launchpad.net/bugs/1499617>06:38
mupBug #1499617 changed:  juju machine add --constraints arch=i386 says machine created, then doesn't create machine <juju-core:New> <https://launchpad.net/bugs/1499617>06:44
mupBug #1499617 opened:  juju machine add --constraints arch=i386 says machine created, then doesn't create machine <juju-core:New> <https://launchpad.net/bugs/1499617>06:47
mupBug #1499617 changed:  juju machine add --constraints arch=i386 says machine created, then doesn't create machine <juju-core:New> <https://launchpad.net/bugs/1499617>06:50
mupBug #1499617 opened:  juju machine add --constraints arch=i386 says machine created, then doesn't create machine <juju-core:New> <https://launchpad.net/bugs/1499617>06:56
frobwarevoidspace, dooferlad: Thinking of postponing planning/retrospective until Monday when dimiter and frank are back. Thoughts?08:21
voidspacefrobware: agreed08:21
dooferladfrobware: seems reasonable08:21
frobwarevoidspace, dooferlad: it would allow us to concentrate on the spaces bugs08:21
voidspacefrobware: so, Monday?08:21
frobwarevoidspace, yep08:21
voidspacestandup as usual today then08:21
frobwarevoidspace, yes, probably not long but we should...08:21
voidspaceok08:22
voidspacefrobware: how's your git-fu?08:23
voidspacefrobware: I wish to branch off 1.2508:23
frobwarevoidspace, mostly OK within Emacs... :)08:23
voidspaceheh08:23
frobwarevoidspace, in your github clone?08:23
voidspaceif I checkout 1.24 (a tag from my upstream) it works fine08:24
voidspacefrobware: yep08:24
voidspaceif I checkout 1.25 I get told it doesn't exist08:24
voidspacegit checkout upstream/1.25 works08:24
voidspacebut puts me in a detached head08:24
frobwarevoidspace, I have 1.2x branches in my github fork so I just branch from those08:24
voidspacefrobware: I wonder why my github fork doesn't have a 1.25 branch/tag08:25
voidspaceand how I get one...08:25
voidspaceif08:25
voidspaceth08:25
voidspacee08:25
frobwarevoidspace, I ran into this the other day and just pushed a branch08:25
voidspaceoops08:25
voidspaceif08:25
voidspaceif08:25
voidspace8f008:25
voidspaces-a08:25
voidspace 08:26
voidspace  08:26
dooferladwell, this is interesting to watch08:26
dooferladit looks like voidspace just had a cat sit on his enter key :-)08:26
dooferladbtw, you need to git checkout -b localname origin/branchname08:27
dooferladhttp://stackoverflow.com/questions/471300/git-switch-branch-without-detaching-head08:28
voidspacemy keyboard switched into "crazy mode" and I failed to get it to behave itself08:36
voidspaceeven on reboot08:36
voidspaceso new keyboard it is08:36
voidspacedooferlad: thanks, I can branch off the detached head08:36
voidspacedooferlad: I just wondered why I apparently have a 1.24 tag/branch and not a 1.25 one08:37
voidspaceand also I wondered if the detached head was expected/correct08:37
dooferladvoidspace: you may have branched rather than checked out previously?08:37
voidspaceyour implication is that it is08:37
voidspacedooferlad: possibly08:37
fwereadefrankban, ping08:37
frankbanfwereade: hi08:38
fwereadefrankban, ancient history now, but: https://github.com/juju/juju/commit/c67e13c37948d5b3e41125c40425fccbee59245208:38
dooferladvoidspace: this is why I paid for http://www.syntevo.com/smartgit/ -- it is all the git-fu I need08:38
dooferladvoidspace: shame it doesn't do bzr!08:38
fwereadefrankban, do you recall what the motivation for adding JujuOsEnvSuite to BaseSuite was?08:38
voidspacedooferlad: your mental model is better than mine too I think08:38
voidspacealthough I'll look at smartgit08:39
voidspaceanything that makes my life easier is good...08:39
dooferladvoidspace: it feels like there should be a joke in there about me being mental...08:39
voidspacedooferlad: oh, I wouldn't joke about that!08:40
dooferladvoidspace: :p08:40
frankbanfwereade: it seems that BaseSuite was cleaning up env var before as well08:42
fwereadefrankban, yeah, sorry, on closer inspection it looks like it's just an extraction08:42
frankbanfwereade: yeah, np08:43
dooferladvoidspace: https://plus.google.com/hangouts/_/canonical.com/sapphire09:02
voidspacedooferlad: omw09:03
voidspacedooferlad: frobware: oh, I forgot to mention in standup. I have a meeting at daughter's school for an hour this afternoon (school just round the corner so not much travel time). Will work later to make up the time.09:32
=== psivaa is now known as psivaa-afk
=== psivaa-afk is now known as psivaa
mgz_master is broken.11:08
anastasiamacmgz_: oh?.. why?11:09
mgz_anastasiamac: pr321011:10
mgz_doesn't build on windows. last time dave poked the version also broke the build.11:11
anastasiamac:(11:12
bogdanteleagamgz_: we really ought to get a GOOS=windows build test in the hook if this actually happens that often11:16
mgz_bogdanteleaga: I have a bigger, more painful for everyone solution11:16
mgz_that I've been procrastinating over11:16
mgz_but given the failure rate recently on windows testing, is justified to just gate on a full windows run, even though it doubles the time11:18
mupBug #1499689 opened: Windows ftb after version.Binary.OS change <blocker> <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1499689>11:21
bogdanteleagamgz_: might still save time overall :)11:23
=== psivaa is now known as psivaa-lunch
mupBug # changed: 1466498, 1466514, 1488576, 1497456, 149848112:42
rogpeppemgz_: why would gating on a full windows run double the time? does it really take three times as long to run the tests on windows?12:47
mgz_rogpeppe: takes longer, and doing two runs means the various intermittent failures are more likely to be hit on any given merge attempt12:50
rogpeppemgz_: presumably you could do the two runs concurrently?12:51
mgz_yeah, which is why it's only going to ~double the time12:51
mupBug # opened: 1466498, 1466514, 1488576, 1497456, 149848112:51
rogpeppemgz_: (in general it might be interesting to consider running all the tests concurrently across a few machines)12:51
rogpeppemgz_: (shouldn't be that hard, i'd think)12:52
mgz_rogpeppe: if the tests were just reliable run either in parallel, or under lxc, could already massively speed up the run12:52
rogpeppemgz_: why would running them under lxc help?12:53
mgz_don't actually need multiple machines, just to be able to use all the cpus12:53
rogpeppemgz_: doesn't go test use all cpus anyway?12:53
mgz_rogpeppe: because then I can just use multiple containers, also avoids the overhead of starting up a new machine each time12:54
rogpeppemgz_: i'm fairly sure that by default it runs GOMAXPROCS packages' tests at the same time12:54
mupBug # changed: 1466498, 1466514, 1488576, 1497456, 149848112:54
rogpeppemgz_: so we can't run tests under lxc?12:54
mgz_rogpeppe: I may be wrong, but I belive GOMAXPROCS defaults to 1 for us12:55
mgz_rogpeppe: they mostly work, but are less reliable and hits timing issues much more12:56
mgz_though, job also not helped by being on wily these days and the tests not passing on wily:12:57
mgz_<http://juju-ci.vapour.ws/job/xx-run-unit-tests-lxc-wily-amd64/>12:57
rogpeppemgz_: i think you'd need to deliberately set GOMAXPROCS to get it to default to 112:57
rogpeppemgz_: you can find out with fmt.Println(runtime.GOMAXPROCS(0))12:57
rogpeppemgz_: tbh we *should* always run with GOMAXPROCS>112:57
rogpeppemgz_: anyway, spreading tests across machines would also be very feasible12:58
mgz_rogpeppe: wasn't the default changed in some go > 1.2.1?12:58
rogpeppemgz_: i think it's controlled by the -p flag:13:06
rogpeppe-p n13:06
rogpeppethe number of builds that can be run in parallel.13:06
rogpeppeThe default is the number of CPUs available.13:06
rogpeppemgz_: so unless you're deliberately running with -p 1, i think you'll be running num-CPU tests at a time currently anyway13:07
rogpeppemgz_: contrary to my assertion above, GOMAXPROCS is orthogonal to this13:08
mgz_rogpeppe: yeah, they're different effects. we used to force -p to something small, but that at least is no longer needed.13:09
rogpeppemgz_: so probably you'll need to split across multiple machines in order to speed things up13:10
rogpeppemgz_: another way to speed things up would be to have a git cache so that we're not fetching all the deps each time13:11
mgz_rogpeppe: another way would be make the tests less pants :)13:12
rogpeppemgz_: i'm not asking for miracles :)13:12
mgz_the download isn't much of a speed issue - it's more painful when github api is down and the job fails out13:13
rogpeppemgz_: if i had the task of speeding up the tests, i'd start by looking at setup/teardown time - there are lots of tests that take almost no time but fixture setup and teardown takes at least 0.25s13:14
mgz_rogpeppe: yeah, a bunch of the problem is still we're using suites that are terrible13:15
mgz_though there was some connsuite destruction recently13:15
bogdanteleagaanybody has an idea if juju uses the proxy settings right on the first setup? and if so, how?13:15
bogdanteleagaI can see it takes the config values from the state machine when proxyupdater starts13:15
rogpeppemgz_: and i'd also look at the problem that there are quite a few tests that run for 5s or 10s or 15s because they're waiting for the poll interval. that shouldn't be too hard to sort out.13:15
rogpeppemgz_: one thing that might potentially speed things up is to use a single external mongodb instance for all packages.13:16
rogpeppemgz_: running 4 (or however many) mongodb instances at a time is not gonna be good for speed13:17
rogpeppemgz_: i think that moving towards mocking everything because it's too slow is actually a step backwards in some ways.13:17
rogpeppemgz_: and yeah, jujuconnsuite sets up much more than it needs to (directories, files, etc). most tests don't need that.13:18
mupBug #1499617 changed:  juju machine add --constraints arch=i386 says machine created, then doesn't create machine <add-machine> <constraints> <juju-core:New> <https://launchpad.net/bugs/1499617>13:21
=== psivaa-lunch is now known as psivaa
rogpeppehi all. i have another step in my apiserver changes for macaroon auth available for your delight and edification. i'm sure you'll all be dying to review it. http://reviews.vapour.ws/r/2758/13:54
mgz_how cute rog.13:54
rogpeppemgz_: :)13:55
rogpeppeTheMue, cmars: it seems you're OCR... any chance of a review? :) http://reviews.vapour.ws/r/2758/13:58
cmarsrogpeppe, yep, got a bit of a backlog already though14:16
rogpeppecmars: fair enough, had to try :)14:17
frobwarerogpeppe, TheMue is out this week15:35
rogpeppefrobware: ah, ok15:35
frobwarerogpeppe, which is obviously a bit late in the day to find out...15:36
rogpeppefrobware: it's fine, 'cos cmars is on the case, right casey? :)15:36
cmarsrogpeppe, reviewing!15:37
rogpeppecmars: much appreciated15:37
natefinchfwereade: you around?16:15
mattywfwereade, ping?16:24
mupBug #1499781 opened: macaroonLoginSuite fails on windows on chicago-cubs <ci> <test-failure> <windows> <juju-core:Incomplete> <juju-core chicago-cubs:Triaged> <https://launchpad.net/bugs/1499781>16:31
fwereadenatefinch, just passing -- can I help?17:27
natefinchfwereade: no worries, was wondering about the unit assigning worker I'm writing... I presume it should be a singular worker, since we don't want multiple workers assigning units at the same time.17:47
mupBug #1499689 changed: Windows ftb after version.Binary.OS change <blocker> <ci> <regression> <windows> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1499689>18:46
sinzuiabentley: hangout?19:00
abentleysinzui: let's.19:01
cmarshttp://reviews.vapour.ws/r/2762/, fixes LP:#149961320:39
mupBug #1499613: Windows device path mismatch in volumeSuite.TestListVolumesStorageLocationBlockDevicePath <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1499613>20:39
* natefinch changes code... test fails.20:41
* natefinch changes test... test passes.20:41
* natefinch wonders if anyone actually cares what error is returned from this function, so long as it actually fails.20:42
cmarsnatefinch, can you review these? http://reviews.vapour.ws/r/2762/ http://reviews.vapour.ws/r/2763/20:47
natefinchcmars: ship 'em20:49
cmarsnatefinch, thanks!20:49
natefinchcmars: thanks for fixing it, and FWIW, I wish we gated on the windows tests too20:49
mupBug #1499900 opened: scope: container is too ambiguous and confusing <juju-core:New> <https://launchpad.net/bugs/1499900>21:56

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