| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-12 | |||
| 15:33:29 | melwitt | mriedem: ah yup, thanks for the heads up | |
| 15:33:32 | melwitt | will revisit that | |
| 15:39:55 | stephenfin | Pro tip #1: 'tox -e py27 -- --failing' runs all the tests that failed on a previous iteration | |
| 15:40:29 | stephenfin | Pro tip #2: 'tox -e py27 -- -n nova/tests/unit/virt/test_hardware.py' let's you run tests without needing to convert to a Python path | |
| 15:42:20 | mriedem | efried: alex_xu: arvindn05: karimull: on its way to the gate of horrors https://review.openstack.org/#/c/569498/ - i'll do a follow up for my comments | |
| 15:42:35 | efried | mriedem: cool mon | |
| 15:42:54 | mriedem | pass the dutchie | |
| 15:43:15 | mriedem | melwitt: ^ means another runway slot will be open today | |
| 15:43:16 | melwitt | that means we get to close out a bp right? woo | |
| 15:43:26 | melwitt | noyce. good news | |
| 15:44:45 | melwitt | stephenfin: protip #2 I didn't know about, thanks | |
| 15:46:13 | efried | I tend to use stestr run directly from the venv so I don't have to wait an extra 45 seconds for tox to do... whatever it does in "preparation". | |
| 15:47:15 | melwitt | I do too when I'm iterating on running tests | |
| 15:47:49 | stephenfin | efried: I think we discussed this before, but doesn't 'touch nova.egg_info' fix that for you? | |
| 15:48:50 | efried | stephenfin: That does sound familiar. Not sure. But I know this works :) | |
| 15:49:05 | stephenfin | Fair :) | |
| 15:49:07 | efried | stephenfin: I've got it in a bash function so I can kick it off easily | |
| 15:50:08 | stephenfin | I really need to figure out what's going on with tox there. It seems pretty useless, given how often I need to recreate stuff when dependencies change | |
| 15:51:11 | efried | i.e. very rarely, yah? | |
| 15:52:06 | stephenfin | Ever :) If it's doing a dependency check based on the timestamp of .egg_info, that check should be failing because dependencies have changed | |
| 15:52:07 | efried | Assuming it's dependency checks that are slow, if there was a tox --no-dep-check flag that let you bypass all that stuff, that would be coolness. | |
| 15:52:23 | stephenfin | If it's not failing, you'd have to wonder what the "dependency check" _is_ doing | |
| 15:52:24 | efried | oh, or that, if it's actually a bug that should just be fixed :) | |
| 15:52:52 | efried | well, occasionally tox does rebuild my venv. I assume it does that based on figuring out that something is out of date. | |
| 15:53:23 | stephenfin | Yeah, I'd rather some way to just disable it, personally. The gate will catch the rare case where a local version mismatch causes issues | |
| 15:53:44 | stephenfin | The only time I see a full rebuild is when tox.ini changes | |
| 15:53:45 | melwitt | mine never auto rebuilds the venv for me. I do it manually if I hit "no module X found" errors when things change | |
| 15:53:54 | stephenfin | (assuming you mean recreate) | |
| 15:53:58 | stephenfin | melwitt: Yeah, same here | |
| 15:54:18 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Compute: Handle reshaped provider trees https://review.openstack.org/576236 | |
| 15:54:21 | stephenfin | Hence, what _is_ tox doing :) | |
| 15:54:52 | melwitt | yeah... | |
| 15:54:55 | efried | If I know a dep is out of date, I'll enter the venv and pip install/upgrade the sucker manually. | |
| 15:55:02 | melwitt | I'd like to know too but I've no idea how to find out | |
| 15:55:04 | efried | Takes way less time than rebuilding the whole damn venv. | |
| 15:55:29 | melwitt | heh, I've done that in the past but nowadays I'm like meh | |
| 15:56:00 | stephenfin | efried: That. I personally let it rebuild but Real World Devs (TM) often fix this stuff themselves. I think a flag would be a good idea | |
| 15:56:08 | efried | Usually when I'm running tox it's because I actually want to run tests, not because I want to kick off a command and go eat lunch and come back to see if it has finished yet. | |
| 15:56:25 | stephenfin | ...as soon as we figure out what is taking that time when it's not rebuilding (the thing 'touch nova.*' solves) | |
| 15:56:58 | efried | Cool mon, let me know if you want me to try anything out. | |
| 15:57:43 | stephenfin | Ack. I'll try take a look tomorrow once I get somewhere on these functional tests for numa-aware-vswitch | |
| 15:57:59 | efried | That's not using nrp, is it? | |
| 15:58:12 | efried | (I haven't read the spec in yonks, have totally forgotten what it actually does) | |
| 15:58:58 | stephenfin | Nope, nothing to do with placement | |
| 15:59:33 | stephenfin | Not now, anyway. A fancier version of it might use it in the future but that's 2-3 cycles down the road, I'd imagine | |
| 16:03:01 | mriedem | TheJulia: do you know if there are any ironic jobs that can be used to test this rescue patch? https://review.openstack.org/#/c/416487/3 | |
| 16:03:05 | mriedem | https://review.openstack.org/#/c/416487/ | |
| 16:03:20 | mriedem | i know tempest tests rescue, we'd just have to flip the switch in some ironic job config | |
| 16:03:42 | TheJulia | mriedem: we've not merged them yet because of the nova patch not merging, looking it up | |
| 16:03:56 | mriedem | TheJulia: ok but we can see a depends-on patch passing tests right? | |
| 16:03:59 | TheJulia | that being said, the logs show it working in the proposed tempest patch | |
| 16:04:07 | mriedem | ah https://review.openstack.org/#/c/528699/ | |
| 16:04:09 | TheJulia | mriedem: already did if my memory is correct | |
| 16:04:20 | TheJulia | yup, thats the one | |
| 16:05:18 | TheJulia | https://review.openstack.org/#/c/528704/ | |
| 16:06:03 | mriedem | ok that depends on the plugin change which depends on the nova change, i see | |
| 16:06:48 | TheJulia | and I see you already rechecked it | |
| 16:06:49 | TheJulia | thanks! | |
| 16:07:00 | openstackgerrit | MultipleCrashes proposed openstack/nova master: Retry decorator fix for instances which go into ERROR state during bulk delete https://review.openstack.org/563418 | |
| 16:12:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Follow up for Ie49d605c66062d2548241d7e04f5a2a6b98c011e https://review.openstack.org/582292 | |
| 16:13:01 | kashyap | mriedem: The above commit message is really odd | |
| 16:13:40 | kashyap | (It's logically correct. But it can be turned into a sentence w/o a commit has :-)) | |
| 16:17:36 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Resource provider examples https://review.openstack.org/553461 | |
| 16:27:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: scheduler: Start utilizing RequestSpec.network_metadata https://review.openstack.org/564452 | |
| 16:27:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Add '[neutron] physnets' and related options https://review.openstack.org/564440 | |
| 16:27:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.network_metadata field https://review.openstack.org/564441 | |
| 16:30:42 | anupn | mriedem_away: Yes n-cpu showed the sec group used was wrong, and after changing that instance was launched :) | |
| 16:42:57 | stephenfin | dansmith: PEBCAK http://paste.openstack.org/show/725735/ (line 14) | |
| 16:43:25 | dansmith | stephenfin: heh, good | |
| 16:44:04 | stephenfin | Two days. | |
| 16:46:23 | melwitt | I know the feeling all too well | |
| 16:47:54 | dansmith | pebkac is way better than some obscure bug | |
| 16:48:05 | dansmith | feels stupid, but it's almost always better | |
| 16:49:30 | melwitt | true that | |
| 16:51:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.network_metadata field https://review.openstack.org/564441 | |
| 16:52:01 | stephenfin | Agreed | |
| 16:52:08 | stephenfin | and with that, I'm outta here | |
| 17:15:21 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Compute: Handle reshaped provider trees https://review.openstack.org/576236 | |
| 17:25:56 | openstackgerrit | melanie witt proposed openstack/nova master: Update process doc to be more generic about point of contact https://review.openstack.org/582312 | |
| 17:34:54 | melwitt | does anyone know if/how we can identify ARM64 platform in the libvirt driver? would it just be fields.Architecture.AARCH64? asking in the context of this bug I'm triaging https://bugs.launchpad.net/nova/+bug/1748280 | |
| 17:34:55 | openstack | Launchpad bug 1748280 in nova (Ubuntu) "'nova reboot' on arm64 is just 'nova reboot --hard' but slower" [Undecided,Confirmed] | |
| 17:39:15 | mriedem | the host capabilities should have the arch | |
| 17:40:17 | melwitt | yeah, wasn't sure if it's ARMV6 or ARMV7 or ARMV7B or AARCH64 or all of them. commenting on the bug | |
| 17:44:17 | melwitt | this is a troubling one from pike https://bugs.launchpad.net/nova/+bug/1781368 | |
| 17:44:18 | openstack | Launchpad bug 1781368 in OpenStack Compute (nova) "KeyError: 'flavor' when nova boot" [Undecided,New] - Assigned to zhaolihui (zhaolh) | |
| 17:44:43 | melwitt | actually, I can check some stable/pike gate runs to see if that's in the log | |
| 17:46:21 | dansmith | that trace shows novaclient code | |
| 17:46:27 | dansmith | not on the server side | |
| 17:46:34 | melwitt | oh, guh | |
| 17:48:16 | melwitt | before that, the server returns a 404 which seems wrong though. hm. | |
| 17:54:53 | dansmith | yeah which might be related, but also, | |
| 17:55:00 | dansmith | isn't 2.60 much later than pike? | |
| 17:55:27 | dansmith | 2.53 is pike | |
| 17:55:54 | melwitt | oh yeah, queens. 17.0.5 is queens, sorry | |
| 17:56:02 | dansmith | okay | |
| 18:03:16 | melwitt | this is a weird one that I've noticed myself when trying to trace requests during debugging, periodic tasks sharing request_id with actual requests. the weird thing is I swear this did not use to happen in the past, but AFAIK nothing has changed around the periodic task context use https://bugs.launchpad.net/nova/+bug/1773102 | |
| 18:03:17 | openstack | Launchpad bug 1773102 in OpenStack Compute (nova) "Abnormal request id in logs" [Undecided,New] | |
| 18:03:49 | melwitt | I don't know why this has started happening in the last couple of cycles (not sure when it started) | |
| 18:04:48 | melwitt | maybe cell targeting is messing with it somehow | |
| 18:05:01 | efried | melwitt: Nothing to do with the global request ID work? | |