| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-06 | |||
| 17:38:14 | sean-k-mooney | so gibi's main concern seams to be those are private filed and there for could break which is valid. if oslo were ok providing public access in some way i would be ok with this as a backportable approch as long as we update to using the public appropch in the future | |
| 17:39:31 | melwitt | sean-k-mooney: right. it's mine too, which is why I mentioned it in the commit message. yeah I think that sounds reasonable | |
| 17:39:33 | sean-k-mooney | i dont hate it but if we could just do ENFORCE.get_registered_limists(None) | |
| 17:39:39 | sean-k-mooney | i would be happier | |
| 17:39:56 | melwitt | sure | |
| 17:39:57 | sean-k-mooney | the other option for now | |
| 17:40:12 | melwitt | will that work currently? /me looks | |
| 17:40:15 | sean-k-mooney | is kep doing it the old way and instead fo raising try and do it this way | |
| 17:40:28 | sean-k-mooney | melwitt: i was trying ot figure that out | |
| 17:40:36 | sean-k-mooney | you can pass it i just dont know what happens if you do | |
| 17:41:09 | sean-k-mooney | its this right https://docs.openstack.org/api-ref/identity/v3/#list-registered-limits | |
| 17:41:13 | melwitt | it looks like it would do nothing | |
| 17:41:20 | melwitt | https://github.com/openstack/oslo.limit/blob/master/oslo_limit/limit.py#L355 | |
| 17:41:30 | sean-k-mooney | it say resouce name is optional in the api | |
| 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 | |