| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-06-09 | |||
| 14:15:02 | sean-k-mooney | my linclition is to delet this entirly | |
| 14:15:08 | sean-k-mooney | but i want to look a the history and usage | |
| 14:15:15 | sean-k-mooney | before we make a code change for it | |
| 14:15:57 | sean-k-mooney | id ont think https://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/modules/generic.py#L82 | |
| 14:15:59 | sean-k-mooney | is currently used | |
| 14:16:19 | sean-k-mooney | so we will liekly delete the enfire https://github.com/openstack/cyborg/tree/master/cyborg/accelerator/drivers/modules directory | |
| 14:16:36 | sean-k-mooney | but as i said we need to investigate if this is infact dead code or not | |
| 14:16:39 | chandankumar | https://review.opendev.org/c/openstack/cyborg/+/473186 - added the generic driver | |
| 14:17:30 | jgilaber | it looks like not all drivers inherit from the base one e.g https://github.com/openstack/cyborg/blob/233f2a5b7e396c24bf15ae22f8cf64a480666f5c/cyborg/accelerator/drivers/gpu/base.py#L30 | |
| 14:17:51 | sean-k-mooney | chandankumar: yes but that generic dirver was lated remvoed | |
| 14:18:46 | sean-k-mooney | jgilaber: ya that also a problem kind of | |
| 14:18:59 | sean-k-mooney | it will work but id dont want to chagne thie picemeal | |
| 14:19:00 | chandankumar | I will look into the history | |
| 14:19:32 | chandankumar | I can see two specs also https://github.com/openstack/cyborg-specs/blob/981405a8938ed786feaaf63ea1955aa7174a367b/specs/pike/implemented/cyborg-driver-proposal.rst#L8 and https://github.com/openstack/cyborg-specs/blob/981405a8938ed786feaaf63ea1955aa7174a367b/specs/train/implemented/cyborg-accelerator-driver.rst#L8 around generic driver | |
| 14:19:44 | sean-k-mooney | chandankumar: ok | |
| 14:20:03 | sean-k-mooney | so i have been hining at the fact that this might need a spec or mor thought then a quick bugfix | |
| 14:20:21 | sean-k-mooney | i.e. tha that you shoudl proably not focus on this right now | |
| 14:20:26 | sean-k-mooney | let me know what you find | |
| 14:20:27 | chandankumar | yes correct | |
| 14:20:43 | chandankumar | sure, I will dig into the history and open a bug around that | |
| 14:20:47 | chandankumar | we can take it from there | |
| 14:20:53 | sean-k-mooney | this was somithing i was plannign to look into closer to the end of the cycle ebfor ethe next ptg | |
| 14:21:12 | sean-k-mooney | i dont really expect use to make large changes to this ebfore then | |
| 14:22:26 | sean-k-mooney | basiclly i want to look at propsoign a new generic driver framework for next chcel | |
| 14:22:39 | sean-k-mooney | and prot the exitign fucntionaltiy as part fo that work | |
| 14:22:44 | chandankumar | yup, I will keep it to finding, you can take it from there | |
| 14:23:19 | sean-k-mooney | cool so i think we can move onto jgilaber spec | |
| 14:23:25 | chandankumar | yes | |
| 14:23:38 | chandankumar | #link https://review.opendev.org/c/openstack/cyborg-specs/+/982276: Add generic mdev driver spec for 2026.2 | |
| 14:23:56 | chandankumar | jgilaber: I have added your spec since you made changes to it | |
| 14:24:05 | chandankumar | Anything you want to highlight from last revision | |
| 14:24:18 | jgilaber | thanks for the reviews on the spec | |
| 14:24:35 | jgilaber | there is one thing worth pointing out I think | |
| 14:25:10 | jgilaber | while going through sean-k-mooney comments there is one that made me doubt, let me find the link | |
| 14:25:26 | jgilaber | #link https://review.opendev.org/c/openstack/cyborg-specs/+/982276/comment/b5f2b851_3cfdee76/ | |
| 14:25:31 | jgilaber | #undo | |
| 14:25:48 | jgilaber | sorry, I though I pasted the wrong link | |
| 14:26:02 | sean-k-mooney | the deplicate device coment | |
| 14:26:11 | jgilaber | yes | |
| 14:26:18 | sean-k-mooney | ya so in the medium term the conducrot shoud nto eb talkign to palcement at all | |
| 14:26:36 | sean-k-mooney | the cybrog compute agents should | |
| 14:26:39 | jgilaber | it looks to me that currently in cyborg we cannot currently have a deployable with more than one resource class | |
| 14:26:55 | jgilaber | which we might want to do to use multiple mdev classes from one device | |
| 14:27:16 | sean-k-mooney | well that proably ok | |
| 14:27:29 | sean-k-mooney | what we need to model is as follows | |
| 14:27:44 | sean-k-mooney | we need 1 placement resouce provider per PF | |
| 14:28:00 | sean-k-mooney | and we need an inventory of mdev benetat it | |
| 14:28:38 | sean-k-mooney | so each mdev will be a deployable right but there wotn be a 1:1 mapping between deployabels and resouce providers | |
| 14:29:13 | sean-k-mooney | i need to look into that in more deail myself to see how this is currently working | |
| 14:29:41 | sean-k-mooney | one thing that would help is some ascii diagrams in the spec | |
| 14:29:46 | sean-k-mooney | to visually show how this works | |
| 14:30:24 | sean-k-mooney | we have 2 related concepts in cybrogs api devices and deployables | |
| 14:30:32 | jgilaber | good point I'll add some diagrams, it was confusing for me too | |
| 14:30:54 | jgilaber | but if I understood correctly, in cyborg the resrouce provider is created from a DriverDeployable | |
| 14:31:10 | jgilaber | not from a DriverDevice | |
| 14:32:19 | sean-k-mooney | so the only way we woudl supprot more then one mdev type per phsyica device | |
| 14:32:27 | sean-k-mooney | is if we were addign the VFs | |
| 14:33:00 | sean-k-mooney | with that said we coudl aslo suffix the pci adress in the rp name | |
| 14:33:02 | sean-k-mooney | with the type | |
| 14:33:09 | sean-k-mooney | so i think we coudl workaroudn that limiation | |
| 14:33:20 | sean-k-mooney | but we may want to think about the modelign more | |
| 14:33:31 | sean-k-mooney | in nova we started with 1 type per device | |
| 14:33:38 | sean-k-mooney | so that woudl eb a reasonable limiation fro v1 | |
| 14:33:56 | sean-k-mooney | the nvidia driver didnt supprotr multipel asfar as im aware either | |
| 14:34:06 | jgilaber | that is my understanding yes, the simplest workaround would be one DriverDeployable for each mdev type | |
| 14:34:31 | sean-k-mooney | can you write up some of the options in the spec | |
| 14:34:39 | sean-k-mooney | and we can discuss the tradeoffs | |
| 14:34:43 | jgilaber | the nvidia driver just picks the first vgpu type it finds and uses that to create the rp | |
| 14:34:55 | sean-k-mooney | i see | |
| 14:34:57 | jgilaber | sure, I already have some of this but I'll expand with the diagrams | |
| 14:35:00 | sean-k-mooney | that less then useful | |
| 14:36:27 | sean-k-mooney | that comemnt was it picking the first one | |
| 14:36:41 | sean-k-mooney | jgilaber: did you have any other questions you wanted to raise | |
| 14:37:05 | jgilaber | no, thanks, the rest of the feedback was clear and I think I addressed it all | |
| 14:37:26 | chandankumar | thank you jgilaber | |
| 14:37:30 | chandankumar | moving to last review | |
| 14:37:42 | chandankumar | #link SRBAC: https://review.opendev.org/q/topic:%22bp/consistent-and-secure-rbac%22 | |
| 14:38:04 | chandankumar | #link srbac spec https://review.opendev.org/c/openstack/cyborg-specs/+/991932 | |
| 14:38:13 | chandankumar | sean-k-mooney: do you want to take it | |
| 14:38:21 | sean-k-mooney | sure | |
| 14:38:34 | sean-k-mooney | so this is one of 2 specs im planing to work on this cycle | |
| 14:38:48 | sean-k-mooney | part of the work was already compelted as part fo the CVE fixes | |
| 14:39:03 | sean-k-mooney | that focused on geting a secure baselien for api policy | |
| 14:39:16 | sean-k-mooney | the spec covers the 3 phases of the srbac comunity goal | |
| 14:39:29 | sean-k-mooney | it intnet for this cycle ist to supprot all standard roels | |
| 14:39:43 | sean-k-mooney | admin, manager, member, reader and service | |
| 14:39:55 | sean-k-mooney | i have mostly implemtned the spec already | |
| 14:40:00 | sean-k-mooney | including tmpest tests | |
| 14:40:08 | sean-k-mooney | but i woudl liek to ask for folks to review the spec | |
| 14:40:25 | sean-k-mooney | with attention pated to the polices/personas mapped to each api endpoint | |
| 14:40:45 | sean-k-mooney | basiclly ask does it make sense for this persona to eb able to call this api | |
| 14:41:08 | sean-k-mooney | i have 1 small bug in the cybrog patches which isll fix today/tomorrow | |
| 14:41:17 | sean-k-mooney | its technical debt form the cve fixes | |
| 14:41:27 | sean-k-mooney | that i want to think about a little more before fixing | |
| 14:41:44 | sean-k-mooney | the simple fix is trivali but im thinkign fo cleaning up a little more tech debt while im there | |
| 14:41:56 | sean-k-mooney | any questions on the effort or in general? | |
| 14:42:40 | jgilaber | not really, I've added the spec to my review list, I hope to get to it by the end of the week | |
| 14:42:53 | chandankumar | thank you for all the patches and spec, will go over the spec and have feedback there | |
| 14:42:55 | sean-k-mooney | in the spec i detail the timelien as well. this cycle suprpot the new polices, 2027.1 make the new polices the default and 2027.2 delete the old code | |
| 14:43:07 | sean-k-mooney | oh before i forget | |