Earlier  
Later
New Search
Posted Nick Remark
#openstack-cyborg - 2026-09-11
09:43:36 sean-k-mooney bogdando[m]: form the api ref "A attribute represents the trait of a physical card like FPGA or GPU."
09:43:54 sean-k-mooney its litally just a proxy api to add traits to the placement resouce provider
09:44:07 sean-k-mooney its not needed today because you can do that directly via the placment api
09:45:09 sean-k-mooney this is why i said i dont think its fit for porpus today and i woudl prefer to entirly replace it in the future
09:47:54 bogdando[m] attributes api looks redundant, yes, although mentions non-placement/nova use cases
09:48:27 sean-k-mooney it would acked as a geneitc metatdata store
09:48:52 sean-k-mooney but https://bugs.launchpad.net/openstack-cyborg/+bug/2158996 prevents it form being used at all today
09:49:25 sean-k-mooney the implemtion today requries you to know the internal database primary key which is never returend form teh api
09:49:45 bogdando[m] "A device may have components, such as flash memory or BMC, which are not of relevance to Nova or Placement. Those components may have attributes"
09:50:29 sean-k-mooney we do not have any usecase that require that currnetly
09:51:38 sean-k-mooney to be clear if i was a core when this was propsoed i would have been -2 on the spec based on its curent content
09:52:06 bogdando[m] actually that "not of Nova relevance" answers to my propoal already - phys_net is in relevance, hence not a fit for that api
09:53:06 sean-k-mooney i can see usecase for device metadta or config apis in the future but that diffent
16:27:54 sean-k-mooney melwitt: ok i finially finsihed reviewign both your spec and left comments inline
16:28:37 sean-k-mooney directionally both are a good start but between teh 2 i left 60 ish comments so maybe wait till monday to read them :)
16:57:48 melwitt sean-k-mooney: 60?? lol ok. thank you for reviewing :)
17:06:01 sean-k-mooney melwitt: some of them may be duplicative
17:06:28 sean-k-mooney i went seciton by seciton and later noteice that soem eiarer coment were paticly adressed
17:06:45 melwitt ah nice I got some review from bogdando[m] too. thanks both
17:07:00 melwitt ah k
17:09:04 sean-k-mooney i started early today and it now 18:00 so im going to finsh nowish
17:09:26 sean-k-mooney if you want to chat about any of the feed back on a call or somehting we can grab some time next week
17:09:52 melwitt sounds good :)
17:09:53 sean-k-mooney but we can continue to dicuss on gerrit too
17:16:23 opendevreview Takashi Kajinami proposed openstack/cyborg-tempest-plugin master: Add stable/2026.2 job https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/1005315
#openstack-cyborg - 2026-09-12
01:11:15 opendevreview melanie witt proposed openstack/cyborg-specs master: Add spec for NIC SR-IOV support in the generic PCI driver https://review.opendev.org/c/openstack/cyborg-specs/+/1005089
#openstack-cyborg - 2026-09-14
15:24:32 melwitt sean-k-mooney: thanks for the review on my specs :) I have replied and updated the NIC support in generic PCI driver one
15:25:09 sean-k-mooney cool ill try and take a look later in the week
15:25:32 sean-k-mooney did the expectaion aound the nova cybrog neutron interactions make sense to you wehn you read them
15:26:35 sean-k-mooney i know that is a bit complex but the spec were at least somehwat clear on what each service should be doing
15:26:48 sean-k-mooney i looked at the neutron code but didnt look at teh nova side
16:08:41 melwitt sean-k-mooney: yes I think I understood the basics of what you said about nova/cyborg/neutron
16:09:35 melwitt on the nova side it appears you are right about accessing 'physical_network' is _currently_ pointless bc it's not used for anything
16:10:01 melwitt it accesses the key but then does nothing with it
16:11:35 sean-k-mooney ack
16:11:40 melwitt the question is then, should nova be using that key to report a trait to placement (per the https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html spec)
16:11:41 sean-k-mooney that shoudl be an easy fix so
16:11:50 sean-k-mooney no it should not
16:12:02 sean-k-mooney the placement reporting is doen by cyborg
16:12:29 sean-k-mooney nova shuld be using the phsyical network form the neturon port/network to request the phsynet when quering placement
16:12:30 melwitt yeah, in my testing I commented out that key access and then was able to create the server successfully with the sriov port
16:12:32 melwitt ack
16:13:07 sean-k-mooney basiclly we shoudd more or less do this like we would for neutron sriov ports
16:13:18 sean-k-mooney currenly we do that filtering after the placement call
16:13:23 sean-k-mooney but ideally we woudl do it before hand
16:13:38 sean-k-mooney i.e. we do it via the pci filter today for neutron
16:15:21 sean-k-mooney in nova our vifi object have a type filed and a network field https://github.com/openstack/nova/blob/master/nova/network/model.py#L427-L428
16:16:14 sean-k-mooney but im not sure we currently recored the phsynet in the network
16:16:29 sean-k-mooney so we may have to look that up directly form neutron
16:16:44 sean-k-mooney or plumb that inf though the modeles
16:16:56 sean-k-mooney this is the bit i didnt want to look up on firday :)
16:18:14 sean-k-mooney we have some exsting code we can draw form like https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2183-L2224
16:18:48 sean-k-mooney for example in create_resouces_requsts https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2356
16:19:23 sean-k-mooney infact that is also wehre we are creating the cyborg requests
16:19:27 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2356-L2373
16:20:52 melwitt hm ok, so nova should be using the key to request a trait rather
16:21:01 sean-k-mooney unless im missing somehting we are looking up the phsynet and nerver actully passing it
16:21:12 sean-k-mooney melwitt: yes
16:21:24 melwitt that is what I saw as well, looking it up but then doing nothing with it
16:21:27 sean-k-mooney because the device profile is the same regardless fo the network
16:21:46 sean-k-mooney but hte phsynet depend on the network and or l2 segment
16:22:12 melwitt ok I will update the nova bug with this info
16:27:01 sean-k-mooney ah... https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2417-L2422
16:27:04 melwitt ok yeah I see now, I had misread the spec
16:27:26 sean-k-mooney so right now stpehens piror chagnes are findign a host aht has the requried phnets
16:27:45 sean-k-mooney but when they added the cybrog feature the didnt do it on a per nic basis
16:28:04 sean-k-mooney i.e. then never enriched the requried traits for the cyborg request group
16:28:29 sean-k-mooney so if your host only has 1 phsynet this will owrk but if it has 2 then you might get a device on the wrong one form placement
16:28:38 melwitt does that mean anything needst o change about the code you linked with the physnets? or would the cyborg change be an additive change
16:28:41 sean-k-mooney that will then fail at the port bidning stage in neutron
16:28:53 sean-k-mooney no the code shoudl still be changed
16:29:20 melwitt I mean, does _that_ code need to change? with cyborg, is it bad to add the physnet to the set the way it is currently?
16:29:45 sean-k-mooney those are 2 diffent api responces
16:29:53 sean-k-mooney it is correct to add it to the attachment handel
16:30:07 sean-k-mooney but https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2367-L2376 is the imporant part we need to check
16:30:20 sean-k-mooney we are gettign the reqeust form the device profile
16:30:28 melwitt oh ok, so the if physnet: physnets.add(physnet) can stay as-is even when we fix the cyborg part
16:30:28 sean-k-mooney the device profile shoudl not have the phsynet
16:30:35 sean-k-mooney right
16:30:40 melwitt ok that's good
16:30:48 sean-k-mooney that for neutron sriov port
16:30:51 sean-k-mooney so that bit is fine
17:02:01 sean-k-mooney sorry was distracted with nova irc meeting as you probaly saw
18:13:49 melwitt yes np
#openstack-cyborg - 2026-09-15
12:00:35 opendevreview chandan kumar proposed openstack/cyborg-specs master: Repropose generic nvme driver secure cleanup spec for 2027.1 https://review.opendev.org/c/openstack/cyborg-specs/+/1005716
12:04:16 opendevreview chandan kumar proposed openstack/cyborg-specs master: Repropose generic nvme driver secure cleanup spec for 2027.1 https://review.opendev.org/c/openstack/cyborg-specs/+/1005716
13:02:30 opendevreview Joan Gilabert proposed openstack/cyborg-specs master: Repropose generic mdev driver spec for 2026.2 https://review.opendev.org/c/openstack/cyborg-specs/+/1005068
13:21:37 opendevreview Joan Gilabert proposed openstack/cyborg-specs master: Repropose generic mdev driver spec for 2027.1 https://review.opendev.org/c/openstack/cyborg-specs/+/1005068
13:44:40 opendevreview Joan Gilabert proposed openstack/cyborg-specs master: Repropose generic mdev driver spec for 2027.1 https://review.opendev.org/c/openstack/cyborg-specs/+/1005068
13:47:24 opendevreview chandan kumar proposed openstack/cyborg-specs master: Repropose NVMe secure cleanup spec for 2027.1 https://review.opendev.org/c/openstack/cyborg-specs/+/1005716
14:02:19 opendevmeet The meeting name has been set to 'cyborg'
14:02:19 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:19 opendevmeet Meeting started Tue Sep 15 14:02:19 2026 UTC and is due to finish in 60 minutes. The chair is jgilaber. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:19 jgilaber #startmeeting cyborg
14:02:25 jgilaber Hi! Who is around today?
14:02:33 gamio o/
14:02:37 chandankumar o/
14:02:41 morenod o/
14:02:42 sean-k-mooney o/
14:02:59 jgilaber while we gather, feel free to add your topics to the agenda https://etherpad.opendev.org/p/openstack-cyborg-irc-meeting#L49

Earlier   Later