| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-03-10 | |||
| 14:10:55 | sean-k-mooney | with standard tempest | |
| 14:12:29 | chandankumar | bind and unbind arg sounds good | |
| 14:13:28 | chandankumar | I will break the existing test into multiple tests to have bind/ubind as well as passthrough to vim via standard tempest tests | |
| 14:13:53 | chandankumar | Thank you! I will update it in next meeting how it goes. | |
| 14:14:10 | bogdando[m] | a naive question, can't we reboot zuul node in CI? that breaks devstack, right? | |
| 14:14:26 | sean-k-mooney | yes and no | |
| 14:14:31 | sean-k-mooney | reboots dont break devstack | |
| 14:14:36 | sean-k-mooney | and we can remboot the vms | |
| 14:14:43 | sean-k-mooney | we woudl do that before installing devstack however | |
| 14:16:07 | sean-k-mooney | if the kernel is compiled with supprot for it | |
| 14:16:09 | sean-k-mooney | echo 1 | sudo tee /sys/module/vfio/parameters/enable_unsafe_noiommu_mode | |
| 14:16:09 | bogdando[m] | so worth exploring? | |
| 14:16:21 | sean-k-mooney | is the simples option in the exsitng pre playbook | |
| 14:17:43 | sean-k-mooney | without that we can still do some testign via whtiebox we just can boot a vm. lets see if ubuntu 24.04 or debian 13 ship with that kernel module partmer | |
| 14:17:52 | sean-k-mooney | if not we can revisit how we approch this | |
| 14:18:06 | sean-k-mooney | liek addign a new image to the ci and nodepool lable with the viommu enabled | |
| 14:18:27 | sean-k-mooney | we dont wnat to do that by defualt as there is a non trivial performace hti to that | |
| 14:18:31 | chandankumar | I will check with my existing nvmevirt preplaybook | |
| 14:19:52 | chandankumar | yes, we can revisit this topic in next meeting based on testing how it goes. | |
| 14:20:06 | chandankumar | Any more questions on this topic? | |
| 14:20:23 | sean-k-mooney | ubuntu@openclaw:~$ grep CONFIG_VFIO_NOIOMMU /boot/config-$(uname -r) | |
| 14:20:25 | sean-k-mooney | CONFIG_VFIO_NOIOMMU=y | |
| 14:20:42 | sean-k-mooney | so ubuntu 24.04 appears to have it enabeld at least if we install the mainline kernel | |
| 14:20:50 | bogdando[m] | \o/ | |
| 14:20:51 | sean-k-mooney | but now lets see what your ci run shows | |
| 14:21:20 | sean-k-mooney | if we need to install the mainline (upstream kernel) we can do that but we need to verify it in a vanilla 24.04 | |
| 14:22:13 | chandankumar | yup, I will verify it locally with mainline kernel | |
| 14:22:22 | chandankumar | good point! | |
| 14:23:00 | chandankumar | moving to next topic | |
| 14:23:09 | chandankumar | #topic Reviews | |
| 14:23:25 | chandankumar | there is one review | |
| 14:23:29 | chandankumar | #link 979805: Rename devstack CYBORG_CONF_FILE to CYBORG_CONF for consistency | https://review.opendev.org/c/openstack/cyborg/+/979805 | |
| 14:24:18 | chandankumar | While I was working on nvmevirt devstack patch, I found that In cyborg we use CYBORG_CONF_FILE var for cyborg conf in devstack | |
| 14:24:41 | sean-k-mooney | hum i think its currently CYBORG_CONF_FILE to disambiguate with CYBORG_CONF_DIR | |
| 14:24:53 | chandankumar | but in Nova or other services we use <SERVICE>_CONF, so I thought about changing it to nova format | |
| 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 | bogdando[m] | looks like it should stay deferred unless standalone cyborg gets on the radar | |
| 14:30:51 | sean-k-mooney | and that workflow | |
| 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 | |