| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-11 | |||
| 16:45:18 | bauzas | with a fragile interface and many ways to get it wrong | |
| 16:45:29 | sean-k-mooney | that depends | |
| 16:45:41 | dansmith | if we can see all of them, then passing the name/path to the one libvirt is in so we can inspect it would be better, but idk.. seems fragile to me like bauzas says | |
| 16:45:41 | sean-k-mooney | if your in a contianer you cant see the host one by default | |
| 16:46:00 | dansmith | sean-k-mooney: right, so we likely can't see libvirt's either right? | |
| 16:46:20 | sean-k-mooney | not thte way tripleo or kolla deploys nova | |
| 16:46:31 | sean-k-mooney | or our new instaler | |
| 16:46:45 | dansmith | yeah | |
| 16:46:48 | sp-bmilanov | cgroupns_mode: "host"" | |
| 16:46:48 | sp-bmilanov | sean-k-mooney mentioned in the change that kolla and tripleo are working around it... sean-k-mooney, where do you "not typiclaly run the nova-comptue binary with | |
| 16:47:11 | sean-k-mooney | right so exisitng installer only set that on libvirt | |
| 16:47:14 | sean-k-mooney | not on nova | |
| 16:47:21 | sean-k-mooney | so nova-comptue has a restricted view | |
| 16:47:37 | sp-bmilanov | ah, right.. but which installer is that? | |
| 16:47:55 | sp-bmilanov | (I might be missing Nova context) | |
| 16:48:26 | sp-bmilanov | (btw, there's the other side of the discussion, if we were to treat that currently Nova can start and schedule VMs with this misconfiguration, what would be the fix so it does not start at all (as sean-k-mooney suggested in the change comments)) | |
| 16:49:24 | sean-k-mooney | libvirt has it in kolla https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/defaults/main.yml#L11 | |
| 16:49:29 | sean-k-mooney | but not nova-compute https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/defaults/main.yml#L55 | |
| 16:49:40 | sean-k-mooney | adn its the same in tripleo and the new isntaller redhat wrote | |
| 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 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-11-16.01.log.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 | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-11-16.01.html | |
| 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 | bauzas | #endmeeting | |
| 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 | |