*** jkilpatr has quit IRC | 00:01 | |
*** jkilpatr has joined #zuul | 00:14 | |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Remove unused repos from repo init https://review.openstack.org/458232 | 00:28 |
---|---|---|
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Remove project3 https://review.openstack.org/458233 | 00:36 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Use 'org/project' for tests which only operate on one project https://review.openstack.org/458237 | 00:36 |
*** jkilpatr has quit IRC | 05:50 | |
*** jkilpatr has joined #zuul | 05:51 | |
*** isaacb has joined #zuul | 06:24 | |
*** bhavik1 has joined #zuul | 06:49 | |
*** jhesketh has quit IRC | 07:14 | |
*** jamielennox has quit IRC | 07:28 | |
*** jamielennox has joined #zuul | 07:42 | |
*** jhesketh has joined #zuul | 07:44 | |
*** bhavik1 has quit IRC | 08:26 | |
*** hashar has joined #zuul | 08:56 | |
*** jkilpatr has quit IRC | 10:41 | |
*** jkilpatr has joined #zuul | 11:02 | |
*** lennyb has quit IRC | 11:29 | |
*** lennyb has joined #zuul | 11:30 | |
*** openstackgerrit has quit IRC | 11:32 | |
*** atarakt has joined #zuul | 12:15 | |
*** atarakt has quit IRC | 12:15 | |
*** atarakt has joined #zuul | 12:16 | |
*** jkilpatr has quit IRC | 14:07 | |
*** hashar has quit IRC | 14:11 | |
*** hashar has joined #zuul | 14:13 | |
*** jkilpatr has joined #zuul | 14:22 | |
*** dkranz has joined #zuul | 14:26 | |
*** isaacb has quit IRC | 14:54 | |
jlk | blah, so both of my changes for simple_layout failed. I'll dig into those today | 14:58 |
*** isaacb has joined #zuul | 15:11 | |
jeblair | jlk: i think i left a comment on the first about it | 15:27 |
*** jkilpatr has quit IRC | 15:44 | |
*** isaacb has quit IRC | 16:08 | |
*** openstackgerrit has joined #zuul | 16:11 | |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Move test_tags to simple_layout https://review.openstack.org/458240 | 16:11 |
Shrews | jeblair: mordred: I've encountered some roadblocks with changing the current design of the log streamer to be incorporated with the executor. I've put my thoughts up here: http://paste.openstack.org/show/607375/ If you have time, I'd appreciate any suggestions that I haven't considered. | 16:11 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Move some uses of updateConfigLayout to simple_layout https://review.openstack.org/458262 | 16:12 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Remove unused test git repos https://review.openstack.org/458263 | 16:12 |
Shrews | a bit pre-occupied with some other things atm, so very likely overlooked something easy | 16:12 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Remove outdated TODO https://review.openstack.org/456089 | 16:13 |
* Shrews steps away for lunch | 16:18 | |
jeblair | Shrews: i feel like the phares "daemon subprocess" is a specific term of art that i should know the meaning of (similarly, the admonition "daemon subprocesses should not start subprocesses of their own"); do you have a reference for what exactly those mean? | 16:22 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move semaphore tests to their own class https://review.openstack.org/458584 | 16:29 |
*** hashar has quit IRC | 16:41 | |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move semaphore tests to their own class https://review.openstack.org/458584 | 16:44 |
jeblair | that one ran in 7.5m | 16:45 |
Shrews | jeblair: sorry. That was from the viewpoint of using the multiprocessing module and setting the daemon=True attr | 16:51 |
jeblair | Shrews: got it, thanks. | 16:52 |
jeblair | Shrews: i will dig into that a little later | 16:53 |
*** jkilpatr has joined #zuul | 17:30 | |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move semaphore tests to their own class https://review.openstack.org/458584 | 17:31 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move timer tests to commitConfigUpdate https://review.openstack.org/458599 | 17:31 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move timer tests to commitConfigUpdate https://review.openstack.org/458599 | 17:34 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move test_repo_deleted to simple_layout https://review.openstack.org/458269 | 17:34 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: move test_disable_at to simple_layout https://review.openstack.org/458252 | 17:34 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move semaphore tests to their own class https://review.openstack.org/458584 | 17:34 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove org_unknown git repo from single-client test config https://review.openstack.org/458270 | 17:34 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move check_ignore_dependencies to simple_layout https://review.openstack.org/458255 | 17:34 |
jeblair | jlk: i updated your patches | 17:34 |
jlk | well shoot I was just inthe midle of that | 17:34 |
jlk | I was running tests locally this time to see if they'd pass :) | 17:34 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move timer tests to commitConfigUpdate https://review.openstack.org/458599 | 17:35 |
jeblair | jlk: sorry :( | 17:35 |
jlk | no worries | 17:35 |
jlk | I had it wrong anyway | 17:35 |
clarkb | are files like https://git.openstack.org/cgit/openstack-infra/zuul/tree/tests/fixtures/layout-disable-at.yaml?h=feature/zuulv3 able to be removed? | 17:36 |
clarkb | my grepping shows that we may have quite a few of those layouts that are unused | 17:36 |
jlk | all the patches for setting a hostname in source merged yesterday right? | 17:37 |
jeblair | clarkb: yes, though some of them are still unported v2 tests; may be easiest to clean them all up when all the tests are done | 17:38 |
jeblair | jlk: yes | 17:38 |
jlk | jeblair: is that setting hostname stuff the last of hte multi-connection bits, or is there more coming? | 17:38 |
jeblair | jlk: i think that's it | 17:40 |
clarkb | jeblair: wouldn't they show up in greps if part of unported tests? | 17:40 |
jlk | alrighty, I'll start a rebase going. along the way I'll be moving all the tests to the simple_layout mechanism. | 17:40 |
jeblair | clarkb: yep. that should be safe. | 17:41 |
jeblair | jlk: note that the "build a config scenario directory" is still a good way of handling configuration. in the same way that we will end up with a bunch of scheduler tests with "a gerrit, one project, and a check and gate pipeline" operating from a config directory, if you end up with a situation with a bunch of github tests wanting a similar configuration, it may well be worth doing that, at least for some of the tests. | 17:45 |
jeblair | (just wanted to make it clear that i think both techniques have their place; right tool for the job and all) | 17:46 |
jlk | nod | 17:46 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move timer tests to commitConfigUpdate https://review.openstack.org/458599 | 17:54 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move semaphore tests to their own class https://review.openstack.org/458584 | 17:54 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove org_unknown git repo from single-client test config https://review.openstack.org/458270 | 17:54 |
jlk | jeblair: ahhh, so reading setupSimpleLayout() it assumes a source of gerrit. | 18:33 |
openstackgerrit | Merged openstack-infra/zuul master: Remove link to modindex https://review.openstack.org/415498 | 18:33 |
jlk | jeblair: would you accept a change so that the driver can be passed in as an option, that defaults to gerrit? | 18:34 |
*** hashar has joined #zuul | 18:44 | |
*** hashar is now known as hasharAway | 18:44 | |
jeblair | jlk: sounds good | 18:46 |
jlk | working up an isolated change for that to test with | 18:46 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Allow simple_layout to support custom drivers https://review.openstack.org/458624 | 19:06 |
jlk | jeblair: ^^ that does the driver option. Seemed to pass tests locally. | 19:08 |
jlk | I'm going to stack the rest of the github patch set on top of that one | 19:08 |
tobiash | jeblair: that's correct, it's implicitly configured with max 1 to behave like a mutex | 19:22 |
tobiash | jeblair: the reason for that was backwards compatibility for the v2 version of the patch | 19:23 |
tobiash | jeblair: and for the v3 version of the semaphores I just left this behaviour | 19:24 |
tobiash | jeblair: but I'm also fine making this explicitly required | 19:24 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move two more tests to commitConfigUpdate https://review.openstack.org/458647 | 20:09 |
openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove commitLayoutUpdate https://review.openstack.org/458648 | 20:13 |
openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Allow simple_layout to support custom drivers https://review.openstack.org/458624 | 20:19 |
*** hasharAway has quit IRC | 20:19 | |
*** hashar has joined #zuul | 20:20 | |
jlk | woo. | 20:23 |
* jlk lunches | 20:23 | |
*** hashar has quit IRC | 20:23 | |
*** hashar has joined #zuul | 20:23 | |
*** yolanda has quit IRC | 20:35 | |
jeblair | Shrews: i'd avoid the multiprocessing module for this. i'd prefer for us to be explicit about exactly what's happening, and multiprocessing hides a lot of stuff which i think we'd want to know about it (i really like it as a simple replacement for threads, but this is more nitty gritty than that). another option to consider is to manage a subprocess like the scheduler does for the 'built-in' gear server. that seems to work well enough most of ... | 20:39 |
jeblair | ... the time. see zuul/cmd/scheduler for how it starts/stops it. that may port over fairly well to zuul/cmd/executor. | 20:39 |
jeblair | Shrews: i also left some comments on the current changes -- i think those comments are generally still forward compatible with ^^ if we do that. | 20:40 |
jeblair | clarkb, mordred: I think 458252 -- 458648 are ready to go. | 20:41 |
jeblair | SpamapS: 458648 deletes a method you wrote; it's replaced with a similar method, but just wanted to draw your attention to it. | 20:42 |
*** jkilpatr has quit IRC | 20:45 | |
SpamapS | jeblair: I'll take a gander | 20:53 |
clarkb | jeblair: ya I had started at the bottom of that stack then lunch arrived | 20:56 |
clarkb | picking it up again | 20:56 |
clarkb | jeblair: I don't see why the tag called init is necessary in https://review.openstack.org/#/c/458270/3/tests/base.py don't you just need a repository? | 21:02 |
jeblair | clarkb: somewhere along the way addFakeChangeToRepo grew a requirement that there be a commit tagged init. | 21:07 |
*** dkranz has quit IRC | 21:21 | |
*** jkilpatr has joined #zuul | 21:23 | |
SpamapS | jeblair: quite nice. Thanks for optimizing the tests.. :) | 21:27 |
clarkb | jeblair: thats an interseting requirement :) | 21:27 |
jeblair | clarkb: oh i think i get it. we've had that requirement forever. init_repo used to do it automatically. but then i had it stop doing it because i wanted some other initialization path (i think probably the config directory system) to do it, and supply its own initial commit. but then that's adding it back because there are some tests where do we want init_repo to handle it directly and create the initial commit. | 21:42 |
jeblair | (i still don't understand why it's actually needed, but that explains that the change above isn't really much of a change) | 21:43 |
jeblair | clarkb, jlk, SpamapS, mordred: btw, i just performed 3 test runs on my local workstation. the testr elapsed time before the multi-connection stack was 367s. at the end of the multi-connection stack (which added way more git ops) was 539s. at the end of the test-cleanup stack it's now 251s. | 21:46 |
jlk | whoh | 21:46 |
SpamapS | Ran 219 (-1) tests in 852.227s (-93.742s) | 21:47 |
SpamapS | FAILED (id=44, failures=2 (-2), skips=23) | 21:47 |
SpamapS | That's on my laptop | 21:47 |
SpamapS | and that's testing 458648 | 21:47 |
SpamapS | 'tox -r -epy27' | 21:47 |
SpamapS | I got one Alarm Clock :-/ | 21:47 |
jeblair | weird, i ran 240 tests. | 21:48 |
* clarkb starts a local zk again and runs the tests | 21:48 | |
SpamapS | The alarm clock kills all the rest of the tests in that process | 21:48 |
jeblair | ah | 21:48 |
SpamapS | and likely I had one the last time I tried too | 21:48 |
SpamapS | I shut down a few naughty slack windows .. maybe having that CPU back will help ;-) | 21:49 |
SpamapS | testr should subtract the rounded 10 minute load average from its concurrency guess | 21:50 |
*** dkranz has joined #zuul | 21:51 | |
SpamapS | still got an alarm clock even with a relatively quiet system. :-/ | 21:55 |
clarkb | I forgot to exclude the mysql tests... so those are failing. Still waiting for completion | 21:57 |
SpamapS | tests.unit.test_scheduler.TestScheduler.test_dependent_behind_dequeue | 22:02 |
SpamapS | always the worst of the bunch | 22:02 |
jlk | that's the one | 22:06 |
jeblair | we could probably have it run fewer jobs and still have it be a valid test | 22:07 |
jeblair | i have to run out for a bit | 22:09 |
clarkb | woo finally think I have it running with all the sql tests excluded lets see if this is happy | 22:14 |
clarkb | testr run 'tests.unit.(?!test_connection.(TestSQLConnection|TestConnectionsBadSQL)).*' or tox -ep27 -- 'tests.unit.(?!test_connection.(TestSQLConnection|TestConnectionsBadSQL)).*' is the magic | 22:15 |
*** hashar has quit IRC | 22:25 | |
*** jamielennox is now known as jamielennox|away | 22:25 | |
*** jamielennox|away is now known as jamielennox | 22:29 | |
clarkb | appears its not going to finish quickly :/ I have a bunch of failures. This low power i5 from 6 years ago not that great I guess | 22:44 |
SpamapS | so even with OS_TEST_TIMEOUT=9999 there's something in that test that still causes an alarm clock. Very confusing. | 22:44 |
SpamapS | model name: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz | 22:45 |
SpamapS | and it still takes mine 900 or so seconds | 22:46 |
clarkb | model name: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz | 22:46 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Allow using webapp from connections https://review.openstack.org/439831 | 22:46 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Support GitHub PR webhooks https://review.openstack.org/439834 | 22:46 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Add basic Github Zuul Reporter. https://review.openstack.org/443323 | 22:46 |
clarkb | the S means "Slow" (actually its the low power chip iirc but ya that means slow) | 22:46 |
SpamapS | I think there's more to it than CPU | 22:48 |
SpamapS | %Cpu(s): 29.7 us, 65.9 sy, 0.1 ni, 4.0 id, 0.1 wa, 0.0 hi, 0.2 si, 0.0 st | 22:48 |
SpamapS | 65.9% system CPU | 22:49 |
SpamapS | http://paste.ubuntu.com/24423387/ | 22:50 |
SpamapS | Most of its time spent in clone() | 22:50 |
clarkb | might be good to attach yappi to a test run | 22:51 |
SpamapS | dunno what that is | 22:52 |
clarkb | its a python profiler that is generally betterwith threads and such | 22:52 |
SpamapS | ah, well honestly, clone() is likely because of all the git | 22:52 |
clarkb | ya | 22:53 |
SpamapS | I wonder if something else is using alarm() | 22:53 |
clarkb | also 277 stat errors? | 22:53 |
SpamapS | because it makes 0 sense that I"d get an Alarm Clock with OS_TEST_TIMEOUT=9999 in less than 300s.. but I just did | 22:53 |
SpamapS | clarkb: that's just how os.path.exists() works | 22:53 |
clarkb | ah | 22:53 |
SpamapS | "errors" | 22:53 |
SpamapS | means "set errno" | 22:53 |
clarkb | I'm thinking my test run won't finish because it ate itself when it errored | 22:55 |
SpamapS | it will | 22:58 |
SpamapS | if it's using any CPU | 22:59 |
SpamapS | you just get less tests run | 22:59 |
clarkb | it is still cpuing | 22:59 |
SpamapS | since any scheduled on that process after the fail don't run | 22:59 |
clarkb | I shall be patient | 22:59 |
* SpamapS trying with gentle=True to see if that changes anything | 22:59 | |
clarkb | most of the cputime does appear to be spent by a single process so maybe thats the last one doing any work? | 23:01 |
SpamapS | yeah | 23:01 |
SpamapS | that's the pattern I see | 23:01 |
SpamapS | http://paste.ubuntu.com/24423454/ | 23:06 |
SpamapS | with gentle timeout that's what I get | 23:06 |
clarkb | and thats before you hit the timeout right? | 23:07 |
clarkb | so something else is SIGALARMing? | 23:07 |
SpamapS | No that's the timeout that is normally causing SIGALRM to kill the process | 23:07 |
SpamapS | but with gentle=True it catches it and logs it. | 23:07 |
clarkb | right any alarm will cause that code to raise | 23:08 |
clarkb | so wondering if it happened at expected time or later | 23:08 |
clarkb | er earlier | 23:08 |
SpamapS | ansible uses alarm() I think | 23:08 |
SpamapS | but it's in a different process | 23:08 |
SpamapS | so I don't think that would propagate | 23:08 |
SpamapS | oh I got another one | 23:09 |
SpamapS | File "tests/unit/test_scheduler.py", line 765, in test_patch_order | 23:09 |
SpamapS | just this time "timeout waiting for zuul to settle | 23:10 |
SpamapS | .tox/py27/lib/python2.7/site-packages/ansible/plugins/action/pause.py: signal.alarm(seconds) | 23:11 |
SpamapS | I wonder | 23:11 |
SpamapS | no pauses in our playbooks | 23:11 |
SpamapS | Ran 240 (+27) tests in 969.116s (+241.735s) | 23:15 |
SpamapS | FAILED (id=48, failures=2, skips=24) | 23:15 |
clarkb | setitimer uses the same clock and also raises sigalrm | 23:16 |
clarkb | mine is still running I think its been about an hour | 23:17 |
SpamapS | oy | 23:17 |
SpamapS | Yeah I forgot about setitimer | 23:17 |
* SpamapS used it in pipemeter of all things | 23:17 | |
clarkb | SpamapS: I'm knee deep in manpages | 23:17 |
SpamapS | nothing in the deps uses itimer | 23:18 |
clarkb | you know, I wonder if my btrfs choice was a poor one here >_> | 23:18 |
SpamapS | clarkb: do you have a tmpfs for ZUUL_TEST_ROOT ? | 23:19 |
clarkb | no | 23:19 |
SpamapS | I mean, SSD should make that mostly meh | 23:20 |
clarkb | the gate jobs aren't using one as far as I know so it shouldn't be necessary | 23:20 |
clarkb | and yes ssd | 23:20 |
SpamapS | but still I haven't looked at how well btrfs handles concurrent metadata writes | 23:20 |
SpamapS | if nothing else you're creating and destroying a lot of tmpdirs in one single dir | 23:21 |
clarkb | I'm pretty sure its much slower than ext4 across the baord | 23:21 |
clarkb | but I wouldn't expect it to be that much slower that zuul just fails | 23:21 |
SpamapS | I was always assured btrfs was comparable to ext4 except when it got really full | 23:22 |
clarkb | https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-FS-5-Way | 23:23 |
SpamapS | so... | 23:23 |
SpamapS | if one sets OS_TEST_TIMEOUT=0 | 23:23 |
SpamapS | it should make test base class not even use the timeout fixture | 23:23 |
SpamapS | and yet... | 23:23 |
clarkb | basically for dby type stuff btrfs is slow | 23:23 |
clarkb | SpamapS: how are you setting it? and are you using tox? | 23:26 |
SpamapS | Everything is slower than XFS for databases. | 23:26 |
clarkb | tox filters the env by default so you can hard code it in tox.ini or set it in .testr.conf | 23:26 |
clarkb | SpamapS: ya but ext4 is also quicker than btrfs | 23:26 |
SpamapS | They all just fail so badly for concurrent writes to the same file except XFS. | 23:26 |
SpamapS | but yeah I see your point. | 23:27 |
clarkb | ext4 beats btrfs and xfs with pgbench too (though thats a specific test not to be taken alone) | 23:27 |
SpamapS | what if it's .testrepository that is making yours slow? | 23:27 |
clarkb | oh maybe, just writing out all the datas? | 23:27 |
SpamapS | rheeeeeeeealllly? | 23:27 |
SpamapS | pg I'd expect to lurve some xfs | 23:27 |
clarkb | SpamapS: bottom of thel ink I posted | 23:27 |
SpamapS | damnit.... ok | 23:28 |
SpamapS | so.. | 23:28 |
SpamapS | tox.ini sets OS_TEST_TIMEOUT to 120 | 23:28 |
SpamapS | apparently setenv sections don't respect already-set values. Damn. | 23:28 |
SpamapS | so that's been my confusion | 23:28 |
SpamapS | we should remove that | 23:29 |
SpamapS | and just set a default in the test suite | 23:29 |
jlk | hah oops | 23:29 |
SpamapS | I mean, I'd like to know why my tests are going so slow that they finish 2x slower than on crappy cloud vms | 23:29 |
SpamapS | but .. that's why I set it =9999 ... cause I just want it to finish and then I'll debug | 23:30 |
clarkb | the default is set in .testr.conf iirc | 23:30 |
jlk | in good news, my rebased github patches (only have completed 3 so far) are passing tests in CI! | 23:30 |
clarkb | appaerntly not | 23:31 |
clarkb | I think typically you'd have it set in .testr.conf so that it only affects testr runs | 23:31 |
clarkb | and can be overridden easily | 23:31 |
SpamapS | oh yeah I think it should be there yeah | 23:31 |
SpamapS | and with a ${OS_TEST_TIMEOUT:120} | 23:31 |
SpamapS | :-120 I guess | 23:32 |
SpamapS | thanks, bash, for using single characters to represent entire concepts, so we can't read ANYTHING | 23:32 |
clarkb | ya that | 23:32 |
clarkb | I'm testing just tests.unit.test_scheduler.TestScheduler.test_disable_at with a lcean testrepository and no timeout | 23:33 |
clarkb | it passes in 24 seconds | 23:33 |
clarkb | now to run it a bunch and see if it regresses because .testrepository | 23:33 |
clarkb | curious if my 24s is really off the mark compared to SpamapS' | 23:34 |
SpamapS | clarkb: test_disable_at? Let me look | 23:37 |
SpamapS | tests.unit.test_scheduler.TestScheduler.test_disable_at 46.568 | 23:37 |
SpamapS | something's terribly wrong on my computer I think ;) | 23:38 |
clarkb | it seems pretty stable around 24s on its own | 23:39 |
clarkb | whats the big test that fails for you? | 23:39 |
clarkb | let me try that one next | 23:39 |
clarkb | tests.unit.test_scheduler.TestScheduler.test_dependent_behind_dequeue ? | 23:40 |
SpamapS | yeah that one | 23:41 |
SpamapS | I don't know how long it really takes | 23:42 |
SpamapS | because it's been dying at 120s | 23:42 |
clarkb | Ran 1 tests in 58.010s here | 23:42 |
SpamapS | Ran 240 (+72) tests in 1010.691s (+645.160s) | 23:42 |
SpamapS | PASSED (id=50, skips=24) | 23:42 |
* clarkb tries a full run with concurrency=1 | 23:42 | |
clarkb | wondering if its jus tterrible contention | 23:42 |
clarkb | and I forgot to disable the mysql tests again... oh well | 23:43 |
SpamapS | clarkb: what OS and kernel are you on? | 23:44 |
SpamapS | I"m on Xenial, 4.4.0-72 | 23:44 |
clarkb | SpamapS: suse tumbleweed, 4.10.1-2-default | 23:44 |
SpamapS | entirely possible that the xenial kernel has some crapiness in it | 23:44 |
SpamapS | hmmmmmmmmm | 23:46 |
openstackgerrit | Jesse Keating proposed openstack-infra/zuul feature/zuulv3: Add 'push' and 'tag' github webhook events. https://review.openstack.org/443947 | 23:46 |
SpamapS | I wonder if I only have one actual CPU | 23:47 |
SpamapS | dmidecode suggests that I do | 23:47 |
SpamapS | ah 2 cores though | 23:48 |
jlk | one cpu, 2 cores. so you _should_ be able to concurrency=2 | 23:48 |
jlk | or it should pick that up | 23:48 |
clarkb | I've got 4 cores and it runs 4way by default | 23:48 |
clarkb | anyways trying it with concurrency=1 to see if thats stable | 23:49 |
SpamapS | jlk: I'm getting concurrency=4 | 23:49 |
SpamapS | because 4 threads | 23:49 |
SpamapS | so maybe testr's doing it wrong | 23:49 |
jlk | how is it figuring on 4 threads? | 23:50 |
SpamapS | let's see what concurrency=2 does | 23:50 |
SpamapS | jlk: SMT | 23:50 |
jlk | oh, so you've got 1 package, 2 cores, hyperthreading? | 23:50 |
SpamapS | yep | 23:51 |
clarkb | mine is actually 4 cores not hyperthreaded | 23:51 |
SpamapS | I'm trying with conc=2 | 23:51 |
clarkb | I should clean out the case so that the turboboost can boost more :) | 23:53 |
SpamapS | add some stickers | 23:55 |
clarkb | well in theory for single cpu load its supposed to clock up to ~3.3ghz | 23:56 |
clarkb | but currently only at 2.650 and I think its thermally limited | 23:56 |
clarkb | tests.unit.test_scheduler.TestScheduler.test_client_promote_dependent and tests.unit.test_scheduler.TestScheduler.test_client_promote each took like a minute and a half | 23:58 |
clarkb | I could see those going over the timeout limit if things were really loaded up | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!