Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-02-11
16:41:30 sp-bmilanov yep, that's not ideal, but we can simplify or extend the checks as much as deemed necessary
16:41:34 bauzas last time we tried to look at sysfs for CPU management, it created some problems
16:42:02 sean-k-mooney sp-bmilanov: in general we try to aovid parsing /sys or /proc if at all posible
16:42:05 bauzas so I'm afraid some OSes couldn't support that
16:42:11 sean-k-mooney it create mantaince issues for us
16:42:23 dansmith a feature that works "sometimes" if a bunch of assumptions are made (i.e. libvirt and nova in the same slice) seems worse than no feature to me, in a lot of cases
16:43:03 sean-k-mooney if we were to do it i could maybe see doing if and only if you provide the path or slice as a config option
16:43:13 sean-k-mooney and only if you configure it
16:43:16 sean-k-mooney i.e. opt in
16:43:22 sean-k-mooney not on by default
16:43:24 sp-bmilanov sean-k-mooney that sounds good
16:43:38 sp-bmilanov an opt-in, if-set -like option
16:44:00 sp-bmilanov a bit like the CPU pinning, but more autonomous
16:44:33 sean-k-mooney mostly but im not sure how other feel about that
16:44:59 bauzas seems yet another knob to me
16:45:11 dansmith can we see all the slices in sysfs or only ours?
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 sean-k-mooney if your in a contianer you cant see the host one by default
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: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 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:46:48 sp-bmilanov cgroupns_mode: "host""
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 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

Earlier   Later