)]}'
{"specs/queens/approved/pci-by-device-id.rst":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Today (Pike), PCI devices are identified in three places:"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"* The compute driver constructs a list of ``pci_passthrough_devices`` in the"},{"line_number":31,"context_line":"  data returned by ``get_available_resource``."},{"line_number":32,"context_line":"* In the compute config, ``[pci]passthrough_whitelist`` delineates which"},{"line_number":33,"context_line":"  devices are allowed to be assigned to VMs."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_ed058112","line":30,"range":{"start_line":30,"start_character":6,"end_line":30,"end_character":13},"updated":"2017-08-26 10:09:42.000000000","message":"s/compute/virt/","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  `slices`_ select chunks out of its DRC index and doles them out into the"},{"line_number":57,"context_line":"  domain/bus/slot/func buckets.  This is a similar pain point as for vendor and"},{"line_number":58,"context_line":"  product ID, *except* that there are code paths in Nova which assume that"},{"line_number":59,"context_line":"  information about a device can be gleaned from ``/sys`` special file paths"},{"line_number":60,"context_line":"  constructed based on the PCI address.  Obviously these paths do not exist for"},{"line_number":61,"context_line":"  spoofed addresses."},{"line_number":62,"context_line":"* For some hypervisors, the devices aren\u0027t owned by the compute node.  HyperV"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_2d170948","line":59,"range":{"start_line":59,"start_character":58,"end_line":59,"end_character":76},"updated":"2017-08-26 10:09:42.000000000","message":"they\u0027re not special. it\u0027s standardized Linux sysfs.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb86e041953079b11ae4d6acc023b7099b70468","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  `slices`_ select chunks out of its DRC index and doles them out into the"},{"line_number":57,"context_line":"  domain/bus/slot/func buckets.  This is a similar pain point as for vendor and"},{"line_number":58,"context_line":"  product ID, *except* that there are code paths in Nova which assume that"},{"line_number":59,"context_line":"  information about a device can be gleaned from ``/sys`` special file paths"},{"line_number":60,"context_line":"  constructed based on the PCI address.  Obviously these paths do not exist for"},{"line_number":61,"context_line":"  spoofed addresses."},{"line_number":62,"context_line":"* For some hypervisors, the devices aren\u0027t owned by the compute node.  HyperV"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_b380fa47","line":59,"in_reply_to":"7f287b81_18d48d47","updated":"2017-08-26 15:50:00.000000000","message":"Sorry guys, I meant \"special\" in the sense of \"device special files\".  Perhaps that\u0027s an archaic term, but it refers to the fact that they\u0027re not \"normal\" data files.  (Then again, maybe they are these days.)\n\nAnyway, can reword.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"ff6cbe4c53793af27cd577c93a6200e589c8be3d","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  `slices`_ select chunks out of its DRC index and doles them out into the"},{"line_number":57,"context_line":"  domain/bus/slot/func buckets.  This is a similar pain point as for vendor and"},{"line_number":58,"context_line":"  product ID, *except* that there are code paths in Nova which assume that"},{"line_number":59,"context_line":"  information about a device can be gleaned from ``/sys`` special file paths"},{"line_number":60,"context_line":"  constructed based on the PCI address.  Obviously these paths do not exist for"},{"line_number":61,"context_line":"  spoofed addresses."},{"line_number":62,"context_line":"* For some hypervisors, the devices aren\u0027t owned by the compute node.  HyperV"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_18d48d47","line":59,"in_reply_to":"7f287b81_2d170948","updated":"2017-08-26 12:43:08.000000000","message":"Sure, but the primary point still stands: the code path makes two assumptions which aren\u0027t always: the devices being validated are local to the hardware where the code is being; the devices are being identified the way the linux sysfs identifies things. Those kinds of assumptions ought to be contained in the virt drivers.\n\nI agree that \"special\" is the wrong word here, and that this section could be clarified.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"ff6cbe4c53793af27cd577c93a6200e589c8be3d","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  other environments, like PowerVM, it is not possible to make the device"},{"line_number":65,"context_line":"  appear on the compute node.  Thus any logic such as the aforementioned"},{"line_number":66,"context_line":"  ``/sys`` special file usage is at best unusable, and at worst makes features"},{"line_number":67,"context_line":"  of PCI passthrough unavailable under those drivers."},{"line_number":68,"context_line":"* It is only possible to identify groupings of devices to assign to VMs based"},{"line_number":69,"context_line":"  on a single vendor/product ID pair.  This is of inadequate granularity in"},{"line_number":70,"context_line":"  both directions:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_b8ce99b1","line":67,"updated":"2017-08-26 12:43:08.000000000","message":"I would guess that this point and the previous one could probably be chunkified into small points to illuminate the issues more clear. More list items, maybe with sub lists, more punchy.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":73,"context_line":"    cards; but they\u0027re attached to different networks.  I have no way to"},{"line_number":74,"context_line":"    construct an alias, flavor, and spawn request that gets my VM a network"},{"line_number":75,"context_line":"    card on a specific one of those networks.  (See `this blueprint`_ for a"},{"line_number":76,"context_line":"    previous request for this functionality.)"},{"line_number":77,"context_line":"  * **Too narrow**: I have multiple GPUs with different vendor/product IDs.  I"},{"line_number":78,"context_line":"    have no way to specify an alias/flavor that allows my VM to get any one of"},{"line_number":79,"context_line":"    them."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_cd1f6559","line":76,"updated":"2017-08-26 10:09:42.000000000","message":"In the example above, the network the device is attached to would be a trait of the resource provider. This is important to be clear about: device \"pools\" as they exist in the current PCI device management module should go the way of the Dodo. The user doesn\u0027t need a \"intranet-linked SR-IOV VF\" resource. They need an SR-IOV VF resource that is being provided by a physical function resource provider decorated with a trait marking the physical function is physically connected to the intranet network.\n\nIt\u0027s a subtle but important difference. Referring to the user needing \"an intranet-linked SRIOV VF\" as a resource leads to unnecessary custom resource classes representing these \"device pools\" whereas the latter approach leads to standard resource classes and custom traits. The reporting of the two is quite different, IMHO.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"cbelu@cloudbasesolutions.com","username":"claudiub"},"change_message_id":"56edcae369f48dda03b163fc454beafbfde2538d","unresolved":false,"context_lines":[{"line_number":73,"context_line":"    cards; but they\u0027re attached to different networks.  I have no way to"},{"line_number":74,"context_line":"    construct an alias, flavor, and spawn request that gets my VM a network"},{"line_number":75,"context_line":"    card on a specific one of those networks.  (See `this blueprint`_ for a"},{"line_number":76,"context_line":"    previous request for this functionality.)"},{"line_number":77,"context_line":"  * **Too narrow**: I have multiple GPUs with different vendor/product IDs.  I"},{"line_number":78,"context_line":"    have no way to specify an alias/flavor that allows my VM to get any one of"},{"line_number":79,"context_line":"    them."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f2577a7_d79e3806","line":76,"in_reply_to":"7f287b81_cd1f6559","updated":"2017-09-11 11:54:45.000000000","message":"Hm, I guess we could consider the network to which the NIC is connected to as a trait, but it\u0027s not necessary for this issue to be solved.\n\nI\u0027ve hit this issue as well, as I\u0027ve had 2 identical NICs, but connected to different physical networks. Using vendor_id and product_id to whitelist the NICs doesn\u0027t help much.\n\nSo, this problem has 2 sides, which has to be treated differently.\n\n1. NIC\u0027s VFs as PCI devices. This is the simpler scenario, all we have to do is to whitelist the VFs in order to allocate them.\n\nOn linux, I think you could solve this by passing the devname in the PCI passthrough_whitelist and physical_network\u003dphysnetX, or whatever neutron network a given physical network is associated with, and that would be sufficient for the VF to be plugged into the right neutron network, on the intended physical network. Haven\u0027t tried this though.\n\nOn Hyper-V, that won\u0027t work at the moment, the code tied to the devname workflow is linux-specific, unfortunately. Though, we could make it Hyper-V friendly, it can be quite a roundabout solution.\n\n2. NICs as full PCI passthrough devices (attach the NICs to the VMs as is). In this scenario, the NICs will be associated with a VM through it\u0027s PCI device alias, defined in the nova.conf\u0027s [pci]alias config option. There\u0027s no way to differentiate the NICs at the moment and thus, you may end up with the wrong NIC attached.\n\nWe should be able to alias PCI devices through other means as well, such as device_id, or parent_addr, or other fields like this.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":76,"context_line":"    previous request for this functionality.)"},{"line_number":77,"context_line":"  * **Too narrow**: I have multiple GPUs with different vendor/product IDs.  I"},{"line_number":78,"context_line":"    have no way to specify an alias/flavor that allows my VM to get any one of"},{"line_number":79,"context_line":"    them."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":".. _machinations: https://blogs.technet.microsoft.com/heyscriptingguy/2016/07/14/passing-through-devices-to-hyper-v-vms-by-using-discrete-device-assignment/"},{"line_number":82,"context_line":".. _slices: https://review.openstack.org/#/c/496434/3/nova_powervm/virt/powervm/vm.py@884"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_cd540501","line":79,"updated":"2017-08-26 10:09:42.000000000","message":"Not entirely following you on this example. Could you elaborate? Are you saying if you have multiple GPUs with the *same* vendor/product ID, you don\u0027t have control over which of those GPUs an instance uses?\n\nIf that\u0027s what you\u0027re saying above, that\u0027s precisely how resource allocation *should* work in a cloud. A user doesn\u0027t pick which of identical resources they want to use, because the cloud user doesn\u0027t *know* about those identical resources.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"cbelu@cloudbasesolutions.com","username":"claudiub"},"change_message_id":"56edcae369f48dda03b163fc454beafbfde2538d","unresolved":false,"context_lines":[{"line_number":76,"context_line":"    previous request for this functionality.)"},{"line_number":77,"context_line":"  * **Too narrow**: I have multiple GPUs with different vendor/product IDs.  I"},{"line_number":78,"context_line":"    have no way to specify an alias/flavor that allows my VM to get any one of"},{"line_number":79,"context_line":"    them."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":".. _machinations: https://blogs.technet.microsoft.com/heyscriptingguy/2016/07/14/passing-through-devices-to-hyper-v-vms-by-using-discrete-device-assignment/"},{"line_number":82,"context_line":".. _slices: https://review.openstack.org/#/c/496434/3/nova_powervm/virt/powervm/vm.py@884"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f2577a7_d7b75886","line":79,"in_reply_to":"7f287b81_93de1e6b","updated":"2017-09-11 11:54:45.000000000","message":"Ah, I understand what Eric is saying. He\u0027s saying that we should be able to request an instance with *a* / *any* GPU, regardless of what GPU it is, just give me one.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb86e041953079b11ae4d6acc023b7099b70468","unresolved":false,"context_lines":[{"line_number":76,"context_line":"    previous request for this functionality.)"},{"line_number":77,"context_line":"  * **Too narrow**: I have multiple GPUs with different vendor/product IDs.  I"},{"line_number":78,"context_line":"    have no way to specify an alias/flavor that allows my VM to get any one of"},{"line_number":79,"context_line":"    them."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":".. _machinations: https://blogs.technet.microsoft.com/heyscriptingguy/2016/07/14/passing-through-devices-to-hyper-v-vms-by-using-discrete-device-assignment/"},{"line_number":82,"context_line":".. _slices: https://review.openstack.org/#/c/496434/3/nova_powervm/virt/powervm/vm.py@884"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_93de1e6b","line":79,"in_reply_to":"7f287b81_cd540501","updated":"2017-08-26 15:50:00.000000000","message":"No, that\u0027s the previous (\"Too broad\") scenario.\n\nThis is one where I want my VM to be able to get any ol\u0027 GPU.  I don\u0027t care if it\u0027s from vendor X or vendor Y.  Which is also accomodated smoothly by the generic resource provider framework, as you\u0027ve described it.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":85,"context_line":"Use Cases"},{"line_number":86,"context_line":"---------"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"* Deepa Devanayagam, a compute driver Developer, wants to be able to populate"},{"line_number":89,"context_line":"  her ``pci_passthrough_devices`` list with identifying data gleaned natively"},{"line_number":90,"context_line":"  on her specific hypervisor for her specific devices.  She should not be"},{"line_number":91,"context_line":"  forced to specify an ``address`` in ``domain:bus:slot.func`` format if her"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_8d3dddc5","line":88,"range":{"start_line":88,"start_character":23,"end_line":88,"end_character":30},"updated":"2017-08-26 10:09:42.000000000","message":"s/compute/virt/","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"cbelu@cloudbasesolutions.com","username":"claudiub"},"change_message_id":"56edcae369f48dda03b163fc454beafbfde2538d","unresolved":false,"context_lines":[{"line_number":90,"context_line":"  on her specific hypervisor for her specific devices.  She should not be"},{"line_number":91,"context_line":"  forced to specify an ``address`` in ``domain:bus:slot.func`` format if her"},{"line_number":92,"context_line":"  hypervisor doesn\u0027t see it that way; or a ``vendor_id`` and ``product_id`` if"},{"line_number":93,"context_line":"  her device doesn\u0027t have one."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"* Ophelia Oppenheimer, an Operator, wants to be able to populate her"},{"line_number":96,"context_line":"  ``[pci]passthrough_whitelist`` and ``[pci]alias`` configs with identifiers"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f2577a7_57ab681c","line":93,"updated":"2017-09-11 11:54:45.000000000","message":"agreed.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"cbelu@cloudbasesolutions.com","username":"claudiub"},"change_message_id":"56edcae369f48dda03b163fc454beafbfde2538d","unresolved":false,"context_lines":[{"line_number":97,"context_line":"  familiar to - and readily, natively discoverable on - the hypervisor against"},{"line_number":98,"context_line":"  which her Nova compute/API services are running.  She should not have to run"},{"line_number":99,"context_line":"  awkward commands or perform awkward calculations to retrofit native"},{"line_number":100,"context_line":"  identifiers into these configs."},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"* Ms. Oppenheimer also wants to be able to group devices into deployable"},{"line_number":103,"context_line":"  aliases at any level of granularity."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f2577a7_977670d8","line":100,"updated":"2017-09-11 11:54:45.000000000","message":"agreed","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":107,"context_line":"  example, when Endymion wants a generic GPU, he should not have to worry about"},{"line_number":108,"context_line":"  whether to use flavor X or flavor Y, where the only difference is the vendor"},{"line_number":109,"context_line":"  ID of the GPUs aliased therein."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Proposed change"},{"line_number":112,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":113,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_6d3f51b4","line":110,"updated":"2017-08-26 10:09:42.000000000","message":"lol. love your actor names.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb86e041953079b11ae4d6acc023b7099b70468","unresolved":false,"context_lines":[{"line_number":107,"context_line":"  example, when Endymion wants a generic GPU, he should not have to worry about"},{"line_number":108,"context_line":"  whether to use flavor X or flavor Y, where the only difference is the vendor"},{"line_number":109,"context_line":"  ID of the GPUs aliased therein."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Proposed change"},{"line_number":112,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":113,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_33e1aa2b","line":110,"in_reply_to":"7f287b81_6d3f51b4","updated":"2017-08-26 15:50:00.000000000","message":":)","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":115,"context_line":"will be treated as an arbitrary string throughout Nova for the purposes of"},{"line_number":116,"context_line":"matching for whitelisting and claims."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"As part of this effort, we propose to extend the syntax of the ``[pci]alias``"},{"line_number":119,"context_line":"config to allow lists of devices.  This will ensure continued (and in fact,"},{"line_number":120,"context_line":"expanded) support of the grouping capabilities currently offered by the"},{"line_number":121,"context_line":"``vendor_id`` and ``product_id`` fields therein."},{"line_number":122,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_2d45c943","line":119,"range":{"start_line":118,"start_character":0,"end_line":119,"end_character":33},"updated":"2017-08-26 10:09:42.000000000","message":"This can and should be a completely separate spec/blueprint. I believe this particular item would be fairly non-controversial and fulfill the 3rd use case above (the end user one). There\u0027s no reason to tie it to the other parts.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb86e041953079b11ae4d6acc023b7099b70468","unresolved":false,"context_lines":[{"line_number":115,"context_line":"will be treated as an arbitrary string throughout Nova for the purposes of"},{"line_number":116,"context_line":"matching for whitelisting and claims."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"As part of this effort, we propose to extend the syntax of the ``[pci]alias``"},{"line_number":119,"context_line":"config to allow lists of devices.  This will ensure continued (and in fact,"},{"line_number":120,"context_line":"expanded) support of the grouping capabilities currently offered by the"},{"line_number":121,"context_line":"``vendor_id`` and ``product_id`` fields therein."},{"line_number":122,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_b3cebab1","line":119,"range":{"start_line":118,"start_character":0,"end_line":119,"end_character":33},"in_reply_to":"7f287b81_2d45c943","updated":"2017-08-26 15:50:00.000000000","message":"Yeah, I agree it could be split out.  I included it here because without it, device_id wouldn\u0027t be much use on the alias side.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":129,"context_line":"* A ``pci_passthrough_devices`` entry may contain a ``device_id`` field, in"},{"line_number":130,"context_line":"  which case ``address``, ``vendor_id``, and ``product_id`` are optional."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"* For SR-IOV support, a ``pci_passthrough_devices`` entry for a VF may contain"},{"line_number":133,"context_line":"  a ``parent_device_id`` field, whose semantics are similar to that of the"},{"line_number":134,"context_line":"  ``parent_addr`` field.  That is, a VF is matched to a whitelist entry or"},{"line_number":135,"context_line":"  alias based on its ``parent_device_id`` rather than its ``device_id``."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_0d78cd8d","line":132,"range":{"start_line":132,"start_character":5,"end_line":132,"end_character":20},"updated":"2017-08-26 10:09:42.000000000","message":"not just SR-IOV support, actually. some vGPU items use a parent-child relationship to represent \"pGPU groups\" (some NVIDIA cards).","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":8213,"name":"Claudiu Belu","email":"cbelu@cloudbasesolutions.com","username":"claudiub"},"change_message_id":"56edcae369f48dda03b163fc454beafbfde2538d","unresolved":false,"context_lines":[{"line_number":132,"context_line":"* For SR-IOV support, a ``pci_passthrough_devices`` entry for a VF may contain"},{"line_number":133,"context_line":"  a ``parent_device_id`` field, whose semantics are similar to that of the"},{"line_number":134,"context_line":"  ``parent_addr`` field.  That is, a VF is matched to a whitelist entry or"},{"line_number":135,"context_line":"  alias based on its ``parent_device_id`` rather than its ``device_id``."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"Today, in order to whitelist a specific device, a"},{"line_number":138,"context_line":"``[pci]passthrough_whitelist`` entry must contain either the full PCI"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f2577a7_5780088c","line":135,"updated":"2017-09-11 11:54:45.000000000","message":"agreed, and also, it might be just my case, but for VFs, I would like the PCI address field to not be mandatory.\n\nIn the Hyper-V scenario, the VFs do not have a particular address.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  case no other fields are required::"},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"    [pci]"},{"line_number":146,"context_line":"    passthrough_whitelist \u003d {\"device_id\": \"U78CB.001.WZS0JZB-P1-C10\"}"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Today, devices are grouped under an alias (referenced by flavors for deploy)"},{"line_number":149,"context_line":"based on a single ``vendor_id`` and ``product_id`` pair.  We propose:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_ed7c6184","line":146,"updated":"2017-08-26 10:09:42.000000000","message":"Does the above device_id indicate a *specific* device on the host or does it represent a *class* of devices? Because if it represents a specific device, that is going to make administration of PowerVM systems extremely annoying (the admin is essentially going to have to pre-discover all device IDs for the entire system (multiple hosts) and write a nova.conf file that includes every one of those device IDs. The purpose of the product_id/vendor_id whitelist was to enable admins to specify *classes* of devices that should be made available to end users.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb86e041953079b11ae4d6acc023b7099b70468","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  case no other fields are required::"},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"    [pci]"},{"line_number":146,"context_line":"    passthrough_whitelist \u003d {\"device_id\": \"U78CB.001.WZS0JZB-P1-C10\"}"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"Today, devices are grouped under an alias (referenced by flavors for deploy)"},{"line_number":149,"context_line":"based on a single ``vendor_id`` and ``product_id`` pair.  We propose:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_f36682c1","line":146,"in_reply_to":"7f287b81_ed7c6184","updated":"2017-08-26 15:50:00.000000000","message":"A *specific* device; and you\u0027re right.  But what\u0027s the alternative when my device doesn\u0027t have a vendor/product ID?\n\nAgain, generic resource providers to the rescue.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":166,"context_line":"                {\"vendor_id\": \"a1b2\", \"product_id\": \"f9e8\"},"},{"line_number":167,"context_line":"            ]}"},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"The ``device_id`` and ``parent_device_id`` introduced above are opaque strings."},{"line_number":170,"context_line":"They are not to be introspected by Nova code; only compared for exact equality"},{"line_number":171,"context_line":"against other opaque ``device_id`` strings."},{"line_number":172,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_ad72d9ab","line":169,"range":{"start_line":169,"start_character":6,"end_line":169,"end_character":15},"updated":"2017-08-26 10:09:42.000000000","message":"Note there is already an existing \"dev_id\" field in the pci_devices table:\n\nhttps://github.com/openstack/nova/blob/master/nova/objects/pci_device.py#L111\n\nHaving both a dev_id and device_id field would be exceedingly confusing.","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d4e7a588e5576bcf8859b5651a50b013ef329c6c","unresolved":false,"context_lines":[{"line_number":166,"context_line":"                {\"vendor_id\": \"a1b2\", \"product_id\": \"f9e8\"},"},{"line_number":167,"context_line":"            ]}"},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"The ``device_id`` and ``parent_device_id`` introduced above are opaque strings."},{"line_number":170,"context_line":"They are not to be introspected by Nova code; only compared for exact equality"},{"line_number":171,"context_line":"against other opaque ``device_id`` strings."},{"line_number":172,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_cd6d25cd","line":169,"range":{"start_line":169,"start_character":24,"end_line":169,"end_character":59},"updated":"2017-08-26 10:09:42.000000000","message":"note that there is already an existing \"parent_addr\" field in the pci_devices table:\n\nhttps://github.com/openstack/nova/blob/master/nova/objects/pci_device.py#L117","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb86e041953079b11ae4d6acc023b7099b70468","unresolved":false,"context_lines":[{"line_number":166,"context_line":"                {\"vendor_id\": \"a1b2\", \"product_id\": \"f9e8\"},"},{"line_number":167,"context_line":"            ]}"},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"The ``device_id`` and ``parent_device_id`` introduced above are opaque strings."},{"line_number":170,"context_line":"They are not to be introspected by Nova code; only compared for exact equality"},{"line_number":171,"context_line":"against other opaque ``device_id`` strings."},{"line_number":172,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_33688a85","line":169,"range":{"start_line":169,"start_character":6,"end_line":169,"end_character":15},"in_reply_to":"7f287b81_ad72d9ab","updated":"2017-08-26 15:50:00.000000000","message":"Wul heck, can we just use that?  I\u0027ll have to dig into the code some more to figure out what it\u0027s used for today (if anything).","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bcb86e041953079b11ae4d6acc023b7099b70468","unresolved":false,"context_lines":[{"line_number":166,"context_line":"                {\"vendor_id\": \"a1b2\", \"product_id\": \"f9e8\"},"},{"line_number":167,"context_line":"            ]}"},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"The ``device_id`` and ``parent_device_id`` introduced above are opaque strings."},{"line_number":170,"context_line":"They are not to be introspected by Nova code; only compared for exact equality"},{"line_number":171,"context_line":"against other opaque ``device_id`` strings."},{"line_number":172,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f287b81_1307cecc","line":169,"range":{"start_line":169,"start_character":24,"end_line":169,"end_character":59},"in_reply_to":"7f287b81_cd6d25cd","updated":"2017-08-26 15:50:00.000000000","message":"Right - ``parent_device_id`` is to ``device_id`` as ``parent_addr`` is to ``addr`` (see bullet on L132).","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":22255,"name":"Tuan","email":"tuanla@vn.fujitsu.com","username":"Tuan"},"change_message_id":"dd323c440ab82cb59465a9b9d856e6038f9e3d05","unresolved":false,"context_lines":[{"line_number":463,"context_line":"Please discuss the important scenarios needed to test here, as well as"},{"line_number":464,"context_line":"specific edge cases we should be ensuring work correctly. For each"},{"line_number":465,"context_line":"scenario please specify if this requires specialized hardware, a full"},{"line_number":466,"context_line":"openstack environment, or can be simulated inside the Nova tree."},{"line_number":467,"context_line":""},{"line_number":468,"context_line":"Please discuss how the change will be tested. We especially want to know what"},{"line_number":469,"context_line":"tempest tests will be added. It is assumed that unit test coverage will be"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f515b1d_b86d7333","line":466,"range":{"start_line":466,"start_character":0,"end_line":466,"end_character":9},"updated":"2017-10-09 07:28:39.000000000","message":"/s OpenStack/openstack","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"},{"author":{"_account_id":22255,"name":"Tuan","email":"tuanla@vn.fujitsu.com","username":"Tuan"},"change_message_id":"dd323c440ab82cb59465a9b9d856e6038f9e3d05","unresolved":false,"context_lines":[{"line_number":511,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":512,"context_line":""},{"line_number":513,"context_line":"Optional section intended to be used each time the spec is updated to describe"},{"line_number":514,"context_line":"new design, API or any database schema updated. Useful to let reader understand"},{"line_number":515,"context_line":"what\u0027s happened along the time."},{"line_number":516,"context_line":""},{"line_number":517,"context_line":".. list-table:: Revisions"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f515b1d_986ab717","line":514,"range":{"start_line":514,"start_character":0,"end_line":514,"end_character":3},"updated":"2017-10-09 07:28:39.000000000","message":"/s the new/ new","commit_id":"6560a60908e04ca0902a2e1bce3870027e579b65"}]}