| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-11 | |||
| 16:50:08 | sean-k-mooney | sp-bmilanov: what installer do you use | |
| 16:50:21 | bauzas | time check : 10 mins before end of meeting | |
| 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? | |