Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-02-11
16:50:34 sean-k-mooney dansmith: bauzas am i right in thinking you agree this is out of scope fo nova
16:50:40 sean-k-mooney and in scope fo the installer
16:51:09 sp-bmilanov we have seen a few, but yes, kolla and no installer (opereating system packages)
16:51:20 dansmith I mean, that's kinda my point that this seems like us introspecting the system to dynamically configure ourselves, but in a way that can only work in certain situations
16:51:21 bauzas I'd tend to say yes, this sounds a tooling mechanism that could set the config correctly
16:51:51 sean-k-mooney i would be less agaisnt this if libvirt provided an api for this
16:51:57 bauzas the concern I have is that this approach doesn't sound generic at all and very targeted to a specific case
16:52:22 sean-k-mooney also those config options we use are ment to be virt dirver independent
16:52:37 dansmith right, if libvirt exposes it, that's totally different
16:53:02 dansmith in that case, configuring libvirt is the job of the installer, and nova can maybe even lose some config, right? or at least, not always require it to be set
16:53:05 gibi also it opens the question what if the cgroups config changes while nova-compute is running
16:53:18 sean-k-mooney fun times :)
16:53:40 gibi at least the current config nova has is validated at nova-compute startup
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

Earlier   Later