Tuesday, 2024-08-06

*** bauzas_ is now known as bauzas02:39
*** bauzas_ is now known as bauzas04:47
*** elodilles_pto is now known as elodilles05:51
*** bauzas_ is now known as bauzas07:37
songwenpinghi team, i have update libvirt-python to lastest version of 10.6.0, but also meet the error: module 'libvirt' has no attribute 'VIR_NODE_DEVICE_CREATE_XML_VALIDATE', any advice?08:45
gibisongwenping: the libvirt api def still documents that flag https://libvirt.org/html/libvirt-libvirt-nodedev.html#virNodeDeviceCreateXMLFlagsh09:00
gibiand I can import it in 10.5.009:02
gibibash-5.1$ rpm -qa | grep python3-libvirt09:02
gibipython3-libvirt-10.5.0-1.el9.x86_6409:02
gibibash-5.1$ python309:02
gibiPython 3.9.19 (main, Jul 18 2024, 00:00:00) 09:02
gibi[GCC 11.4.1 20231218 (Red Hat 11.4.1-3)] on linux09:02
gibiType "help", "copyright", "credits" or "license" for more information.09:02
gibi>>> import libvirt 09:02
gibi>>> libvirt.VIR_NODE_DEVICE_CREATE_XML_VALIDATE09:02
gibi109:02
gibi>>> 09:02
songwenpingmy OS is ubuntu2204, i will try 10.5.009:03
gibihm I pulled 10.6.0 from pypi and I can still import the constant : https://paste.opendev.org/show/b0IJ31RkWUw7MvcqpReb/09:04
fricklershould one generally use libvirt-python from the distro to match the installed libvirt? and thus not use it from pypi at all?09:06
songwenpingyeah, tried 10.5.0, still has no this attribute.09:07
gibifrickler: I would say, use the matching version 09:07
fricklerfwiw I don't see the above symbol either on 22.04, libvirt version 8.0.0-1ubuntu7.1009:16
fricklersongwenping: do you use libvirt from ubuntu or a newer version built from source?09:16
songwenpinglibvirt on ubuntu with 'pip install libvirt-python'09:18
gibifrickler: I don't see it either in ubuntui 22.04 installed python-libvirt with apt09:21
songwenpingi replace VIR_NODE_DEVICE_DEFINE_XML_VALIDATE with 1 and the vm is created successful.09:23
fricklerI 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#L126709:26
gibinova declares libvirt min version as 8.0.009:27
gibihttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L22109:27
fricklerbut devstack loads uca, so maybe this isn't really tested anywhere09:28
gibiyeah09:28
frickleralso MIN_LIBVIRT_VERSION is still 7.0.0, NEXT_MIN_LIBVIRT_VERSION is only for the future, isn't it?09:29
gibifrickler: sorry you are right09:29
gibifrickler: so yeah we should work with 7.0.009:30
gibibut 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-486ddc37ce8e7c105a51566dd2cffbda034f28fae7eaad2e74abf470ab296352R24809:31
gibistill it seems the constant is missing in those old libvirts09:31
fricklerseems 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
gibifrickler: we test with 8.0.0 https://zuul.opendev.org/t/openstack/build/38facdd66a1e4e69bd6995fea4174d82/log/job-output.txt#9305 we just don't test mdevs09:42
sean-k-mooneyfrickler: we dont test mdevs upstream yet09:43
sean-k-mooneyfrickler: it requires us to compile a kernel module09:43
gibiI think we will test is via https://review.opendev.org/q/topic:%22mtty_support%2209:43
sean-k-mooneyfrickler: bauzas is currently working on a job for that09:43
sean-k-mooneygibi: yep that the series09:44
sean-k-mooneyalthough at the moment bauzas is working on it in a different job instead of nova-next like we orginally proposed09:44
gibifrickler, 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_VALIDATE09:44
gibiI will file a bug...09:45
sean-k-mooneyam we are ment to have a falback09:45
sean-k-mooneythats form melwitt's series09:45
sean-k-mooneywe only supprot persistance in a later libvirt and falback to the old way when runingon older libvirt09:46
sean-k-mooneyat least that was teh plan09:46
gibihttps://github.com/openstack/nova/commit/74befb68a79f8bff823fe067e0054504391ee179#diff-486ddc37ce8e7c105a51566dd2cffbda034f28fae7eaad2e74abf470ab296352R248-R25209:46
gibithese are the checks09:46
gibion the libvirt version09:46
gibibut the constant is not even in 8.0.009:47
sean-k-mooney i wonder if they complied it out09:47
gibiI don't know how to check that09:48
sean-k-mooneythat or that support came later.09:48
sean-k-mooneyhttps://github.com/libvirt/libvirt/blob/049846497b9e8a3eec82bfdcf3ebfe7c15e62c55/include/libvirt/libvirt-nodedev.h#L15209:49
sean-k-mooneyso that looks liek the validation is a 8.10.0 feature09:49
gibihttps://github.com/libvirt/libvirt/commit/d8791c3c7caa6e3cadaf98a5a2c94b232ac30fed09:49
gibiyeah I found the same thing09:50
sean-k-mooneyso looking at that09:50
sean-k-mooneythe validation was only added in 8.10.09:50
gibiso we either need to remove the flag or change the version guard 09:50
sean-k-mooneyright09:50
gibiI lean towards changing th guard09:50
sean-k-mooneyso for 8.10+ we can pass the validation09:51
gibias this is on master09:51
sean-k-mooneyand below that no flag09:51
sean-k-mooneywhy?09:51
sean-k-mooneyschma validation is nice to have but it was never part of the feature09:51
fricklerah, likely that's why the experimental job runs on 24.04 which has 10.0.009:52
sean-k-mooneyfrickler: thats not the only reason but one of them09:52
gibiOK from that perspective we can make the flag version dependent. My viewpoint was that on master we can require newer libvirt09:52
sean-k-mooneyfrickler: this code was tested with centos 9 with 8.1009:52
sean-k-mooneygibi: ya im not sure if we are alowed to do that bump this cycle or if we are allwoed to do it next09:53
sean-k-mooneyi wanted to do it on the non slurps09:53
sean-k-mooneyso advertise the next version during a slurp and bump in the next non slurp09:54
sean-k-mooneymeanign we could bump it now but we cant really do that until we move to noble09:54
sean-k-mooneyso for this release i woudl just add the version check09:54
gibisean-k-mooney: ack, make sense, we have a dependency on noble :/09:54
sean-k-mooneyand we can remove that when we bump09:54
* gibi filing bug09:54
gibihttps://bugs.launchpad.net/nova/+bug/207616309:58
elodillesauniyal 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/+/92564710:57
elodillesif you have any question then feel free to ping me10:57
jlejeuneelodilles: 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/+/90165512:21
elodillesjlejeune: 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:)12:54
jlejeuneelodilles: ho sorry for the misunderstanding, I saw that you were very active so I thought you were a core reviewer, my bad :)13:01
sean-k-mooneyjlejeune: https://review.opendev.org/c/openstack/nova/+/899379 is not a correct fix13:04
sean-k-mooneyjlejeune: 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 bug13:06
jlejeuneok, sorry I'm not yet very familiar with the process...13:17
jlejeunenow you have seen the bug report, what do you think about it ?13:17
sean-k-mooneyso https://bugs.launchpad.net/nova/+bug/2040986 is partly valid. the request spec shoudl not have the property for iamge b13:21
sean-k-mooneywhen it faild13:21
sean-k-mooneybut the issue is not that we dont revert request spec content13:21
sean-k-mooneyit shoudl not have been updated unless it passed the schduler 13:21
sean-k-mooneyfixing 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 copy13:22
jlejeuneyes we are treating the symthom and not the bug itself, agree about that13:22
sean-k-mooneyideally we woudl fix the orginal issue by not saving the modifed request spec until after the schduler says its ok13:22
sean-k-mooneyjlejeune: 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 behaivor13:23
sean-k-mooneyhttps://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 bugs13:24
sean-k-mooneyhttps://github.com/openstack/nova/commit/21fd0c430c714d21c52e0a0c996351c374a3e3d6 and https://github.com/openstack/nova/commit/ee9ed0f7c6abf7c4847e6dc31f6d3d79b25b9d9913:25
sean-k-mooneydemontrate the standard pattern13:25
jlejeuneare the regression tests are always mandatory ? because I see a lot of changes without them13:41
artomjlejeune, 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
artomjlejeune, 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:45
sean-k-mooneyjlejeune: 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 requried13:47
jlejeuneok so in that case, I need to ?13:51
sean-k-mooneyyes 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 dbs13:52
sean-k-mooneythat is not somethign that unit tests are sufficent to demondatate13:52
sean-k-mooneyso we woudl generally requrie a fucntioanl repoducer test 13:52
jlejeuneok13:53
sean-k-mooneythis 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-regressions13:54
sean-k-mooneythe bit that is a littel out of date is "These should be full stack tests which inherit from nova.test.TestCase directly."13:54
sean-k-mooneythat is still prefered but not required anymore13:55
sean-k-mooneyit can be a heavy lift to set up all the fixtures unless you are deeply familar with how our test work13:55
opendevreviewArtom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block  https://review.opendev.org/c/openstack/nova/+/92577113:56
sean-k-mooneyso we do allow inheriting form ntegrated_helpers._IntegratedTestBase13:56
sean-k-mooneyas is done in https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1732947.py13:56
sean-k-mooneyor sometimes even the libvirt specific vairiant however if its not virt driver specific we avoid using the more complex base classes13:57
jlejeuneok I will try13:59
*** bauzas_ is now known as bauzas14:05
jlejeuneartom: sean-k-mooney: and what about that one: https://review.opendev.org/c/openstack/nova/+/901655 ?14:11
artomjlejeune, IMO that's simple enough to not need a reproducer.14:13
sean-k-mooneythat ism more incliend to say is a valid bug but on the other hand im not eintrly sure its safe to not mark the instnace as in error14:13
sean-k-mooneyif the rpc timeout happens in pre live migrate i agree the instance should stay in active14:14
sean-k-mooneyand only the migration should be in error14:14
sean-k-mooneyso https://review.opendev.org/c/openstack/nova/+/901655/4/nova/compute/manager.py i think is the correct approch in this case14:15
sean-k-mooneyif the rpc timeout happesn after we have started the migration its get harder14:16
sean-k-mooneyjlejeune: i woudl prefer ot have a fucntioal repoducer for that too14:17
sean-k-mooneybut i think the way its being fixed is generally ok14:18
*** ministry is now known as __ministry15:04
*** ykarel is now known as ykarel|away15:29
gibinova meeting starts here in 15 minutes15:45
opendevreviewTakashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support  https://review.opendev.org/c/openstack/nova/+/92568515:55
gibi#startmeeting nova16:00
opendevmeetMeeting started Tue Aug  6 16:00:48 2024 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'nova'16:00
elodilleso/16:00
gibiI will be your host today as bauzas is on PTO16:01
dansmitho/16:01
gibi#topic Bugs (stuck/critical)16:02
tkajinamo/16:02
gibi#info No Critical bug16:02
gibiis there any bug that we need to discuss?16:02
gibi#topic Gate status16:03
gibi#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs16:03
gibi#link https://etherpad.opendev.org/p/nova-ci-failures-minimal16:03
gibi#link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status16:03
gibicentos 9 based jobs are still read 16:04
gibired16:04
gibidue to 16:04
gibiFailed to enable unit: Unit file rabbitmq-server.service does not exist.16:04
dansmithso some work was done in devstack recently,16:04
dansmithrelated to the release repo, which I thought was going to fix some of it16:05
dansmithrocky started working at least16:05
dansmithbut it was also (re-)asserted that stream is making it clear it's not stable enough for our purposes, which I definitely agree with :)16:05
dansmithhttps://review.opendev.org/c/openstack/devstack/+/925368?tab=change-view-tab-header-zuul-results-summary16:06
gibithank dansmith for the pointers16:07
gibiIf somebody has the time to investigate further then go for it. :)16:08
gibibut I guess as it is not blocking the CI directly it will take a while to get to it16:08
gibianything else about the centos jobs or about the gate in general?16:09
gibi#topic Release Planning16:10
gibi#link https://releases.openstack.org/dalmatian/schedule.html16:10
gibi#info Dalmatian-3 in 3 weeks16:10
gibi#topic Review priorities16:10
gibi#link https://etherpad.opendev.org/p/nova-dalmatian-status16:10
gibiIs there anything to discuss about the upcoming release?16:11
tkajinamthere is one open follow-up edit of the spec. would be nice if it can be quickly reviewed https://review.opendev.org/c/openstack/nova-specs/+/92456316:12
gibitkajinam: I will look at it after the meeting16:12
tkajinamgibi, thx !16:12
gibi#topic Stable Branches16:13
gibielodilles: hi! :)16:13
elodilleso/16:13
elodilles#info stable/202*.* gates seem to be OK16:13
elodilles#info nova stable release patches (with CVE fix): https://review.opendev.org/q/project:openstack/releases+intopic:nova+is:open16:14
sean-k-mooneydansmith: it may be worth condiering if the fibs jobs could move to rocky to be slightly more stable but ya i still agree in general. we can discusus that later if peopel want to do that work outside the meeting or in open dicussion at the end16:14
elodilleswaiting for release liaison reviews ^^^ o:)16:14
gibibauzas and Uggla are on PTO16:14
elodillesgibi: ACK16:14
sean-k-mooneyamit is also a release liason16:14
dansmithsean-k-mooney: yep16:15
elodillesthen auniyal is the only available release liaison o:)16:15
sean-k-mooneyauniyal: ^ can you prioitse that16:15
elodillesthanks in advance o:)16:15
elodilles#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci16:15
elodillesif anyone finds any gate issue then please add it there ^^^16:16
elodillesthat's all about stable from me16:16
gibielodilles: thanks!16:17
elodillesnp16:17
gibi#topic vmwareapi 3rd-party CI efforts Highlights16:17
gibi#info fwiesel on PTO until the 27th August.16:17
gibiso I guess no news here16:17
gibi#topic Open discussion16:17
gibi(bauzas) Aug 6, 13 and 20 nova meetings16:17
gibiso I took today's meeting but cannot do 13th or 20th16:18
gibiany volunteer?16:18
gibithen they are cancelled16:20
gibi#info the meeting on the 13th and on the 20th are cancelled16:20
gibiany other topic for today?16:21
dansmith++ for cancel :)16:21
gibiI guess we are done for today then16:23
gibi#endmeeting16:23
opendevmeetMeeting ended Tue Aug  6 16:23:31 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:23
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2024/nova.2024-08-06-16.00.html16:23
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-08-06-16.00.txt16:23
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2024/nova.2024-08-06-16.00.log.html16:23
elodillesthanks o/16:23
gibithanks folks16:23
tkajinamthanks16:24
opendevreviewMerged openstack/nova-specs master: Follow up for "libvirt: AMD SEV-ES support"  https://review.opendev.org/c/openstack/nova-specs/+/92456316:24
opendevreviewArtom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block  https://review.opendev.org/c/openstack/nova/+/92577118:09
opendevreviewArtom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block  https://review.opendev.org/c/openstack/nova/+/92577118:31
*** bauzas_ is now known as bauzas19:37
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Check version for node device XML validate flags  https://review.opendev.org/c/openstack/nova/+/92582623:09
melwittfyi gibi and sean-k-mooney ^ thanks songwenping_ for reporting the issue23:14
sean-k-mooneymelwitt: that wont work23:17
sean-k-mooneythe api does not have a flags filed before 8.10.023:17
sean-k-mooneymelwitt: so you ned to change the function call rahter then the flags23:18
melwittsean-k-mooney: ugh dammit. thanks 😩 23:18
sean-k-mooney actully23:19
sean-k-mooneyno i miss read the c code23:19
sean-k-mooneyhttps://github.com/libvirt/libvirt/commit/d8791c3c7caa6e3cadaf98a5a2c94b232ac30fed#diff-29f62ad20a5a2dffc62d8d09df5ef6e7b28c36c723ae7da56eb371c7547fbf98L7023:19
sean-k-mooneyso it was passing a hardcoded 0 for flags before23:19
sean-k-mooneyso your change shoudl be good23:19
sean-k-mooneyill review it properly tomorrow after we see what ci says23:20
sean-k-mooneythe docs change clarifies it 23:20
sean-k-mooneyhttps://github.com/libvirt/libvirt/commit/d8791c3c7caa6e3cadaf98a5a2c94b232ac30fed#diff-7552129210db333b0c2e3d224d1ae11a674bbb0b56f6b2708452be4e0c023a98L69723:20
sean-k-mooney@flags: extra flags; not used yet, so callers should always pass 023:20
sean-k-mooneyto * @flags: bitwise-OR of supported virNodeDeviceCreateXMLFlags23:20
melwittah ok, I have seen they have that for some APIs where it takes flags of 0 as sort of a placeholder23:22
sean-k-mooneyyep23:22
sean-k-mooneythe try to future proof may apis by allowing flags even if not supproted23:23
sean-k-mooneyi guess that semi reasonabel for c to not break abi compatiablity23:23
*** bauzas_ is now known as bauzas23:45

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!