| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-03-03 | |||
| 14:24:03 | sean-k-mooney | i.e. a sriov capable nvida gpu | |
| 14:24:24 | bogdando[m] | I am not sure there would be real migration paths, given that no functional deployments will be possible for VFs by nvidia driver until kernels support vfio variant driver?.. | |
| 14:24:53 | sean-k-mooney | so that not the limitation exactly | |
| 14:25:10 | sean-k-mooney | it was possibel to passthough the vf it just would not function correctly in the guest | |
| 14:25:17 | sean-k-mooney | my conder is not for the workload | |
| 14:25:22 | sean-k-mooney | it for the cybrog service | |
| 14:25:40 | sean-k-mooney | we need to ensure that if ther is an allcoation in place that is handeled gracefully | |
| 14:26:11 | bogdando[m] | we cannot filter out VFs in such a case? | |
| 14:26:22 | sean-k-mooney | that can be refusing the remove the resocue provider and deployable until the allcoation is deleted with a loud error message | |
| 14:26:35 | sean-k-mooney | bogdando[m]: we can but not the ones that are currently assigned | |
| 14:26:42 | bogdando[m] | ack | |
| 14:26:53 | sean-k-mooney | so nova has a protection for this for the pci tracker | |
| 14:27:01 | sean-k-mooney | if you remove a device form the devspec | |
| 14:27:04 | bogdando[m] | wrt HW to test, I could use hardware, but no way to install cyborg there yet | |
| 14:27:15 | sean-k-mooney | we will not remove it form the db until it is freeded by a vm that was assigned to it | |
| 14:27:30 | sean-k-mooney | bogdando[m]: ack that is fine for now | |
| 14:28:27 | sean-k-mooney | while we will eventually want to do more hadware based testing we can simulate the test env for the short term in unit tests | |
| 14:28:52 | sean-k-mooney | i assume the lspci data you used in the test came form a real system | |
| 14:29:08 | sean-k-mooney | thats why i was asking if you had access | |
| 14:29:13 | bogdando[m] | it looks real, yes | |
| 14:31:38 | sean-k-mooney | i didnt really have any other questions to ask | |
| 14:31:47 | bogdando[m] | simulating test env with minimal services to have placement db would be great | |
| 14:32:13 | sean-k-mooney | adding fucntional tests like nova has with the palcment fixture | |
| 14:32:20 | sean-k-mooney | is definetly soemting we shoudl build | |
| 14:32:30 | sean-k-mooney | just not in that bug fix | |
| 14:32:45 | bogdando[m] | right | |
| 14:32:55 | sean-k-mooney | the placement-fixture form placement provide a placement api backed by sqlite | |
| 14:33:15 | sean-k-mooney | which you can use in your tests witouth actully deploying placmenet seperatly | |
| 14:33:24 | sean-k-mooney | that allows you to test the end to end behavior | |
| 14:33:47 | bogdando[m] | so we can build the migration path like you noted w/o func tests yet in that patch, right? | |
| 14:34:28 | sean-k-mooney | what i think we need to do is test how cyborg handels removal of placemetn rps and deployables in general | |
| 14:34:39 | sean-k-mooney | so we can test that with the pci driver for example | |
| 14:34:53 | sean-k-mooney | then based on that we can determin how to proceed with the nvidia driver | |
| 14:35:46 | sean-k-mooney | the management of the placment inventories and deployables shoudl not be driver dependnet in general but we will need to review how that works today | |
| 14:36:05 | sean-k-mooney | if we find that will break | |
| 14:36:14 | sean-k-mooney | then we may put the fix behind a config option for now | |
| 14:36:35 | sean-k-mooney | so that you can move forward with the simple fix which will for for 99% of deployments | |
| 14:36:51 | sean-k-mooney | and we can defer the upgrade question to a sperate patch | |
| 14:37:07 | bogdando[m] | makes sense | |
| 14:38:34 | bogdando[m] | I will fence that fix with a config knob then | |
| 14:39:06 | sean-k-mooney | ack | |
| 14:39:20 | sean-k-mooney | we can discuss it more in the review | |
| 14:40:45 | jgilaber | ack thanks, any other comment on this review? | |
| 14:41:36 | jgilaber | let's move to bug triage then | |
| 14:41:43 | jgilaber | #topic Bugs | |
| 14:41:50 | jgilaber | #link https://bugs.launchpad.net/openstack-cyborg/+bug/1940511 | |
| 14:42:42 | sean-k-mooney | so this i need to build more context on | |
| 14:42:59 | sean-k-mooney | the api docs site is unfortunetlly down right now for me | |
| 14:43:19 | sean-k-mooney | openstack accelerator arq create command | |
| 14:43:36 | sean-k-mooney | isue used to create the Accleerator resouce request, this is normally only done by nova | |
| 14:43:45 | sean-k-mooney | so humans shoudl not really call this directly | |
| 14:44:48 | sean-k-mooney | https://github.com/openstack/cyborg/blob/master/api-ref/source/arqs.inc | |
| 14:45:53 | jgilaber | looking at the api the command is not correct, but the client does have a "--group-id" option | |
| 14:45:53 | sean-k-mooney | the request looks somethign like this https://github.com/openstack/cyborg/blob/master/doc/api_samples/accelerator_requests/accelerator_requests-post-curl.json | |
| 14:46:31 | sean-k-mooney | and this is the responce https://github.com/openstack/cyborg/blob/master/doc/api_samples/accelerator_requests/accelerator_requests-create-resp.json | |
| 14:46:46 | sean-k-mooney | so the comemnt is that https://github.com/openstack/cyborg/blob/master/doc/api_samples/accelerator_requests/accelerator_requests-create-resp.json#L14 | |
| 14:46:49 | sean-k-mooney | is always 0 | |
| 14:48:13 | sean-k-mooney | we likely shoudl create a repoducer | |
| 14:48:25 | sean-k-mooney | but i thinkw e need to better understand teh semantics of the api | |
| 14:48:30 | sean-k-mooney | by reviewing the related spec | |
| 14:49:40 | sean-k-mooney | i think for now we shoudl move on | |
| 14:49:53 | jgilaber | agreed, not sure if it's a real bug or not, do we mark as incomplete or we leave it as is? | |
| 14:50:11 | sean-k-mooney | lets mark it incomplete for now sure | |
| 14:50:16 | sean-k-mooney | i added the api tag | |
| 14:50:24 | jgilaber | ack thanks | |
| 14:50:26 | sean-k-mooney | it not clear if its a clinet or api bug | |
| 14:50:36 | sean-k-mooney | or neither | |
| 14:50:42 | jgilaber | let's move to the second one | |
| 14:50:43 | jgilaber | #link https://bugs.launchpad.net/openstack-cyborg/+bug/1941025 | |
| 14:51:19 | sean-k-mooney | so this is a feature reqeust | |
| 14:51:25 | sean-k-mooney | its also in the wrogn repo | |
| 14:51:35 | sean-k-mooney | it shoudl be in the python-cyborg client repo | |
| 14:51:52 | sean-k-mooney | its valid i think to supprot this in the future | |
| 14:52:35 | sean-k-mooney | i have fixed that | |
| 14:52:44 | sean-k-mooney | what shoudl we triage this ass | |
| 14:52:46 | sean-k-mooney | *as | |
| 14:53:04 | sean-k-mooney | wishlist since it a feature reqeust ro medium becuase its a partiy gap | |
| 14:53:10 | sean-k-mooney | between the cli and api | |
| 14:53:47 | jgilaber | I'm leaning towards wishlist for now | |
| 14:54:17 | jgilaber | but no strong opinion either way | |
| 14:54:47 | sean-k-mooney | works for me | |
| 14:55:11 | jgilaber | ack, let's move to the third one | |
| 14:55:16 | jgilaber | #link https://bugs.launchpad.net/openstack-cyborg/+bug/1954888 | |
| 14:55:38 | jgilaber | this is a doc request | |
| 14:56:29 | sean-k-mooney | so there im conflcited | |
| 14:56:42 | sean-k-mooney | only nova and zun should do that directly | |
| 14:56:58 | sean-k-mooney | as bidnign and unbinding the acclerator via ARQs shoudl reqruei the service role | |
| 14:57:16 | sean-k-mooney | with that said if you used cybrog in standaloen deployment | |
| 14:57:31 | sean-k-mooney | without either then it would not be a terible thing to document | |
| 14:57:42 | sean-k-mooney | im just not sure we want to supprot that usage mode | |
| 14:57:46 | sean-k-mooney | or at least not right now | |
| 14:58:01 | sean-k-mooney | so this feels low to wishlist if not invalid | |
| 14:58:18 | sean-k-mooney | im all for adding documeition fo how the bidnign flow shoudl work | |
| 14:58:22 | sean-k-mooney | in the contibutor docs | |
| 14:58:38 | sean-k-mooney | but i dont think we shoudl be documenting a manual end user/admin procedure | |
| 14:58:53 | jgilaber | I'm wondering if the intention was to document how to use nova with cyborg to bind accelerators? | |
| 14:59:07 | jgilaber | I'm not sure how well that is documented right now | |
| 14:59:16 | sean-k-mooney | it could be interepeted as a requce to docuemtn the function as a serivce flow | |
| 14:59:43 | sean-k-mooney | i think we set this to incomplete and come back to it next week | |
| 14:59:55 | sean-k-mooney | we need to basiclly refine the scope of it | |