Earlier  
Posted Nick Remark
#openstack-cyborg - 2026-09-07
12:44:46 chandankumar Hello sean-k-mooney, I did not get a chance to work on 2026.2 release prelude.
12:44:51 chandankumar Feel free to take it.
12:45:18 sean-k-mooney sure will do ill do that later today
12:45:30 sean-k-mooney once that is merge i think we will tag rc1
12:50:36 chandankumar thank you!
13:42:50 opendevreview sean mooney proposed openstack/cyborg master: use seperate config for cyborg agent https://review.opendev.org/c/openstack/cyborg/+/1004421
14:49:06 opendevreview Joan Gilabert proposed openstack/cyborg-specs master: Move 2026.2 RBAC spec to implemented https://review.opendev.org/c/openstack/cyborg-specs/+/1004438
15:02:00 opendevreview chandan kumar proposed openstack/cyborg master: Route ARQ unbind through conductor-to-agent cleanup RPCs https://review.opendev.org/c/openstack/cyborg/+/999939
15:02:01 opendevreview chandan kumar proposed openstack/cyborg master: Guard ARQ bind against non-available devices https://review.opendev.org/c/openstack/cyborg/+/999941
15:02:01 opendevreview chandan kumar proposed openstack/cyborg master: nvme: implement NVMeDriver.cleanup() https://review.opendev.org/c/openstack/cyborg/+/999940
15:02:02 opendevreview chandan kumar proposed openstack/cyborg master: Expose device_state in device API and register nvme_driver entrypoint https://review.opendev.org/c/openstack/cyborg/+/999942
15:02:40 opendevreview chandan kumar proposed openstack/cyborg master: Deprecate SSD drivers in favour of NVMe driver https://review.opendev.org/c/openstack/cyborg/+/999943
15:02:51 opendevreview chandan kumar proposed openstack/cyborg master: Add NVMe driver admin guide and API reference for microversion 2.4 https://review.opendev.org/c/openstack/cyborg/+/999944
15:03:02 opendevreview chandan kumar proposed openstack/cyborg master: Add per-PF vf_personality sysfs interface https://review.opendev.org/c/openstack/cyborg/+/998603
15:03:23 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: introduce personality ops-table dispatch for VF device types https://review.opendev.org/c/openstack/cyborg/+/999125
15:03:37 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe host kernel module https://review.opendev.org/c/openstack/cyborg/+/999928
15:05:17 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe VFIO guest probe and host handoff https://review.opendev.org/c/openstack/cyborg/+/999929
15:05:29 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add software MSI-X domain to fake host bridge https://review.opendev.org/c/openstack/cyborg/+/1003255
15:05:40 opendevreview chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945
15:34:34 opendevreview chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945
15:35:08 opendevreview sean mooney proposed openstack/cyborg master: use separate config for the cyborg agent https://review.opendev.org/c/openstack/cyborg/+/1004421
15:41:05 opendevreview chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945
16:18:30 opendevreview Joan Gilabert proposed openstack/cyborg-specs master: Move 2026.2 RBAC spec to implemented https://review.opendev.org/c/openstack/cyborg-specs/+/1004438
17:06:56 opendevreview sean mooney proposed openstack/cyborg master: use separate config for the cyborg agent https://review.opendev.org/c/openstack/cyborg/+/1004421
17:52:59 opendevreview sean mooney proposed openstack/cyborg master: Add 2026.2 release prelude https://review.opendev.org/c/openstack/cyborg/+/1004468
17:53:28 sean-k-mooney im going to use ^ as the basis of the marketing highliths now
18:28:19 sean-k-mooney done https://review.opendev.org/c/openstack/releases/+/1004471 we can review both tomorrow
18:45:15 opendevreview sean mooney proposed openstack/cyborg master: Use a separate config for cyborg-agent https://review.opendev.org/c/openstack/cyborg/+/1004421
#openstack-cyborg - 2026-09-08
04:46:57 opendevreview chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945
07:08:48 opendevreview chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945
10:30:11 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe VFIO guest probe and host handoff https://review.opendev.org/c/openstack/cyborg/+/999929
10:30:11 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe host kernel module https://review.opendev.org/c/openstack/cyborg/+/999928
10:30:12 opendevreview chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945
10:30:12 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add software MSI-X domain to fake host bridge https://review.opendev.org/c/openstack/cyborg/+/1003255
12:49:30 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe VFIO guest probe and host handoff https://review.opendev.org/c/openstack/cyborg/+/999929
12:49:30 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add NVMe host kernel module https://review.opendev.org/c/openstack/cyborg/+/999928
12:49:31 opendevreview chandan kumar proposed openstack/cyborg master: Add NVMe driver devstack plugin support https://review.opendev.org/c/openstack/cyborg/+/999945
12:49:31 opendevreview chandan kumar proposed openstack/cyborg master: pci-sim: add software MSI-X domain to fake host bridge https://review.opendev.org/c/openstack/cyborg/+/1003255
13:42:32 opendevreview Merged openstack/cyborg master: Add 2026.2 release prelude https://review.opendev.org/c/openstack/cyborg/+/1004468
14:01:55 opendevmeet The meeting name has been set to 'cybrog'
14:01:55 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:55 opendevmeet Meeting started Tue Sep 8 14:01:54 2026 UTC and is due to finish in 60 minutes. The chair is sean-k-mooney. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:55 sean-k-mooney #startmeeting cybrog
14:02:14 chandankumar o/
14:02:19 morenod o/
14:02:22 sean-k-mooney ping list amoralej bogdando jgilaber rlandy chandankumar skovili melwit
14:02:25 jgilaber o/
14:02:32 rlandy o/
14:02:53 sean-k-mooney #link https://etherpad.opendev.org/p/openstack-cyborg-irc-meeting
14:03:02 sean-k-mooney we will start shortly
14:03:35 sean-k-mooney if there are any topics feel free to add them to the adjeda above
14:03:49 melwitt o/
14:04:42 sean-k-mooney ok i think that is most of the folks that are around today
14:04:49 sean-k-mooney so lets start
14:05:00 sean-k-mooney #topic Support for multiple resource classes per deployable
14:05:26 sean-k-mooney jgilaber: this one is yours
14:05:45 jgilaber yes, I wanted to ask about how to handle this
14:05:55 sean-k-mooney so contex for every one
14:06:06 jgilaber for context, cyborg only supports one resource class per deployable
14:06:09 sean-k-mooney today cyborg modesl resouce provider in placmeent as deployables
14:06:56 sean-k-mooney yep which for the generic mdev drvier or pci driver means that if we want to group mdevs or pci vf by the parent pf
14:07:14 sean-k-mooney they either must all have the same resouce class
14:07:27 sean-k-mooney or we have to model it diffently with nested resouces
14:07:41 sean-k-mooney nested provdiers
14:08:01 sean-k-mooney so i guess your question is shoudl this be its own feature/spec
14:08:20 sean-k-mooney the ablity to have more then one resocue class per deploryable/resource provider
14:08:23 jgilaber exactly
14:08:29 sean-k-mooney im inlcined to say yes
14:08:37 jgilaber in the approved spec we agreed to have one deployable per mdev type and revisit in the future
14:08:46 sean-k-mooney repopose the mdev spec as is with only 1 type
14:09:01 jgilaber but since I have to repropose anyway I figured I'd look into it
14:09:05 sean-k-mooney and seperately propsole a seperate feature to supprot multiple rescoues classes per deployable
14:09:40 sean-k-mooney jgilaber: so without going into the details too much
14:09:51 jgilaber wanted to get people thoughts but that was my idea since this would affect all drivers
14:09:55 sean-k-mooney i think we need to move to modelign the resouce class on teh device or attachment handel
14:10:31 sean-k-mooney currently i belive we use the atibutes tabel to store it correct?
14:11:12 jgilaber yes, I think that's right
14:11:27 jgilaber e.g from the pci driver https://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/pci/pci/sysinfo.py#L71-L74
14:11:36 sean-k-mooney we maynot need ot modify the device or attach hanel actully it just depend what atributes are assocated with
14:11:54 sean-k-mooney ah so ya that is the problem
14:11:56 sean-k-mooney https://github.com/openstack/cyborg/blob/master/cyborg/db/sqlalchemy/models.py#L144-L156
14:12:19 sean-k-mooney the Attribute table references the deployable not the device
14:13:05 sean-k-mooney i think this is a generic capablity that all drviers shoudl be able to leverage when needed
14:13:15 sean-k-mooney so to me that makes it its own spec
14:13:24 sean-k-mooney anyone else have an opionon on that?
14:13:47 melwitt I think that sounds a good idea
14:14:05 melwitt keep each piece smaller
14:14:21 sean-k-mooney there is a larger related topic
14:14:27 jgilaber ack, I was leaning towards that so +1 from me
14:14:45 sean-k-mooney i think we need to look at and impvoe the modeling of device, atibutes, deployabels and attachment handels in general
14:15:07 sean-k-mooney even if tha tis just docs to descibe there role
14:16:07 sean-k-mooney right now the exact meaning/uage of all of the above feel a bit fuzzy and it woudl be nice to impvoe that going forward
14:16:31 sean-k-mooney i think this is just one fo the pain point in that model but perhasp its a good one to adress first
14:17:16 jgilaber that's a good point, we can build docs as part of this new spec
14:17:48 sean-k-mooney part of the problem is the atribtues api
14:17:52 sean-k-mooney that was merged
14:17:58 sean-k-mooney did not follow the approves sepc
14:18:19 sean-k-mooney so its an areay of technial debt that we need to adress at some point
14:19:29 sean-k-mooney so we may want to adress that as part of this work and use this as an opterutnity to docuemtn the intended behvior
14:19:56 sean-k-mooney anyway we can dicuss that in a spec or ptg topic unless there is anyting else you want to raise today?

Earlier   Later