| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-18 | |||
| 19:26:36 | opendevreview | Stephen Finucane proposed openstack/nova master: db: De-duplicate list of removed table columns https://review.opendev.org/c/openstack/nova/+/814489 | |
| 19:26:36 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove nova-network models https://review.opendev.org/c/openstack/nova/+/812151 | |
| 19:27:22 | stephenfin | melwitt: Regarding that question on the issues from with ARM hosts and the migrations, it could be that the migrations are simply taking too long now on underpowered hosts. I don't know why though since there's only one (well, now two) migrations there. I'll investigate | |
| 19:27:40 | stephenfin | If nothing else, we can reuse gibi's trick of running those particular tests in series instead of parallel | |
| 19:27:58 | stephenfin | (at least I think that's what his tox changes did - I'll have to revisit) | |
| 21:14:56 | opendevreview | melanie witt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/c/openstack/nova/+/712139 | |
| 21:14:57 | opendevreview | melanie witt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143 | |
| 21:14:57 | opendevreview | melanie witt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142 | |
| 21:14:58 | opendevreview | melanie witt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749 | |
| 21:14:58 | opendevreview | melanie witt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707 | |
| 21:14:59 | opendevreview | melanie witt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/c/openstack/nova/+/615180 | |
| 21:14:59 | opendevreview | melanie witt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/c/openstack/nova/+/713301 | |
| 21:15:00 | opendevreview | melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499 | |
| 21:15:00 | opendevreview | melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498 | |
| 21:15:02 | opendevreview | melanie witt proposed openstack/nova master: WIP Enable unified limits in the nova-next job https://review.opendev.org/c/openstack/nova/+/789963 | |
| 21:15:02 | opendevreview | melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271 | |
| #openstack-nova - 2021-10-19 | |||
| 05:31:27 | hgy | 1111 | |
| 08:08:48 | bauzas | good morning Nova | |
| 08:16:23 | gibi | bauzas: good morning | |
| 08:16:38 | bauzas | gibi: hey ;) | |
| 08:36:05 | brinzhang | bauzas, gibi: we cannot open the ethercalc, it report Service Unavailable(503), about the nova-cyborg interaction vGPU topic you can talked and pasting the decision on the etherpad, and we will look it ASAP | |
| 08:36:28 | brinzhang | bauzas, gibi: thanks | |
| 08:43:38 | gibi | bauzas: fyi, reported a new gate failure bug https://bugs.launchpad.net/nova/+bug/1947687 | |
| 08:44:26 | gibi | brinzhang: we will have that session today from 13:00 UTC | |
| 08:47:49 | bauzas | brinzhang: the cyborg-nova meeting will happen at 1pm UTC | |
| 08:48:06 | bauzas | gibi: ack | |
| 08:48:27 | gibi | bauzas: I'm not jumping to investigative mode for tha bug now. | |
| 08:51:25 | brinzhang | ack,but I cannot open https://ethercalc.openstack.org/8tum5yl1bx43 this page | |
| 08:52:37 | brinzhang | report 503 now, in cyborg PTG meeting we were usd tencent meeting instead of zoom | |
| 08:58:31 | gibi | brinzhang: could you open https://ptg.opendev.org/ptg.html ? | |
| 08:59:06 | gibi | brinzhang: if yes, then try to click on the nova cell in the 13:00 UTC column | |
| 08:59:20 | gibi | brinzhang: that should bring you in the zoom call | |
| 08:59:35 | gibi | (probably nobody there at the momement) | |
| 09:00:44 | bauzas | brinzhang: what gibi said | |
| 09:00:54 | bauzas | they moved from ethercalc AFAIK | |
| 09:03:03 | brinzhang | ack | |
| 09:03:13 | opendevreview | Balazs Gibizer proposed openstack/nova-specs master: Re-propose QoS minimum guaranteed packet rate https://review.opendev.org/c/openstack/nova-specs/+/814531 | |
| 09:16:38 | stephenfin | gibi: bauzas: Have you noticed many failures on the 'nova.tests.unit.db.main.test_migrations.TestModelsSyncMySQL.test_models_sync' and 'TestModelsLegacySyncMySQL.test_models_sync' tests? | |
| 09:16:56 | gibi | stephenfin: I'm not | |
| 09:18:07 | stephenfin | Ah, okay, I'm seeing a lot of failures on the bp/remove-sqlalchemy-migrate series and trying to figure out if I've already broken master slightly or if its one of the unmerged patches that's breaking things, e.g. https://review.opendev.org/c/openstack/nova/+/812144 | |
| 09:24:38 | songwenping | gibi,bauzas: when i stop nova_compute service and evacuate the vm on the host, then i delete the vm when it is evacuating, the vm is local deleted by nova-api, but the libvirt process is not terminated, and the resources like GPU are still used by the vm process, how can we handle the vm process? | |
| 09:33:46 | gibi | songwenping: you delete the VM while it is being evacuated? | |
| 09:34:54 | songwenping | yes | |
| 09:35:18 | gibi | and then you start the source compute back up | |
| 09:35:48 | songwenping | yeah | |
| 09:36:01 | gibi | and the the source compute does not clean up the instance? | |
| 09:36:22 | songwenping | yeah | |
| 09:36:35 | gibi | I think the source compute should detect that there was a local delete while it was down and clean up the instance | |
| 09:36:38 | gibi | so it is probably a bug | |
| 09:37:15 | songwenping | i am looking into the init_host process. | |
| 10:14:04 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Increase timeout for migration tests https://review.opendev.org/c/openstack/nova/+/814547 | |
| 10:14:51 | stephenfin | gibi: bauzas: I'm not sure how to test that, but I'm pretty sure we're going to need it to at least fix the migrations issues we've been seen in the ARM CI jobs ^ | |
| 10:15:00 | stephenfin | I guess I can mash recheck | |
| 10:16:43 | gibi | stephenfin: ack | |
| 10:16:54 | gibi | is it only affects ARM? | |
| 10:34:16 | stephenfin | I don't think so. I've seen failures on x86 also, but ARM is particularly badly affected | |
| 10:34:33 | stephenfin | example: https://zuul.opendev.org/t/openstack/build/00197f336d1249e4a55255769f24faf7 | |
| 10:34:42 | stephenfin | vs (aarch64) https://zuul.opendev.org/t/openstack/build/f693ac69815f4b92b75f7f8dc5ec3803 | |
| 10:34:49 | stephenfin | gibi: ^ | |
| 10:40:52 | gibi | stephenfin: when it passes it is also slow just not too slow to hit the timeout? | |
| 10:42:39 | gibi | I see this runs | |
| 10:42:40 | gibi | nova.tests.unit.db.main.test_migrations.TestModelsSyncMySQL.test_models_sync 11.154 | |
| 10:42:48 | gibi | where it is actully fast | |
| 10:43:00 | gibi | https://zuul.opendev.org/t/openstack/build/8c4f8a81770e4dd1a523e86690ce340b/log/job-output.txt | |
| 10:44:35 | gibi | anyhow I'm not against extending the timeout | |
| 10:44:51 | gibi | I just feel that we still not fully grok what can be the problems with this db tests | |
| 10:49:31 | opendevreview | Ilya Popov proposed openstack/nova master: Fix to use NUMA cell with more free memory first https://review.opendev.org/c/openstack/nova/+/805649 | |
| 11:09:02 | stephenfin | gibi: Yeah, I see about 7-8 seconds runtime on my localhost but it _seems_ very much dependent on the environment. Perhaps it's because some VMs are using spinning rust and others are SSD based? | |
| 11:09:30 | stephenfin | We can compare these two builds https://zuul.opendev.org/t/openstack/build/00197f336d1249e4a55255769f24faf7 (iWeb) and https://zuul.opendev.org/t/openstack/build/8c4f8a81770e4dd1a523e86690ce340b (OVH) | |
| 11:14:06 | stephenfin | gibi: Yeah, crazy differences in the MySQL tests https://paste.opendev.org/show/810073/ | |
| 11:15:11 | gibi | I remember I saw this craxy differences before alembic too, and I had not explanation for that | |
| 11:16:49 | songwenping | gibi: the evacuation status is failed, and this filter[1] cannot get the vm. [1]https://review.opendev.org/plugins/gitiles/openstack/nova/+/refs/heads/master/nova/compute/manager.py#703 | |
| 11:17:33 | songwenping | so the vm process is not destory when the compute service restore. | |
| 11:18:51 | gibi | songwenping: the problem with failed evacuation itself is that it does not imply the the VM is deleted (and hence the evac failed). If the evac fail for other reasons then keeping the VM on the source host after recovery is logical | |
| 11:19:32 | gibi | so I think you have to make some logic changes where the failed evacuations are also queried but only if the instance is already marked deleted | |
| 11:22:56 | songwenping | to report a bug? | |
| 11:24:35 | stephenfin | Looks like https://review.opendev.org/c/openstack/nova/+/814547/ is working at least, since the aarch64 jobs are passing. I left a comment for bauzas | |
| 11:39:03 | sean-k-mooney | stephenfin: i do have an arm laptop, my pinebook pro i can proably try and run it or power it up and let you ssh into it an use it although i proably will have to reinstall the os before its really useful | |
| 11:40:57 | stephenfin | sean-k-mooney: I don't think it's specific to the architecture. I think it's the host in general. Bad I/O performance or something similar | |
| 11:41:02 | stephenfin | but that's just a theory | |
| 11:41:13 | sean-k-mooney | ah ok | |
| 11:52:33 | opendevreview | Stephen Finucane proposed openstack/nova master: docs: Add notes about IoOpsWeigher, BuildFailureWeigher https://review.opendev.org/c/openstack/nova/+/814561 | |
| 11:52:34 | opendevreview | Stephen Finucane proposed openstack/nova master: docs: Add new architecture guide https://review.opendev.org/c/openstack/nova/+/814563 | |
| 11:52:34 | opendevreview | Stephen Finucane proposed openstack/nova master: docs: Add a new cells v2 document https://review.opendev.org/c/openstack/nova/+/814562 | |
| 11:54:48 | stephenfin | bauzas: you're probably interested in https://review.opendev.org/c/openstack/nova/+/814561 also when you're back | |
| 12:02:00 | gibi | songwenping: sure, a bug is needed too | |
| 12:03:43 | gibi | stephenfin: yep it seems to work. It runs the test longer than before | |
| 12:04:08 | gibi | nova.tests.unit.db.main.test_migrations.TestMigrationsWalkMySQL.test_walk_versions [372.936004s] | |
| 12:04:15 | gibi | that is a lot of time :) | |
| 12:06:59 | sean-k-mooney | gibi: stephenfin im proably goingt to add https://review.opendev.org/c/openstack/nova/+/805649 to the ptg adgenda at the end but i think directionally this is the correct approch to take and once the testing is built out and a release note added its close to a complete | |
| 12:07:43 | sean-k-mooney | if ye have time could ye take a look and or set review priority on it if you think it should have it | |
| 12:08:25 | gibi | sean-k-mooney: ack, does it have a bp attached? I'm not 100% sure it is a bug per se | |
| 12:08:34 | sean-k-mooney | tl;dr its adressign numa blancing and pci affintiy my making prefer actully prefer the numa node | |
| 12:08:46 | sean-k-mooney | gibi: right i think it a blueprint not a bug | |
| 12:09:16 | sean-k-mooney | so no it currently does not | |
| 12:10:26 | gibi | sean-k-mooney: also it worth discussing on the ptg. I think we need a consensus on what are the inputs we are sorting the NUMA cells on | |
| 12:10:41 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1893121 was my orginal bug | |
| 12:11:16 | sean-k-mooney | which when we lass discussed it we said was a blueprint | |
| 12:11:23 | sean-k-mooney | gibi: yes that is why i was going to add it | |
| 12:11:39 | sean-k-mooney | to make sure we agreed on the algoritim | |