Earlier  
Posted Nick Remark
#openstack-cyborg - 2026-03-10
14:25:37 sean-k-mooney well nova has more then one conf it uses with mutlipe variables
14:25:48 sean-k-mooney i.e. NOVA_CPU_CONF
14:25:50 sean-k-mooney i think
14:26:14 sean-k-mooney we could make this change im just not sure it by us much
14:27:10 sean-k-mooney if we do this i woudl make it fallback to the old name
14:28:08 sean-k-mooney so CYBORG_CONF=${CYBORG_CONF:-${CYBORG_CONF_FILE}}
14:28:10 chandankumar ok make sense, It will not break existing user
14:28:25 chandankumar I will update the review after this call.
14:28:51 sean-k-mooney ack
14:29:05 chandankumar since there is no more reviews moving to next topic
14:29:09 chandankumar #topic Bugs
14:29:30 chandankumar #link https://bugs.launchpad.net/openstack-cyborg/+bug/1954888 Docs: state how to use bound accelerators
14:29:39 chandankumar we discussed this bug in the last meeting
14:30:44 sean-k-mooney ya so im incliend to ether use this to track descirbing how to create the nova flavor and device profile
14:30:51 sean-k-mooney and that workflow
14:30:51 bogdando[m] looks like it should stay deferred unless standalone cyborg gets on the radar
14:31:08 sean-k-mooney or using it to track a contibutor doc or closing as wont fix
14:31:30 sean-k-mooney right standalon cyborg is not really a thing today so we shoudl nto have end user docs for that
14:31:46 sean-k-mooney so either we have a conceptal do for devleoper/contibutors
14:32:02 sean-k-mooney or we docuemnt the nova flow for end admins ro end users
14:32:13 sean-k-mooney but i dont think we shoudl spend time on stand alone
14:32:35 sean-k-mooney we could close this and create 2 seperate bugs for those other two docs gaps
14:32:41 jgilaber +1 I think there is value in documenting the standard workflow using nova, but I would not go further than that for now
14:33:41 sean-k-mooney i.e. 1 for admin doc for configuing and testign the standard wrokflow and 2 a contibutor doc to serve as a technial deep dive/refence of howt he services interact?
14:34:44 chandankumar Do we have a reference for nova flow doc link which we can add as a reference in the bug?
14:35:32 sean-k-mooney i dont think this really exist out side fo the spec today
14:35:50 sean-k-mooney i dont recall htere being a nova doc for ti but there may be
14:36:56 chandankumar ok
14:36:58 sean-k-mooney i will file 2 seperate bugs and close this when done
14:37:15 chandankumar thanks sean-k-mooney!
14:37:20 sean-k-mooney i can likely create a draft for the docs in the next few weeks if no one else does
14:37:46 chandankumar ok
14:38:01 chandankumar any more question on this bug.
14:38:18 chandankumar moving to next one
14:38:29 chandankumar #link https://bugs.launchpad.net/openstack-cyborg/+bug/1955285 arq delete no valid
14:39:23 sean-k-mooney that is just invliad
14:39:52 sean-k-mooney openstack accelerator arq delete c48f5ac0-0bff-44c0-9106-1850b355c5ca woudl be deliting arq c48f5ac0-0bff-44c0-9106-1850b355c5ca
14:39:57 sean-k-mooney not the arq for instance c48f5ac0-0bff-44c0-9106-1850b355c5ca
14:40:33 sean-k-mooney we might have a docs bug or a help text bug if it imples its the vm uuid
14:41:12 bogdando[m] how reasonable is having this in CLI assuming only service user should be allowed to do that low level things for/via nova?
14:41:13 sean-k-mooney but that is not what "openstack accelerator arq delete" means per the openstack client naming conventions
14:41:44 sean-k-mooney bogdando[m]: it some thing we will need to enfoce going forard
14:41:46 jgilaber there is an api call to delete arqs using the instance uuid Ie1894311b0e384ab52b1b3dfe0eb50618eef6c9f
14:41:56 jgilaber sorry pasted wrong
14:42:01 jgilaber https://docs.openstack.org/api-ref/accelerator/#delete-accelerator-requests-by-instance-uuid
14:42:04 sean-k-mooney its only vaild for a user to delete an arq if its not asssocated with an instance
14:42:49 sean-k-mooney ack let me review that seperatly
14:42:59 sean-k-mooney this clie shoudl be callign the other one
14:43:11 sean-k-mooney /v2/accelerator_requests?arqs={accelerator_request_uuid} not /v2/accelerator_requests?instance={instance_uuid}
14:43:35 sean-k-mooney both exist and the nameing convetion of osc woudl requrie we call the first path
14:43:44 sean-k-mooney to call the second we woudl need --instance or similar
14:43:58 sean-k-mooney but the secodn is invlid from my persective
14:44:26 sean-k-mooney im saying that as a nova core not a cybrog one
14:44:39 bogdando[m] the original use case seemed to be remove all arqs for a running instance
14:45:11 sean-k-mooney yep that not supproted by nova
14:45:16 jgilaber for what is worth the usage test of openstack accelerator arq delete is clear enough
14:45:29 jgilaber usage: openstack accelerator arq delete [-h] <uuid> [<uuid> ...
14:45:38 jgilaber <uuid> UUID(s) of the accelerator_request(s) to delete.
14:45:44 sean-k-mooney +1
14:45:46 jgilaber no mentions of instance uuids
14:45:56 sean-k-mooney that confims the expecation in the bug reprot is incorect
14:46:16 jgilaber yep, we can close it
14:46:25 bogdando[m] at least for now
14:46:41 sean-k-mooney i willl likely need to adress /v2/accelerator_requests?instance={instance_uuid} in my srback spec
14:46:53 sean-k-mooney but i suspect wwe will need to remove it in a future microversion
14:47:00 sean-k-mooney ill dig into the history of it
14:47:02 bogdando[m] may be it makes sense in future, as housekeeping things, like defragment vram to allow repartitioning
14:47:54 sean-k-mooney lets not specualte on it now
14:48:00 bogdando[m] ack
14:48:23 sean-k-mooney jgilaber: do you want to leave a comment on the bug or will i
14:48:30 sean-k-mooney i woudl liek to link to the doc sting when closing it
14:48:34 chandankumar https://github.com/openstack/cyborg/commit/1f9a808f1d965063a2744c6ea6ddeb76a5d57061 adds some does around second option
14:48:37 jgilaber I can do it
14:48:42 sean-k-mooney jgilaber: ++
14:49:42 sean-k-mooney chandankumar nova only supprots 1 ARQ today
14:50:00 sean-k-mooney i think this was added in preperation for cybrog device via neuton ports
14:50:10 sean-k-mooney since that fits the time frame but that never happend in nova or neutron
14:51:04 chandankumar ok
14:51:11 sean-k-mooney shall we move on to the next bug or finish early?
14:51:16 chandankumar yes
14:51:25 chandankumar #link https://bugs.launchpad.net/openstack-cyborg/+bug/1955286 cyborg cmd exec meeting keystone authentication fail
14:53:31 sean-k-mooney that looks like a deployment isseu
14:53:48 sean-k-mooney they are gettign a 401 form the micoversion endpoint
14:53:55 sean-k-mooney which shoudl not requrie auth
14:54:10 sean-k-mooney so without more info mation i think we close this as incompl.ete
14:54:24 sean-k-mooney bases on the path this looks liek a devstack deployment not production
14:54:37 sean-k-mooney /opt/stack/data/CA/int-ca/ca-chain.pem
14:54:51 sean-k-mooney /opt/stack/data is where devstack store service state
14:55:31 chandankumar I will take care of this one
14:55:44 sean-k-mooney ack
14:55:58 chandankumar there is one more bug, but I will move it to next meeting
14:56:03 sean-k-mooney we could see if we have the same bevhior in our local devstack but i dont think this si a real issue
14:56:08 sean-k-mooney ack
14:56:20 chandankumar moving to last topic
14:56:31 chandankumar #topic volunteer for next meeting
14:56:40 rlandy I'll do it since I skipped my last round
14:56:50 chandankumar thanks rlandy !
14:56:59 chandankumar #topic open discussion
14:57:13 chandankumar Anyone wants to bring any topic before closing the meeting.
14:58:44 chandankumar if not, then let me close the meeting

Earlier   Later