Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-06
17:50:18 sean-k-mooney i guess oslo.limits is not inteded as a generic keyston clinet
17:51:09 sean-k-mooney you could argue that we shoudl not be using ot get the registered limits and shoudl use the sdk instead
17:51:18 melwitt yeah.. it's not. that was what I felt conflicted about. like making it a passthrough to the underlying keystone client? when it already has a public connection attribute? I dunno. just seemed kind of weird
17:52:29 melwitt yeah. I think maybe they did that because the keystone API does not have the ability to filter a limit list by a set of resource names. but you could just filter it yourself after getting it. you'll get all of them in one API call
17:53:41 sean-k-mooney ubuntu@sean-devstack-watcher-1:~/repos/nova$ curl -s -H "X-Auth-Token: $TOKEN" -H "OpenStack-API-Version: compute 2.99" http://192.168.50.140/identity/v3/registered_limits | jq | nc termbin.com 9999
17:53:43 sean-k-mooney https://termbin.com/kqfj
17:54:07 melwitt so maybe the right thing to do is "fix" the internal impl of get_registered_limits() to just filter in python instead of doing N API calls
17:54:46 sean-k-mooney without a regioun or service id you get ll registered limits if you call keystoen
17:54:56 melwitt I know lol
17:55:04 sean-k-mooney the region we know right
17:55:07 melwitt that's literally what it's doing already
17:55:22 melwitt yes we know the region
17:55:24 sean-k-mooney well yes but is it just the service id we ned
17:55:28 melwitt we don't know the endpoint id
17:55:30 melwitt yes
17:57:30 melwitt er sorry yeah it's service id that the call actually needs. I keep mixing it up with the conf options
17:57:54 sean-k-mooney so the sdk supprot the service
17:57:59 sean-k-mooney https://github.com/openstack/openstacksdk/blob/master/openstack/identity/v3/service.py
17:58:17 sean-k-mooney and you can query by type i.e.. nova
17:58:21 sean-k-mooney *compute
17:58:22 melwitt yes, that's what oslo.limit does for the discovery
17:58:37 melwitt https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L294
17:58:45 sean-k-mooney ya so you were suggeting we coudl prot that to nova
17:58:51 melwitt so we can do that too obviously
17:59:43 melwitt yeah, if I do that then no more private access. I thought about it but figured I'd just throw the "most efficient" thing up to get discussion
17:59:58 opendevreview Dan Smith proposed openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486
18:00:24 melwitt that would also get us endpoint discovery as a backport
18:00:37 sean-k-mooney ya
18:01:21 melwitt probably a better move. I'll push an update with that and see what yall think
18:04:59 sean-k-mooney before you do
18:05:19 sean-k-mooney why are we even using oslo.limist for this when the openstack sdk has a function ot get registered limits
18:05:21 sean-k-mooney https://github.com/openstack/openstacksdk/blob/master/openstack/identity/v3/_proxy.py#L1625-L1634
18:05:50 melwitt sean-k-mooney: to make it use the [oslo.limit] config section. or do you suppose there's another way to do that?
18:06:34 sean-k-mooney well we coudl read those config varible oursleves
18:06:44 sean-k-mooney i.e. for region
18:07:03 sean-k-mooney lookup the service id our selves and then just call keystone directly
18:07:24 melwitt yeah. will need all the other auth stuff too and I was thinking it should match what nova is using for enforcing
18:07:25 sean-k-mooney or even use our keystoneauth section
18:08:13 sean-k-mooney i would agree if oslo.limit provided the apis we needed :)
18:08:22 sean-k-mooney ok for now lets not boil the ocean
18:08:35 sean-k-mooney and focus on the smallest change to make it work
18:08:48 melwitt eh.. I was wary of that because the idea of using one avenue to get the limits and a different one to enforce. I'm not sure if there could be consequence for some part of the config being different
18:08:52 melwitt I was thinking it's likely less error prone to use the same exact thing oslo.limit is using
18:09:35 melwitt same user, same password etc and not let there be the ability to make them different
18:11:13 melwitt and creating a dummy enforcer seemed like the simplest way to do that. maybe I can make a direct sdk connection read the config section I want. there's probably a way to do that, I'll check
18:13:48 melwitt oh yeah, looks like that can be done easily. I'll try that and see what we think
20:37:33 opendevreview Merged openstack/nova master: api: Add response body schemas for for console auth token APIs (v2.99) https://review.opendev.org/c/openstack/nova/+/943252
#openstack-nova - 2025-03-07
01:23:17 opendevreview Masahito Muroi proposed openstack/nova master: Use dict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/939658
11:33:54 opendevreview Rajesh Tailor proposed openstack/nova master: Add support for showing instance-action finish_time https://review.opendev.org/c/openstack/nova/+/928933
14:36:13 opendevreview OpenStack Release Bot proposed openstack/os-vif stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/os-vif/+/943753
14:36:14 opendevreview OpenStack Release Bot proposed openstack/os-vif stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/os-vif/+/943754
14:36:16 opendevreview OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/os-vif/+/943756
14:36:22 opendevreview OpenStack Release Bot proposed openstack/osc-placement stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/osc-placement/+/943757
14:36:23 opendevreview OpenStack Release Bot proposed openstack/osc-placement stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/osc-placement/+/943758
14:36:24 opendevreview OpenStack Release Bot proposed openstack/osc-placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/osc-placement/+/943759
14:36:32 opendevreview OpenStack Release Bot proposed openstack/python-novaclient stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/python-novaclient/+/943762
14:36:34 opendevreview OpenStack Release Bot proposed openstack/python-novaclient stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/python-novaclient/+/943763
14:36:35 opendevreview OpenStack Release Bot proposed openstack/python-novaclient master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/python-novaclient/+/943764
15:11:10 opendevreview Merged openstack/os-vif stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/os-vif/+/943753
15:12:03 opendevreview Merged openstack/os-vif stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/os-vif/+/943754
15:12:04 opendevreview Merged openstack/os-vif master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/os-vif/+/943756
15:42:16 dansmith gibi: if I look at the allocations that we have in the resource tracker before we do the local claim stuff, I don't see any for the pci device
15:42:24 dansmith ...but I should right?
15:44:09 dansmith yeah, they're in the actual allocations in placement, they're just not like added to the allocations we pass down to the compute node..
15:54:15 gibi dansmith: allocation is made in placement, the InstancePCIRequest carries the information about what RPs are fulfilling what request by placement.
15:54:38 dansmith yeah I guess I would just expect those to be in our list of allocations
15:55:03 gibi when you say "allocation" what you mean exactly?
15:57:38 gibi the pci claim only happens on the compute side. so the pci tracker has no information about the allocation until the pci claim happens on the comptue side
16:03:56 dansmith gibi: https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L142
16:04:10 dansmith that allocations variable is a dict of {rp_uuid: {allocation_dict}}
16:04:34 dansmith in this case, it has the local compute node's rp_uuid and allocations for memory, etc, but not the pci allocations
16:05:19 dansmith to me, it should be "all the allocations that have been made for this instance".. or at least, that's what I expect
16:08:31 gibi yeah that should have it
16:08:44 gibi do you have pci_in_placement enable?
16:09:45 gibi https://github.com/openstack/nova/blob/276685b3db6e8f2ad59c33bc254461c255700ff8/nova/compute/manager.py#L2615C1-L2617C40
16:09:57 gibi we load allocation from placement before the instance_claim call
16:10:40 gibi so if you see the allocation in placement then the same data should be in the allocation dict in the claim call
16:10:42 dansmith yes, the allocations get made in placement, and the pci device has the rp_uuid in the extra_info, it's just never getting merged
16:11:52 gibi I suggest to trace how we read the allocations from placement before the instance_claim call
16:12:03 dansmith the device that we get back from the pci claim also doesn't get the new key in extra_info that I'm putting in device_spec
16:12:49 dansmith gibi: okay I thought those were passed down via rpc and not re-loaded in compute, but I could be wrong
16:13:39 dansmith but yeah I see that get_allocations_for_consumer() call.. it's almost like that's filtering for just our RP or something
16:14:18 gibi dansmith: for the devspec => dev data move you need to extend this https://github.com/openstack/nova/blob/276685b3db6e8f2ad59c33bc254461c255700ff8/nova/pci/devspec.py#L418
16:15:14 dansmith ah, okay I added the key in the update, like this: https://review.opendev.org/c/openstack/nova/+/942144/4/nova/objects/pci_device.py
16:15:35 dansmith and I see it in the "final resource view" when n-cpu starts, but not when I get it back from the pci claim
16:15:45 dansmith I'll add it there too
16:16:26 gibi I need to drop. It was a long week. I will try to check back later today but more likely only on monday
16:16:45 dansmith no prob, thanks
16:19:05 dansmith yep, that did it
16:23:45 gibi ohh if you see the allocation in placement but not during claim then it must be the allocation healing that creates the allocation in placement and not the scheduler. pci_in_placement flag needs to be true in the config not just report_in_placement
16:32:59 dansmith hmm
17:15:56 opendevreview Merged openstack/python-novaclient master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/python-novaclient/+/943764
17:22:51 dansmith gibi: aha, yep, that does it, thanks
17:36:37 opendevreview Merged openstack/nova stable/2024.2: Reproduce bug/2097359 https://review.opendev.org/c/openstack/nova/+/942085
18:09:57 opendevreview Merged openstack/nova stable/2024.2: Update InstanceNUMACell version after data migration https://review.opendev.org/c/openstack/nova/+/942086
18:11:46 opendevreview sean mooney proposed openstack/nova master: only show standard image properties in server show. https://review.opendev.org/c/openstack/nova/+/942413
18:13:20 opendevreview Merged openstack/nova stable/2024.2: Update InstanceNUMACell version in more cases https://review.opendev.org/c/openstack/nova/+/942087
18:16:05 opendevreview sean mooney proposed openstack/nova master: only show standard image properties in server show. https://review.opendev.org/c/openstack/nova/+/942413
18:17:23 sean-k-mooney gibi: ^ this is a less dramtic rewite tha tavoid round triping the data via the object when we are composing the responce
18:17:45 sean-k-mooney gibi: so it will keep the keys and values matching what we have in the system_metadta_table

Earlier   Later