| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-11 | |||
| 16:50:30 | ygk_12345 | so i will just retry with nova control plane restart | |
| 16:50:34 | sean-k-mooney | that will resullt in a different serivce uuid and break placment | |
| 16:50:49 | sean-k-mooney | since the hostname uuid pair will fail the unique constrait | |
| 16:50:56 | ygk_12345 | ok | |
| 16:51:20 | sean-k-mooney | try restartin the contolplane contianer but i expect them to fail | |
| 16:51:28 | sean-k-mooney | without the workaround option set | |
| 16:51:41 | sean-k-mooney | since your compute service versions shoudl be <56 | |
| 16:51:44 | ygk_12345 | its working for our other setups perfectly | |
| 16:51:46 | sean-k-mooney | since you have not started them | |
| 16:52:40 | ygk_12345 | anyway let me try and will bother you later | |
| 16:52:44 | sean-k-mooney | ygk_12345: what you are currently trying is not something we expect to wrok upstream so if you are able to do it else wehre you must have the workaround enabled or a downstream patch | |
| 16:52:49 | sean-k-mooney | ok | |
| 16:53:03 | ygk_12345 | sean-k-mooney: thanks | |
| 19:53:19 | mnaser | does nova like to take cpu flag related decisions or is that not a direction nova wants to take anymore | |
| 19:53:54 | mnaser | i've got 100% identical cpus in terms of make/model that fail to live migrate, and it seems like this is because some of them have `tsx-ctrl` and `taa-no` and others dont. | |
| 19:54:24 | mnaser | those two are apparently found in cpu MSR and not in cpuid so they're not visible (see here https://www.qemu.org/docs/master/system/qemu-cpu-models.html?highlight=taa#important-cpu-features-for-intel-x86-hosts ) | |
| 19:55:04 | mnaser | should we warn on it? should we just disable it? it seems like "Same cpu model" isn't really even valid anymore lol | |
| 22:32:09 | TheJulia | It hasn't really felt valid for a long time, to me... but I had a 6 week order lag and ran into something super similar ~12-13 years ago. | |
| #openstack-nova - 2022-07-12 | |||
| 00:31:20 | sean-k-mooney[m] | mnaser: that is something that libvirt not nova has always been in charge of | |
| 00:31:52 | sean-k-mooney[m] | intel can change the cpu flags via microcode and when it comes to tsx they have on several ocations | |
| 00:32:44 | sean-k-mooney[m] | nova for the most part triese to leave all cpu compatiablity checkign to the hyperviors the virt driver is managing | |
| 00:33:00 | sean-k-mooney[m] | the excption to this is the abstction we have via traits | |
| 00:35:17 | sean-k-mooney[m] | nova sepcficaly the libvirt driver uses the libvirt api to introspect the cpu to report traits | |
| 00:35:53 | sean-k-mooney[m] | we do not use cpuid or msrs to detect this as its libvirts jobs to unify the feature flags in a vendor indepentent way | |
| 00:36:18 | sean-k-mooney[m] | and its also libvirts job to determin cpu comparitblity for the most part in live migration. | |
| 00:36:54 | sean-k-mooney[m] | nova has never used the current cpu model or cpu flags to make schduling decision for migrations | |
| 00:37:34 | sean-k-mooney[m] | if you configure required traits in the flavor or image we can take those into account but the current cpu flags of a vm are not an input into the schduleing desicion. | |
| 00:38:09 | sean-k-mooney[m] | and they never have been that has alwasy been delegated to the operator to enforce using host aggreates | |
| 00:39:04 | sean-k-mooney[m] | so nova has not changed in this regard since i started working on openstack for the most part. | |
| 07:33:04 | opendevreview | Sylvain Bauza proposed openstack/nova master: api: Drop generating a keypair and add special chars to naming https://review.opendev.org/c/openstack/nova/+/849133 | |
| 07:33:40 | bauzas | gibi: sean-k-mooney: I'm done with the keypair generation removal | |
| 07:34:13 | bauzas | given Uggla's patches seem good for unshelve, I'll rebase my branch up on Uggla's unshelve API change once he rebases | |
| 07:35:00 | bauzas | gibi: sean-k-mooney: I'll actually be off from tonight to next week (I'll also take Friday) | |
| 07:38:40 | gibi | bauzas: thanks for moving you stuff top of Uggla's that is nice selflessness | |
| 07:39:12 | gibi | bauzas: have a nice PTO, do you have someting on your PTL table we should keep in mind while you are away? | |
| 07:39:37 | bauzas | gibi: nothing in my mind, I'll abandon the yoga open specs next week then | |
| 07:40:04 | bauzas | we're on yoga-2 on Thursday | |
| 07:40:13 | bauzas | July-14 | |
| 07:40:23 | bauzas | that will mean we won't accept new specs | |
| 07:40:33 | bauzas | but actually, we don't have a lot of them for zed | |
| 07:42:10 | gibi | OK, so I guess you will do the official freeze mail when you are back on Monday. That is KO | |
| 07:42:13 | gibi | OK | |
| 07:42:29 | bauzas | yup | |
| 07:42:45 | bauzas | unless you wanna use the axe | |
| 07:43:16 | gibi | nope | |
| 07:43:22 | gibi | the axe is yours :) | |
| 07:43:43 | gibi | and as you said we don't have much open | |
| 07:43:51 | gibi | so there is no need for the axe | |
| 07:45:47 | bauzas | gibi: yeah, in my email, I'll clarify the situation https://review.opendev.org/q/project:openstack/nova-specs+status:open+file:%255Especs/zed/.* | |
| 07:46:08 | bauzas | about ironic's discussion, this won't need to be hold by the deadline | |
| 07:46:37 | bauzas | so only artom's spec is impacted... unless he's able to revive it before the deadline | |
| 07:47:25 | bauzas | I don't know if sean-k-mooney had wheels for https://review.opendev.org/c/openstack/nova-specs/+/821419 | |
| 07:49:51 | bauzas | gibi: about the API changes, those are stacking | |
| 07:49:57 | bauzas | with the same API microversion | |
| 07:50:12 | bauzas | I'm not really worried yet | |
| 07:50:40 | bauzas | but maybe next week, I'd propose some etherpad for trying to organize series between them | |
| 07:50:59 | bauzas | like, Uggla would take the 2.91 as he's close to be merged | |
| 07:51:17 | bauzas | mine would take 2.92 as this is a quite self-contained change | |
| 07:51:35 | bauzas | and we would debate on other patches for 2.93 and others | |
| 07:51:52 | bauzas | idea being that owners of those patches would have time in advance to rebase | |
| 08:03:51 | opendevreview | Sylvain Bauza proposed openstack/nova master: zuul: Put Centos9 Stream job periodic-weekly and experimental https://review.opendev.org/c/openstack/nova/+/849463 | |
| 08:03:58 | bauzas | gibi: sean-k-mooney: ^ | |
| 08:05:24 | bauzas | Uggla: good morning | |
| 08:06:00 | gibi | bauzas: thanks for the summary above. I agree with the plans | |
| 08:06:54 | Uggla | bauzas, o/ | |
| 08:06:55 | gibi | I'm +2 on the centos9 patch | |
| 08:06:59 | gibi | Uggla: o/ | |
| 08:07:27 | bauzas | Uggla: as I mentioned above, I'll rebase my keypair generation API change on top of your unshelve API patch | |
| 08:08:08 | bauzas | gibi: do you think we actually need to rebase all our branches ? Can't I just write my patch saying "this is 2.92" ? | |
| 08:08:44 | bauzas | of course, I would get a merge conflict because gerrit wouldn't be able to rebase the rest api microversion list doc | |
| 08:09:03 | bauzas | but this would waaaaay simplify the merge conflict resolution | |
| 08:10:30 | Uggla | bauzas, regarding unshelve have you entered your comments ? | |
| 08:10:41 | bauzas | Uggla: not yet, that's my next move | |
| 08:11:07 | bauzas | Uggla: I have a direct interest in merging your branch | |
| 08:11:55 | gibi | bauzas: I'm not sure you can verify your code if it is on 2.92 without 2.91 existing | |
| 08:12:13 | gibi | but other than that I'm OK to have 2.92 haning off 2.90 with a merge conflict | |
| 08:12:31 | Uggla | bauzas, ok I'll wait then I will fix gibi and yours quickly so you could probably merge. | |
| 08:12:45 | gibi | I'm here so I can quickly re-review | |
| 08:14:24 | bauzas | gibi: yeah the tests will probably fail | |
| 08:14:47 | bauzas | but I see this as a security layer in case of a distracted core reviewer | |
| 08:15:13 | bauzas | people can work on the the latest microversion, wait for Zuul +1ing | |
| 08:15:30 | bauzas | and then modifying their patches with a placeholder microversion | |
| 08:15:44 | bauzas | Zuul would say no, but we'd have evidence this was working before | |
| 08:16:20 | bauzas | and a merge resolution would solve it quickier once the concurrent patch merges | |
| 08:16:44 | bauzas | I think I'm fool enough to test it on my series | |
| 08:17:00 | bauzas | once Zuul blesses my last revision | |
| 08:17:36 | gibi | bauzas: yeah if you want then you can test this on the keypair series | |
| 08:23:06 | opendevreview | Amit Uniyal proposed openstack/nova master: add regression test case for bug 1978983 https://review.opendev.org/c/openstack/nova/+/849104 | |
| 09:33:34 | bauzas | Uggla: -1 on https://review.opendev.org/c/openstack/nova/+/831507 due to missing UTs on nova.compute.api | |
| 09:34:05 | bauzas | you wrote excellent conditionals (kudos to gibi and you) but you don't verify them :) | |
| 09:34:35 | bauzas | also, please help poor reviewers by not reindenting tests, that doesn't help to see the bone of the change :) | |
| 09:34:37 | gibi | bauzas: there is a bunch of functional coverage that I felt enough | |
| 09:35:25 | bauzas | gibi: yeah but we already have UTs for az | |
| 09:35:46 | gibi | ack, I'm not against having exta UTs too, just stated why I ' | |
| 09:35:47 | bauzas | and the functests are done on the latter patch | |
| 09:35:49 | gibi | why I'm OK as is | |
| 09:40:07 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check, if admin has set compute service down https://review.opendev.org/c/openstack/nova/+/848886 | |
| 09:42:00 | Uggla | bauzas, you mean the conditionals with host and az ? There are fully tested with functional tests. Am I missing something ? | |
| 09:44:13 | bauzas | Uggla: you test them on the functests in https://review.opendev.org/c/openstack/nova/+/845897/4/nova/tests/functional/test_servers.py | |
| 09:44:20 | bauzas | which is the latter patch | |