| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-06 | |||
| 09:07:01 | songwenping | yeah, tried 10.5.0, still has no this attribute. | |
| 09:07:55 | gibi | frickler: I would say, use the matching version | |
| 09:16:02 | frickler | fwiw I don't see the above symbol either on 22.04, libvirt version 8.0.0-1ubuntu7.10 | |
| 09:16:57 | frickler | songwenping: do you use libvirt from ubuntu or a newer version built from source? | |
| 09:18:12 | songwenping | libvirt on ubuntu with 'pip install libvirt-python' | |
| 09:21:44 | gibi | frickler: I don't see it either in ubuntui 22.04 installed python-libvirt with apt | |
| 09:23:30 | songwenping | i replace VIR_NODE_DEVICE_DEFINE_XML_VALIDATE with 1 and the vm is created successful. | |
| 09:26:30 | frickler | I only found this single ref in nova code, does it mean this is not tested on 22.04? or does it need newer libvirt from UCA? can't check the latter right now https://opendev.org/openstack/nova/blame/branch/master/nova/virt/libvirt/host.py#L1267 | |
| 09:27:41 | gibi | nova declares libvirt min version as 8.0.0 | |
| 09:27:49 | gibi | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L221 | |
| 09:28:38 | frickler | but devstack loads uca, so maybe this isn't really tested anywhere | |
| 09:28:50 | gibi | yeah | |
| 09:29:27 | frickler | also MIN_LIBVIRT_VERSION is still 7.0.0, NEXT_MIN_LIBVIRT_VERSION is only for the future, isn't it? | |
| 09:29:56 | gibi | frickler: sorry you are right | |
| 09:30:07 | gibi | frickler: so yeah we should work with 7.0.0 | |
| 09:31:14 | gibi | but the persistent mdev feature that introduced the usage of the constant only enabled with 7.3.0 or higher https://github.com/openstack/nova/commit/74befb68a79f8bff823fe067e0054504391ee179#diff-486ddc37ce8e7c105a51566dd2cffbda034f28fae7eaad2e74abf470ab296352R248 | |
| 09:31:31 | gibi | still it seems the constant is missing in those old libvirts | |
| 09:42:18 | frickler | seems uca no longer has newer libvirt, so devstack is running with the same 8.0.0 currently that I checked. makes me wonder why tests aren't failing, or maybe there is no integrated test for mdevs? | |
| 09:42:30 | gibi | frickler: we test with 8.0.0 https://zuul.opendev.org/t/openstack/build/38facdd66a1e4e69bd6995fea4174d82/log/job-output.txt#9305 we just don't test mdevs | |
| 09:43:30 | sean-k-mooney | frickler: we dont test mdevs upstream yet | |
| 09:43:43 | sean-k-mooney | frickler: it requires us to compile a kernel module | |
| 09:43:49 | gibi | I think we will test is via https://review.opendev.org/q/topic:%22mtty_support%22 | |
| 09:43:55 | sean-k-mooney | frickler: bauzas is currently working on a job for that | |
| 09:44:12 | sean-k-mooney | gibi: yep that the series | |
| 09:44:48 | sean-k-mooney | although at the moment bauzas is working on it in a different job instead of nova-next like we orginally proposed | |
| 09:44:52 | gibi | frickler, sean-k-mooney: so to conclude we have a bug on master as with libvirt 7.3.0 (or 8.0.0) the persistent mdev feature does not work due to the missing constant libvirt.VIR_NODE_DEVICE_CREATE_XML_VALIDATE | |
| 09:45:05 | gibi | I will file a bug... | |
| 09:45:34 | sean-k-mooney | am we are ment to have a falback | |
| 09:45:42 | sean-k-mooney | thats form melwitt's series | |
| 09:46:11 | sean-k-mooney | we only supprot persistance in a later libvirt and falback to the old way when runingon older libvirt | |
| 09:46:17 | sean-k-mooney | at least that was teh plan | |
| 09:46:44 | gibi | https://github.com/openstack/nova/commit/74befb68a79f8bff823fe067e0054504391ee179#diff-486ddc37ce8e7c105a51566dd2cffbda034f28fae7eaad2e74abf470ab296352R248-R252 | |
| 09:46:47 | gibi | these are the checks | |
| 09:46:57 | gibi | on the libvirt version | |
| 09:47:04 | gibi | but the constant is not even in 8.0.0 | |
| 09:47:28 | sean-k-mooney | i wonder if they complied it out | |
| 09:48:31 | gibi | I don't know how to check that | |
| 09:48:49 | sean-k-mooney | that or that support came later. | |
| 09:49:31 | sean-k-mooney | https://github.com/libvirt/libvirt/blob/049846497b9e8a3eec82bfdcf3ebfe7c15e62c55/include/libvirt/libvirt-nodedev.h#L152 | |
| 09:49:43 | sean-k-mooney | so that looks liek the validation is a 8.10.0 feature | |
| 09:49:45 | gibi | https://github.com/libvirt/libvirt/commit/d8791c3c7caa6e3cadaf98a5a2c94b232ac30fed | |
| 09:50:01 | gibi | yeah I found the same thing | |
| 09:50:29 | sean-k-mooney | so looking at that | |
| 09:50:36 | sean-k-mooney | the validation was only added in 8.10. | |
| 09:50:37 | gibi | so we either need to remove the flag or change the version guard | |
| 09:50:45 | sean-k-mooney | right | |
| 09:50:59 | gibi | I lean towards changing th guard | |
| 09:51:02 | sean-k-mooney | so for 8.10+ we can pass the validation | |
| 09:51:03 | gibi | as this is on master | |
| 09:51:07 | sean-k-mooney | and below that no flag | |
| 09:51:30 | sean-k-mooney | why? | |
| 09:51:43 | sean-k-mooney | schma validation is nice to have but it was never part of the feature | |
| 09:52:25 | frickler | ah, likely that's why the experimental job runs on 24.04 which has 10.0.0 | |
| 09:52:37 | sean-k-mooney | frickler: thats not the only reason but one of them | |
| 09:52:37 | gibi | OK from that perspective we can make the flag version dependent. My viewpoint was that on master we can require newer libvirt | |
| 09:52:50 | sean-k-mooney | frickler: this code was tested with centos 9 with 8.10 | |
| 09:53:27 | sean-k-mooney | gibi: ya im not sure if we are alowed to do that bump this cycle or if we are allwoed to do it next | |
| 09:53:34 | sean-k-mooney | i wanted to do it on the non slurps | |
| 09:54:01 | sean-k-mooney | so advertise the next version during a slurp and bump in the next non slurp | |
| 09:54:19 | sean-k-mooney | meanign we could bump it now but we cant really do that until we move to noble | |
| 09:54:35 | sean-k-mooney | so for this release i woudl just add the version check | |
| 09:54:40 | gibi | sean-k-mooney: ack, make sense, we have a dependency on noble :/ | |
| 09:54:46 | sean-k-mooney | and we can remove that when we bump | |
| 09:58:02 | gibi | https://bugs.launchpad.net/nova/+bug/2076163 | |
| 10:57:30 | elodilles | auniyal Uggla : when you have some time, could you please take a look at these release patches? https://review.opendev.org/c/openstack/releases/+/925646 & https://review.opendev.org/c/openstack/releases/+/925647 | |
| 10:57:53 | elodilles | if you have any question then feel free to ping me | |
| 12:21:48 | jlejeune | elodilles: hello, after your release, will you have some time to review my patchs please ? https://review.opendev.org/c/openstack/nova/+/899379 and https://review.opendev.org/c/openstack/nova/+/901655 | |
| 12:54:50 | elodilles | jlejeune: just to note, i'm not core reviewer on master branch, I don't have +2 rights on master, I'm only stable maintainer core member o:) | |
| 13:01:26 | jlejeune | elodilles: ho sorry for the misunderstanding, I saw that you were very active so I thought you were a core reviewer, my bad :) | |
| 13:04:22 | sean-k-mooney | jlejeune: https://review.opendev.org/c/openstack/nova/+/899379 is not a correct fix | |
| 13:06:03 | sean-k-mooney | jlejeune: also as a aside no one form the core team has reviewd https://bugs.launchpad.net/nova/+bug/2040986 to confirm if its even valid and ^ did not include a repoducer functional test to demponstarte the bug | |
| 13:17:04 | jlejeune | ok, sorry I'm not yet very familiar with the process... | |
| 13:17:30 | jlejeune | now you have seen the bug report, what do you think about it ? | |
| 13:21:03 | sean-k-mooney | so https://bugs.launchpad.net/nova/+bug/2040986 is partly valid. the request spec shoudl not have the property for iamge b | |
| 13:21:06 | sean-k-mooney | when it faild | |
| 13:21:23 | sean-k-mooney | but the issue is not that we dont revert request spec content | |
| 13:21:33 | sean-k-mooney | it shoudl not have been updated unless it passed the schduler | |
| 13:22:15 | sean-k-mooney | fixing the issue in the excpt class is invliad as propsoed because its trying to use the info form glance and not corm the cell db copy | |
| 13:22:32 | jlejeune | yes we are treating the symthom and not the bug itself, agree about that | |
| 13:22:37 | sean-k-mooney | ideally we woudl fix the orginal issue by not saving the modifed request spec until after the schduler says its ok | |
| 13:23:44 | sean-k-mooney | jlejeune: back to the procedure topic the first step in fixing the bug should be to create a functional regression test for the bug to demonstarte the incorrect behaivor | |
| 13:24:54 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1732947.py and https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_2040264.py are two examples of rebuidl regression tests for past bugs | |
| 13:25:48 | sean-k-mooney | https://github.com/openstack/nova/commit/21fd0c430c714d21c52e0a0c996351c374a3e3d6 and https://github.com/openstack/nova/commit/ee9ed0f7c6abf7c4847e6dc31f6d3d79b25b9d99 | |
| 13:25:55 | sean-k-mooney | demontrate the standard pattern | |
| 13:41:04 | jlejeune | are the regression tests are always mandatory ? because I see a lot of changes without them | |
| 13:45:02 | artom | jlejeune, strongly encouraged when fixing bugs. Our so-called "functional" tests are advanced enough that most bugs, even races, can be reproduced with them, with judicious use of stubs or mocks. The accepted standard practice is to first demonstrate the bug in a functional test, then with the patch on top demonstrate that the fix does what it's supposed to. | |
| 13:45:28 | artom | jlejeune, other than that, regression tests are not mandatory (and even for bug fixes there can be exceptions, depending on the nature of the bug). | |
| 13:47:24 | sean-k-mooney | jlejeune: we dont always requrie a funcitonal repoducer sometime unit test repoducer are also fine but for anyting like rebuild or an change that is not targeted to a very speciifc part of code i.e. the xml generation or logging its almost alwayys requried | |
| 13:51:12 | jlejeune | ok so in that case, I need to ? | |
| 13:52:12 | sean-k-mooney | yes in this case you are trying to fix an issue that hapens as a result of multipel api action and an interaction betwwen the conductor and schduler resulting in incositenies betwwen two dbs | |
| 13:52:31 | sean-k-mooney | that is not somethign that unit tests are sufficent to demondatate | |
| 13:52:43 | sean-k-mooney | so we woudl generally requrie a fucntioanl repoducer test | |
| 13:53:01 | jlejeune | ok | |
| 13:54:31 | sean-k-mooney | this is a littel out of date but this is where that was orignally documented https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/README.rst#tests-for-specific-regressions | |
| 13:54:56 | sean-k-mooney | the bit that is a littel out of date is "These should be full stack tests which inherit from nova.test.TestCase directly." | |
| 13:55:04 | sean-k-mooney | that is still prefered but not required anymore | |
| 13:55:32 | sean-k-mooney | it can be a heavy lift to set up all the fixtures unless you are deeply familar with how our test work | |
| 13:56:15 | opendevreview | Artom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block https://review.opendev.org/c/openstack/nova/+/925771 | |
| 13:56:25 | sean-k-mooney | so we do allow inheriting form ntegrated_helpers._IntegratedTestBase | |
| 13:56:55 | sean-k-mooney | as is done in https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1732947.py | |