Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1803502

Summary:	[RFE] Desired/Specific NIC's VF pci bus address should be probed for configuring nic partitioning for data plane
Product:	Red Hat OpenStack	Reporter:	Jaison Raju <jraju>
Component:	openstack-ironic-python-agent	Assignee:	OSP Team <rhos-maint>
Status:	CLOSED DUPLICATE	QA Contact:	mlammon
Severity:	low	Docs Contact:
Priority:	medium
Version:	16.0 (Train)	CC:	bfournie, cfontain, hakhande, jkreger, jraju, mburns, slinaber, supadhya
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-12 10:40:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jaison Raju 2020-02-16 14:00:34 UTC

Description of problem:
NIC Partitioning for data plane traffic with PCI Passthrough configuration requires pci bus address of VFs. This information is not obtained in introspection.


Introspection should be able to probe pci bus address of Virtual Functions of specific NICs so that the templates can be accordingly designed for using nic partitioning for data plane.

I am referring to '3.' in following doc, which requires this information to be added in the templates:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/network_functions_virtualization_planning_and_configuration_guide/index#sect-configuring-host-sriov

Version-Release number of selected component (if applicable):
RHOS16

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Although this is Tech Preview, I thought it best to track this feature.

Comment 4 Julia Kreger 2021-07-09 13:51:19 UTC

In essence, it sounds like the ask is a hardware manager *or* extension of python-hardware to extract additional information, however without access to such hardware an a better understanding, I don't think the hardware provisioning team can effectively work to provide a solution to the ask. If more details could be provided to help us understand the use/cases and what is needed, and hardware was accessible, it may be feasible depending on team capacity.