Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-13
15:57:44 dansmith smh
15:57:52 sean-k-mooney the stats name came for the fact its a summary
15:58:00 sean-k-mooney i.e. a count and some metadata
15:58:05 dansmith so PciDevicePool has a product and vendor but not an address,
15:58:06 sean-k-mooney rather then each device
15:58:13 sean-k-mooney correct
15:58:29 dansmith so I assume we take the alias map and generate all the PciDevicePool objects we need with the appropriate count, even if count=1 because they just specified one address?
15:58:33 sean-k-mooney its a count of how many of that type of device (product/vendor) are avaible
15:58:50 sean-k-mooney yes
15:59:08 sean-k-mooney if the pci dev spec only allows 1 device you get a pool or 1
15:59:12 sean-k-mooney *of 1
15:59:16 dansmith this code is, I think, a very nice concrete example of why I normally just gloss over anytime PCI stuff comes up and try to ignore it :)
15:59:28 dansmith ack
15:59:53 sean-k-mooney i actully like this code partly becasue to me it very placement like
16:00:03 dansmith does the grouping per physnet, per rp, etc, etc happen in compute node so we report the proper splitting to scheduler?
16:00:03 sean-k-mooney well conceptually
16:00:18 sean-k-mooney dansmith: yes it does
16:00:41 dansmith sean-k-mooney: I mean the name confusion and the converting everything to mis-named dicts to work on :)
16:00:42 sean-k-mooney its part of the resouce summary view we create as a perodic
16:00:48 dansmith okay makes sense
16:01:17 sean-k-mooney dansmith: some of this code i think predate when you added nova objects
16:01:31 sean-k-mooney so ya the conventiosn were not as well established
16:02:22 dansmith sean-k-mooney: I don't think it predates objects, but I know it's old
16:02:51 sean-k-mooney perhasp it was 2012 ish
16:03:33 sean-k-mooney not imporant now i ugess
16:03:43 gibi another "complication" that pool filtering happens twice by this code, once from the PCIPassthroughFilter and once from the pci claim on the compute. But it happens a bit differently as the former only handles counts, while the latter handles real device addresses to allocat
16:04:05 sean-k-mooney it actully happens 3 times
16:04:56 gibi true, twice in the scheduler
16:05:23 sean-k-mooney it happens in both the pci passthoguh filter and again in the numa topology filter
16:06:19 sean-k-mooney the pci filter really just checks that there are enough devices of the correct type
16:06:30 sean-k-mooney the numa filter need to also take into acocunt the numa constraits
17:30:12 opendevreview Dan Smith proposed openstack/nova master: Support "one-time-use" PCI devices https://review.opendev.org/c/openstack/nova/+/943816
17:30:13 opendevreview Dan Smith proposed openstack/nova master: Add one-time-use devices docs and reno https://review.opendev.org/c/openstack/nova/+/944262
17:38:24 opendevreview Balazs Gibizer proposed openstack/nova master: Reproduce bug/2098496 https://review.opendev.org/c/openstack/nova/+/941673
17:38:25 opendevreview Balazs Gibizer proposed openstack/nova master: Ignore metadata tags in pci/stats _find_pool logic https://review.opendev.org/c/openstack/nova/+/944277
19:59:39 atmark hello, does ceph driver for nova support rbd namespaces?
#openstack-nova - 2025-03-14
07:37:07 gokhan hello folks, we are using nova with ceph backend. Sometimes we are getting "nova-compute: Got no allocation candidates from the Placement API. This could be due to insufficient resources or a temporary occurrence as compute nodes start up" warnings. when I look at the resource provider inventory list, hosts DISK_GB value is not correct. Only one host shows corresct value as ceph pool capacity. https://paste.openstack.org/show/b9g8Js7V63bdf7rKuLqg/
07:37:07 gokhan . I want to be sure if this is expected behaviour with ceph.
07:58:37 frickler gokhan: that does sound like a bug to me, what versions of nova and ceph? probably best create a bug report
08:02:33 gokhan frickler, nova version is 29.2.0 and ceph is 18.2.2. But in my other deployments which has same version, DISK_GB on every hosts is correct.
08:06:41 gokhan frickler, ohh sorry ceph versions sre different. İt is working with ceph 18.2.4 but with ceph 18.2.2 it is not working. may be there is a known issue
10:50:20 ishanwar Hi Everyone!
10:50:38 ishanwar I am planning to take a shot at this LHF https://bugs.launchpad.net/nova/+bug/2027156
10:51:15 ishanwar Can someone help me understand why we invented to use to the neutron quota API here ? Please dont mind me question I am new to nova dev
10:51:32 ishanwar intend
10:52:02 ishanwar @Sean-k-mooney @bauzas
10:59:47 sean-k-mooney ishanwar: am short version is today we are pulling the full port object with all the extentions and then counting them in python
11:00:08 sean-k-mooney to see if we exceed the quota the project has for total ports
11:00:22 sean-k-mooney but neutron has an api that just returns this as a number
11:00:45 sean-k-mooney so its much faster to use the dedciated api and less work for both nova and neutron if we do
11:01:14 sean-k-mooney so this is just a performance optimisation ot reduce the amount of data sent over the wire and reduce the database load on the neutron side
11:02:33 sean-k-mooney ishanwar: so the idea is, 1 try and use the neutron api exteion for quota details, if that works great we can skip the extra work of counting the ports ourselves, if not fall back to what we do today
11:06:09 ishanwar Hi Sean
11:06:21 ishanwar Thanks for your response
11:06:51 ishanwar The big mentions that the quota api seems to be controlled by Also, the extension seems to be controlled by the cfg.CONF.QUOTAS.quota_driver config option: https://github.com/openstack/neutron/blob/6fa9142ced0eed8de9a89042747438b93de7202d/neutron/extensions/quotasv2_detail.py#L37
11:07:19 ishanwar So all neutron servers may not have this, how can we check the availability of the api ?
11:11:12 sean-k-mooney there are two way, we can assuem its there and just catch the excption when not and fall back
11:11:20 sean-k-mooney or we can call the extention list api
11:11:59 sean-k-mooney https://docs.openstack.org/api-ref/network/v2/#show-extension-details
11:12:28 sean-k-mooney using the extension list api is probaly better. in either case we have a convention of caching that result in nova
11:13:31 sean-k-mooney like this https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L1435-L1455
11:39:07 ishanwar thanks let me try to gather more details before create a gerrit review request
13:28:56 opendevreview mitya-eremeev-2 proposed openstack/nova master: Add more thorough handling of evacuated instances https://review.opendev.org/c/openstack/nova/+/944058
13:39:28 dansmith gibi: I don't understand your response to my comment
13:41:06 dansmith _find_pool() is not where things get sorted into pools, right? It looks through the already-sorted pools and finds the one that _dev_pool (which I think is just the device, right?) matches?
13:41:14 opendevreview mitya-eremeev-2 proposed openstack/nova master: Remove instance directory on live-migration https://review.opendev.org/c/openstack/nova/+/944058
13:47:26 gibi dansmith: yes, find_pool tries to find a matching pool, the callers of _find_pool creating a logic that if a pool is not found for a dev then a new pool is created for the dev
13:48:02 gibi but as matching logic was broken in _find_pool the upper layer created new pool for the devs
13:48:05 gibi during deallocation
13:48:21 dansmith ohhh, I see okay, let me follow that thread
13:49:00 dansmith since you're changing it and the allocation part I was mostly linking those in my head (and because _find_pool is almost like _filter_pools)
13:50:13 dansmith so if I comment out the _find_pool() part, I fail this part of the test:
13:50:22 gibi yeah the two changed code path are only linked from afar. the _find_pool runs during new device discovery and device deallocatin (putting back to pool). The _apply runs during scheduling of a VM, the consume codepath runs during the pci claim from the pci tracker in the compute
13:50:24 dansmith # assert that the single pool is not broken into two during the de-allocation
13:50:33 dansmith which makes sense based on what you said
13:50:34 gibi yeas
13:51:28 gibi and the _find_pool fix is the only thing that is necessary, the other code change is just safetynet
13:54:43 dansmith gibi: okay and the place where we do that (add a pool if we don't find it) is in add_device()..
13:54:55 dansmith it doesn't look like we run remove_device() when we consume it from the pool or anything,
13:55:19 dansmith so I'm not sure why we're re-running add_device() there, except maybe just as idempotentcy/healing or something?
13:56:46 gibi I think add_device is used both during new device discover at startup and during deallocation when we place the device back to the pool
13:57:09 dansmith I see it used in consume_requests() but the only other place is update_device() which isn't called from here at all
13:57:40 dansmith anyway, it doesn't matter that much because I see the problem now, it just seems confusing to me
13:58:13 dansmith however, at least it's consistent with all the other confusing terminology in here (devs, pools, dev_pools, stats, all of which are kinda the same :)
13:59:06 gibi _allocate_devs pops the device from the pool
13:59:17 dansmith we also call add_device() from _free_device() in compute manager while we're deallocating
13:59:18 gibi during consume_request
13:59:41 dansmith oh, it doesn't call remove_device() but it removes it some other way?
13:59:46 gibi yeah
13:59:48 gibi :/
14:00:14 sean-k-mooney the way we test in teh schduler if a host passes is we call consume_requests on a copy of the pools and just dont save it from Supprots_requests()
14:00:21 gibi literarily pci_dev = pool['devices'].pop()
14:00:27 dansmith ack
14:00:48 dansmith okay so the add_device is adding it back in after it's no longer used I guess instead of just being marked as in-use...
14:00:49 gibi sean-k-mooney: nope, we call _apply, consume is for the pci tracker
14:01:04 gibi dansmith: yes that is my understanding
14:01:32 sean-k-mooney i may have mixed up the names but the point i wanted to make is, we test if we can allcoate the device by trying to do it on a copy of the data)
14:01:52 gibi sort of yes
14:03:03 gibi even in the scheduler (host manager) we do an allocation on the stats via apply to allow mutlicreate to see a proper resource availability
14:03:47 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L779-L821

Earlier   Later