Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-02-11
16:54:11 sean-k-mooney yep it wont actully catch this specific case
16:54:29 sean-k-mooney i.e. we validate the cpu are in the info provided by libvirt
16:54:35 sean-k-mooney and if they are online ectra
16:54:48 sean-k-mooney but we dont have visablity into cgroups at all really
16:54:53 sean-k-mooney at least not in this context
16:55:19 sean-k-mooney we have some basic check to know if its cgroups v2 vs v1
16:56:17 bauzas time check : 4 mins left.
16:57:11 gibi this is complexity that either lives in the installer or lives in nova, as nova is big enough already I rather see this complexity added in the installer. Sure we have multiple installers so that duplicates some effort.
16:57:32 dansmith ++
16:57:35 sp-bmilanov I was wondering if there is also a way to know this outside of reading cgroups that might be more robust
16:57:51 sean-k-mooney if there is im not aware of one
16:58:05 dansmith there is actually
16:58:11 dansmith ....and it's talking to libvirt :D
16:58:15 sean-k-mooney :)
16:58:36 sp-bmilanov :D
16:58:43 bauzas I guess we can't solve that question now
16:59:09 bauzas sp-bmilanov: could you at least talk to the libvirt community and see their toughts about that ?
16:59:15 sp-bmilanov in any case, it sounds like a good idea to initiate a discussion with libvirt devs as well
16:59:16 bauzas and then come back to us ?
16:59:28 sp-bmilanov bauzas: yep
16:59:31 bauzas cool
16:59:41 bauzas thanks then
16:59:52 sp-bmilanov you're welcome
17:00:04 sp-bmilanov thanks for the input, all
17:00:08 bauzas if you're OK, I think we're done for today
17:00:14 bauzas thanks all
17:00:17 bauzas #endmeeting
17:00:17 opendevmeet Meeting ended Tue Feb 11 17:00:17 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:00:17 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-11-16.01.html
17:00:17 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-11-16.01.txt
17:00:17 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-11-16.01.log.html
17:00:27 elodilles thanks o/
17:00:38 Uggla thx o/
17:00:55 sean-k-mooney bauzas: dansmith gibi outside the meeting i have a general question for ye
17:01:02 sean-k-mooney https://termbin.com/de4d
17:01:12 sean-k-mooney that virsh capablites form a centos host
17:01:33 sean-k-mooney i jsut noticed they started reporting whcih machine types are deprecated
17:01:36 sean-k-mooney <machine maxCpus='710' deprecated='yes'>pc-q35-rhel8.5.0</machine>
17:01:51 sean-k-mooney i dont know if they do this for cpu models as well
17:02:08 sean-k-mooney is this something we shoudl be proxying to our logs as a warning?
17:02:19 sean-k-mooney i.e. if you create a vm with a deprecated machine type
17:02:29 sean-k-mooney should not log a warning for that?
17:02:42 sean-k-mooney qemu/libvirt will in the libvirt qemu instance log
17:02:51 gibi sean-k-mooney: do you mean nova logs a warning at startup for each instance using a deprecated type? or just warning if nova default type is deprecated?
17:03:13 sean-k-mooney well either i guess.
17:03:24 gibi not a bad idea
17:03:25 sean-k-mooney it could get noisy
17:03:35 gibi if it is startup only then it is not a constant noise
17:03:45 sean-k-mooney but i dotn belive we have any openstack level log about this
17:03:53 sean-k-mooney liek it almost a nova-status thing
17:03:59 sean-k-mooney but we dont run that on computes
17:04:21 sean-k-mooney oh so on start up check the current isntances and log a warning?
17:04:24 sean-k-mooney something liek that
17:04:44 dansmith yeah not a bad idea, but I wouldn't warn too often
17:05:09 sean-k-mooney <model usable='yes' deprecated='yes' vendor='Intel' canonical='core2duo-v1'>core2duo</model>
17:05:22 dansmith warning only on startup is maybe not that great either.. once per deprecated use would be nicer.. can we leverage the warnings module perhaps?
17:05:23 sean-k-mooney ok os domain caps also has this info now for the cpu models
17:05:40 sean-k-mooney so if you cofnigured a custom cpu model and its deprecated we could perhaps warn on startup
17:06:08 sean-k-mooney the implication of it being deprecated is it may be removed in the next major release of your OS
17:06:56 sean-k-mooney or i guess technially the next major release of libvirt/qemu but realisticaly i think distros would not do the removal in a minor release
17:07:11 sean-k-mooney so proably only on major release of the distro
17:08:09 gibi dansmith: yeah we can be smart and log one warning per deprecated type with a list of instance uuid using it
17:08:48 dansmith gibi: ack, but I also think it would be nice to log on instance boot if we haven't complained about that type yet
17:09:00 dansmith in which case the list would only be one (so far)
17:10:07 sean-k-mooney i dont knwo if livbirt supprt thsi deprecation annochment for other things
17:10:32 sean-k-mooney like is deprecated valid for the supprot video models in teh domcaps api for example
17:11:29 gibi dansmith: yeah why not both :)
17:11:37 sean-k-mooney it might be good for us to reach out and see what there advice is for management applications to consume this info
17:13:24 sean-k-mooney ok we dont have to design this now but maybe somethign for the ptg or next cycle
17:14:29 gibi I'm supportive
17:19:16 bauzas dansmith: thanks for your comments, WDYM by mirroring dict.items() ? https://review.opendev.org/c/openstack/nova/+/940642/5/nova/objects/base.py#183
17:19:53 dansmith bauzas: you're returning [(key, value), (key,value)] right?
17:20:19 bauzas yeah but by a set
17:20:54 dansmith right, so my point is that's exactly like what dict.items() returns, so you might just name the property (or use a method) "items" for parity/consistency
17:21:22 bauzas ahah OK
17:21:53 dansmith just an idea, not critical
17:22:11 bauzas also, I think I'll use obj_to_primitive() for that, as I got https://6ae015e4c924496dfda3-74c26bb67ca36871e200d07f3210a3f0.ssl.cf1.rackcdn.com/940642/5/check/nova-multi-cell/c2a2f68/controller/logs/screen-n-sch.txt due to the fact I'd also want to modify a list
17:22:40 dansmith ack
18:10:28 opendevreview Merged openstack/nova stable/2024.2: ironic: Fix ConflictException when deleting server https://review.opendev.org/c/openstack/nova/+/940836
18:18:37 opendevreview Sylvain Bauza proposed openstack/nova master: Add a new ImagePropertiesWeigher https://review.opendev.org/c/openstack/nova/+/940642
19:14:20 mikal sean-k-mooney: did you end up having any joy on your tempest SPICE thing? I tweaked the tempest test last night to address review comments, but I am not sure where exactly we're up to now.
19:15:23 mikal Also melwitt if you're around, I'd appreciate a quick re-review on https://review.opendev.org/c/openstack/os-traits/+/940418. I think its good to go and it has a +2 from sean-k-mooney already.
19:29:09 gmann mikal: I am going to check tempest/devstack changes soon after TC discussion
19:31:24 mikal gmann: thanks
19:31:46 mikal gmann: I assume you don't want to actually merge that tempest change until the microversion merges in nova though?
19:36:16 gmann mikal: not strong opinion, as tests are capped with microversion those going to be skipped/not failed. I am ok to merge tempest test before nova change also or after whatever make things easy.
19:36:37 mikal gmann: ok cool
19:36:38 gmann I know you have made tempest change depends-on on nova change so that test results can be seen while review which is good dependency/
19:47:32 mikal What's the best way in the zuul output to verify the test actually run? I'm not entirely which file I should be searching for that.
19:51:31 MengyangZhang[m] <MengyangZhang[m]> "understood, just curious in..." <- I may need some help with implementing the min version check. I have two ideas:
19:54:14 gmann mikal: commented here, we need to change the tempest test regex in this job https://review.opendev.org/c/openstack/nova/+/940873/5/.zuul.yaml#173
19:54:53 gmann log/job-output.txt is where you can see the test running and how much time it takes https://zuul.opendev.org/t/openstack/build/afeee7c92cce46348341232a188427b3/log/job-output.txt
19:55:19 gmann or testr_results.html for quick ref https://e287b5846f894c7179f4-83ee41d1d15b6e7c94a25488c54501c9.ssl.cf1.rackcdn.com/924844/34/check/nova-ovs-hybrid-plug/afeee7c/testr_results.html
20:00:05 MengyangZhang[m] "the min compute service check is..." <- I may need some help with implementing this min version check. I have two ideas to do this:... (full message at <https://matrix.org/oftc/media/v1/media/download/Ae0l5EhUbL8JUTeIDS5kp_UoSmlV3GrnEtLP-mZf1daDKwZ50jd2VmhsVYhYto94LzR25EzQz3ob4XDZRrMgDthCeVPrH4jAAG1hdHJpeC5vcmcvVXVaelVtZEp1aU94WllHaU10Q0FlcndG>)
20:01:25 mikal gmann: so yeah, either I am looking in the wrong place or the spice test isn't running in the job yet then... https://e287b5846f894c7179f4-83ee41d1d15b6e7c94a25488c54501c9.ssl.cf1.rackcdn.com/924844/34/check/nova-ovs-hybrid-plug/afeee7c/testr_results.html
20:01:50 mikal That's the nova-ovs-hybrid-plug https://zuul.opendev.org/t/openstack/build/afeee7c92cce46348341232a188427b3 job for https://review.opendev.org/c/openstack/nova/+/924844
20:02:32 mikal I feel like 30 tests is a really low number too, like there's some test filtering happening that I haven't found yet or something.
20:03:21 mikal Oh sorry, that's your regex comment above!
20:03:58 gmann yeah, we need to change the regex
20:04:04 mikal sean-k-mooney: do we feel like we should rename the nova-ovs-hybrid-plug job if it now does more than that/

Earlier   Later