| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-13 | |||
| 19:30:43 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: Make dest send NUMAMigrateData to the source https://review.openstack.org/634828 | |
| 19:46:42 | aspiers | what's the easiest way to set the logger to DEBUG level in functional tests? | |
| 19:49:32 | cdent | if you're based off the nova base class, you probably already have it, but if not self.flag('debug', 'True') might do it. I can't remember for sure | |
| 19:49:54 | dansmith | there's an environment variable | |
| 19:50:06 | aspiers | ^^^ that's the answer I was hoping for ;-) | |
| 19:50:09 | melwitt | aspiers: OS_DEBUG=1 | |
| 19:50:10 | cdent | there's a fixture that will swallow a lot of stuff too | |
| 19:50:16 | dansmith | yeah that^ | |
| 19:50:21 | aspiers | awesome, thanks! :-D | |
| 19:50:29 | melwitt | have fun | |
| 19:50:48 | aspiers | found it in nova/tests/fixtures.py now | |
| 19:51:11 | melwitt | OS_DEBUG=1 tox -efunctional test_stuff | |
| 19:51:58 | melwitt | that will show you log level debug and less during a test run | |
| 19:52:05 | aspiers | cdent: I could maybe answer that if I understood your answer, but I fear it's too sophisticated for me ;-) | |
| 19:52:33 | aspiers | melwitt: yep the env var is working great, although I'm running stestr directly in order to run individual groups of tests quicker | |
| 19:52:40 | melwitt | smart | |
| 19:52:41 | aspiers | going through tox is slow :-/ | |
| 19:52:44 | cdent | aspiers: I think I was answering "I want to manipulate log handling in a functional test I'm making" not "I want to see the debug logs" | |
| 19:52:57 | aspiers | cdent: ah yeah, thought it might be something like that :) | |
| 19:53:12 | aspiers | sorry for not being clear enough in the original q | |
| 19:53:22 | cdent | no worries, worked out in the end | |
| 19:54:23 | aspiers | melwitt: shall I add OS_DEBUG to HACKING.rst? | |
| 19:55:59 | dansmith | aspiers: wouldn't you rather keep it secret and seem smart the next time a newbie comes along? | |
| 19:56:38 | aspiers | dansmith: tempting, but I think it's even more satisfying to be able to RTFH somebody by pointing them to docs I wrote myself ;-p | |
| 19:56:54 | dansmith | aspiers: okay as long as shame is involved either way | |
| 19:57:02 | aspiers | that way I can appear smart *and* conceited | |
| 19:57:05 | aspiers | exactly | |
| 19:57:30 | melwitt | haha, nice | |
| 19:57:44 | aspiers | after all I only went into coding in order to be able to shame others :-p | |
| 19:58:36 | melwitt | that's the right motivation | |
| 19:58:49 | aspiers | glad we're on the same page XD | |
| 19:59:17 | melwitt | and yeah, it would be a good addition to HACKING.rst. and also our contributor doc/ | |
| 20:00:38 | aspiers | melwitt: under https://docs.openstack.org/nova/latest/contributor/testing.html or a new page? | |
| 20:00:52 | aspiers | presumably https://docs.openstack.org/nova/latest/contributor/index.html#testing isn't a good place for it | |
| 20:01:20 | melwitt | lemme see, I think I saw a place | |
| 20:02:33 | melwitt | I was looking at https://docs.openstack.org/nova/latest/contributor/development-environment.html#running-unit-tests but yeah, similarly doesn't have the same level of detail that HACKING.rst does | |
| 20:03:08 | aspiers | I could just add a link from there to HACKING? | |
| 20:03:21 | melwitt | that also looks really old :\ | |
| 20:03:30 | aspiers | Yeah | |
| 20:07:58 | melwitt | aspiers: I think a link to HACKING for nova-specific test running notes would be a good fit there on that last page. because the existing doc is a link to the general openstack-wide test running guide | |
| 20:08:52 | aspiers | melwitt: yeah OK ... but how do I link to HACKING? since it's not published with the docs :-/ | |
| 20:08:59 | aspiers | link to cgit? | |
| 20:09:21 | aspiers | http://git.openstack.org/cgit/openstack/nova/tree/HACKING.rst doesn't render | |
| 20:09:47 | aspiers | https://github.com/openstack/nova/blob/master/HACKING.rst might be nicer | |
| 20:10:00 | aspiers | but kind of breaks the unspoken "avoid GitHub" convention | |
| 20:10:35 | openstackgerrit | Adam Spiers proposed openstack/nova master: Document how to make tests log at DEBUG level https://review.openstack.org/636744 | |
| 20:10:55 | aspiers | I guess the link to HACKING can be done separately anyway | |
| 20:11:37 | melwitt | yeah, we can punt that idea since there's not an obvious counterpart in our docs | |
| 20:11:46 | openstackgerrit | Adam Spiers proposed openstack/nova master: Drop specific versions of openSUSE-based distributions https://review.openstack.org/636745 | |
| 20:12:34 | melwitt | I had been thinking about this I think, which is not nova docs (or even docs.o.o) https://wiki.openstack.org/wiki/Testr | |
| 20:12:44 | melwitt | from back in the day | |
| 20:12:45 | openstackgerrit | Adam Spiers proposed openstack/nova master: Document how to make tests log at DEBUG level https://review.openstack.org/636744 | |
| 20:12:54 | aspiers | ah yeah | |
| 20:46:19 | openstackgerrit | Adam Spiers proposed openstack/nova master: Document how to make tests log at DEBUG level https://review.openstack.org/636744 | |
| 21:04:03 | aspiers | please can someone explain how the functional tests mock responses from the placement API? | |
| 21:04:25 | aspiers | I'm lost in a twisty maze of fixture code | |
| 21:05:17 | mriedem | i believe the PlacementFixture is pulled in from the placement repo | |
| 21:05:19 | mriedem | via tox siblings | |
| 21:05:23 | aspiers | ahhhhh | |
| 21:05:27 | aspiers | that's why I couldn't find it | |
| 21:05:36 | aspiers | thanks! | |
| 21:05:52 | mriedem | https://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/placement.py#L27 | |
| 21:07:05 | cdent | aspiers: not mocks. 100% functionally real. | |
| 21:07:05 | aspiers | yeah, looks like the actual fixtures are in gabbits.py | |
| 21:07:24 | mriedem | aspiers: the gabbits are placement functional tests in placement | |
| 21:07:27 | aspiers | cdent: yeah, I see that now :) | |
| 21:07:44 | mriedem | nova uses the PlacementFixture for stubbing out the nova.scheduler.client.report.SchedulerClient calls, which is essentially nova's placement client | |
| 21:07:50 | mriedem | but yeah not really stubs | |
| 21:07:55 | mriedem | hits the actual placement api and db | |
| 21:08:54 | aspiers | mriedem: I'm trying to figure out why the HW_CPU_X86_VMX trait is missing in your traits functional test which I've rebased | |
| 21:09:10 | aspiers | the expectation that it's there is hard-coded, and I couldn't see why | |
| 21:13:39 | aspiers | actually I still can't | |
| 21:13:45 | aspiers | does it come from GranularFixture maybe? | |
| 21:14:21 | aspiers | https://review.openstack.org/#/c/538498/8/nova/tests/functional/test_servers.py@2007 | |
| 21:14:33 | aspiers | ^^^ this is what's confusing me | |
| 21:15:26 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Microversion 2.68: Remove 'forced' live migrations, evacuations https://review.openstack.org/635131 | |
| 21:18:27 | mriedem | i'm not sure what you're hitting, | |
| 21:18:30 | mriedem | but i see this in the test failure | |
| 21:18:31 | mriedem | AttributeError: <class 'nova.virt.fake.SmallFakeDriver'> does not have the attribute 'get_traits' | |
| 21:19:34 | mriedem | that method used to exist in the base class https://review.openstack.org/#/c/538498/7/nova/virt/driver.py@905 | |
| 21:19:36 | mriedem | but no longer does | |
| 21:19:53 | mriedem | HW_CPU_X86_VMX is a standard trait in the os-traits library, | |
| 21:19:59 | mriedem | the placement api puts that into the traits table on startup | |
| 21:21:33 | mriedem | dansmith: this had to be tweaked but do you want to re-approve https://review.openstack.org/#/c/551302/ | |
| 21:22:44 | dansmith | ack | |
| 21:39:10 | melwitt | mriedem: commented on https://review.openstack.org/636701, it seems to me we do need to lock around the bdm lookup, unless I'm missing something | |
| 22:14:37 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Lock detach_volume https://review.openstack.org/636701 | |
| 22:14:52 | mriedem | changed | |
| 22:17:17 | aspiers | mriedem: ignore the get_traits failure, I already fixed it but didn't push a new patchset yet | |
| 22:18:31 | aspiers | I guess I can push a new one and you'll see the exact failure | |
| 22:20:34 | openstackgerrit | Adam Spiers proposed openstack/nova master: WIP: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498 | |
| 22:34:59 | aspiers | mriedem: https://gist.github.com/aspiers/d64eff8a1d5594ad9763ebbd192d36b1 | |
| 22:42:29 | mriedem | yeah it's failing because you removed the get_traits mock which was returning ['CUSTOM_FOO', 'HW_CPU_X86_VMX'] | |
| 22:42:35 | mriedem | from the drier | |
| 22:42:35 | aspiers | DOH | |
| 22:42:39 | mriedem | *driver | |
| 22:42:40 | aspiers | lol | |
| 22:42:47 | aspiers | missed that | |
| 22:43:45 | mriedem | you essentially need to stub the driver.update_provider_tree method with a fake so you can intercept the provider tree and shove your traits into it | |
| 22:43:46 | mriedem | i think | |