yahoo-eng-team team mailing list archive

[xiewj <xie.wenjun2@xxxxxxxxxx>]

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