Public bug reported: In the spec sriov-physical-function-passthrough.rst,'filtering/cliaming' shoule be 'filtering/claiming'
The spec's url is as follow: https://github.com/openstack/nova-specs/blob/master/specs/mitaka/implemented/sriov-physical-function-passthrough.rst Data model impact ----------------- Even though there is a way currently to figure out the PF a single VF belongs to (through the use of `extra_info` free-form field) it may be necessary to add a more "query friendly" relationship, that will allow us to answer the question "given a PCI device record that is a PF, which VF records does it contain". It is likely to be implemented as a foreign key relationship to the same table, and objects support will be added, but the actual implementation discussion is better suited for the actual code proposal review. It will also be necessary to be able to know relations between individual PFs and VFs in the aggregate view of the PCI device data used in scheduling, so changes to the way PciDeviceStats holds aggregate data. This will also result in changes to the filtering/cliaming logic, the extent of which may impact decisions about the data model so this is best discussed on actual implementation changes. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1610092 Title: There's a typo in the spec of sriov-physical-function-passthrough.rst Status in OpenStack Compute (nova): New Bug description: In the spec sriov-physical-function- passthrough.rst,'filtering/cliaming' shoule be 'filtering/claiming' The spec's url is as follow: https://github.com/openstack/nova-specs/blob/master/specs/mitaka/implemented/sriov-physical-function-passthrough.rst Data model impact ----------------- Even though there is a way currently to figure out the PF a single VF belongs to (through the use of `extra_info` free-form field) it may be necessary to add a more "query friendly" relationship, that will allow us to answer the question "given a PCI device record that is a PF, which VF records does it contain". It is likely to be implemented as a foreign key relationship to the same table, and objects support will be added, but the actual implementation discussion is better suited for the actual code proposal review. It will also be necessary to be able to know relations between individual PFs and VFs in the aggregate view of the PCI device data used in scheduling, so changes to the way PciDeviceStats holds aggregate data. This will also result in changes to the filtering/cliaming logic, the extent of which may impact decisions about the data model so this is best discussed on actual implementation changes. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1610092/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp