Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-06
17:41:53 sean-k-mooney you could try [""]
17:42:16 melwitt yes that's why I'm using the connection directly
17:42:24 sean-k-mooney i.e. ENFORCE.get_registered_limists([""])
17:42:44 sean-k-mooney ya well modle.connection is public it seams
17:42:58 sean-k-mooney its just the endpoint id and service id that not right
17:42:59 melwitt yes and I'm using it in that patch :)
17:43:38 melwitt Enforcer.get_registered_limits() does "for resource_name in resource_names:" and will do nothing if you don't pass it a list of names and if you pass it a list of names it will pull each limit in a separate API call
17:44:03 melwitt sean-k-mooney: correct it's the endpoint id and service id that are not public
17:45:31 melwitt I could alternatively pull those separately the same way that oslo.limit does today
17:45:39 sean-k-mooney ya im not seeing a better way to do it with the current api
17:45:41 melwitt I considered that might be more well liked
17:46:43 melwitt so maybe I should push a new PS that pulls the services and then gets the endpoint ID from it, that way no private attrs need to be used
17:47:31 sean-k-mooney thats an incremental imporment. i fell lilke they didnt fully fix the usablity problem
17:48:18 sean-k-mooney as in they didnt really fix the usablity problem reported in https://launchpad.net/bugs/1931875
17:48:35 sean-k-mooney if we have to port that code to nova
17:48:59 melwitt well that works for 99% of users who have no need to query for the list of limits
17:49:22 sean-k-mooney ya but athat a pretty fundemental thing
17:49:26 melwitt strictly for limit enforcement what they did fixes it all
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

Earlier   Later