Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-11-12
15:20:42 vsaienko on 8 libvirt indeed setting mtu for vdpa is not possible https://paste.openstack.org/show/bi1VqvW3ScWE5obNpaRu/
15:20:45 sean-k-mooney so the mtu will only be set if the mtu on the neutorn netowrk is not 1500
15:21:10 sean-k-mooney i tought https://issues.redhat.com/browse/RHEL-7298 refence both mac and mtu but apprently not
15:22:11 vsaienko yes they closed https://bugzilla.redhat.com/show_bug.cgi?id=2057748 as duplicate but forgot to implement?
15:22:36 vsaienko on nova side mtu is not configured for vdpa device at all
15:22:50 vsaienko even when neutron network has > 1500
15:22:51 sean-k-mooney ack the its beacuse of that orgial limiation
15:23:12 sean-k-mooney right so i dont know if that was also fixed in libvirt/qemu or not
15:25:29 sean-k-mooney vsaienko: so ya https://github.com/libvirt/libvirt/commit/a5e659f071ae5f5fc9aadb46ad7c31736425f8cf
15:25:42 sean-k-mooney libvirt supprot for mutlqueue came in 8.2.0
15:26:04 sean-k-mooney that means we need to either rais our min version to libvirt 10 which is declared as or next min version
15:26:24 sean-k-mooney or you woudl have to support libvirt 8.0.0 by checkign the local version before enabling it
15:26:54 sean-k-mooney bumping the min version is the better chocies btu mroe work
15:27:18 sean-k-mooney we now know the minium requiremts at lesat qemu:6.2.0 and libvirt:8.2.0
15:27:37 sean-k-mooney that woudl need to be captured in the release notes
15:27:52 vsaienko ack
15:29:02 vsaienko do we need additional check for libvirt version, because right now min libvirt is 8.0.0 and it is supported starting from 8.2.0
15:29:34 sean-k-mooney yep i sasid that while you disconencted
15:29:51 vsaienko ack
15:29:57 sean-k-mooney we either need to supprot 8.0.0 via a version check ro bump our min version
15:30:06 sean-k-mooney whcih we can also do this cycle
15:30:31 sean-k-mooney its a littel more work but we have 1 or 2 feature that it woudl simplfy
15:30:34 bauzas sean-k-mooney: gibi: I can join the eventlet meeting but honestly I don't have the context
15:34:17 vsaienko should I add limitations section to and add mtu limitation here? https://docs.openstack.org/nova/latest/admin/vdpa.html
15:39:43 sean-k-mooney https://bugs.launchpad.net/nova/+bug/2119114
16:58:01 gibi sean-k-mooney: dansmith: bauzas: Why does it make sense to use a named lock instance in the provide tree? https://github.com/openstack/nova/blob/b7d50570c7a79a38b0db6476ccb3c662b237f69b/nova/compute/provider_tree.py#L252 It was there from the beginning added by Jay but it does not make sense to me. This means that any instances of the ProviderTree class will share the same named lock instead of have
16:58:07 gibi its own lock.
16:59:12 dansmith the providertree is always for a single compute provider root in placement (per process) right?
17:00:16 gibi we are deep.copying ProviderTree objects around within the same process
17:00:34 dansmith right but they represent the same provider (tree) in placement right?
17:00:38 gibi but a single ProviderTree represents a single compute
17:01:21 gibi hm
17:01:23 gibi maybe ironic
17:01:31 gibi working with multiple nodes per compute service
17:01:56 gibi has multiple trees one for each node
17:02:39 gibi the ProviderTree class allows multiplre roots for some reason :/
17:04:11 bauzas yeah I remember sometimes before we said we could have multiple roots
17:04:19 bauzas at least jay said it :p
17:04:59 bauzas I can't unfortunately remember the usecase where we could have multiple roots per compute
17:05:17 bauzas probably shared storage or something like that
17:06:22 gibi OK multiple roots is because the a single ProviderTree will have all the root providers that are connected to our compute root via placement aggregates
17:06:46 gibi Returns a fresh ProviderTree representing all providers which are in the same tree or in the same aggregate as the specified provider, including their aggregates, traits, and inventories
17:23:29 opendevreview Balazs Gibizer proposed openstack/nova master: Fix ProviderTree copying with threading Lock https://review.opendev.org/c/openstack/nova/+/956091
17:23:29 opendevreview Balazs Gibizer proposed openstack/nova master: [test]Further categorization of disabled unit tests https://review.opendev.org/c/openstack/nova/+/956092
17:23:30 opendevreview Balazs Gibizer proposed openstack/nova master: Do not fork compute workers in native threading mode https://review.opendev.org/c/openstack/nova/+/965466
17:23:30 opendevreview Balazs Gibizer proposed openstack/nova master: Compute manager to use thread pools selectively https://review.opendev.org/c/openstack/nova/+/966016
17:23:31 opendevreview Balazs Gibizer proposed openstack/nova master: Libvirt event handling without eventlet https://review.opendev.org/c/openstack/nova/+/965949
17:23:32 opendevreview Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467
17:31:58 opendevreview sean mooney proposed openstack/nova master: ensure correct cleanup of multi-attach volumes https://review.opendev.org/c/openstack/nova/+/916322
17:32:22 sean-k-mooney gibi: ^ i swap to a reader writer lock in the test too to show that it really fixes the issue
17:32:47 sean-k-mooney and hardened the context manager to technially work if shared across thread even if you shoudl not do that
#openstack-nova - 2025-11-13
10:10:03 kklimaszewski Hello, I'm Karol Klimaszewski - one of the presenters of NUMA in Placement at OpenInfra. While my colleague Dominik is still working on making patches related to that feature, I wanted to ask about another nova feature made by CloudFerro that was mentioned during conversation after our presentation. Well, it is more like two features. First is ephemeral storage backend for libvirt driver based on local NVMe disks managed by SPDK.
10:10:03 kklimaszewski Second is adding to nova the ability to handle multiple ephemeral storage backends on one nova-compute. I was wondering if there is any interest in us introducing those features to the upstream? And if yes, then is creating a blueprint and a spec proposal at nova-specs opendev repo a good first step to make it clear what we are trying to introduce?
10:14:48 opendevreview Stephen Finucane proposed openstack/nova master: WIP: libvirt: Ensure LibvirtDriver._host is initialized https://review.opendev.org/c/openstack/nova/+/967005
10:15:16 stephenfin gibi: interested in your thoughts on ^
10:15:52 stephenfin If you think it makes sense, I can fix up the tests (or try bribe sean-k-mooney to do it for me...)
11:33:37 sean-k-mooney gibi did you get an resolution to your lock question. i also dont know if that is really required.
11:34:59 sean-k-mooney gibi looking at the usage
11:35:13 sean-k-mooney https://github.com/openstack/nova/blob/b7d50570c7a79a38b0db6476ccb3c662b237f69b/nova/compute/provider_tree.py#L269-L278
11:36:43 sean-k-mooney im not seeing any get_or_create type pattern where we woudl eighter get a cached value or create it
11:37:32 sean-k-mooney at lset not in tha tfuction but we obvioulsy are doign esit chace else where https://github.com/openstack/nova/blob/b7d50570c7a79a38b0db6476ccb3c662b237f69b/nova/compute/provider_tree.py#L409-L423
11:38:30 sean-k-mooney the ironic case sort of makes sesen but i wonder is there also an interaction with share resouce providers and or provider.yaml at play
11:49:17 sean-k-mooney gibi: lookign a the the patch that intoduced, its clear that this exest to preveve concurrent modification f the provider try while iterating over it so a remove and find or add can happen a th esame time. why it not usign say the compute node uuid instead of a single lock. the only thin ghta makes sense to me in the orginal patch is the for over the comptue nodes. i
11:49:19 sean-k-mooney personally woudl have modele this very slightly diffent. the placemetn resouces manage by a compuate agent are a forest fo trees not a signel tree. so i would not have accpeted a list of compute nodes however you wuld still have needed a list a of root for sharing resouce providers, i think if we upleveled the compute nodes to a seperate map of cn uuid to provider tree the
11:49:21 sean-k-mooney lock in the provder tree coudl use the cn.uuid but the map woudl still likely need to ahve a single lock
11:52:11 sean-k-mooney we did refactor this a bit but we never actully turnd it into a forest of trees
11:56:37 opendevreview sean mooney proposed openstack/nova master: ensure correct cleanup of multi-attach volumes https://review.opendev.org/c/openstack/nova/+/916322
11:57:49 opendevreview sean mooney proposed openstack/nova master: ensure correct cleanup of multi-attach volumes https://review.opendev.org/c/openstack/nova/+/916322
12:28:41 gibi stephenfin: replied in the commit
12:32:22 gibi sean-k-mooney: I'm questioning the need of a named and therefore global lock for any instances of ProviderTree in the process. Even if it is as simple libvirt compute with just a single root provider. I don't see why we need to ensure that two copies of the ProviderTree is not accessed at the same time. I totally understand why we would use a threading.Lock per ProviderTree instance so concurrent
12:32:28 gibi access to the data is synchronized.
12:33:46 gibi but anyhow I keep the global named lock for the ProviderTree in https://review.opendev.org/c/openstack/nova/+/956091 I just feel like it is totally unnecessary
12:33:49 sean-k-mooney yep i realsise that. im just wondering is there any shareing here btween the reshaps that can happen due ot OTU devices and the perodics
12:34:02 sean-k-mooney i dont think we share the same PT between treads today
12:34:09 sean-k-mooney so a simpel lock is likely enough
12:34:52 gibi when we update placement we update that based on a specific ProviderTree instance. A copy of that object does not matter as it is an independent copy
12:34:58 sean-k-mooney the real qustion for me is do we ever store this PT in a shared location like the resouce tracker
12:35:08 sean-k-mooney or is it only constucted in side a function
12:35:21 gibi we pass around PTs
12:35:34 gibi and we alos copy them around in some cases
12:35:48 gibi because we pass arond a threading.lock is needed
12:35:52 sean-k-mooney right so its pass down the call stack but not in shared mutable storage either because of a copy or how its constucted
12:36:32 sean-k-mooney im not directly seeing a need for it to be a named lock either for what its worth
12:36:33 gibi even if we pass to a shared mutable storage, we pass an instance there with a threading lock is enough, we don't need to share the lock across the copies because they are independent deep copies
12:37:15 gibi actually in nova-compute a named lock is never needed as the compute is a single process
12:37:35 gibi so we only sync across threads so a threading.lock is enough
12:37:54 gibi in the scheduler or conductor a named lock might be needed iff we share data across worker processes
12:38:00 gibi like DB state
12:39:10 gibi anyhow I stop here. I just noticed it and felt strange, but I can ignore it and be safe that it will keep working as before
14:20:03 opendevreview Balazs Gibizer proposed openstack/nova master: Compute manager to use thread pools selectively https://review.opendev.org/c/openstack/nova/+/966016
14:20:04 opendevreview Balazs Gibizer proposed openstack/nova master: Libvirt event handling without eventlet https://review.opendev.org/c/openstack/nova/+/965949
14:20:04 opendevreview Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467
14:21:22 gibi gmaan: FYI https://review.opendev.org/c/openstack/nova/+/966016 proposes changing the default value of some of our config options. After the discussion of dansmith and sean-k-mooney we think this is OK from compatibility perspective via having an upgrade relnote. Do you agree?
14:32:43 opendevreview Balazs Gibizer proposed openstack/nova master: Compute manager to use thread pools selectively https://review.opendev.org/c/openstack/nova/+/966016
14:32:43 opendevreview Balazs Gibizer proposed openstack/nova master: Libvirt event handling without eventlet https://review.opendev.org/c/openstack/nova/+/965949
14:32:44 opendevreview Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467
14:33:21 opendevreview Dan Smith proposed openstack/nova master: Test nova-next with >1 parallel migrations https://review.opendev.org/c/openstack/nova/+/966447
15:08:00 gibi stephenfin: after a bit of deliberation and a failed trial I'm OK with the direction in 967005
15:08:04 gibi 967005
15:08:13 gibi https://review.opendev.org/c/openstack/nova/+/967005

Earlier   Later