Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-06
15:53:43 gibi dansmith: so for me I don't need a full blown swap operation between any two consumer. I'm OK to have just a PATCH on an existing allocation to update the consumer uuid in it and do nothing else.
15:54:13 sean-k-mooney this is the existing api we are talking about yes https://docs.openstack.org/api-ref/placement/#update-allocations
15:54:18 dansmith gibi: yeah if we can do that cleanly that might be good.. I'll have to start digging in to determine, but yeah
15:54:49 dansmith are you thinking PATCH /allocations/uuid1 with {consume_uuid: uuid2} ?
15:55:05 dansmith that will work, not sure how the REST police feel, but I'd think it's better than a POST /swap_action
15:55:16 gibi sean-k-mooney: we are talking about https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L2059 that is what we do today
15:55:50 gibi dansmith: yeah lets ask the REST gods about it but the PATCH feels simple to me
15:55:57 dansmith ack
15:56:09 sean-k-mooney patch is an update to an exiting resouce
15:56:22 sean-k-mooney the resouce is keyd by the consumer_uuid /allocations/{consumer_uuid}
15:56:41 sean-k-mooney we could supprot patch to chagne that
15:56:50 sean-k-mooney wihtout conflicting with the existing put
15:57:25 sean-k-mooney but it feesl a littel od ot do /allocations/{instance_uuid} bode: consumer_uuid=<migration uuuid>
15:57:27 gibi yeah we need to change the "key" that is why it feels problematic from REST perspective
15:57:32 bauzas I started to pay attention to this channel but I failed getting the problem to solve
15:57:40 sean-k-mooney i dont hate it
15:57:51 bauzas can someone summarize me the thread ?
15:58:12 sean-k-mooney the ohter option is somthign liek /allocations/{old uuid}/swap/{new uuid}
15:58:20 dansmith bauzas: https://bugs.launchpad.net/nova/+bug/1943191
15:58:23 gibi bauzas: move operations does not work if the source RP is over allocated or allocated and reserved
15:58:24 sean-k-mooney that would be a post i guess
15:58:37 dansmith bauzas: that and several other bugs, plus my OTU spec
15:59:06 bauzas I see
16:00:14 sean-k-mooney gibi: i think if we document things properly iether could work i think POST /allocations/{consumer_uuid}/swap/{new_consumer_id} is clear honestly
16:01:25 sean-k-mooney tha twould not have any body
16:01:46 sean-k-mooney so there is no posiblity of changing the allcotin or capsity useage and there for its ok to not do checks
16:02:21 sean-k-mooney if we go with patch we would have to ensure the resouces are not changed as well
16:07:46 gibi yeah I'm not against either the PATCH or the POST //swap/ way
16:10:07 sean-k-mooney i think we can all agree that if it alllow us to finally resovle thos bugs in nova either approch is better then what we have today. so if that the direction we head in im fine with say lets define that in the placement api spec
16:13:11 gibi I agree
16:14:01 dansmith yup
17:06:15 melwitt sean-k-mooney: not sure what you'll think of this but I uploaded a patch in regard to the oslo.limit endpoint discovery https://review.opendev.org/c/openstack/nova/+/943507 fyi
17:17:52 sean-k-mooney so we remove the end point check since oslo limists will do that for use internally
17:18:44 sean-k-mooney and we repalce the end point fuction with one that returns the limits for this service/region
17:19:26 sean-k-mooney these are the global limits right not the project specific ones
17:21:25 sean-k-mooney melwitt: without properly loadign context and looking at oslo limits its seams reasonable at first glance
17:23:50 melwitt sean-k-mooney: yeah the thing I think is controversial is the private attributes access
17:24:08 sean-k-mooney that not required with the latest version of oslo.limits right
17:24:09 melwitt maybe in parallel propose some public accesses in oslo.limit and update it when available? dunno
17:25:19 sean-k-mooney https://review.opendev.org/c/openstack/oslo.limit/+/914783/3/oslo_limit/limit.py
17:26:46 melwitt what is there currently will work for both old and new versions
17:27:09 melwitt and underneath oslo.limit will do what it needs to
17:27:10 sean-k-mooney right in the new version we can just call get_registered_limits
17:27:13 sean-k-mooney on the enforcer
17:27:48 sean-k-mooney https://github.com/openstack/oslo.limit/blob/8ada297e6a82f7e50bf746453b8dd21716743798/oslo_limit/limit.py#L183
17:29:43 sean-k-mooney melwitt: do you need to use the connection today
17:30:50 sean-k-mooney oh that funciton takes a set of resouces to check
17:33:25 melwitt sean-k-mooney: yeah I do that because I want to pull all the resourcs limits in one API call. oslo.limiit does them one API call per resource
17:34:07 sean-k-mooney it sound like we shoudl add a funciton to oslo limits to do that
17:34:17 sean-k-mooney but i think we can work around it in nova for now
17:34:33 melwitt maybe. there's already one so not sure if we change the internal impl or make another alongside
17:35:45 sean-k-mooney you could make None a seential value for all or use the sentenial object pattern
17:36:18 melwitt yeah
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

Earlier   Later