)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Parent:     37c576b9 (Fix problem description number in deprecate file injection spec)"},{"line_number":2,"context_line":"Author:     Konstantinos Samaras-Tsakiris \u003ckonstantinos.samaras-tsakiris@cern.ch\u003e"},{"line_number":3,"context_line":"AuthorDate: 2018-08-09 18:41:29 +0200"},{"line_number":4,"context_line":"Commit:     Konstantinos Samaras-Tsakiris \u003ckonstantinos.samaras-tsakiris@cern.ch\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"3f79a3b5_791591e4","line":1,"updated":"2018-08-22 22:59:01.000000000","message":"can I get co-author credit here?","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Parent:     37c576b9 (Fix problem description number in deprecate file injection spec)"},{"line_number":2,"context_line":"Author:     Konstantinos Samaras-Tsakiris \u003ckonstantinos.samaras-tsakiris@cern.ch\u003e"},{"line_number":3,"context_line":"AuthorDate: 2018-08-09 18:41:29 +0200"},{"line_number":4,"context_line":"Commit:     Konstantinos Samaras-Tsakiris \u003ckonstantinos.samaras-tsakiris@cern.ch\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"3f79a3b5_82e02928","line":1,"in_reply_to":"3f79a3b5_791591e4","updated":"2018-08-23 15:20:58.000000000","message":"Yes, this spec is entirely based upon your original idea. Sorry for not putting you here already; I\u0027m a new contributor and hadn\u0027t noticed the co-authored-by tag!","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"863f4060b5c142e9e8cbc6611bf63edab14fb70f","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Parent:     37c576b9 (Fix problem description number in deprecate file injection spec)"},{"line_number":2,"context_line":"Author:     Konstantinos Samaras-Tsakiris \u003ckonstantinos.samaras-tsakiris@cern.ch\u003e"},{"line_number":3,"context_line":"AuthorDate: 2018-08-09 18:41:29 +0200"},{"line_number":4,"context_line":"Commit:     Konstantinos Samaras-Tsakiris \u003ckonstantinos.samaras-tsakiris@cern.ch\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"3f79a3b5_255d9578","line":1,"in_reply_to":"3f79a3b5_82e02928","updated":"2018-08-23 16:55:38.000000000","message":"Yeah, no worries :)","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"}],"specs/stein/approved/device-placement-model.rst":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":67,"context_line":"          specification for particular device types by vendor/product ID, which"},{"line_number":68,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The path to the YAML will be provided by a config option in the default"},{"line_number":71,"context_line":"section of nova.conf, which will default to ``/etc/nova/inventory.yaml``."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":74,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d658328b","line":71,"range":{"start_line":70,"start_character":43,"end_line":71,"end_character":20},"updated":"2018-08-22 22:59:01.000000000","message":"We should state what this option will be called.\n\nAlso, is [DEFAULT] the right thing? I guess if all the configuration relating to device passthrough is going to be in the yaml file itself, it would be overkill to have a whole section just for this one opt. I\u0027m guessing the future will see us add more opts, but I suppose we can create a new section and move stuff if necessary.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"863f4060b5c142e9e8cbc6611bf63edab14fb70f","unresolved":false,"context_lines":[{"line_number":67,"context_line":"          specification for particular device types by vendor/product ID, which"},{"line_number":68,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The path to the YAML will be provided by a config option in the default"},{"line_number":71,"context_line":"section of nova.conf, which will default to ``/etc/nova/inventory.yaml``."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":74,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_854b49af","line":71,"range":{"start_line":70,"start_character":43,"end_line":71,"end_character":20},"in_reply_to":"3f79a3b5_821589e7","updated":"2018-08-23 16:55:38.000000000","message":"wfm","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":67,"context_line":"          specification for particular device types by vendor/product ID, which"},{"line_number":68,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The path to the YAML will be provided by a config option in the default"},{"line_number":71,"context_line":"section of nova.conf, which will default to ``/etc/nova/inventory.yaml``."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":74,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_821589e7","line":71,"range":{"start_line":70,"start_character":43,"end_line":71,"end_character":20},"in_reply_to":"3f79a3b5_d658328b","updated":"2018-08-23 15:20:58.000000000","message":"Could be similar to the option for \"/etc/nova/api-paste.ini\", [wsgi]/api_paste_config. So:\n  [DEFAULT]/inventory_config","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":73,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":74,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"The parsing of the file will happen in driver-independent code, which will be"},{"line_number":77,"context_line":"responsible for handling the dynamic reloading of the configuration at SIGHUP"},{"line_number":78,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":79,"context_line":"will expect a dict containing all the parsed keys."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_82534939","line":76,"range":{"start_line":76,"start_character":39,"end_line":76,"end_character":62},"updated":"2018-08-23 15:20:58.000000000","message":"Here is a good place to say where exactly the code will be put. This will be a difference with the proposed OOT change [1].\n\n[1] https://review.openstack.org/#/c/589668/6/nova_powervm/virt/powervm/driver.py@1053","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"863f4060b5c142e9e8cbc6611bf63edab14fb70f","unresolved":false,"context_lines":[{"line_number":73,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":74,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"The parsing of the file will happen in driver-independent code, which will be"},{"line_number":77,"context_line":"responsible for handling the dynamic reloading of the configuration at SIGHUP"},{"line_number":78,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":79,"context_line":"will expect a dict containing all the parsed keys."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_e5d79dbe","line":76,"range":{"start_line":76,"start_character":39,"end_line":76,"end_character":62},"in_reply_to":"3f79a3b5_82534939","updated":"2018-08-23 16:55:38.000000000","message":"That\u0027s probably a detail best left to implementation time. Otherwise we\u0027ll stall the spec bikeshedding it to death. Sufficient to say that it\u0027s driver-independent.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":78,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":79,"context_line":"will expect a dict containing all the parsed keys."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The file will contain paragraphs, each of which will:"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"* Identify zero or more devices based on system information available to each"},{"line_number":84,"context_line":"  implementing driver for each device type (see `identification`_).  Any device"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_76491eb5","line":81,"range":{"start_line":81,"start_character":22,"end_line":81,"end_character":32},"updated":"2018-08-22 22:59:01.000000000","message":"fwiw, I\u0027ve started using the term \"rule\" in my head for the thing a paragraph represents.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":105,"context_line":"containing one or more keys corresponding to device properties. These"},{"line_number":106,"context_line":"properties are parsed by the virt drivers. For example, the libvirt driver has"},{"line_number":107,"context_line":"a concept of a ``pci_device`` and understands some of the properties that"},{"line_number":108,"context_line":"``lspci`` reports. The PowerVM driver understands ``IOSlot`` NovaLink REST"},{"line_number":109,"context_line":"object properties. A third driver may understand different properties and the"},{"line_number":110,"context_line":"same is true for device types other than PCI."},{"line_number":111,"context_line":"For this reason, the proposed YAML schema is extensible and includes the union"},{"line_number":112,"context_line":"of the properties that any driver understands."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_82982975","line":109,"range":{"start_line":108,"start_character":19,"end_line":109,"end_character":18},"updated":"2018-08-23 15:20:58.000000000","message":"efried is this correct in in-tree context?","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"863f4060b5c142e9e8cbc6611bf63edab14fb70f","unresolved":false,"context_lines":[{"line_number":105,"context_line":"containing one or more keys corresponding to device properties. These"},{"line_number":106,"context_line":"properties are parsed by the virt drivers. For example, the libvirt driver has"},{"line_number":107,"context_line":"a concept of a ``pci_device`` and understands some of the properties that"},{"line_number":108,"context_line":"``lspci`` reports. The PowerVM driver understands ``IOSlot`` NovaLink REST"},{"line_number":109,"context_line":"object properties. A third driver may understand different properties and the"},{"line_number":110,"context_line":"same is true for device types other than PCI."},{"line_number":111,"context_line":"For this reason, the proposed YAML schema is extensible and includes the union"},{"line_number":112,"context_line":"of the properties that any driver understands."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_45f0d167","line":109,"range":{"start_line":108,"start_character":19,"end_line":109,"end_character":18},"in_reply_to":"3f79a3b5_82982975","updated":"2018-08-23 16:55:38.000000000","message":"yup, thanks for checking.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":114,"context_line":".. note:: It is explicitly intended that keys for other drivers can be added in"},{"line_number":115,"context_line":"          the future."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":118,"context_line":" YAML key          Device Property           Format"},{"line_number":119,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":120,"context_line":" pci_address       PCI Slot                  [\\X{4}:]\\X{2}:\\X{2}.\\X{1} ([4:]2:2.1 uppercase hex digits)"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_76defeda","line":117,"updated":"2018-08-22 22:59:01.000000000","message":"thinking it may be useful to add a checkbox column per driver indicating which drivers understand which keys.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"518e2f9d591f8bb1c4da47c2b445a5cd37884ef7","unresolved":false,"context_lines":[{"line_number":114,"context_line":".. note:: It is explicitly intended that keys for other drivers can be added in"},{"line_number":115,"context_line":"          the future."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":118,"context_line":" YAML key          Device Property           Format"},{"line_number":119,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":120,"context_line":" pci_address       PCI Slot                  [\\X{4}:]\\X{2}:\\X{2}.\\X{1} ([4:]2:2.1 uppercase hex digits)"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_263ca92d","line":117,"in_reply_to":"3f79a3b5_76defeda","updated":"2018-08-27 13:19:49.000000000","message":"I don\u0027t really see why, but no strong opinion.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c2b70d9e6a6e8c200d1e74e84806c4d7308c78c1","unresolved":false,"context_lines":[{"line_number":134,"context_line":"In the case of libvirt, the values should be those reported by"},{"line_number":135,"context_line":"``lspci -Dvnmm`` (but following the format above). Example:"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":".. code::"},{"line_number":138,"context_line":"  $ lspci -Dvnmm -s 2:"},{"line_number":139,"context_line":"  Slot: 0000:02:00.0"},{"line_number":140,"context_line":"  Class:  0300"},{"line_number":141,"context_line":"  Vendor: 10de"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_280a4c1f","line":138,"range":{"start_line":137,"start_character":0,"end_line":138,"end_character":22},"updated":"2018-08-23 16:58:51.000000000","message":"sphinx build failure is here - need a blank line.\n\n(note that the build stops on the first error, though; may want to build this locally to see what else pops)","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":196,"context_line":""},{"line_number":197,"context_line":"resource_class"},{"line_number":198,"context_line":"~~~~~~~~~~~~~~"},{"line_number":199,"context_line":"If ``allow`` is omitted or ``true``, an optional ``resource_class`` key is"},{"line_number":200,"context_line":"supported. Its string value allows the author to designate the resource class"},{"line_number":201,"context_line":"to be used for the inventory unit representing the device on the resource"},{"line_number":202,"context_line":"provider. If omitted, ``%(BUS_TYPE)_DEVICE`` is used, eg. for PCI devices"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_96b2ba93","line":199,"range":{"start_line":199,"start_character":0,"end_line":199,"end_character":36},"updated":"2018-08-22 22:59:01.000000000","message":"I think we can nix this clause to avoid confusion. The `allow` section already implies it, so we don\u0027t really lose anything.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":196,"context_line":""},{"line_number":197,"context_line":"resource_class"},{"line_number":198,"context_line":"~~~~~~~~~~~~~~"},{"line_number":199,"context_line":"If ``allow`` is omitted or ``true``, an optional ``resource_class`` key is"},{"line_number":200,"context_line":"supported. Its string value allows the author to designate the resource class"},{"line_number":201,"context_line":"to be used for the inventory unit representing the device on the resource"},{"line_number":202,"context_line":"provider. If omitted, ``%(BUS_TYPE)_DEVICE`` is used, eg. for PCI devices"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_c27b8125","line":199,"range":{"start_line":199,"start_character":0,"end_line":199,"end_character":36},"in_reply_to":"3f79a3b5_96b2ba93","updated":"2018-08-23 15:20:58.000000000","message":"indeed","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":203,"context_line":"``PCI_DEVICE`` will be used as the default."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":".. note:: To support other bus types, new resource classes will have to be"},{"line_number":206,"context_line":"          added to os-resource-classes [5]_"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":".. note:: **Future:** We may be able to get smarter about dynamically"},{"line_number":209,"context_line":"          defaulting the resource class based on inspecting the device"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d6b4b284","line":206,"updated":"2018-08-22 22:59:01.000000000","message":"...when that\u0027s a thing.\n\nPerhaps better to just say, \"...added to the set of standard resource classes.\"","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"863f4060b5c142e9e8cbc6611bf63edab14fb70f","unresolved":false,"context_lines":[{"line_number":203,"context_line":"``PCI_DEVICE`` will be used as the default."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":".. note:: To support other bus types, new resource classes will have to be"},{"line_number":206,"context_line":"          added to os-resource-classes [5]_"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":".. note:: **Future:** We may be able to get smarter about dynamically"},{"line_number":209,"context_line":"          defaulting the resource class based on inspecting the device"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_a58be5bd","line":206,"in_reply_to":"3f79a3b5_82d4a9ea","updated":"2018-08-23 16:55:38.000000000","message":"That blueprint is for overall placement extraction, whic certainly isn\u0027t fully completed yet. I think we agreed to mark the bp as implemented because we had achieved all we hoped to achieve in the Rocky timeframe.\n\nos-resource-classes has a couple of different impls proposed in github [1] [2] but nothing in openstack yet.\n\n[1] https://github.com/jaypipes/os-resource-classes\n[2] https://github.com/cdent/os-resource-classes","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":203,"context_line":"``PCI_DEVICE`` will be used as the default."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":".. note:: To support other bus types, new resource classes will have to be"},{"line_number":206,"context_line":"          added to os-resource-classes [5]_"},{"line_number":207,"context_line":""},{"line_number":208,"context_line":".. note:: **Future:** We may be able to get smarter about dynamically"},{"line_number":209,"context_line":"          defaulting the resource class based on inspecting the device"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_82d4a9ea","line":206,"in_reply_to":"3f79a3b5_d6b4b284","updated":"2018-08-23 15:20:58.000000000","message":"I saw \"Implemented\" on the blueprint [5]_, but this still doesn\u0027t exist?","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":212,"context_line":""},{"line_number":213,"context_line":"traits"},{"line_number":214,"context_line":"~~~~~~"},{"line_number":215,"context_line":"If ``allow`` is omitted or ``true``, an optional ``traits`` subsection is"},{"line_number":216,"context_line":"supported. Its value is an array of strings, each of which is the name of a"},{"line_number":217,"context_line":"trait to be added to the resource providers of each device represented by this"},{"line_number":218,"context_line":"paragraph. If the ``traits`` section is included, it must have at least one"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_56a8a21e","line":215,"range":{"start_line":215,"start_character":0,"end_line":215,"end_character":36},"updated":"2018-08-22 22:59:01.000000000","message":"as above","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":212,"context_line":""},{"line_number":213,"context_line":"traits"},{"line_number":214,"context_line":"~~~~~~"},{"line_number":215,"context_line":"If ``allow`` is omitted or ``true``, an optional ``traits`` subsection is"},{"line_number":216,"context_line":"supported. Its value is an array of strings, each of which is the name of a"},{"line_number":217,"context_line":"trait to be added to the resource providers of each device represented by this"},{"line_number":218,"context_line":"paragraph. If the ``traits`` section is included, it must have at least one"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_e2fc7d73","line":215,"range":{"start_line":215,"start_character":0,"end_line":215,"end_character":36},"in_reply_to":"3f79a3b5_56a8a21e","updated":"2018-08-23 15:20:58.000000000","message":"ok","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Resource Providers"},{"line_number":241,"context_line":"~~~~~~~~~~~~~~~~~~"},{"line_number":242,"context_line":"The drivers will create nested resource providers, one per device, as children"},{"line_number":243,"context_line":"of the compute node provider."},{"line_number":244,"context_line":""},{"line_number":245,"context_line":".. note:: In the case where multiple devices with the same traits exist on the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_f6476e76","line":242,"range":{"start_line":242,"start_character":59,"end_line":242,"end_character":65},"updated":"2018-08-22 22:59:01.000000000","message":"This should probably have a footnote saying that, when sub-device granularity is supported, it will be one provider per physical function (PF).","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"863f4060b5c142e9e8cbc6611bf63edab14fb70f","unresolved":false,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Resource Providers"},{"line_number":241,"context_line":"~~~~~~~~~~~~~~~~~~"},{"line_number":242,"context_line":"The drivers will create nested resource providers, one per device, as children"},{"line_number":243,"context_line":"of the compute node provider."},{"line_number":244,"context_line":""},{"line_number":245,"context_line":".. note:: In the case where multiple devices with the same traits exist on the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_85a7c950","line":242,"range":{"start_line":242,"start_character":59,"end_line":242,"end_character":65},"in_reply_to":"3f79a3b5_62f06d92","updated":"2018-08-23 16:55:38.000000000","message":"Depends how you look at them, I think. Under lspci I suspect you\u0027re correct. Under IOSlot, what you see is a whole card. (In fact a slot - even if it\u0027s empty.)","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"518e2f9d591f8bb1c4da47c2b445a5cd37884ef7","unresolved":false,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Resource Providers"},{"line_number":241,"context_line":"~~~~~~~~~~~~~~~~~~"},{"line_number":242,"context_line":"The drivers will create nested resource providers, one per device, as children"},{"line_number":243,"context_line":"of the compute node provider."},{"line_number":244,"context_line":""},{"line_number":245,"context_line":".. note:: In the case where multiple devices with the same traits exist on the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_cc25d75d","line":242,"range":{"start_line":242,"start_character":59,"end_line":242,"end_character":65},"in_reply_to":"3f79a3b5_85a7c950","updated":"2018-08-27 13:19:49.000000000","message":"Judging by [1], lspci it seems indeed shows them separately.\n\n[1] https://docs.openstack.org/neutron/pike/admin/config-sriov.html#create-virtual-functions-compute","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Resource Providers"},{"line_number":241,"context_line":"~~~~~~~~~~~~~~~~~~"},{"line_number":242,"context_line":"The drivers will create nested resource providers, one per device, as children"},{"line_number":243,"context_line":"of the compute node provider."},{"line_number":244,"context_line":""},{"line_number":245,"context_line":".. note:: In the case where multiple devices with the same traits exist on the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_62f06d92","line":242,"range":{"start_line":242,"start_character":59,"end_line":242,"end_character":65},"in_reply_to":"3f79a3b5_f6476e76","updated":"2018-08-23 15:20:58.000000000","message":"I don\u0027t have SR-IOV NICs to play with, but don\u0027t PFs appear as distinct PCI devices? I\u0027ll rephrase this in any case.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":275,"context_line":"provide a clear migration path in the future, if, for example, Cyborg takes"},{"line_number":276,"context_line":"over generating these providers."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"We will let the placement service generate the UUID."},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"Inventory"},{"line_number":281,"context_line":"~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_562bc293","line":278,"range":{"start_line":278,"start_character":0,"end_line":278,"end_character":52},"updated":"2018-08-22 22:59:01.000000000","message":"This should be up to the driver. I would rephrase as:\n\n\"There is no expectation for provider UUIDs; drivers may choose to derive/discover/generate them, or allow placement to generate them.\"","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":275,"context_line":"provide a clear migration path in the future, if, for example, Cyborg takes"},{"line_number":276,"context_line":"over generating these providers."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"We will let the placement service generate the UUID."},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"Inventory"},{"line_number":281,"context_line":"~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_22635544","line":278,"range":{"start_line":278,"start_character":0,"end_line":278,"end_character":52},"in_reply_to":"3f79a3b5_562bc293","updated":"2018-08-23 15:20:58.000000000","message":"ok","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"6463621760a58dee5ea55571940b540cb925aa6d","unresolved":false,"context_lines":[{"line_number":315,"context_line":"traits with"},{"line_number":316,"context_line":"  ``CUSTOM_LIBVIRT_DEVICE_``"},{"line_number":317,"context_line":"and the PowerVM with"},{"line_number":318,"context_line":"  ``CUSTOM_POWERVM_DEVICE_``"},{"line_number":319,"context_line":"The driver can populate the namespace with any device capabilities that it"},{"line_number":320,"context_line":"recognizes. If an operator, however, provides traits within its namespace, the"},{"line_number":321,"context_line":"driver will either remove them with a warning or raise an exception."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_96ba046c","line":318,"range":{"start_line":318,"start_character":4,"end_line":318,"end_character":26},"updated":"2018-08-20 17:05:55.000000000","message":"DEVICE or IOSLOT?","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":315,"context_line":"traits with"},{"line_number":316,"context_line":"  ``CUSTOM_LIBVIRT_DEVICE_``"},{"line_number":317,"context_line":"and the PowerVM with"},{"line_number":318,"context_line":"  ``CUSTOM_POWERVM_DEVICE_``"},{"line_number":319,"context_line":"The driver can populate the namespace with any device capabilities that it"},{"line_number":320,"context_line":"recognizes. If an operator, however, provides traits within its namespace, the"},{"line_number":321,"context_line":"driver will either remove them with a warning or raise an exception."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d905c511","line":318,"range":{"start_line":318,"start_character":4,"end_line":318,"end_character":26},"in_reply_to":"3f79a3b5_96ba046c","updated":"2018-08-22 22:59:01.000000000","message":"Yeah, there\u0027s some history there. The object in PowerVM that we\u0027re looking at and using for passthrough is called IOSlot. Hedging on a future where we might be looking at a different object, I thought it prudent to use IOSLOT instead of DEVICE. I guess I would prefer to keep it that way, unless there\u0027s some reason that level of consistency is really important across drivers\u0027 namespaces (which are already prefixed with the driver name).","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"863f4060b5c142e9e8cbc6611bf63edab14fb70f","unresolved":false,"context_lines":[{"line_number":315,"context_line":"traits with"},{"line_number":316,"context_line":"  ``CUSTOM_LIBVIRT_DEVICE_``"},{"line_number":317,"context_line":"and the PowerVM with"},{"line_number":318,"context_line":"  ``CUSTOM_POWERVM_DEVICE_``"},{"line_number":319,"context_line":"The driver can populate the namespace with any device capabilities that it"},{"line_number":320,"context_line":"recognizes. If an operator, however, provides traits within its namespace, the"},{"line_number":321,"context_line":"driver will either remove them with a warning or raise an exception."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_c55f013f","line":318,"range":{"start_line":318,"start_character":4,"end_line":318,"end_character":26},"in_reply_to":"3f79a3b5_c2d861f0","updated":"2018-08-23 16:55:38.000000000","message":"The only mention of DEVICE in the spec is for the generated traits involving device_id.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":315,"context_line":"traits with"},{"line_number":316,"context_line":"  ``CUSTOM_LIBVIRT_DEVICE_``"},{"line_number":317,"context_line":"and the PowerVM with"},{"line_number":318,"context_line":"  ``CUSTOM_POWERVM_DEVICE_``"},{"line_number":319,"context_line":"The driver can populate the namespace with any device capabilities that it"},{"line_number":320,"context_line":"recognizes. If an operator, however, provides traits within its namespace, the"},{"line_number":321,"context_line":"driver will either remove them with a warning or raise an exception."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_c2d861f0","line":318,"range":{"start_line":318,"start_character":4,"end_line":318,"end_character":26},"in_reply_to":"3f79a3b5_d905c511","updated":"2018-08-23 15:20:58.000000000","message":"No reason. I think at some point in the OOT spec you refer to DEVICE as well, so was confused.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":339,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":340,"context_line":"This resource provider tree structure will be created in Nova by augmenting"},{"line_number":341,"context_line":"the ``driver.update_provider_tree`` method, called during the"},{"line_number":342,"context_line":"periodic_task. The config options corresponding to the inventory YAML are at"},{"line_number":343,"context_line":"this point available to the driver and up-to-date via the SIGHUP mechanism (see"},{"line_number":344,"context_line":"`Device Identification and Whitelisting`_)."},{"line_number":345,"context_line":"The algorithm will be as follows:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d9538515","line":342,"range":{"start_line":342,"start_character":0,"end_line":342,"end_character":13},"updated":"2018-08-22 22:59:01.000000000","message":"the `update_available_resource` periodic_task","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":339,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":340,"context_line":"This resource provider tree structure will be created in Nova by augmenting"},{"line_number":341,"context_line":"the ``driver.update_provider_tree`` method, called during the"},{"line_number":342,"context_line":"periodic_task. The config options corresponding to the inventory YAML are at"},{"line_number":343,"context_line":"this point available to the driver and up-to-date via the SIGHUP mechanism (see"},{"line_number":344,"context_line":"`Device Identification and Whitelisting`_)."},{"line_number":345,"context_line":"The algorithm will be as follows:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_62faad43","line":342,"range":{"start_line":342,"start_character":0,"end_line":342,"end_character":13},"in_reply_to":"3f79a3b5_d9538515","updated":"2018-08-23 15:20:58.000000000","message":"ok","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":380,"context_line":""},{"line_number":381,"context_line":"Driver specifics: PowerVM"},{"line_number":382,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":383,"context_line":"\u003c anything ??? \u003e"},{"line_number":384,"context_line":""},{"line_number":385,"context_line":"Flavor Support"},{"line_number":386,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_398ab969","line":383,"range":{"start_line":383,"start_character":0,"end_line":383,"end_character":16},"updated":"2018-08-22 22:59:01.000000000","message":"Yeah, I mean, it\u0027s pretty much the same. We have a patch up with the proposed update_provider_tree implementation [1]. The earlier patches in that series contain the guts of e.g. \"build_filtered_inventory\".\n\nI can compose some words here if you think it\u0027s necessary, but it\u0027s probably not.\n\n[1] https://review.openstack.org/#/c/589668/6/nova_powervm/virt/powervm/driver.py@1049","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":380,"context_line":""},{"line_number":381,"context_line":"Driver specifics: PowerVM"},{"line_number":382,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":383,"context_line":"\u003c anything ??? \u003e"},{"line_number":384,"context_line":""},{"line_number":385,"context_line":"Flavor Support"},{"line_number":386,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_026f39fc","line":383,"range":{"start_line":383,"start_character":0,"end_line":383,"end_character":16},"in_reply_to":"3f79a3b5_398ab969","updated":"2018-08-23 15:20:58.000000000","message":"No, I\u0027ll erase this section if there\u0027s no special info here. For libvirt there is.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Device allocation"},{"line_number":406,"context_line":"-----------------"},{"line_number":407,"context_line":"Implementation of the actual device allocation/deallocation to VMs is deferred"},{"line_number":408,"context_line":"to a follow-up spec."},{"line_number":409,"context_line":""},{"line_number":410,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_798b5167","line":407,"range":{"start_line":407,"start_character":36,"end_line":407,"end_character":59},"updated":"2018-08-22 22:59:01.000000000","message":"use \u0027attach/detach\u0027 here to avoid confusion with the resource allocation/deallocation done by placement (that\u0027s part of the thing above that will \"just work\").","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":404,"context_line":""},{"line_number":405,"context_line":"Device allocation"},{"line_number":406,"context_line":"-----------------"},{"line_number":407,"context_line":"Implementation of the actual device allocation/deallocation to VMs is deferred"},{"line_number":408,"context_line":"to a follow-up spec."},{"line_number":409,"context_line":""},{"line_number":410,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_023df9db","line":407,"range":{"start_line":407,"start_character":36,"end_line":407,"end_character":59},"in_reply_to":"3f79a3b5_798b5167","updated":"2018-08-23 15:20:58.000000000","message":"ok","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":405,"context_line":"Device allocation"},{"line_number":406,"context_line":"-----------------"},{"line_number":407,"context_line":"Implementation of the actual device allocation/deallocation to VMs is deferred"},{"line_number":408,"context_line":"to a follow-up spec."},{"line_number":409,"context_line":""},{"line_number":410,"context_line":""},{"line_number":411,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_79fcb1b4","line":408,"updated":"2018-08-22 22:59:01.000000000","message":"Nah, I think we ought to talk about it here.\n\nIt will be driver-specific.\n\nBut the crux will be that each driver will receive the necessary information via the `allocations` parameter to e.g. the spawn ComputeDriver method. The driver will need to look for allocations of devices (presumably based on recognizing the namespaced prefix of the name of the resource provider associated with the allocation) and do whatever platform-specific thing is necessary to attach the device, just like they would have in the old world.\n\nIn libvirt, this is probably the guts of _guest_add_pci_devices.\n\nThe in-tree PowerVM driver doesn\u0027t support device passthrough yet, but we do it by stuffing the IOSlot object into the LogicalPartition object and sending that object to our REST API.\n\nFor drivers which already support passthrough, there will be a (multi-release) transition period where devices must be recognized through the legacy subsystem as well as the new placement-based system - i.e. the union of both should be funneled into whatever core attach/detach method does the real work. With appropriate error handling for conflicts between the two. (The dual-support thing is necessary so we can start with a subset of support in the new system - i.e. whole-device only as this spec says - and incrementally add other bits until everything is covered and we can deprecate/remove the legacy system entirely.)","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0845bab91478cb4a3486afde154a87eb081a3225","unresolved":false,"context_lines":[{"line_number":405,"context_line":"Device allocation"},{"line_number":406,"context_line":"-----------------"},{"line_number":407,"context_line":"Implementation of the actual device allocation/deallocation to VMs is deferred"},{"line_number":408,"context_line":"to a follow-up spec."},{"line_number":409,"context_line":""},{"line_number":410,"context_line":""},{"line_number":411,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_6f67ee4e","line":408,"in_reply_to":"3f79a3b5_79fcb1b4","updated":"2018-08-23 15:20:58.000000000","message":"The only reason I didn\u0027t include it here is because I haven\u0027t checked that flow too much in the code yet, but the last few days I\u0027ve been thinking the same, we should support a complete use case with the spec.\nUnderstood.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8a9d3641980992955d7bdc944dae4b8eec5016ae","unresolved":false,"context_lines":[{"line_number":428,"context_line":"---------------"},{"line_number":429,"context_line":"It is the operator\u0027s responsibility to ensure that the passthrough YAML config"},{"line_number":430,"context_line":"file has appropriate permissions, and lists only devices which do not"},{"line_number":431,"context_line":"themselves pose a security risk if attached to a malicious VM."},{"line_number":432,"context_line":""},{"line_number":433,"context_line":""},{"line_number":434,"context_line":"End user impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d924e562","line":431,"updated":"2018-08-22 22:59:01.000000000","message":"Something something policy.","commit_id":"947ce3e7dbe87afb081f70d635a73d5f7d9ced78"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"f265f78d557a9a8293f166246210c6968563aa9c","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Placement model for passthrough devices"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/device-placement-passthrough"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_14f389e9","line":8,"updated":"2018-08-28 20:39:44.000000000","message":"If possible, I think we should consider changing the title of this document. Based on the title alone I was expecting to find changes to the data model of placement itself (perhaps some new table or query structure).\n\nThat\u0027s not what we\u0027ve got here. Instead what\u0027s described is a way of controlling, in a tidy way, the sort of information that might get reported to placement using placement\u0027s existing APIs and data structures from a compute host that has access to interesting devices.\n\n* Modelling passthrough devices for report to placement\n* Nested providers model for passthrough devices\n* Abstraction for inventorying passthrough devices\n\nare some possibilities.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0f0e7042b1e93dfbc7ef2394cde93751e091b9cd","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Placement model for passthrough devices"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/device-placement-passthrough"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Provide a generic way to model devices, such as GPUs, in Placement."},{"line_number":14,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_6387ac14","line":11,"range":{"start_line":11,"start_character":44,"end_line":11,"end_character":72},"updated":"2018-09-13 17:36:47.000000000","message":"just noticed, this needs to match the file name (or vice versa)","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":22,"context_line":"VMs. Today in Nova this is possible only in very restrictive circumstances."},{"line_number":23,"context_line":"For PCI devices as an example, the primary issues are:"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"* the special way in which PCI devices are currently inventoried"},{"line_number":26,"context_line":"* the special way to schedule VMs that request PCI passthrough, which doesn\u0027t"},{"line_number":27,"context_line":"  rely on Placement to provide the correct allocation candidates, but on the"},{"line_number":28,"context_line":"  ``PciPassthroughFilter`` to filter out incapable nodes"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_abea960b","line":25,"range":{"start_line":25,"start_character":6,"end_line":25,"end_character":13},"updated":"2018-08-27 18:43:30.000000000","message":"\"special\" is a nice way of putting that. I would likely have used a different word.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":36,"context_line":"* specific implementations of the Placement model for the libvirt and PowerVM"},{"line_number":37,"context_line":"  drivers (see `Placement Model`_)"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"The implementation for 2 drivers paves the way for implementing it in any"},{"line_number":40,"context_line":"other."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The primary goal for the current release is to pass through entire physical"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_daf0fe93","line":39,"range":{"start_line":39,"start_character":23,"end_line":39,"end_character":24},"updated":"2018-08-27 16:44:28.000000000","message":"style: two","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":36,"context_line":"* specific implementations of the Placement model for the libvirt and PowerVM"},{"line_number":37,"context_line":"  drivers (see `Placement Model`_)"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"The implementation for 2 drivers paves the way for implementing it in any"},{"line_number":40,"context_line":"other."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The primary goal for the current release is to pass through entire physical"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_7fa50ab4","line":39,"range":{"start_line":39,"start_character":23,"end_line":39,"end_character":24},"in_reply_to":"3f79a3b5_daf0fe93","updated":"2018-08-28 14:06:50.000000000","message":"Done","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The primary goal for the current release is to pass through entire physical"},{"line_number":43,"context_line":"GPUs or FPGAs. However, it should be straightforward to extend it to support"},{"line_number":44,"context_line":"vGPUs, and possibly SR-IOV NIC VFs, albeit in coordination with [4]_."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_cd45aab5","line":44,"range":{"start_line":44,"start_character":6,"end_line":44,"end_character":34},"updated":"2018-08-27 16:44:28.000000000","message":"I don\u0027t see how we can do one without the other. SR-IOV VF support is managed with the PCI manager and, while you say running the two side-by-side would be possible, I find it hard to see how that would be wise. What are the blocks that prevent us from tackling VFS in placement at the same time? I mean, they\u0027re essentially the same thing from an indexing perspective, right?","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The primary goal for the current release is to pass through entire physical"},{"line_number":43,"context_line":"GPUs or FPGAs. However, it should be straightforward to extend it to support"},{"line_number":44,"context_line":"vGPUs, and possibly SR-IOV NIC VFs, albeit in coordination with [4]_."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_4bc2e286","line":44,"range":{"start_line":44,"start_character":0,"end_line":44,"end_character":5},"updated":"2018-08-27 18:43:30.000000000","message":"VGPU is already a distinct resource class that is currently handles by both the libvirt and Xen virt drivers.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ec371bd32e6786c89be648e5a4a89867aad19cfb","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The primary goal for the current release is to pass through entire physical"},{"line_number":43,"context_line":"GPUs or FPGAs. However, it should be straightforward to extend it to support"},{"line_number":44,"context_line":"vGPUs, and possibly SR-IOV NIC VFs, albeit in coordination with [4]_."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_a6388b9f","line":44,"range":{"start_line":44,"start_character":6,"end_line":44,"end_character":34},"in_reply_to":"3f79a3b5_cd45aab5","updated":"2018-08-27 19:29:01.000000000","message":"A couple answers here.\n\nI don\u0027t see it being possible for us to transition 100% in one spec/series/release. I could be wrong.\n\nAs you can see by the legacy PCI code, SR-IOV is a pretty complicated thing, with the ability to pass PFs vs VFs, direct vs macvtap (whatever that is), three different vif types... Also, the way VFs are managed is wildly different in PowerVM than in libvirt. (I therefore assume it might be wildly different for other platforms as well.) Trying to \"solve\" it in a generic way is going to be nontrivial. Certainly compared to passing through entire devices.\nSo if we want to bite off a chunk, SR-IOV seems like a fairly decent thing to leave behind for now.\n\nFurther on the topic of subsetting, IMO it also makes sense to draw a boundary at \"devices with a wire out the back\". Because that brings in questions of connectivity etc. which will be more complicated to solve than just \"slap on a trait with the network name\". There\u0027s interaction with neutron to consider, creating a port via a separate command, etc. We have to worry about none of that if we pass through whole devices via flavors.\n\nAs far as coexistence is concerned, it really shouldn\u0027t be a huge problem. I assume that operators can continue using [pci]passthrough_whitelist until we actually start removing that code, which presumably shouldn\u0027t be until we can do everything via placement. In the meantime, we\u0027ll gradually add support for things via the inventory.yaml and placement resource extra_specs, and anything the operator wants to do the new way they\u0027ll just use the new syntax for.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":47,"context_line":"Use Cases"},{"line_number":48,"context_line":"---------"},{"line_number":49,"context_line":"As an operator, I wish to be able to configure my host and flavors to allow"},{"line_number":50,"context_line":"passthrough of whole physical GPUs to VMs, and to schedule these VMs based"},{"line_number":51,"context_line":"on Placement."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"As a user, I wish to make use of appropriate flavors to create VMs with GPUs"},{"line_number":54,"context_line":"attached."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_ab6136ab","line":51,"range":{"start_line":50,"start_character":69,"end_line":51,"end_character":13},"updated":"2018-08-27 18:43:30.000000000","message":"s/based on Placement/using the same resource request filtering that is done for other types of resources such as VCPU or MEMORY_MB/","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":47,"context_line":"Use Cases"},{"line_number":48,"context_line":"---------"},{"line_number":49,"context_line":"As an operator, I wish to be able to configure my host and flavors to allow"},{"line_number":50,"context_line":"passthrough of whole physical GPUs to VMs, and to schedule these VMs based"},{"line_number":51,"context_line":"on Placement."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"As a user, I wish to make use of appropriate flavors to create VMs with GPUs"},{"line_number":54,"context_line":"attached."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_9fc6e667","line":51,"range":{"start_line":50,"start_character":69,"end_line":51,"end_character":13},"in_reply_to":"3f79a3b5_ab6136ab","updated":"2018-08-28 14:06:50.000000000","message":"Done","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":50,"context_line":"passthrough of whole physical GPUs to VMs, and to schedule these VMs based"},{"line_number":51,"context_line":"on Placement."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"As a user, I wish to make use of appropriate flavors to create VMs with GPUs"},{"line_number":54,"context_line":"attached."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_cb64b2bb","line":54,"range":{"start_line":53,"start_character":0,"end_line":54,"end_character":9},"updated":"2018-08-27 18:43:30.000000000","message":"This isn\u0027t a use case. It\u0027s an implementation detail. Recommend removing it.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":50,"context_line":"passthrough of whole physical GPUs to VMs, and to schedule these VMs based"},{"line_number":51,"context_line":"on Placement."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"As a user, I wish to make use of appropriate flavors to create VMs with GPUs"},{"line_number":54,"context_line":"attached."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_5fa28eaf","line":54,"range":{"start_line":53,"start_character":0,"end_line":54,"end_character":9},"in_reply_to":"3f79a3b5_cb64b2bb","updated":"2018-08-28 14:06:50.000000000","message":"ok","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":60,"context_line":"Device Identification and Whitelisting"},{"line_number":61,"context_line":"--------------------------------------"},{"line_number":62,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":63,"context_line":"passthrough of devices by way of a YAML file per compute host."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":".. note:: **Future:** We may someday figure out a way to support a config file"},{"line_number":66,"context_line":"          on the controller. This would allow e.g. cloud-wide whitelisting and"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_ba2f42f4","line":63,"range":{"start_line":63,"start_character":35,"end_line":63,"end_character":62},"updated":"2018-08-27 16:44:28.000000000","message":"I see jaypipes has been here","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":60,"context_line":"Device Identification and Whitelisting"},{"line_number":61,"context_line":"--------------------------------------"},{"line_number":62,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":63,"context_line":"passthrough of devices by way of a YAML file per compute host."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":".. note:: **Future:** We may someday figure out a way to support a config file"},{"line_number":66,"context_line":"          on the controller. This would allow e.g. cloud-wide whitelisting and"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_cb0912dd","line":63,"range":{"start_line":63,"start_character":35,"end_line":63,"end_character":62},"in_reply_to":"3f79a3b5_ba2f42f4","updated":"2018-08-27 18:43:30.000000000","message":"Actually, I haven\u0027t (yet). Maybe you\u0027re referring to my previous idea about the provider YAML file from this now-abandoned effort?\n\nhttps://review.openstack.org/#/c/550244/","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ec371bd32e6786c89be648e5a4a89867aad19cfb","unresolved":false,"context_lines":[{"line_number":60,"context_line":"Device Identification and Whitelisting"},{"line_number":61,"context_line":"--------------------------------------"},{"line_number":62,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":63,"context_line":"passthrough of devices by way of a YAML file per compute host."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":".. note:: **Future:** We may someday figure out a way to support a config file"},{"line_number":66,"context_line":"          on the controller. This would allow e.g. cloud-wide whitelisting and"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_4b2182b3","line":63,"range":{"start_line":63,"start_character":35,"end_line":63,"end_character":62},"in_reply_to":"3f79a3b5_ba2f42f4","updated":"2018-08-27 19:29:01.000000000","message":"Perhaps as an echo from the Queens PTG. This was mine.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":61,"context_line":"--------------------------------------"},{"line_number":62,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":63,"context_line":"passthrough of devices by way of a YAML file per compute host."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":".. note:: **Future:** We may someday figure out a way to support a config file"},{"line_number":66,"context_line":"          on the controller. This would allow e.g. cloud-wide whitelisting and"},{"line_number":67,"context_line":"          specification for particular device types by vendor/product ID, which"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_5a594e8b","line":64,"updated":"2018-08-27 16:44:28.000000000","message":"An example right here would be amazing. Could you add one?","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ec371bd32e6786c89be648e5a4a89867aad19cfb","unresolved":false,"context_lines":[{"line_number":61,"context_line":"--------------------------------------"},{"line_number":62,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":63,"context_line":"passthrough of devices by way of a YAML file per compute host."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":".. note:: **Future:** We may someday figure out a way to support a config file"},{"line_number":66,"context_line":"          on the controller. This would allow e.g. cloud-wide whitelisting and"},{"line_number":67,"context_line":"          specification for particular device types by vendor/product ID, which"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8641cf0c","line":64,"in_reply_to":"3f79a3b5_5a594e8b","updated":"2018-08-27 19:29:01.000000000","message":"Agree. Until it\u0027s edited in, here\u0027s the WIP from nova-powervm:\n\nhttps://review.openstack.org/#/c/579289/12/nova_powervm/tests/virt/powervm/inventory_sample.yaml","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":62,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":63,"context_line":"passthrough of devices by way of a YAML file per compute host."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":".. note:: **Future:** We may someday figure out a way to support a config file"},{"line_number":66,"context_line":"          on the controller. This would allow e.g. cloud-wide whitelisting and"},{"line_number":67,"context_line":"          specification for particular device types by vendor/product ID, which"},{"line_number":68,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The path to the YAML will be provided in nova.conf by the config option"},{"line_number":71,"context_line":"``[DEFAULT]/inventory_config``"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_2b23e657","line":68,"range":{"start_line":65,"start_character":0,"end_line":68,"end_character":78},"updated":"2018-08-27 18:43:30.000000000","message":"This isn\u0027t something that Nova itself should be responsible for, IMHO. This is the domain of configuration management and deployment systems (Ansible, Puppet/Chef, etc) and should not be a duty of Nova itself.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":68,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The path to the YAML will be provided in nova.conf by the config option"},{"line_number":71,"context_line":"``[DEFAULT]/inventory_config``"},{"line_number":72,"context_line":"which will default to ``/etc/nova/inventory.yaml``."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_ab905644","line":71,"range":{"start_line":71,"start_character":2,"end_line":71,"end_character":28},"updated":"2018-08-27 18:43:30.000000000","message":"For filepath options, recommend naming the option with \"filepath\" or \"path\" suffix. So, something like\n\n [DEFAULT]/inventory_config_filepath","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":68,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The path to the YAML will be provided in nova.conf by the config option"},{"line_number":71,"context_line":"``[DEFAULT]/inventory_config``"},{"line_number":72,"context_line":"which will default to ``/etc/nova/inventory.yaml``."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_1f6ad6eb","line":71,"range":{"start_line":71,"start_character":2,"end_line":71,"end_character":28},"in_reply_to":"3f79a3b5_ab905644","updated":"2018-08-28 14:06:50.000000000","message":"Done","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":68,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The path to the YAML will be provided in nova.conf by the config option"},{"line_number":71,"context_line":"``[DEFAULT]/inventory_config``"},{"line_number":72,"context_line":"which will default to ``/etc/nova/inventory.yaml``."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":75,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_aba296ac","line":72,"range":{"start_line":71,"start_character":0,"end_line":72,"end_character":51},"updated":"2018-08-27 18:43:30.000000000","message":"It\u0027s more than just inventory, though. :)\n\nThis is why my original proposal featuring a YAML file for this type of data was called a \"provider descriptor file\" and contained inventory, trait and UUID/name translation information in the same file.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":68,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The path to the YAML will be provided in nova.conf by the config option"},{"line_number":71,"context_line":"``[DEFAULT]/inventory_config``"},{"line_number":72,"context_line":"which will default to ``/etc/nova/inventory.yaml``."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":75,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_a274e936","line":72,"range":{"start_line":71,"start_character":0,"end_line":72,"end_character":51},"in_reply_to":"3f79a3b5_aba296ac","updated":"2018-08-28 14:06:50.000000000","message":"I hadn\u0027t seen your proposal before, thanks for the reference.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":77,"context_line":"The parsing of the file will happen in driver-independent code, which will be"},{"line_number":78,"context_line":"responsible for handling the dynamic reloading of the configuration at SIGHUP"},{"line_number":79,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":80,"context_line":"will expect a dict containing all the parsed keys."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"The file will contain paragraphs, each of which will:"},{"line_number":83,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_6baf9e7c","line":80,"range":{"start_line":80,"start_character":14,"end_line":80,"end_character":18},"updated":"2018-08-27 18:43:30.000000000","message":"I would recommend an object instead of a dict, so that you can add versioning to it. Otherwise, virt drivers are going to be passed a random bunch of key/values that will certainly change over time and no indication of schema version.\n\nBetter yet, update this proposal to include the JSONSchema representation of the YAML file contents for a version 1.0 of this file.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":79,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":80,"context_line":"will expect a dict containing all the parsed keys."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"The file will contain paragraphs, each of which will:"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* Identify zero or more devices based on system information available to each"},{"line_number":85,"context_line":"  implementing driver for each device type (see `identification`_).  Any device"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_da1ebeb9","line":82,"range":{"start_line":82,"start_character":22,"end_line":82,"end_character":32},"updated":"2018-08-27 16:44:28.000000000","message":"sections (here and elsewhere in the spec)","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":79,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":80,"context_line":"will expect a dict containing all the parsed keys."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"The file will contain paragraphs, each of which will:"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* Identify zero or more devices based on system information available to each"},{"line_number":85,"context_line":"  implementing driver for each device type (see `identification`_).  Any device"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_e2b2e193","line":82,"range":{"start_line":82,"start_character":22,"end_line":82,"end_character":32},"in_reply_to":"3f79a3b5_da1ebeb9","updated":"2018-08-28 14:06:50.000000000","message":"Done","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":85,"context_line":"  implementing driver for each device type (see `identification`_).  Any device"},{"line_number":86,"context_line":"  not identified by any paragraph in the file is denied for passthrough. But"},{"line_number":87,"context_line":"  see the `allow`_ section for future plans around supporting explicit denials."},{"line_number":88,"context_line":"* Name the resource class to associate with the resource provider inventory"},{"line_number":89,"context_line":"  unit by which the device will be exposed to the driver. If not specified,"},{"line_number":90,"context_line":"  ``%(BUS_TYPE)_DEVICE`` is used, eg. for PCI devices ``PCI_DEVICE`` (see"},{"line_number":91,"context_line":"  `resource_class`_.)."},{"line_number":92,"context_line":"* List traits to include on the resource provider. See `traits`_."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"A formal schema will be implemented."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_06437f40","line":91,"range":{"start_line":88,"start_character":0,"end_line":91,"end_character":22},"updated":"2018-08-27 18:43:30.000000000","message":"-1 for a couple reasons...\n\nThe device may be the provider of multiple types of resources. Imagine, for example, that you have an SR-IOV NIC. That NIC might provide SRIOV_NET_VF resources or it might be used as a PF passthrough, in which case it would have a single inventory record of a total of 1 resource class representing that passthrough device (SRIOV_NET_PF? PCI_PASSTHROUGH? etc)\n\nSimilarly, the device itself might not actually have ANY inventory itself but simply acts as an intermediary child provider. Think here of a NUMA system, where each NUMA cell acts as a child provider to the root compute node provider and each NUMA cell provider has multiple SR-IOV PF child providers with their own inventory of SRIOV_NET_VF resources. The NUMA cells may not have any inventory records at all.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ec371bd32e6786c89be648e5a4a89867aad19cfb","unresolved":false,"context_lines":[{"line_number":85,"context_line":"  implementing driver for each device type (see `identification`_).  Any device"},{"line_number":86,"context_line":"  not identified by any paragraph in the file is denied for passthrough. But"},{"line_number":87,"context_line":"  see the `allow`_ section for future plans around supporting explicit denials."},{"line_number":88,"context_line":"* Name the resource class to associate with the resource provider inventory"},{"line_number":89,"context_line":"  unit by which the device will be exposed to the driver. If not specified,"},{"line_number":90,"context_line":"  ``%(BUS_TYPE)_DEVICE`` is used, eg. for PCI devices ``PCI_DEVICE`` (see"},{"line_number":91,"context_line":"  `resource_class`_.)."},{"line_number":92,"context_line":"* List traits to include on the resource provider. See `traits`_."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"A formal schema will be implemented."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_a6a2cbac","line":91,"range":{"start_line":88,"start_character":0,"end_line":91,"end_character":22},"in_reply_to":"3f79a3b5_06437f40","updated":"2018-08-27 19:29:01.000000000","message":"It\u0027s a question of scope here. This spec isn\u0027t talking about defining all the providers for this compute node. It\u0027s only talking about inventorying the devices available for passthrough to VMs. You can\u0027t pass through a NUMA node. Virtual functions like VFs or VGPUs are out of scope for now.\n\nSo whereas the structure may be extended in the future (your point above about versioning is well taken) to accomodate more of those things, for now we\u0027re saying one (physical) device \u003d\u003d one provider with one inventory unit of one resource class.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":115,"context_line":".. note:: It is explicitly intended that keys for other drivers can be added in"},{"line_number":116,"context_line":"          the future."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":119,"context_line":" YAML key          Device Property           Format"},{"line_number":120,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":121,"context_line":" pci_address       PCI Slot                  [\\X{4}:]\\X{2}:\\X{2}.\\X{1} ([4:]2:2.1 uppercase hex digits)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_faf5ba51","line":118,"range":{"start_line":118,"start_character":0,"end_line":118,"end_character":1},"updated":"2018-08-27 16:44:28.000000000","message":"style: Don\u0027t think this table should be indented","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":115,"context_line":".. note:: It is explicitly intended that keys for other drivers can be added in"},{"line_number":116,"context_line":"          the future."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":119,"context_line":" YAML key          Device Property           Format"},{"line_number":120,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":121,"context_line":" pci_address       PCI Slot                  [\\X{4}:]\\X{2}:\\X{2}.\\X{1} ([4:]2:2.1 uppercase hex digits)"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_62325112","line":118,"range":{"start_line":118,"start_character":0,"end_line":118,"end_character":1},"in_reply_to":"3f79a3b5_faf5ba51","updated":"2018-08-28 14:06:50.000000000","message":"ok","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":118,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":119,"context_line":" YAML key          Device Property           Format"},{"line_number":120,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":121,"context_line":" pci_address       PCI Slot                  [\\X{4}:]\\X{2}:\\X{2}.\\X{1} ([4:]2:2.1 uppercase hex digits)"},{"line_number":122,"context_line":" vendor_id         PCI Vendor                \\X{4} (4 uppercase hex digits)"},{"line_number":123,"context_line":" device_id         PCI Device                \\X{4}            \""},{"line_number":124,"context_line":" subsys_vendor_id  PCI Subsystem Vendor      \\X{4}            \""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_dafa3e41","line":121,"range":{"start_line":121,"start_character":1,"end_line":121,"end_character":12},"updated":"2018-08-27 16:44:28.000000000","message":"style: These need to be formatted as ``literal`` to make them render correctly","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":118,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":119,"context_line":" YAML key          Device Property           Format"},{"line_number":120,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":121,"context_line":" pci_address       PCI Slot                  [\\X{4}:]\\X{2}:\\X{2}.\\X{1} ([4:]2:2.1 uppercase hex digits)"},{"line_number":122,"context_line":" vendor_id         PCI Vendor                \\X{4} (4 uppercase hex digits)"},{"line_number":123,"context_line":" device_id         PCI Device                \\X{4}            \""},{"line_number":124,"context_line":" subsys_vendor_id  PCI Subsystem Vendor      \\X{4}            \""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_5a9cee0c","line":121,"range":{"start_line":121,"start_character":45,"end_line":121,"end_character":103},"updated":"2018-08-27 16:44:28.000000000","message":"style: ditto","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":118,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":119,"context_line":" YAML key          Device Property           Format"},{"line_number":120,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":121,"context_line":" pci_address       PCI Slot                  [\\X{4}:]\\X{2}:\\X{2}.\\X{1} ([4:]2:2.1 uppercase hex digits)"},{"line_number":122,"context_line":" vendor_id         PCI Vendor                \\X{4} (4 uppercase hex digits)"},{"line_number":123,"context_line":" device_id         PCI Device                \\X{4}            \""},{"line_number":124,"context_line":" subsys_vendor_id  PCI Subsystem Vendor      \\X{4}            \""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_e22501c3","line":121,"range":{"start_line":121,"start_character":1,"end_line":121,"end_character":12},"in_reply_to":"3f79a3b5_dafa3e41","updated":"2018-08-28 14:06:50.000000000","message":"Done","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":127,"context_line":" revision_id       PCI Revision              \\X{2} (2 uppercase hex digits)"},{"line_number":128,"context_line":" drc_index         PowerVM IOSLOT drc_index  \\X{8} (8 uppercase hex digits)"},{"line_number":129,"context_line":" drc_name          PowerVM IOSLOT drc_name   String (physical location code)"},{"line_number":130,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"The values need to be quoted, to avoid YAML parsing hex values like \u00271234\u0027 as"},{"line_number":133,"context_line":"integers, and follow the format specified in the schema above."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_466657ef","line":130,"updated":"2018-08-27 18:43:30.000000000","message":"I actually don\u0027t think a tabular format like this is useful. More useful, IMHO, would be an example YAML file that shows what a particular common host configuration might look like in practice.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":127,"context_line":" revision_id       PCI Revision              \\X{2} (2 uppercase hex digits)"},{"line_number":128,"context_line":" drc_index         PowerVM IOSLOT drc_index  \\X{8} (8 uppercase hex digits)"},{"line_number":129,"context_line":" drc_name          PowerVM IOSLOT drc_name   String (physical location code)"},{"line_number":130,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"The values need to be quoted, to avoid YAML parsing hex values like \u00271234\u0027 as"},{"line_number":133,"context_line":"integers, and follow the format specified in the schema above."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_9d190e7b","line":130,"in_reply_to":"3f79a3b5_466657ef","updated":"2018-08-28 14:06:50.000000000","message":"I think both are useful, this too as a definition. Will add an example in the previous section.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":314,"context_line":"The driver can generate standard traits from ``os-traits``. If a standard trait"},{"line_number":315,"context_line":"exists for a capability, the driver must use that. If not, the driver can"},{"line_number":316,"context_line":"create a custom trait in its namespace (intended more as a transitional"},{"line_number":317,"context_line":"mechanism, until the trait is incorporated in ``os-traits``), as follows."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Each driver will have a trait namespace:"},{"line_number":320,"context_line":"``CUSTOM_%(virt_driver)_DEVICE_``"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8d06d2cd","line":317,"range":{"start_line":317,"start_character":11,"end_line":317,"end_character":60},"updated":"2018-08-27 16:44:28.000000000","message":"For those of us not as well versed in placement, do we have a way to migrate these things. If so, could you link to it from here?","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ec371bd32e6786c89be648e5a4a89867aad19cfb","unresolved":false,"context_lines":[{"line_number":314,"context_line":"The driver can generate standard traits from ``os-traits``. If a standard trait"},{"line_number":315,"context_line":"exists for a capability, the driver must use that. If not, the driver can"},{"line_number":316,"context_line":"create a custom trait in its namespace (intended more as a transitional"},{"line_number":317,"context_line":"mechanism, until the trait is incorporated in ``os-traits``), as follows."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Each driver will have a trait namespace:"},{"line_number":320,"context_line":"``CUSTOM_%(virt_driver)_DEVICE_``"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_06705f3f","line":317,"range":{"start_line":317,"start_character":11,"end_line":317,"end_character":60},"in_reply_to":"3f79a3b5_8d06d2cd","updated":"2018-08-27 19:29:01.000000000","message":"Migrate what things? You mean, having proposed a trait for inclusion in os-traits, how do we make an existing provider tagged with CUSTOM_THINGY be eventually tagged with STANDARD_THINGY, who consumes them and how do they know which to pay attention to, when can we remove CUSTOM_THINGY, etc.?\n\nYeah, I have no idea how that\u0027s supposed to work. It\u0027s not in the scope of this spec, obviously (which you\u0027ve implied by asking for it to be linked).","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"eb8a714eafd346086be3d453796e12a245722b37","unresolved":false,"context_lines":[{"line_number":304,"context_line":"          regions/functions, etc. At that point we will conceivably have"},{"line_number":305,"context_line":"          inventory of multiple units of multiple resource classes, etc."},{"line_number":306,"context_line":""},{"line_number":307,"context_line":"Generated Traits"},{"line_number":308,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":309,"context_line":"The drivers can decorate the resource providers with automatically generated"},{"line_number":310,"context_line":"traits according to extra information about the device\u0027s capabilities that the"},{"line_number":311,"context_line":"system may provide, or even based on device-capability matrices maintained by"},{"line_number":312,"context_line":"the device vendors."},{"line_number":313,"context_line":""},{"line_number":314,"context_line":"The driver can generate standard traits from ``os-traits``. If a standard trait"},{"line_number":315,"context_line":"exists for a capability, the driver must use that. If not, the driver can"},{"line_number":316,"context_line":"create a custom trait in its namespace (intended more as a transitional"},{"line_number":317,"context_line":"mechanism, until the trait is incorporated in ``os-traits``), as follows."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Each driver will have a trait namespace:"},{"line_number":320,"context_line":"``CUSTOM_%(virt_driver)_DEVICE_``"},{"line_number":321,"context_line":"over which it will have full control. The libvirt driver will prefix generated"},{"line_number":322,"context_line":"traits with"},{"line_number":323,"context_line":"``CUSTOM_LIBVIRT_DEVICE_``"},{"line_number":324,"context_line":"and the PowerVM with"},{"line_number":325,"context_line":"``CUSTOM_POWERVM_IOSLOT_``"},{"line_number":326,"context_line":"The driver can populate the namespace with any device capabilities that it"},{"line_number":327,"context_line":"recognizes. If an operator, however, provides traits within its namespace, the"},{"line_number":328,"context_line":"driver will either remove them with a warning or raise an exception."},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"The traits finally included in the resource provider are the union of the"},{"line_number":331,"context_line":"generated traits and those provided by the operator in the inventory YAML (see"},{"line_number":332,"context_line":"`traits`_)."},{"line_number":333,"context_line":""},{"line_number":334,"context_line":""},{"line_number":335,"context_line":"Driver Implementation of Placement Model"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_6d57b602","line":332,"range":{"start_line":307,"start_character":0,"end_line":332,"end_character":11},"updated":"2018-08-27 16:38:48.000000000","message":"this is a direction that i personally would hope we dont proceed with unless we require that no driver generates a trait that could be modeled via a stadard trait in os-tratis and have some mechaniums for deprecating driver triats in favor of stadard traits when new standard traits are added.\n\ndriver namspaces will reuslt in vendorisation of flavors and ultimatly expose details of the infastructure to the end user. e.g. they can tell what hypervior is deploy via the pulblically avaliale flavour.\n\nsince flvor/images/ports will need to use the driver specific variant if they want to consume the generated trait. \nit will break interoperablity between different clouds.\n\nthis is why if there is  a standard trait for say avx the virt drvier must be required to generate the standard from when available so that we dont need to encode CUSTOM_LIBVIRT_HA_AVX in our flavors and images.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0e0771183a4b5a787240de554ab98982536796fe","unresolved":false,"context_lines":[{"line_number":304,"context_line":"          regions/functions, etc. At that point we will conceivably have"},{"line_number":305,"context_line":"          inventory of multiple units of multiple resource classes, etc."},{"line_number":306,"context_line":""},{"line_number":307,"context_line":"Generated Traits"},{"line_number":308,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":309,"context_line":"The drivers can decorate the resource providers with automatically generated"},{"line_number":310,"context_line":"traits according to extra information about the device\u0027s capabilities that the"},{"line_number":311,"context_line":"system may provide, or even based on device-capability matrices maintained by"},{"line_number":312,"context_line":"the device vendors."},{"line_number":313,"context_line":""},{"line_number":314,"context_line":"The driver can generate standard traits from ``os-traits``. If a standard trait"},{"line_number":315,"context_line":"exists for a capability, the driver must use that. If not, the driver can"},{"line_number":316,"context_line":"create a custom trait in its namespace (intended more as a transitional"},{"line_number":317,"context_line":"mechanism, until the trait is incorporated in ``os-traits``), as follows."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Each driver will have a trait namespace:"},{"line_number":320,"context_line":"``CUSTOM_%(virt_driver)_DEVICE_``"},{"line_number":321,"context_line":"over which it will have full control. The libvirt driver will prefix generated"},{"line_number":322,"context_line":"traits with"},{"line_number":323,"context_line":"``CUSTOM_LIBVIRT_DEVICE_``"},{"line_number":324,"context_line":"and the PowerVM with"},{"line_number":325,"context_line":"``CUSTOM_POWERVM_IOSLOT_``"},{"line_number":326,"context_line":"The driver can populate the namespace with any device capabilities that it"},{"line_number":327,"context_line":"recognizes. If an operator, however, provides traits within its namespace, the"},{"line_number":328,"context_line":"driver will either remove them with a warning or raise an exception."},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"The traits finally included in the resource provider are the union of the"},{"line_number":331,"context_line":"generated traits and those provided by the operator in the inventory YAML (see"},{"line_number":332,"context_line":"`traits`_)."},{"line_number":333,"context_line":""},{"line_number":334,"context_line":""},{"line_number":335,"context_line":"Driver Implementation of Placement Model"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_9029058b","line":332,"range":{"start_line":307,"start_character":0,"end_line":332,"end_character":11},"in_reply_to":"3f79a3b5_6d57b602","updated":"2018-08-27 17:05:16.000000000","message":"I have no strong opinion on actually allowing drivers to generate custom traits. As I say, I envision it as a transitional mechanism, expecting that any driver-generated trait should be superseded by a standard one from os-traits (see 2nd paragraph).\n\nI can\u0027t think of any mechanism to programmatically enforce this behavior; how could we say that this driver trait is the same as that standard one? I don\u0027t think there is a strong need for such a thing however, as this is part of driver code and therefore the future code reviews on the actual implementations should be responsible to enforce this.\n\nFor inter-cloud interoperability, the divergence of different drivers could indeed be problematic. However, isn\u0027t the ability of the operators to specify custom traits much more problematic on this account? But at the same time, it is necessary to have any sort of flexibility with local setups.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ec371bd32e6786c89be648e5a4a89867aad19cfb","unresolved":false,"context_lines":[{"line_number":304,"context_line":"          regions/functions, etc. At that point we will conceivably have"},{"line_number":305,"context_line":"          inventory of multiple units of multiple resource classes, etc."},{"line_number":306,"context_line":""},{"line_number":307,"context_line":"Generated Traits"},{"line_number":308,"context_line":"~~~~~~~~~~~~~~~~"},{"line_number":309,"context_line":"The drivers can decorate the resource providers with automatically generated"},{"line_number":310,"context_line":"traits according to extra information about the device\u0027s capabilities that the"},{"line_number":311,"context_line":"system may provide, or even based on device-capability matrices maintained by"},{"line_number":312,"context_line":"the device vendors."},{"line_number":313,"context_line":""},{"line_number":314,"context_line":"The driver can generate standard traits from ``os-traits``. If a standard trait"},{"line_number":315,"context_line":"exists for a capability, the driver must use that. If not, the driver can"},{"line_number":316,"context_line":"create a custom trait in its namespace (intended more as a transitional"},{"line_number":317,"context_line":"mechanism, until the trait is incorporated in ``os-traits``), as follows."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Each driver will have a trait namespace:"},{"line_number":320,"context_line":"``CUSTOM_%(virt_driver)_DEVICE_``"},{"line_number":321,"context_line":"over which it will have full control. The libvirt driver will prefix generated"},{"line_number":322,"context_line":"traits with"},{"line_number":323,"context_line":"``CUSTOM_LIBVIRT_DEVICE_``"},{"line_number":324,"context_line":"and the PowerVM with"},{"line_number":325,"context_line":"``CUSTOM_POWERVM_IOSLOT_``"},{"line_number":326,"context_line":"The driver can populate the namespace with any device capabilities that it"},{"line_number":327,"context_line":"recognizes. If an operator, however, provides traits within its namespace, the"},{"line_number":328,"context_line":"driver will either remove them with a warning or raise an exception."},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"The traits finally included in the resource provider are the union of the"},{"line_number":331,"context_line":"generated traits and those provided by the operator in the inventory YAML (see"},{"line_number":332,"context_line":"`traits`_)."},{"line_number":333,"context_line":""},{"line_number":334,"context_line":""},{"line_number":335,"context_line":"Driver Implementation of Placement Model"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_a6de4b0e","line":332,"range":{"start_line":307,"start_character":0,"end_line":332,"end_character":11},"in_reply_to":"3f79a3b5_9029058b","updated":"2018-08-27 19:29:01.000000000","message":"Totally agree that capabilities should be standard traits. BUT there\u0027s no way that happens completely and immediately upon release of a new piece of hardware. Generating traits like this gives us the ability to survive in a transitionary period until os-traits has caught up.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":335,"context_line":"Driver Implementation of Placement Model"},{"line_number":336,"context_line":"----------------------------------------"},{"line_number":337,"context_line":"The implementations that follow are specific to PCI devices and for the libvirt"},{"line_number":338,"context_line":"and PowerVM drivers. By providing an implementation for 2 drivers, it is"},{"line_number":339,"context_line":"expected that an extension to other drivers will be easy."},{"line_number":340,"context_line":""},{"line_number":341,"context_line":"Every driver will need to parse the inventory YAML configuration, provided to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8d2fb23d","line":338,"range":{"start_line":338,"start_character":55,"end_line":338,"end_character":57},"updated":"2018-08-27 16:44:28.000000000","message":"style: two","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":335,"context_line":"Driver Implementation of Placement Model"},{"line_number":336,"context_line":"----------------------------------------"},{"line_number":337,"context_line":"The implementations that follow are specific to PCI devices and for the libvirt"},{"line_number":338,"context_line":"and PowerVM drivers. By providing an implementation for 2 drivers, it is"},{"line_number":339,"context_line":"expected that an extension to other drivers will be easy."},{"line_number":340,"context_line":""},{"line_number":341,"context_line":"Every driver will need to parse the inventory YAML configuration, provided to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8e6a367e","line":338,"range":{"start_line":338,"start_character":55,"end_line":338,"end_character":57},"in_reply_to":"3f79a3b5_8d2fb23d","updated":"2018-08-28 14:06:50.000000000","message":"Done","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":396,"context_line":"  resources:MEMORY_MB\u003d2048"},{"line_number":397,"context_line":"  resources:DISK_GB\u003d100"},{"line_number":398,"context_line":"  resources1:CUSTOM_GPU\u003d1"},{"line_number":399,"context_line":"  traits1:CUSTOM_PCI_CUDA9\u003drequired"},{"line_number":400,"context_line":"  resources2:CUSTOM_GPU_NVP100\u003d1"},{"line_number":401,"context_line":"  resources3:CUSTOM_GPU\u003d1"},{"line_number":402,"context_line":"  traits3:CUSTOM_PCI_ALIAS_NVP100\u003drequired"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_8b355a47","line":399,"range":{"start_line":399,"start_character":10,"end_line":399,"end_character":26},"updated":"2018-08-27 18:43:30.000000000","message":"CUDA versions are already standardized in os-traits:\n\nhttps://github.com/openstack/os-traits/blob/f4721e5c70133aa1d5ac353c06af1379d553727a/os_traits/hw/gpu/api.py#L69-L86","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":396,"context_line":"  resources:MEMORY_MB\u003d2048"},{"line_number":397,"context_line":"  resources:DISK_GB\u003d100"},{"line_number":398,"context_line":"  resources1:CUSTOM_GPU\u003d1"},{"line_number":399,"context_line":"  traits1:CUSTOM_PCI_CUDA9\u003drequired"},{"line_number":400,"context_line":"  resources2:CUSTOM_GPU_NVP100\u003d1"},{"line_number":401,"context_line":"  resources3:CUSTOM_GPU\u003d1"},{"line_number":402,"context_line":"  traits3:CUSTOM_PCI_ALIAS_NVP100\u003drequired"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_3a86b915","line":399,"range":{"start_line":399,"start_character":10,"end_line":399,"end_character":26},"in_reply_to":"3f79a3b5_0e59468c","updated":"2018-10-12 13:48:22.000000000","message":"merged. thanks for the patch!","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":396,"context_line":"  resources:MEMORY_MB\u003d2048"},{"line_number":397,"context_line":"  resources:DISK_GB\u003d100"},{"line_number":398,"context_line":"  resources1:CUSTOM_GPU\u003d1"},{"line_number":399,"context_line":"  traits1:CUSTOM_PCI_CUDA9\u003drequired"},{"line_number":400,"context_line":"  resources2:CUSTOM_GPU_NVP100\u003d1"},{"line_number":401,"context_line":"  resources3:CUSTOM_GPU\u003d1"},{"line_number":402,"context_line":"  traits3:CUSTOM_PCI_ALIAS_NVP100\u003drequired"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_0e59468c","line":399,"range":{"start_line":399,"start_character":10,"end_line":399,"end_character":26},"in_reply_to":"3f79a3b5_8b355a47","updated":"2018-08-28 14:06:50.000000000","message":"Thanks for the link. Actually CUDA9 isn\u0027t there yet: https://review.openstack.org/#/c/597111","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"eb8a714eafd346086be3d453796e12a245722b37","unresolved":false,"context_lines":[{"line_number":399,"context_line":"  traits1:CUSTOM_PCI_CUDA9\u003drequired"},{"line_number":400,"context_line":"  resources2:CUSTOM_GPU_NVP100\u003d1"},{"line_number":401,"context_line":"  resources3:CUSTOM_GPU\u003d1"},{"line_number":402,"context_line":"  traits3:CUSTOM_PCI_ALIAS_NVP100\u003drequired"},{"line_number":403,"context_line":""},{"line_number":404,"context_line":"Notice above the usability of PCI aliases in this scheme, either as resource"},{"line_number":405,"context_line":"class names or as traits."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_4d251a5b","line":402,"range":{"start_line":402,"start_character":2,"end_line":402,"end_character":42},"updated":"2018-08-27 16:38:48.000000000","message":"i really dislike the idea of using traits for alias\n\ncould we use different resouce classes instead as is show with  resources2:CUSTOM_GPU_NVP100\u003d1","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":399,"context_line":"  traits1:CUSTOM_PCI_CUDA9\u003drequired"},{"line_number":400,"context_line":"  resources2:CUSTOM_GPU_NVP100\u003d1"},{"line_number":401,"context_line":"  resources3:CUSTOM_GPU\u003d1"},{"line_number":402,"context_line":"  traits3:CUSTOM_PCI_ALIAS_NVP100\u003drequired"},{"line_number":403,"context_line":""},{"line_number":404,"context_line":"Notice above the usability of PCI aliases in this scheme, either as resource"},{"line_number":405,"context_line":"class names or as traits."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_cb0a7288","line":402,"range":{"start_line":402,"start_character":2,"end_line":402,"end_character":42},"in_reply_to":"3f79a3b5_4d251a5b","updated":"2018-08-27 18:43:30.000000000","message":"Yeah, big -1 on using traits instead of custom resource classes.\n\nKonstantinos, are you looking for is a way of saying \"this flavor needs a GPU, it can be EITHER a Tesla P100 or it can be a GTX 1080ti\"\n\nBecause if that is the case, you really need to be thinking about what *capabilities* the P100 or the GTX 1080ti provide to the end user. Those capabilities are what traits are. If there are no substantive differences between the capabilities of the P100 and GTX 1080ti *from the perspective of the end user*, then there is no point in creating different resource classes other than, say, \"CUSTOM_GPU\".","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":399,"context_line":"  traits1:CUSTOM_PCI_CUDA9\u003drequired"},{"line_number":400,"context_line":"  resources2:CUSTOM_GPU_NVP100\u003d1"},{"line_number":401,"context_line":"  resources3:CUSTOM_GPU\u003d1"},{"line_number":402,"context_line":"  traits3:CUSTOM_PCI_ALIAS_NVP100\u003drequired"},{"line_number":403,"context_line":""},{"line_number":404,"context_line":"Notice above the usability of PCI aliases in this scheme, either as resource"},{"line_number":405,"context_line":"class names or as traits."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_34b810e4","line":402,"range":{"start_line":402,"start_character":2,"end_line":402,"end_character":42},"in_reply_to":"3f79a3b5_cb0a7288","updated":"2018-08-28 14:06:50.000000000","message":"Indeed this is what I want the operator to be able to express (see also my answer to sean mooney below).\n\nYou\u0027re right, but the big difference between the P100 and GTX1080ti for example is quantitative, ie not a capability but memory amount and bandwidth. I can expect therefore 2 scenarios:\n1. Nova + operator try to be smart and encode these differences that a user might need in many capabilities and create lots of flavors to match\n2. Add the name/alias as a trait and defer the true decision to the user\nI find both of these reasonable, depending on the circumstances. Option 1 is what you propose; it can be better standardized, but, if a particular cloud wants to be more picky about the little differences for which it will be too difficult to create individual flavors in 1, they might want option 2.\n\nIf we want to allow the users to get the P100 either because they are looking for a GPU with HBM2 memory (case 1) or because they ask for it explicitly (case 3), then we have to use a trait instead of an RC.\nI believe in any case that the operator should be free to choose among the examples above. This is nothing more than a few example use cases of the mechanism we specify.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"eb8a714eafd346086be3d453796e12a245722b37","unresolved":false,"context_lines":[{"line_number":402,"context_line":"  traits3:CUSTOM_PCI_ALIAS_NVP100\u003drequired"},{"line_number":403,"context_line":""},{"line_number":404,"context_line":"Notice above the usability of PCI aliases in this scheme, either as resource"},{"line_number":405,"context_line":"class names or as traits."},{"line_number":406,"context_line":""},{"line_number":407,"context_line":""},{"line_number":408,"context_line":"Device attachment"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_4db3da0a","line":405,"range":{"start_line":405,"start_character":12,"end_line":405,"end_character":24},"updated":"2018-08-27 16:38:48.000000000","message":"i would drop this option.\nwe want constency across drivers so lets just use resouce classes. the alisa is not a qualitative aspect of the resouce so lets not use traits to track it.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"0e0771183a4b5a787240de554ab98982536796fe","unresolved":false,"context_lines":[{"line_number":402,"context_line":"  traits3:CUSTOM_PCI_ALIAS_NVP100\u003drequired"},{"line_number":403,"context_line":""},{"line_number":404,"context_line":"Notice above the usability of PCI aliases in this scheme, either as resource"},{"line_number":405,"context_line":"class names or as traits."},{"line_number":406,"context_line":""},{"line_number":407,"context_line":""},{"line_number":408,"context_line":"Device attachment"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_2d69be23","line":405,"range":{"start_line":405,"start_character":12,"end_line":405,"end_character":24},"in_reply_to":"3f79a3b5_4db3da0a","updated":"2018-08-27 17:05:16.000000000","message":"In this example, I take the proposed mechanism and use it as an operator to work for my use case. We can indeed recommend that the \"alias\" use case fits better to be an RC, but I don\u0027t see any way to disallow this use.\n\nMore than that, this example provides the possibility for a more general scheduling shown in resources1. The RP will have a single RC, so resources1 and resources3 are allowed to schedule to the same physical device, unlike resources2.\nIf, OTOH, the operator chooses to use the CUSTOM_GPU_NVP100 RC, he precludes the 1st type of scheduling.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"bf1a0e3d8c743059212b02bc3417e148d3b5fd33","unresolved":false,"context_lines":[{"line_number":407,"context_line":""},{"line_number":408,"context_line":"Device attachment"},{"line_number":409,"context_line":"-----------------"},{"line_number":410,"context_line":"TODO"},{"line_number":411,"context_line":""},{"line_number":412,"context_line":"Alternatives"},{"line_number":413,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_a6bdebd8","line":410,"range":{"start_line":410,"start_character":0,"end_line":410,"end_character":4},"updated":"2018-08-27 18:57:38.000000000","message":"I\u0027d certainly want to see a plan for this.\n\nPresumably things that go here are in the realm of how allocations for these devices are managed, as well as how we communicate those things to the virt drivers so that they actually happen.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"bf1a0e3d8c743059212b02bc3417e148d3b5fd33","unresolved":false,"context_lines":[{"line_number":413,"context_line":"------------"},{"line_number":414,"context_line":"Use Nova\u0027s PCI passthrough subsystem. As scheduling moves to Placement, this"},{"line_number":415,"context_line":"system becomes obsolete as a scheduling mechanism, relying on the"},{"line_number":416,"context_line":"``PciPassthroughFilter`` scheduler filter. Quotas on PCI devices should also"},{"line_number":417,"context_line":"come for free after Placement integration and the implementation of specs like"},{"line_number":418,"context_line":"count-quota-usage-from-placement [2]_ and count-quota-base-on-resource-class"},{"line_number":419,"context_line":"[3]_."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Use oslo.config instead of a YAML file. Experience with the"},{"line_number":422,"context_line":"``[pci]passthrough_whitelist`` has led us to conclude that config format is too"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_46e3b705","line":419,"range":{"start_line":416,"start_character":43,"end_line":419,"end_character":5},"updated":"2018-08-27 18:57:38.000000000","message":"FWIW, I don\u0027t think we have a path forward on this any time soon (if at all). So if you\u0027re depending on replacing something existing with quotas in placement as part of this, think again. (I don\u0027t know if we currently have quotas on pci devices, but I would expect operators to want that, given they\u0027d be some of the most contentious and precious resources in the cloud).","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":413,"context_line":"------------"},{"line_number":414,"context_line":"Use Nova\u0027s PCI passthrough subsystem. As scheduling moves to Placement, this"},{"line_number":415,"context_line":"system becomes obsolete as a scheduling mechanism, relying on the"},{"line_number":416,"context_line":"``PciPassthroughFilter`` scheduler filter. Quotas on PCI devices should also"},{"line_number":417,"context_line":"come for free after Placement integration and the implementation of specs like"},{"line_number":418,"context_line":"count-quota-usage-from-placement [2]_ and count-quota-base-on-resource-class"},{"line_number":419,"context_line":"[3]_."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Use oslo.config instead of a YAML file. Experience with the"},{"line_number":422,"context_line":"``[pci]passthrough_whitelist`` has led us to conclude that config format is too"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_b44980b8","line":419,"range":{"start_line":416,"start_character":43,"end_line":419,"end_character":5},"in_reply_to":"3f79a3b5_46e3b705","updated":"2018-08-28 14:06:50.000000000","message":"We do not have them now, and from checking those two specs it seemed to me that this is the prerequisite to get them.\nThe alternative would be to implement de novo quota counting infrastructure on the existing pci system...","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":418,"context_line":"count-quota-usage-from-placement [2]_ and count-quota-base-on-resource-class"},{"line_number":419,"context_line":"[3]_."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Use oslo.config instead of a YAML file. Experience with the"},{"line_number":422,"context_line":"``[pci]passthrough_whitelist`` has led us to conclude that config format is too"},{"line_number":423,"context_line":"restrictive/awkward. The direction for Nova (as discussed in the Queens PTG in"},{"line_number":424,"context_line":"Denver) will be toward some kind of YAML format; we\u0027re going to be the pioneers"},{"line_number":425,"context_line":"on this front."},{"line_number":426,"context_line":""},{"line_number":427,"context_line":"Data model impact"},{"line_number":428,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_ada5ceb6","line":425,"range":{"start_line":421,"start_character":0,"end_line":425,"end_character":14},"updated":"2018-08-27 16:44:28.000000000","message":"Hmm, so I\u0027m not saying this is wrong but we did manage to work around this for numa-aware-vswitches [1] using dynamic section generation. Is there any reason we couldn\u0027t take the same approach here and keep configuration centralized?\n\n[1] https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-vswitches.html#configuration-options","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f573c67e87f9123ed75ee1d647e33c191af92c1b","unresolved":false,"context_lines":[{"line_number":418,"context_line":"count-quota-usage-from-placement [2]_ and count-quota-base-on-resource-class"},{"line_number":419,"context_line":"[3]_."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Use oslo.config instead of a YAML file. Experience with the"},{"line_number":422,"context_line":"``[pci]passthrough_whitelist`` has led us to conclude that config format is too"},{"line_number":423,"context_line":"restrictive/awkward. The direction for Nova (as discussed in the Queens PTG in"},{"line_number":424,"context_line":"Denver) will be toward some kind of YAML format; we\u0027re going to be the pioneers"},{"line_number":425,"context_line":"on this front."},{"line_number":426,"context_line":""},{"line_number":427,"context_line":"Data model impact"},{"line_number":428,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_ebface40","line":425,"range":{"start_line":421,"start_character":0,"end_line":425,"end_character":14},"in_reply_to":"3f79a3b5_ada5ceb6","updated":"2018-08-27 18:43:30.000000000","message":"pretty sure dansmith and maybe others will have strong opinions about this :)","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"bf1a0e3d8c743059212b02bc3417e148d3b5fd33","unresolved":false,"context_lines":[{"line_number":418,"context_line":"count-quota-usage-from-placement [2]_ and count-quota-base-on-resource-class"},{"line_number":419,"context_line":"[3]_."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Use oslo.config instead of a YAML file. Experience with the"},{"line_number":422,"context_line":"``[pci]passthrough_whitelist`` has led us to conclude that config format is too"},{"line_number":423,"context_line":"restrictive/awkward. The direction for Nova (as discussed in the Queens PTG in"},{"line_number":424,"context_line":"Denver) will be toward some kind of YAML format; we\u0027re going to be the pioneers"},{"line_number":425,"context_line":"on this front."},{"line_number":426,"context_line":""},{"line_number":427,"context_line":"Data model impact"},{"line_number":428,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_26e8fbdf","line":425,"range":{"start_line":421,"start_character":0,"end_line":425,"end_character":14},"in_reply_to":"3f79a3b5_ebface40","updated":"2018-08-27 18:57:38.000000000","message":"I definitely don\u0027t see anything in here that demands using yaml, and I definitely have the concern over versioning this file format. If yaml is really required for arbitrary nesting or something, then so be it, but we need to be super on top of making sure we don\u0027t break the format of this file from release to release.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ec371bd32e6786c89be648e5a4a89867aad19cfb","unresolved":false,"context_lines":[{"line_number":418,"context_line":"count-quota-usage-from-placement [2]_ and count-quota-base-on-resource-class"},{"line_number":419,"context_line":"[3]_."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Use oslo.config instead of a YAML file. Experience with the"},{"line_number":422,"context_line":"``[pci]passthrough_whitelist`` has led us to conclude that config format is too"},{"line_number":423,"context_line":"restrictive/awkward. The direction for Nova (as discussed in the Queens PTG in"},{"line_number":424,"context_line":"Denver) will be toward some kind of YAML format; we\u0027re going to be the pioneers"},{"line_number":425,"context_line":"on this front."},{"line_number":426,"context_line":""},{"line_number":427,"context_line":"Data model impact"},{"line_number":428,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_e64523b5","line":425,"range":{"start_line":421,"start_character":0,"end_line":425,"end_character":14},"in_reply_to":"3f79a3b5_ebface40","updated":"2018-08-27 19:29:01.000000000","message":"I saw the \"dynamic config\" thing as a temporary hack for NUMA-aware vswitches because we hadn\u0027t committed to coming up with *this* yet. Dynamic config is hard to follow, doesn\u0027t self-document like static config, and seems like a really difficult/awkward way to get the arbitrary nesting that yaml gives us for free.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":476,"context_line":"request syntax in `Flavor Support`_. For possible impact, see `Other deployer"},{"line_number":477,"context_line":"impact`_."},{"line_number":478,"context_line":""},{"line_number":479,"context_line":"Only the PCI passthrough devices are considered, according to the"},{"line_number":480,"context_line":"whitelist (see `Device Identification and Whitelisting`_), and the vGPU use"},{"line_number":481,"context_line":"case is not affected."},{"line_number":482,"context_line":""},{"line_number":483,"context_line":""},{"line_number":484,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_ad938e4e","line":481,"range":{"start_line":479,"start_character":0,"end_line":481,"end_character":21},"updated":"2018-08-27 16:44:28.000000000","message":"Are you saying only PCI devices listed here will be available, even if they\u0027re listed in this new YAML file? If not, could you rephrase?","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"3665b44e9b9b2e5a9e5b5b17bdacf6d6782ca44f","unresolved":false,"context_lines":[{"line_number":476,"context_line":"request syntax in `Flavor Support`_. For possible impact, see `Other deployer"},{"line_number":477,"context_line":"impact`_."},{"line_number":478,"context_line":""},{"line_number":479,"context_line":"Only the PCI passthrough devices are considered, according to the"},{"line_number":480,"context_line":"whitelist (see `Device Identification and Whitelisting`_), and the vGPU use"},{"line_number":481,"context_line":"case is not affected."},{"line_number":482,"context_line":""},{"line_number":483,"context_line":""},{"line_number":484,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_e9772cd3","line":481,"range":{"start_line":479,"start_character":0,"end_line":481,"end_character":21},"in_reply_to":"3f79a3b5_ad938e4e","updated":"2018-08-28 14:06:50.000000000","message":"I\u0027m not sure I understand. I\u0027m saying that only the devices (erase \"PCI\") listed in the YAML (whitelisted) will be considered. An operator that provides vGPUs should not list those devices in the inventory YAML, since they are not being passed through. If he does by mistake, the behavior is driver-dependent.\n\nThe vGPU use case is therefore not affected, provided that the operator doesn\u0027t list the physical GPU that provides vGPUs on the inventory YAML - yet. Supporting vGPUs would be future work after this spec.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e975d79e59fbcff5eac9df5dbd1a0d09ea0cd1b2","unresolved":false,"context_lines":[{"line_number":504,"context_line":""},{"line_number":505,"context_line":"Testing"},{"line_number":506,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":507,"context_line":"Testing will require CI nodes with PCI devices for passthrough, which may be"},{"line_number":508,"context_line":"challenging."},{"line_number":509,"context_line":""},{"line_number":510,"context_line":""},{"line_number":511,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f79a3b5_eda426a5","line":508,"range":{"start_line":507,"start_character":0,"end_line":508,"end_character":12},"updated":"2018-08-27 16:44:28.000000000","message":"At a minimum, we\u0027re going to need a guide for how one can test this. After that, we can probably test it with functional tests at least.","commit_id":"765b5c6a0c33bd46ab4f7fd43c1f56b8e4058b05"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c42cbda114686f75e8e682991e8426a3083f8e75","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/device-placement-passthrough"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Provide a generic way to model devices, such as GPUs, in Placement."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This spec is based on Eric Fried\u0027s original spec for nova-powervm [1]_."},{"line_number":16,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_35767541","line":13,"range":{"start_line":13,"start_character":40,"end_line":13,"end_character":53},"updated":"2018-09-13 17:49:50.000000000","message":"FWIW, we already spec\u0027d up this for virtual GPUs https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/add-support-for-vgpu.html\n\nHere, I assume you talk about generic PCI passthrough cases, where VGA passthrough is a special case)","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":24,"context_line":""},{"line_number":25,"context_line":"* the special way in which PCI devices are currently inventoried"},{"line_number":26,"context_line":"* the special way to schedule VMs that request PCI passthrough, which doesn\u0027t"},{"line_number":27,"context_line":"  rely on Placement to provide the correct allocation candidates, but on the"},{"line_number":28,"context_line":"  ``PciPassthroughFilter`` to filter out incapable nodes"},{"line_number":29,"context_line":"* no quotas on PCI devices"},{"line_number":30,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_0a9e7d68","line":27,"range":{"start_line":27,"start_character":66,"end_line":27,"end_character":72},"updated":"2018-10-12 13:48:22.000000000","message":"s/but on/but instead relies on/","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c42cbda114686f75e8e682991e8426a3083f8e75","unresolved":false,"context_lines":[{"line_number":39,"context_line":"The implementation for two drivers paves the way for implementing it in any"},{"line_number":40,"context_line":"other."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The primary goal for the current release is to pass through entire physical"},{"line_number":43,"context_line":"GPUs or FPGAs. However, it should be straightforward to extend it to support"},{"line_number":44,"context_line":"vGPUs, and possibly SR-IOV NIC VFs, albeit in coordination with [4]_."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_d5a9417c","line":43,"range":{"start_line":42,"start_character":60,"end_line":43,"end_character":15},"updated":"2018-09-13 17:49:50.000000000","message":"please don\u0027t be that specific, and just mention PCI (or more?) attached devices.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c42cbda114686f75e8e682991e8426a3083f8e75","unresolved":false,"context_lines":[{"line_number":40,"context_line":"other."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"The primary goal for the current release is to pass through entire physical"},{"line_number":43,"context_line":"GPUs or FPGAs. However, it should be straightforward to extend it to support"},{"line_number":44,"context_line":"vGPUs, and possibly SR-IOV NIC VFs, albeit in coordination with [4]_."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_3520b5f8","line":44,"range":{"start_line":43,"start_character":66,"end_line":44,"end_character":6},"updated":"2018-09-13 17:49:50.000000000","message":"we already support vGPUs with the spec I just mentioned and we also have a current effort on providing multiple types wiht https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/vgpu-rocky.html","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Use Cases"},{"line_number":48,"context_line":"---------"},{"line_number":49,"context_line":"As an operator, I wish to be able to configure my host and flavors to allow"},{"line_number":50,"context_line":"passthrough of whole physical GPUs to VMs, and to schedule these VMs using the"},{"line_number":51,"context_line":"same resource request filtering that is done for other types of resources such"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_eac60542","line":48,"range":{"start_line":48,"start_character":0,"end_line":48,"end_character":9},"updated":"2018-11-02 10:56:38.000000000","message":"nit: here and elsewhere, can you add a space under these header lines?","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":49,"context_line":"As an operator, I wish to be able to configure my host and flavors to allow"},{"line_number":50,"context_line":"passthrough of whole physical GPUs to VMs, and to schedule these VMs using the"},{"line_number":51,"context_line":"same resource request filtering that is done for other types of resources such"},{"line_number":52,"context_line":"as VCPU or MEMORY_MB."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_43b3e909","line":52,"updated":"2018-10-12 13:48:22.000000000","message":"++","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":60,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":61,"context_line":"passthrough of devices by way of a YAML file per compute host."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":".. note:: **Future:** We may someday figure out a way to support a config file"},{"line_number":64,"context_line":"          on the controller. This would allow e.g. cloud-wide whitelisting and"},{"line_number":65,"context_line":"          specification for particular device types by vendor/product ID, which"},{"line_number":66,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The path to the YAML will be provided in nova.conf by the config option"},{"line_number":69,"context_line":"``[DEFAULT]/inventory_config_filepath``"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_caf2299d","line":66,"range":{"start_line":63,"start_character":0,"end_line":66,"end_character":78},"updated":"2018-11-02 10:56:38.000000000","message":"But until then, this is a deployment problem","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":66,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The path to the YAML will be provided in nova.conf by the config option"},{"line_number":69,"context_line":"``[DEFAULT]/inventory_config_filepath``"},{"line_number":70,"context_line":"which will default to ``/etc/nova/inventory.yaml``."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":73,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_c36b7919","line":70,"range":{"start_line":69,"start_character":0,"end_line":70,"end_character":51},"updated":"2018-10-12 13:48:22.000000000","message":"recommend calling the file something other than \"inventory.yaml\" because you are storing information about the providers (the devices), which is more than just \"inventory\".\n\nMaybe something like \"providers.yaml\" or \"devices.yaml\"?","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":66,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The path to the YAML will be provided in nova.conf by the config option"},{"line_number":69,"context_line":"``[DEFAULT]/inventory_config_filepath``"},{"line_number":70,"context_line":"which will default to ``/etc/nova/inventory.yaml``."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":73,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_2afe3d6a","line":70,"range":{"start_line":69,"start_character":0,"end_line":70,"end_character":51},"in_reply_to":"3f79a3b5_c36b7919","updated":"2018-11-02 10:56:38.000000000","message":"+1 to ``devices.yaml``. Clear and to the point","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":72,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":73,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The parsing of the file will happen in driver-independent code, which will be"},{"line_number":76,"context_line":"responsible for handling the dynamic reloading of the configuration at SIGHUP"},{"line_number":77,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":78,"context_line":"will expect a dict containing all the parsed keys."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_c3937958","line":75,"range":{"start_line":75,"start_character":36,"end_line":75,"end_character":62},"updated":"2018-10-12 13:48:22.000000000","message":"is the plan to have a module in nova to start with and maybe move this code to an oslo library?","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":72,"context_line":"The configuration provided in this YAML file will be dynamically reloadable via"},{"line_number":73,"context_line":"SIGHUP, like for mutable oslo.config options [6]_."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The parsing of the file will happen in driver-independent code, which will be"},{"line_number":76,"context_line":"responsible for handling the dynamic reloading of the configuration at SIGHUP"},{"line_number":77,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":78,"context_line":"will expect a dict containing all the parsed keys."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_aae9edab","line":75,"range":{"start_line":75,"start_character":36,"end_line":75,"end_character":62},"in_reply_to":"3f79a3b5_c3937958","updated":"2018-11-02 10:56:38.000000000","message":"If it is, let\u0027s make sure it\u0027s definitely defined in nova first. This is likely to evolve quite fast at the beginning and we don\u0027t want to have to continuously release os-foo and update nova\u0027s requirements in lockstep","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The parsing of the file will happen in driver-independent code, which will be"},{"line_number":76,"context_line":"responsible for handling the dynamic reloading of the configuration at SIGHUP"},{"line_number":77,"context_line":"and low-level parsing details, like file ownership and permissions. The drivers"},{"line_number":78,"context_line":"will expect a dict containing all the parsed keys."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The file will contain sections, each of which will:"},{"line_number":81,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_4396893f","line":78,"range":{"start_line":77,"start_character":68,"end_line":78,"end_character":50},"updated":"2018-10-12 13:48:22.000000000","message":"It will be a more substantial API and less easy to abuse if the thing being passed to the driver is an object with a schema associated with it and that schema has a version.\n\nYou don\u0027t need to use oslo.versionedobjects but just an object with an associated JSONSchema document that describes the object\u0027s attributes is important to have in order to stabilize the API and allow forward evolution of the interfaces.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":89,"context_line":"  `resource_class`_.)."},{"line_number":90,"context_line":"* List traits to include on the resource provider. See `traits`_."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"A formal schema will be implemented."},{"line_number":93,"context_line":"Here is a summary description of each section."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Name"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_e351d564","line":92,"range":{"start_line":92,"start_character":0,"end_line":92,"end_character":36},"updated":"2018-10-12 13:48:22.000000000","message":"this is exactly what should be in this spec, IMHO, instead of table-based description of fields in various sections.\n\nIt\u0027s easier to read a JSONSchema document that describes an expected YAML file. Also, you wouldn\u0027t need to show one giant JSONSchema document. You could have a JSONSchema document for the file, with each section of the file described by separate JSONSchema documents, ala !definitions as described here:\n\nhttps://json-schema.org/understanding-json-schema/structuring.html#using-id-with-ref","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Name"},{"line_number":96,"context_line":"~~~~"},{"line_number":97,"context_line":"Each section will be introduced by a key which is a human-readable name for"},{"line_number":98,"context_line":"the section. The name has no programmatic significance other than to separate"},{"line_number":99,"context_line":"sections. Each section\u0027s name must be unique within the file."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"identification"},{"line_number":102,"context_line":"~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_83bfc15e","line":99,"range":{"start_line":97,"start_character":0,"end_line":99,"end_character":61},"updated":"2018-10-12 13:48:22.000000000","message":"I don\u0027t really understand this part. Are you saying in effect that the file will be basically a dict with the keys being the unique names of the devices?","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":116,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":117,"context_line":" YAML key              Device Property           Format"},{"line_number":118,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":119,"context_line":" ``pci_address``       PCI Slot                  ``[\\X{4}:]\\X{2}:\\X{2}.\\X{1}`` ([4:]2:2.1 uppercase hex digits)"},{"line_number":120,"context_line":" ``vendor_id``         PCI Vendor                ``\\X{4}`` (4 uppercase hex digits)"},{"line_number":121,"context_line":" ``device_id``         PCI Device                ``\\X{4}``            \""},{"line_number":122,"context_line":" ``subsys_vendor_id``  PCI Subsystem Vendor      ``\\X{4}``            \""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_63d94526","line":119,"range":{"start_line":119,"start_character":3,"end_line":119,"end_character":7},"updated":"2018-10-12 13:48:22.000000000","message":"recommend calling it just \"address\"","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":116,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":117,"context_line":" YAML key              Device Property           Format"},{"line_number":118,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":119,"context_line":" ``pci_address``       PCI Slot                  ``[\\X{4}:]\\X{2}:\\X{2}.\\X{1}`` ([4:]2:2.1 uppercase hex digits)"},{"line_number":120,"context_line":" ``vendor_id``         PCI Vendor                ``\\X{4}`` (4 uppercase hex digits)"},{"line_number":121,"context_line":" ``device_id``         PCI Device                ``\\X{4}``            \""},{"line_number":122,"context_line":" ``subsys_vendor_id``  PCI Subsystem Vendor      ``\\X{4}``            \""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_aa3ecd23","line":119,"range":{"start_line":119,"start_character":3,"end_line":119,"end_character":7},"in_reply_to":"3f79a3b5_5a9c716f","updated":"2018-11-02 10:56:38.000000000","message":"I\u0027d suggest two fields: ``address`` and ``format``. If ``format`` is left empty (the most common case?), it\u0027s assumed to be D:B:S:F format. FWIW, this is what OpenAPI 3.0.0 does","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7396cd816b79c07f7b83668e46859808e0439fb9","unresolved":false,"context_lines":[{"line_number":116,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":117,"context_line":" YAML key              Device Property           Format"},{"line_number":118,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":119,"context_line":" ``pci_address``       PCI Slot                  ``[\\X{4}:]\\X{2}:\\X{2}.\\X{1}`` ([4:]2:2.1 uppercase hex digits)"},{"line_number":120,"context_line":" ``vendor_id``         PCI Vendor                ``\\X{4}`` (4 uppercase hex digits)"},{"line_number":121,"context_line":" ``device_id``         PCI Device                ``\\X{4}``            \""},{"line_number":122,"context_line":" ``subsys_vendor_id``  PCI Subsystem Vendor      ``\\X{4}``            \""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_5a9c716f","line":119,"range":{"start_line":119,"start_character":3,"end_line":119,"end_character":7},"in_reply_to":"3f79a3b5_63d94526","updated":"2018-10-22 22:13:07.000000000","message":"I would rather be specific that this field expects a 32-bit PCI address in D:B:S.F format, and other address-y fields would be for different kinds of addresses in whatever format is specific to that address type (e.g. drc_index and drc_name are also address-y fields). What I definitely don\u0027t want is a single \"address\" field that could have any number of possible formats where the consumer of the parsed file has to figure out which format was intended.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c42cbda114686f75e8e682991e8426a3083f8e75","unresolved":false,"context_lines":[{"line_number":122,"context_line":" ``subsys_vendor_id``  PCI Subsystem Vendor      ``\\X{4}``            \""},{"line_number":123,"context_line":" ``subsys_device_id``  PCI Subsystem Device      ``\\X{4}``            \""},{"line_number":124,"context_line":" ``class``             PCI Device Class          ``\\X{4}``            \""},{"line_number":125,"context_line":" ``revision_id``       PCI Revision              ``\\X{2}`` (2 uppercase hex digits)"},{"line_number":126,"context_line":" ``drc_index``         PowerVM IOSLOT drc_index  ``\\X{8}`` (8 uppercase hex digits)"},{"line_number":127,"context_line":" ``drc_name``          PowerVM IOSLOT drc_name   ``String`` (physical location code)"},{"line_number":128,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_d5738115","line":125,"updated":"2018-09-13 17:49:50.000000000","message":"all of the above is super PCI specific, so I assume our inventory will be tied such way.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7396cd816b79c07f7b83668e46859808e0439fb9","unresolved":false,"context_lines":[{"line_number":122,"context_line":" ``subsys_vendor_id``  PCI Subsystem Vendor      ``\\X{4}``            \""},{"line_number":123,"context_line":" ``subsys_device_id``  PCI Subsystem Device      ``\\X{4}``            \""},{"line_number":124,"context_line":" ``class``             PCI Device Class          ``\\X{4}``            \""},{"line_number":125,"context_line":" ``revision_id``       PCI Revision              ``\\X{2}`` (2 uppercase hex digits)"},{"line_number":126,"context_line":" ``drc_index``         PowerVM IOSLOT drc_index  ``\\X{8}`` (8 uppercase hex digits)"},{"line_number":127,"context_line":" ``drc_name``          PowerVM IOSLOT drc_name   ``String`` (physical location code)"},{"line_number":128,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_7a8dad27","line":125,"in_reply_to":"3f79a3b5_d5738115","updated":"2018-10-22 22:13:07.000000000","message":"The point is to support identifying the device in multiple ways in the same stanza. It happens that the two mechanisms I\u0027m most familiar with (PowerVM and libvirt) both support these PCI-ish fields, so there\u0027s overlap there. But e.g. PowerVM will ignore pci_address, and libvirt will ignore drc_*.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":127,"context_line":" ``drc_name``          PowerVM IOSLOT drc_name   ``String`` (physical location code)"},{"line_number":128,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"The values need to be quoted, to avoid YAML parsing hex values like \u00271234\u0027 as"},{"line_number":131,"context_line":"integers, and follow the format specified in the schema above."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"In the case of libvirt, the values should be those reported by"},{"line_number":134,"context_line":"``lspci -Dvnmm`` (but following the format above). Example:"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_6a775509","line":131,"range":{"start_line":130,"start_character":0,"end_line":131,"end_character":62},"updated":"2018-11-02 10:56:38.000000000","message":"nit: Should be formatted as a note. This is a YAML thing and not really anything specific to this spec, even though it\u0027s worth calling out all the same.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c42cbda114686f75e8e682991e8426a3083f8e75","unresolved":false,"context_lines":[{"line_number":130,"context_line":"The values need to be quoted, to avoid YAML parsing hex values like \u00271234\u0027 as"},{"line_number":131,"context_line":"integers, and follow the format specified in the schema above."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"In the case of libvirt, the values should be those reported by"},{"line_number":134,"context_line":"``lspci -Dvnmm`` (but following the format above). Example:"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":".. code::"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_b5c7e511","line":133,"range":{"start_line":133,"start_character":35,"end_line":133,"end_character":41},"updated":"2018-09-13 17:49:50.000000000","message":"could be stuffed (but I\u0027m not in favor of something done automatically, rather left to the operator)","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7396cd816b79c07f7b83668e46859808e0439fb9","unresolved":false,"context_lines":[{"line_number":130,"context_line":"The values need to be quoted, to avoid YAML parsing hex values like \u00271234\u0027 as"},{"line_number":131,"context_line":"integers, and follow the format specified in the schema above."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"In the case of libvirt, the values should be those reported by"},{"line_number":134,"context_line":"``lspci -Dvnmm`` (but following the format above). Example:"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":".. code::"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_3a97353c","line":133,"range":{"start_line":133,"start_character":35,"end_line":133,"end_character":41},"in_reply_to":"3f79a3b5_b5c7e511","updated":"2018-10-22 22:13:07.000000000","message":"What do you mean, stuffed?","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":149,"context_line":"In the case of PowerVM, the values are expected to match those produced by"},{"line_number":150,"context_line":"``pvmctl ioslot list -d \u003cproperty\u003e`` for a given property."},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"Not all drivers need understand all keys. For example, ``drc_index`` is"},{"line_number":153,"context_line":"not understood by the libvirt driver. The handling of this situation is"},{"line_number":154,"context_line":"delegated to each driver."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"If, however, the inventory of a particular host contains keys that the running"},{"line_number":157,"context_line":"driver doesn\u0027t understand, it\u0027s likely to be an operator oversight. Therefore,"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_b97db071","line":154,"range":{"start_line":152,"start_character":0,"end_line":154,"end_character":25},"updated":"2018-11-02 10:56:38.000000000","message":"Something about this feels wrong. It\u0027s almost like we\u0027d want to identify different types of schemas named after the virt driver and nested the keys underneath those, e.g.\n\n  identification:\n    libvirt:\n      address: \u0027...\u0027\n      vendor_id: \u0027...\u0027\n    powervm:\n      drc_index: \u0027...\u0027\n      drc_name: \u0027...\u0027\n\nThis assumes there no overlap between the identification types used by the various hypervisors. If there was, we could make the names more generic. Of the choices we currently have in tree, I imagine only XenAPI and libvirt might have some overlap though.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c42cbda114686f75e8e682991e8426a3083f8e75","unresolved":false,"context_lines":[{"line_number":156,"context_line":"If, however, the inventory of a particular host contains keys that the running"},{"line_number":157,"context_line":"driver doesn\u0027t understand, it\u0027s likely to be an operator oversight. Therefore,"},{"line_number":158,"context_line":"it is *recommended* that each driver log a warning if it sees an unexpected"},{"line_number":159,"context_line":"key."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The ``identification`` section is required, and must contain at least one of"},{"line_number":162,"context_line":"the above keys."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_d5e1419d","line":159,"updated":"2018-09-13 17:49:50.000000000","message":"log a warning at startup ? FWIW, in https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/vgpu-rocky.html some things can raise an exception hence preventing the compute service to start.\n\nHere, I\u0027d really like to see which cases you\u0027d like to see as hard failures for nova to start.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":156,"context_line":"If, however, the inventory of a particular host contains keys that the running"},{"line_number":157,"context_line":"driver doesn\u0027t understand, it\u0027s likely to be an operator oversight. Therefore,"},{"line_number":158,"context_line":"it is *recommended* that each driver log a warning if it sees an unexpected"},{"line_number":159,"context_line":"key."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The ``identification`` section is required, and must contain at least one of"},{"line_number":162,"context_line":"the above keys."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_f98a4863","line":159,"in_reply_to":"3f79a3b5_d5e1419d","updated":"2018-11-02 10:56:38.000000000","message":"Yeah, die die die. This is likely a deployment snafu and operators should be alerted to the brokeness of their tooling. You don\u0027t know what else it has screwed up.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c42cbda114686f75e8e682991e8426a3083f8e75","unresolved":false,"context_lines":[{"line_number":208,"context_line":".. note:: **Future:** We may be able to get smarter about dynamically"},{"line_number":209,"context_line":"          defaulting the resource class based on inspecting the device"},{"line_number":210,"context_line":"          metadata. For now, we have to rely on the author of the config file"},{"line_number":211,"context_line":"          to tell us what kind of device we\u0027re looking at."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"traits"},{"line_number":214,"context_line":"~~~~~~"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_75eaad74","line":211,"updated":"2018-09-13 17:49:50.000000000","message":"what if we mess up some standard trait that is not existing ?","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c42cbda114686f75e8e682991e8426a3083f8e75","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":".. note:: As the generated traits are namespaced, \"conflict\" means that a user"},{"line_number":233,"context_line":"          provides a trait in the driver\u0027s namespace."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Placement Model"},{"line_number":237,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_9592e9fb","line":234,"updated":"2018-09-13 17:49:50.000000000","message":"FWIW, the spec is pretty huge already, so I\u0027d be in favor of decoupling the inventory modeling to the placement reporting as two different specs.","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c713cad1515e654b00ac97e8284888fccef71ded","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":".. note:: As the generated traits are namespaced, \"conflict\" means that a user"},{"line_number":233,"context_line":"          provides a trait in the driver\u0027s namespace."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Placement Model"},{"line_number":237,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_c3a05939","line":234,"in_reply_to":"3f79a3b5_9592e9fb","updated":"2018-10-12 13:48:22.000000000","message":"++","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7396cd816b79c07f7b83668e46859808e0439fb9","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":".. note:: As the generated traits are namespaced, \"conflict\" means that a user"},{"line_number":233,"context_line":"          provides a trait in the driver\u0027s namespace."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Placement Model"},{"line_number":237,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_f19f9bb0","line":234,"in_reply_to":"3f79a3b5_c3a05939","updated":"2018-10-22 22:13:07.000000000","message":"I\u0027ve proposed a new spec for just the provider config file format [1].  It is is derived from this one as well as Jay’s Rocky provider-config-file proposal [2], but differs in several substantive ways.\n\n[1] https://review.openstack.org/#/c/612497/\n[2] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8243ab5daed7866f778946b6b34f3da5e5f58acc","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":".. note:: As the generated traits are namespaced, \"conflict\" means that a user"},{"line_number":233,"context_line":"          provides a trait in the driver\u0027s namespace."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Placement Model"},{"line_number":237,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3f79a3b5_59d1fc59","line":234,"in_reply_to":"3f79a3b5_f19f9bb0","updated":"2018-11-02 10:56:38.000000000","message":"I got this far down before realizing much of what I\u0027d reviewed above has been moved and is therefore no longer relevant here. Could you WIP this, Eric?","commit_id":"496054bbfb7dd34e7c001058df8c521971544854"}],"specs/stein/approved/pci-device-placement.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3a456c943680685fb44cd8041986e2b74b4cf4d4","unresolved":false,"context_lines":[{"line_number":51,"context_line":"Proposed change"},{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Device Identification and Whitelisting"},{"line_number":55,"context_line":"--------------------------------------"},{"line_number":56,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":57,"context_line":"passthrough of devices by way of a YAML file per compute host."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_3a8a8bbe","line":54,"range":{"start_line":54,"start_character":0,"end_line":54,"end_character":38},"updated":"2018-08-13 13:41:05.000000000","message":"the coupleing of capablities and whitelisthing is less of a issue in yaml however i may be worth decopleing the resource class and traits sections from the rest.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"916c255e6284b7ca124450fe606da1cd50609c96","unresolved":false,"context_lines":[{"line_number":51,"context_line":"Proposed change"},{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Device Identification and Whitelisting"},{"line_number":55,"context_line":"--------------------------------------"},{"line_number":56,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":57,"context_line":"passthrough of devices by way of a YAML file per compute host."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_817476d0","line":54,"range":{"start_line":54,"start_character":0,"end_line":54,"end_character":38},"in_reply_to":"3f79a3b5_2cc1e0e5","updated":"2018-08-14 19:47:54.000000000","message":"I like several things about the suggestion in the etherpad. But my concern is that it is attempting to solve the whole world right out of the gate, and is thus more complicated than it needs to be. The schema described in this spec is simple and easy to extend as we add support for more things (other virt drivers, different device types, etc.)","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"b277888f482f7a8de27347f709f86a5603565af4","unresolved":false,"context_lines":[{"line_number":51,"context_line":"Proposed change"},{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Device Identification and Whitelisting"},{"line_number":55,"context_line":"--------------------------------------"},{"line_number":56,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":57,"context_line":"passthrough of devices by way of a YAML file per compute host."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_a3a7560b","line":54,"range":{"start_line":54,"start_character":0,"end_line":54,"end_character":38},"in_reply_to":"3f79a3b5_3a8a8bbe","updated":"2018-08-13 17:13:35.000000000","message":"So, for example, would you propose to structure the yaml as follows? If yes, this looks much more complicated. What would be the benefit?\n\n1. title/alias\n   - identification (no RC nor traits)\n   ... \u003cmore titles/aliases\u003e\n2. Resource Classes\n   - title/alias\n     - \u003cRC\u003e\n3. Traits\n   - title/alias\n     - \u003ctrait\u003e","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"a4fdbf33035593e96c75442988add97359cac619","unresolved":false,"context_lines":[{"line_number":51,"context_line":"Proposed change"},{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Device Identification and Whitelisting"},{"line_number":55,"context_line":"--------------------------------------"},{"line_number":56,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":57,"context_line":"passthrough of devices by way of a YAML file per compute host."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_5048582b","line":54,"range":{"start_line":54,"start_character":0,"end_line":54,"end_character":38},"in_reply_to":"3f79a3b5_817476d0","updated":"2018-08-15 16:59:52.000000000","message":"In efried\u0027s spirit, I don\u0027t think the decoupling provided by the etherpad suggestion outweighs the extra complication. One very good thing are the device pools, as it may answer the question of creating RPs for every device vs aggregating the inventories of similar devices. But this format can be extended to include that.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":51,"context_line":"Proposed change"},{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Device Identification and Whitelisting"},{"line_number":55,"context_line":"--------------------------------------"},{"line_number":56,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":57,"context_line":"passthrough of devices by way of a YAML file per compute host."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_d5a9dd7b","line":54,"range":{"start_line":54,"start_character":0,"end_line":54,"end_character":38},"in_reply_to":"3f79a3b5_a3a7560b","updated":"2018-08-13 23:31:30.000000000","message":"Hm, yes, I remember there being a lot of vitriol over the combined whitelisting and \"metadata\" that happens in the legacy PCI code.\n\nHaving thought through the design enough to write it up and start coding it, I\u0027ve come to believe that it\u0027s not a bad thing in and of itself - that the awkwardness and poor comprehensibility/usability mainly stems from a) trying to cram this level of detail into an oslo.config option; and b) wildcarding, which can make it hard to reason about which devices match, at a glance. (The latter is one reason I thought we should fail if more than one stanza matches the same device.)","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f643fd1372bb677c576c816c0ff3179978e67637","unresolved":false,"context_lines":[{"line_number":51,"context_line":"Proposed change"},{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Device Identification and Whitelisting"},{"line_number":55,"context_line":"--------------------------------------"},{"line_number":56,"context_line":"The administrator can identify and allow (explicitly) or deny (by omission)"},{"line_number":57,"context_line":"passthrough of devices by way of a YAML file per compute host."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_2cc1e0e5","line":54,"range":{"start_line":54,"start_character":0,"end_line":54,"end_character":38},"in_reply_to":"3f79a3b5_d5a9dd7b","updated":"2018-08-14 15:44:55.000000000","message":"i wrote up a quick mock of what it would look like here\nhttps://etherpad.openstack.org/p/generic-device-schema","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3a456c943680685fb44cd8041986e2b74b4cf4d4","unresolved":false,"context_lines":[{"line_number":61,"context_line":"          specification for particular device types by vendor/product ID, which"},{"line_number":62,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"The path to the config will be hardcoded as ``/etc/nova/inventory.yaml``."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"The file shall contain paragraphs, each of which will:"},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_a39bdd70","line":64,"range":{"start_line":64,"start_character":0,"end_line":64,"end_character":73},"updated":"2018-08-13 13:41:05.000000000","message":"no this is not an option in all containerized environments.\n\nit can default to that path but it cannont be hardcoded.\nwe should simply have a config option in the default section of the nova.conf to say were the config is.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"b277888f482f7a8de27347f709f86a5603565af4","unresolved":false,"context_lines":[{"line_number":61,"context_line":"          specification for particular device types by vendor/product ID, which"},{"line_number":62,"context_line":"          could then be overridden (or not) by the files on the compute nodes."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"The path to the config will be hardcoded as ``/etc/nova/inventory.yaml``."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"The file shall contain paragraphs, each of which will:"},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_03bdea00","line":64,"range":{"start_line":64,"start_character":0,"end_line":64,"end_character":73},"in_reply_to":"3f79a3b5_a39bdd70","updated":"2018-08-13 17:13:35.000000000","message":"ack","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":71,"context_line":"  around supporting explicit denials."},{"line_number":72,"context_line":"* Name the resource class to associate with the resource provider inventory unit"},{"line_number":73,"context_line":"  by which the device will be exposed in the driver. If not specified,"},{"line_number":74,"context_line":"  ``CUSTOM_PCI_DEVICE`` is used. See `resource_class`_."},{"line_number":75,"context_line":"* List traits to include on the resource provider. See `traits`_."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"A formal schema will be implemented."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_9507e582","line":74,"range":{"start_line":74,"start_character":4,"end_line":74,"end_character":21},"updated":"2018-08-13 23:31:30.000000000","message":"There\u0027s an existing standard resource class called PCI_DEVICE [1]. Use that.\n\n[1] https://github.com/openstack/nova/blob/afe4512bf66c89a061b1a7ccd3e7ac8e3b1b284d/nova/rc_fields.py#L35","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"1644c8b5a9de29af3fcf7b6afab75c4cc880fa52","unresolved":false,"context_lines":[{"line_number":71,"context_line":"  around supporting explicit denials."},{"line_number":72,"context_line":"* Name the resource class to associate with the resource provider inventory unit"},{"line_number":73,"context_line":"  by which the device will be exposed in the driver. If not specified,"},{"line_number":74,"context_line":"  ``CUSTOM_PCI_DEVICE`` is used. See `resource_class`_."},{"line_number":75,"context_line":"* List traits to include on the resource provider. See `traits`_."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"A formal schema will be implemented."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_a753c938","line":74,"range":{"start_line":74,"start_character":4,"end_line":74,"end_character":21},"in_reply_to":"3f79a3b5_9507e582","updated":"2018-08-14 17:05:54.000000000","message":"ok","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3a456c943680685fb44cd8041986e2b74b4cf4d4","unresolved":false,"context_lines":[{"line_number":92,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":" YAML key          lspci tag             Description"},{"line_number":94,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":95,"context_line":" pci_address       Slot                  [\\x{4}:]\\x{2}:\\x{2}.\\x{1} ([4:]2:2.1 lowercase hex digits)"},{"line_number":96,"context_line":" vendor_id         Vendor                \\x{4} (4 lowercase hex digits)"},{"line_number":97,"context_line":" device_id         Device                \\x{4}            \""},{"line_number":98,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_6852843d","line":95,"range":{"start_line":95,"start_character":1,"end_line":95,"end_character":99},"updated":"2018-08-13 13:41:05.000000000","message":"with powervm the pci_address is not exposed via the hyperviors and a uuid is retruned instead. \n\ni would suggest  changing this to address\nand adding a address_type field that is either \"DBDF\"(domain:bus:device:fucntion) or \"UUID\"\n\nin both cases if this is to replace the current pci whitelist\nyou wouls also likelyneed to supprot regex or wildcard support.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":92,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":" YAML key          lspci tag             Description"},{"line_number":94,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":95,"context_line":" pci_address       Slot                  [\\x{4}:]\\x{2}:\\x{2}.\\x{1} ([4:]2:2.1 lowercase hex digits)"},{"line_number":96,"context_line":" vendor_id         Vendor                \\x{4} (4 lowercase hex digits)"},{"line_number":97,"context_line":" device_id         Device                \\x{4}            \""},{"line_number":98,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_d5a8fd20","line":95,"range":{"start_line":95,"start_character":1,"end_line":95,"end_character":99},"in_reply_to":"3f79a3b5_43a442a6","updated":"2018-08-13 23:31:30.000000000","message":"\u003e with powervm the pci_address is not exposed via the hyperviors and\n \u003e a uuid is retruned instead.\n\nIt\u0027s not a UUID. The DRC index is a 32-bit integer, and the DRC name (location code) is a string of obscure and proprietary format.\n\n \u003e i would suggest  changing this to address\n \u003e and adding a address_type field\n\nI don\u0027t think this is necessary - see below.\n\n \u003e in both cases if this is to replace the current pci whitelist\n \u003e you wouls also likelyneed to supprot regex or wildcard support.\n\nIf you do support something like this, please only do it for the PCI address field, for which I understand the need for such support. See below.\n\n \u003e However the inventory spec should be\n \u003e more general and not depend on the particular driver, so we can\n \u003e include options that only make sense in one driver.\n\nThis seems like a contradictory statement. More below.\n\n \u003e each driver\n \u003e will be free to ignore the keys that don\u0027t make sense.\n\nTHIS. The responsibility for a) discovering which devices exist on the system; b) parsing the inventory.yaml file; c) intersecting the two to produce a filtered list of allowed devices; and d) managing the placement artifacts (providers, inventories, traits, etc.) for those devices MUST BE ON THE VIRT DRIVER. The major pain point for non-libvirt today is the fact that so much of that logic lives in nova outside of the virt driver.\n\nThis effort in Nova cannot be libvirt-specific, or we\u0027ll end up right back where we are today. Since libvirt and PowerVM are pretty far apart on some of these issues, and since PowerVM is already implementing code around this, a design that satisfies both will hopefully also (be extensible to) satisfy other players.\n\n \u003e efried\u0027s original spec includes the keys \"drc_name\" and\n \u003e \"drc_index\". Are you referring to the \"drc_name\"?\n \u003e I could add them (and sub{vendor,product}_id, revision_id, class)\n \u003e in parallel.\n\nYou should include the following here regardless. They\u0027re common to both libvirt and PowerVM.\n\n subsys_vendor_id  SVendor\n subsys_device_id  SDevice\n class             Class\n revision_id       Rev\n\nAs for the unique ones ([drc_index, drc_name] vs. [pci_address]) you could include them all; but at least state that fields for other drivers can be added to the schema later and that fields that don\u0027t make sense to a given driver can be ignored by that driver (or, really, treated however the driver chooses - perhaps PowerVM wants to throw an error if it sees a PCI address).","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f643fd1372bb677c576c816c0ff3179978e67637","unresolved":false,"context_lines":[{"line_number":92,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":" YAML key          lspci tag             Description"},{"line_number":94,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":95,"context_line":" pci_address       Slot                  [\\x{4}:]\\x{2}:\\x{2}.\\x{1} ([4:]2:2.1 lowercase hex digits)"},{"line_number":96,"context_line":" vendor_id         Vendor                \\x{4} (4 lowercase hex digits)"},{"line_number":97,"context_line":" device_id         Device                \\x{4}            \""},{"line_number":98,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7711f103","line":95,"range":{"start_line":95,"start_character":1,"end_line":95,"end_character":99},"in_reply_to":"3f79a3b5_43a442a6","updated":"2018-08-14 15:44:55.000000000","message":"regarding the whilecard/regex support my assumtion is that this would be a replacement for the current pcie whitelist if so then would we not need to have parity and a migration path for does already using the whitelist.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"b277888f482f7a8de27347f709f86a5603565af4","unresolved":false,"context_lines":[{"line_number":92,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":" YAML key          lspci tag             Description"},{"line_number":94,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":95,"context_line":" pci_address       Slot                  [\\x{4}:]\\x{2}:\\x{2}.\\x{1} ([4:]2:2.1 lowercase hex digits)"},{"line_number":96,"context_line":" vendor_id         Vendor                \\x{4} (4 lowercase hex digits)"},{"line_number":97,"context_line":" device_id         Device                \\x{4}            \""},{"line_number":98,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_43a442a6","line":95,"range":{"start_line":95,"start_character":1,"end_line":95,"end_character":99},"in_reply_to":"3f79a3b5_6852843d","updated":"2018-08-13 17:13:35.000000000","message":"I have no experience with powervm, so I\u0027m focusing the implementation on libvirt. However the inventory spec should be more general and not depend on the particular driver, so we can include options that only make sense in one driver. I\u0027ll reword this part to be more general (not libvirt-specific) and each driver will be free to ignore the keys that don\u0027t make sense.\n\nefried\u0027s original spec includes the keys \"drc_name\" and \"drc_index\". Are you referring to the \"drc_name\"?\nI could add them (and sub{vendor,product}_id, revision_id, class) in parallel.\n\nI\u0027ll add wildcard support as a stretch goal.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"916c255e6284b7ca124450fe606da1cd50609c96","unresolved":false,"context_lines":[{"line_number":92,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":" YAML key          lspci tag             Description"},{"line_number":94,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":95,"context_line":" pci_address       Slot                  [\\x{4}:]\\x{2}:\\x{2}.\\x{1} ([4:]2:2.1 lowercase hex digits)"},{"line_number":96,"context_line":" vendor_id         Vendor                \\x{4} (4 lowercase hex digits)"},{"line_number":97,"context_line":" device_id         Device                \\x{4}            \""},{"line_number":98,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_fe1f0769","line":95,"range":{"start_line":95,"start_character":1,"end_line":95,"end_character":99},"in_reply_to":"3f79a3b5_7711f103","updated":"2018-08-14 19:47:54.000000000","message":"The migration path is presumably to support both for a couple of releases while we deprecate [pci]passthrough_whitelist and then remove it entirely. I don\u0027t see the need to support identical syntax or semantics as long as we support the necessary use cases, do you?","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"a4fdbf33035593e96c75442988add97359cac619","unresolved":false,"context_lines":[{"line_number":92,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":" YAML key          lspci tag             Description"},{"line_number":94,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":95,"context_line":" pci_address       Slot                  [\\x{4}:]\\x{2}:\\x{2}.\\x{1} ([4:]2:2.1 lowercase hex digits)"},{"line_number":96,"context_line":" vendor_id         Vendor                \\x{4} (4 lowercase hex digits)"},{"line_number":97,"context_line":" device_id         Device                \\x{4}            \""},{"line_number":98,"context_line":" \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_30fb5cc1","line":95,"range":{"start_line":95,"start_character":1,"end_line":95,"end_character":99},"in_reply_to":"3f79a3b5_fe1f0769","updated":"2018-08-15 16:59:52.000000000","message":"I don\u0027t either.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":113,"context_line":"  Rev:  a1"},{"line_number":114,"context_line":"  NUMANode: 0"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":".. note:: Although lspci provides much more information, libvirt doesn\u0027t"},{"line_number":117,"context_line":"          reveal all of it to Nova. The YAML keys are therefore limited"},{"line_number":118,"context_line":"          to the information available to Nova from libvirt."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"The ``identification`` section is required, and must contain at least one of"},{"line_number":121,"context_line":"the above keys."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_954da59b","line":118,"range":{"start_line":116,"start_character":10,"end_line":118,"end_character":60},"updated":"2018-08-13 23:31:30.000000000","message":"oh, are SVendor, SDevice, Class, and Rev among the fields not revealed to Nova from libvirt?","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"1644c8b5a9de29af3fcf7b6afab75c4cc880fa52","unresolved":false,"context_lines":[{"line_number":113,"context_line":"  Rev:  a1"},{"line_number":114,"context_line":"  NUMANode: 0"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":".. note:: Although lspci provides much more information, libvirt doesn\u0027t"},{"line_number":117,"context_line":"          reveal all of it to Nova. The YAML keys are therefore limited"},{"line_number":118,"context_line":"          to the information available to Nova from libvirt."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"The ``identification`` section is required, and must contain at least one of"},{"line_number":121,"context_line":"the above keys."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_c73e05c0","line":118,"range":{"start_line":116,"start_character":10,"end_line":118,"end_character":60},"in_reply_to":"3f79a3b5_954da59b","updated":"2018-08-14 17:05:54.000000000","message":"yes, but if they are useful to powervm, I\u0027ll add them back, including drc*","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":124,"context_line":"logic."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"allow"},{"line_number":127,"context_line":"~~~~"},{"line_number":128,"context_line":".. note:: The ``allow`` section will not be supported initially, but is"},{"line_number":129,"context_line":"          documented here because we thought through what it should look like."},{"line_number":130,"context_line":"          In the initial implementation, any device encompassed by a paragraph"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_b552213a","line":127,"updated":"2018-08-13 23:31:30.000000000","message":"~","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":160,"context_line":"If ``allow`` is omitted or ``true``, an optional ``resource_class`` key is"},{"line_number":161,"context_line":"supported. Its string value allows the author to designate the resource class"},{"line_number":162,"context_line":"to be used for the inventory unit representing the device on the resource"},{"line_number":163,"context_line":"provider. If omitted, ``CUSTOM_PCI_DEVICE`` will be used as the default."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":".. note:: Should we enforce a prefix of \"CUSTOM_\" for user-provided values ?"},{"line_number":166,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_15619505","line":163,"range":{"start_line":163,"start_character":24,"end_line":163,"end_character":41},"updated":"2018-08-13 23:31:30.000000000","message":"PCI_DEVICE (see above)","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":162,"context_line":"to be used for the inventory unit representing the device on the resource"},{"line_number":163,"context_line":"provider. If omitted, ``CUSTOM_PCI_DEVICE`` will be used as the default."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":".. note:: Should we enforce a prefix of \"CUSTOM_\" for user-provided values ?"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":".. note:: **Future:** We may be able to get smarter about dynamically"},{"line_number":168,"context_line":"          defaulting the resource class based on inspecting the device"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_350cd13f","line":165,"range":{"start_line":165,"start_character":10,"end_line":165,"end_character":76},"updated":"2018-08-13 23:31:30.000000000","message":"No. They need to be able to use standard classes. I would expect us to be introducing new standard resource classes (e.g. GPU, FPGA, SRIOV_NIC, ...) as part of this effort, and moving forward. If we restrict the schema at this stage, we\u0027ll have to change it to allow those standard classes, which may be painful.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"1644c8b5a9de29af3fcf7b6afab75c4cc880fa52","unresolved":false,"context_lines":[{"line_number":162,"context_line":"to be used for the inventory unit representing the device on the resource"},{"line_number":163,"context_line":"provider. If omitted, ``CUSTOM_PCI_DEVICE`` will be used as the default."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":".. note:: Should we enforce a prefix of \"CUSTOM_\" for user-provided values ?"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":".. note:: **Future:** We may be able to get smarter about dynamically"},{"line_number":168,"context_line":"          defaulting the resource class based on inspecting the device"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_077ddd6c","line":165,"range":{"start_line":165,"start_character":10,"end_line":165,"end_character":76},"in_reply_to":"3f79a3b5_350cd13f","updated":"2018-08-14 17:05:54.000000000","message":"ok","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3a456c943680685fb44cd8041986e2b74b4cf4d4","unresolved":false,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"traits"},{"line_number":173,"context_line":"~~~~~~"},{"line_number":174,"context_line":"If ``allow`` is omitted or ``true``, an optional ``traits`` subsection is"},{"line_number":175,"context_line":"supported. Its value is an array of strings, each of which is the name of a"},{"line_number":176,"context_line":"trait to be added to the resource providers of each device represented by this"},{"line_number":177,"context_line":"paragraph. If the ``traits`` section is included, it must have at least one"},{"line_number":178,"context_line":"value in the list. (if no traits are desired, omit the section)"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"The values must be valid trait names (either standard from ``os-traits`` or"},{"line_number":181,"context_line":"custom, matching ``CUSTOM_[A-Z0-9_]+``)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_630625d1","line":184,"range":{"start_line":174,"start_character":1,"end_line":184,"end_character":33},"updated":"2018-08-13 13:41:05.000000000","message":"we already have the ablitiy to auto detect pcie nic feature\nand actully store them in the pci_devices table in the nova db. we do not currently convert them to tratis but that code existis for the libvirt driver. In several other cases we have information available from the hypervior to dynamically infer traits.\n\ni would suggest reprhase this section as follow\n\nif the traits field is ommited it is defaulted to Auto and \ntraits will be infered form the device autmatically.\n\nif the traits field is present is and is set to a empty list then no tratis will be reported for this device.\n\nif the traits field is preset and contrains a non empty list it will be processed as follows.\n\nif the list is a set of traits then those traits will be used. if the list containts auto and set of tratis prefixed by \"+\" or \"-\" then those traits will be added or removed form the set auto generated from the device.\n\n\nthe last version wiht +/- was something we discussed at the dublin ptg for allowing operators to add or remove traits to compute nodes and i think its equally valid here.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"b277888f482f7a8de27347f709f86a5603565af4","unresolved":false,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"traits"},{"line_number":173,"context_line":"~~~~~~"},{"line_number":174,"context_line":"If ``allow`` is omitted or ``true``, an optional ``traits`` subsection is"},{"line_number":175,"context_line":"supported. Its value is an array of strings, each of which is the name of a"},{"line_number":176,"context_line":"trait to be added to the resource providers of each device represented by this"},{"line_number":177,"context_line":"paragraph. If the ``traits`` section is included, it must have at least one"},{"line_number":178,"context_line":"value in the list. (if no traits are desired, omit the section)"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"The values must be valid trait names (either standard from ``os-traits`` or"},{"line_number":181,"context_line":"custom, matching ``CUSTOM_[A-Z0-9_]+``)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_f4b50233","line":184,"range":{"start_line":174,"start_character":1,"end_line":184,"end_character":33},"in_reply_to":"3f79a3b5_630625d1","updated":"2018-08-13 17:13:35.000000000","message":"ack\nHowever, for devices like GPUs, I checked that the only information the libvirt driver currently knows is the vendor/product id, numa node etc; characteristics which aren\u0027t \"capabilities\". But this should allow the driver to get smarter in the future.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"916c255e6284b7ca124450fe606da1cd50609c96","unresolved":false,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"traits"},{"line_number":173,"context_line":"~~~~~~"},{"line_number":174,"context_line":"If ``allow`` is omitted or ``true``, an optional ``traits`` subsection is"},{"line_number":175,"context_line":"supported. Its value is an array of strings, each of which is the name of a"},{"line_number":176,"context_line":"trait to be added to the resource providers of each device represented by this"},{"line_number":177,"context_line":"paragraph. If the ``traits`` section is included, it must have at least one"},{"line_number":178,"context_line":"value in the list. (if no traits are desired, omit the section)"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"The values must be valid trait names (either standard from ``os-traits`` or"},{"line_number":181,"context_line":"custom, matching ``CUSTOM_[A-Z0-9_]+``)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_01d86678","line":184,"range":{"start_line":174,"start_character":1,"end_line":184,"end_character":33},"in_reply_to":"3f79a3b5_a22f3786","updated":"2018-08-14 19:47:54.000000000","message":"\u003e well we promised operators the ablity to add tratits to resouce\n \u003e providers,\n\nYes, but we also promised we would *not* allow operators to try to \"spoof\" capabilities that don\u0027t really exist by setting traits that we have some way to know are bogus. E.g. if a customer sets HW_CPU_X86_AVX2 when that\u0027s not true, we need to remove it.\n\nSo for example, as kosamara implies, CUSTOM_LIBVIRT_ might be an appropriate prefix; though we might consider making it a bit more precise (e.g. CUSTOM_LIBVIRT_DEVICE_). In the nova-powervm spec, we\u0027re using CUSTOM_POWERVM_IOSLOT_.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"1644c8b5a9de29af3fcf7b6afab75c4cc880fa52","unresolved":false,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"traits"},{"line_number":173,"context_line":"~~~~~~"},{"line_number":174,"context_line":"If ``allow`` is omitted or ``true``, an optional ``traits`` subsection is"},{"line_number":175,"context_line":"supported. Its value is an array of strings, each of which is the name of a"},{"line_number":176,"context_line":"trait to be added to the resource providers of each device represented by this"},{"line_number":177,"context_line":"paragraph. If the ``traits`` section is included, it must have at least one"},{"line_number":178,"context_line":"value in the list. (if no traits are desired, omit the section)"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"The values must be valid trait names (either standard from ``os-traits`` or"},{"line_number":181,"context_line":"custom, matching ``CUSTOM_[A-Z0-9_]+``)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_a22f3786","line":184,"range":{"start_line":174,"start_character":1,"end_line":184,"end_character":33},"in_reply_to":"3f79a3b5_ece8c87c","updated":"2018-08-14 17:05:54.000000000","message":"This is a prefix for driver-generated traits. Eg a libvirt-generated trait could be:\n  CUSTOM_LIBVIRT_TSO\nBut this isn\u0027t part of the YAML spec.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f643fd1372bb677c576c816c0ff3179978e67637","unresolved":false,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"traits"},{"line_number":173,"context_line":"~~~~~~"},{"line_number":174,"context_line":"If ``allow`` is omitted or ``true``, an optional ``traits`` subsection is"},{"line_number":175,"context_line":"supported. Its value is an array of strings, each of which is the name of a"},{"line_number":176,"context_line":"trait to be added to the resource providers of each device represented by this"},{"line_number":177,"context_line":"paragraph. If the ``traits`` section is included, it must have at least one"},{"line_number":178,"context_line":"value in the list. (if no traits are desired, omit the section)"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"The values must be valid trait names (either standard from ``os-traits`` or"},{"line_number":181,"context_line":"custom, matching ``CUSTOM_[A-Z0-9_]+``)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_ece8c87c","line":184,"range":{"start_line":174,"start_character":1,"end_line":184,"end_character":33},"in_reply_to":"3f79a3b5_f0442749","updated":"2018-08-14 15:44:55.000000000","message":"well we promised operators the ablity to add tratits to resouce providers, im not sure if we would need to removed them so a prefix might work. can you provide an examle.\nthe traits they want to add may be standard tratis so i assume you dont mean CUSTOM_","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"traits"},{"line_number":173,"context_line":"~~~~~~"},{"line_number":174,"context_line":"If ``allow`` is omitted or ``true``, an optional ``traits`` subsection is"},{"line_number":175,"context_line":"supported. Its value is an array of strings, each of which is the name of a"},{"line_number":176,"context_line":"trait to be added to the resource providers of each device represented by this"},{"line_number":177,"context_line":"paragraph. If the ``traits`` section is included, it must have at least one"},{"line_number":178,"context_line":"value in the list. (if no traits are desired, omit the section)"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"The values must be valid trait names (either standard from ``os-traits`` or"},{"line_number":181,"context_line":"custom, matching ``CUSTOM_[A-Z0-9_]+``)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_f0442749","line":184,"range":{"start_line":174,"start_character":1,"end_line":184,"end_character":33},"in_reply_to":"3f79a3b5_f4b50233","updated":"2018-08-13 23:31:30.000000000","message":"\u003e we already have the ablitiy to auto detect pcie nic feature\n \u003e and actully store them in the pci_devices table in the nova db. we\n \u003e do not currently convert them to tratis but that code existis for\n \u003e the libvirt driver. In several other cases we have information\n \u003e available from the hypervior to dynamically infer traits.\n\nAgree we should generate traits for attributes we can detect in this manner. However...\n\n \u003e i would suggest reprhase this section as follow\n \u003e \n \u003e if the traits field is ommited it is defaulted to Auto and\n \u003e traits will be infered form the device autmatically.\n \u003e \n \u003e if the traits field is present is and is set to a empty list then\n \u003e no tratis will be reported for this device.\n \u003e \n \u003e if the traits field is preset and contrains a non empty list it\n \u003e will be processed as follows.\n \u003e \n \u003e if the list is a set of traits then those traits will be used. if\n \u003e the list containts auto and set of tratis prefixed by \"+\" or \"-\"\n \u003e then those traits will be added or removed form the set auto\n \u003e generated from the device.\n \u003e \n \u003e \n \u003e the last version wiht +/- was something we discussed at the dublin\n \u003e ptg for allowing operators to add or remove traits to compute nodes\n \u003e and i think its equally valid here.\n\nI remember discussing this, but not agreeing on it.\n\nThe way I would like to see generated vs. specified traits handled is via namespacing. The generated traits have a reserved prefix that flags them as being \"owned\" by the device management code in the virt driver. The driver has the right to (and should) remove any traits with that prefix which are not in the set it detects. And the user is free to specify any traits outside of that namespace. No +/- necessary. And no mechanism to switch off the generated traits (why would you need to do that?).","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3a456c943680685fb44cd8041986e2b74b4cf4d4","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_c3ea99d6","line":185,"updated":"2018-08-13 13:41:05.000000000","message":"for backwards compatiablity you will need to add 2 more fields: alias, physnet\n\nyou could use name for alias but the alias field would allow flavour that contain alias today to still be used.\n\nthe physnet field is used for neutron sriov passhtough and idetifes this pcie nic as attached to the relevent neutron physnet.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f643fd1372bb677c576c816c0ff3179978e67637","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_6ce358a5","line":185,"in_reply_to":"3f79a3b5_106be3b6","updated":"2018-08-14 15:44:55.000000000","message":"i was just trying to map the existing pci whitelist stuff\nbut i agree on physnet being a trait.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"916c255e6284b7ca124450fe606da1cd50609c96","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_c15b4ef3","line":185,"in_reply_to":"3f79a3b5_627cbf82","updated":"2018-08-14 19:47:54.000000000","message":"above what?\n\nand what do you mean by \"existing\"?\n\nI don\u0027t think we have a need to support the existing alias string format if that\u0027s what you mean.\n\nBut the functionality of \"allow the user to specify a string that makes me get one of a particular group of devices on my VM\" is perfectly covered by the ability to add an arbitrary trait.\n\nAre we all talking about the same thing here?","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"1644c8b5a9de29af3fcf7b6afab75c4cc880fa52","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_627cbf82","line":185,"in_reply_to":"3f79a3b5_6ce358a5","updated":"2018-08-14 17:05:54.000000000","message":"and I don\u0027t see any way to make the existing alias work, because of the above","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_106be3b6","line":185,"in_reply_to":"3f79a3b5_6ef045fe","updated":"2018-08-13 23:31:30.000000000","message":"No alias. The function of alias is accounted for by the resource class and traits.\n\nNo physnet. That\u0027s a custom trait, period.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"a4fdbf33035593e96c75442988add97359cac619","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_4a1bcac8","line":185,"in_reply_to":"3f79a3b5_c15b4ef3","updated":"2018-08-15 16:59:52.000000000","message":"I was responding to the attempt at backwards-compatibility with the current flavor syntax of \"pci_passthrough:alias\". I don\u0027t think it\u0027s possible because:\n\n \u003e Existing flavors would not (necessarily) get the correct allocation candidates from Placement.\n \u003e If they are modified to ask for resources, they might as well\n \u003e follow my example in `Flavor Support`_ and turn the alias into an\n \u003e operator-defined trait","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"b277888f482f7a8de27347f709f86a5603565af4","unresolved":false,"context_lines":[{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Traits may be used to indicate any device capability, e.g."},{"line_number":184,"context_line":"(``CUSTOM_CAPABILITY_WHIZBANG``)."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_6ef045fe","line":185,"in_reply_to":"3f79a3b5_c3ea99d6","updated":"2018-08-13 17:13:35.000000000","message":"But these should be traits as well?\n\nEspecially for alias, I don\u0027t see a clean way to make it backwards compatible with the existing flavors. Existing flavors would not (necessarily) get the correct allocation candidates from Placement. If they are modified to ask for resources, they might as well follow my example in `Flavor Support`_ and turn the alias into an operator-defined trait, no?","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3a456c943680685fb44cd8041986e2b74b4cf4d4","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7a3803ed","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"updated":"2018-08-13 13:41:05.000000000","message":"this goes against the intent of placement.\nwhile its true we could model it this way\nthe state intent for placement is fro resouce providers to model pools of a particalra resouce as inventories.\n\nso the expectation is that if you have 4 identical pci devices all with the same vendor id, product id and traits attached to numa node 0 then you would create a single resouce provider in placement.\n\nmodelign each device as a seperate resouce provider in placement would effectivly force placement to do device assignment which is explicitly out of scope.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"a4fdbf33035593e96c75442988add97359cac619","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_c5334413","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"in_reply_to":"3f79a3b5_0131465a","updated":"2018-08-15 16:59:52.000000000","message":"\u003e Meaning two VFs/VGPUs/etc. from the same SRIOV_PF/PGPU/etc.? Once\n \u003e we get to virtual, I *do* expect all of the virtual functions from\n \u003e a single physical function to be represented in a single inventory\n \u003e of multiple units.\n\nYes.\n\n \u003e Yeah, I mean, I get that this *might* work, if you have multiple\n \u003e *truly* identical devices. Which I *guess* is a realistic\n \u003e possibility. It just seems like it\u0027s going to be difficult to\n \u003e figure out, and brittle.\n\nLet\u0027s say there are 4 identical pGPUs with 8 vGPUs each (real GPU servers are like that), tagged with exactly the same traits by the operator. We can\u0027t express anti-affinity if we aggregate their inventories in 1 RP. (here the use case for anti-affinity is QoS, although it\u0027s far-fetched)\nTherefore, a general rule of aggregating devices by identical traits isn\u0027t compatible with this use case.\n\nWhat do you think is more reasonable to propose at this point?","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"916c255e6284b7ca124450fe606da1cd50609c96","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_0131465a","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"in_reply_to":"3f79a3b5_02cb8ba4","updated":"2018-08-14 19:47:54.000000000","message":"\u003e well that gets a little more complicated depending if we are using\n \u003e the numbered resource provider syntax and we have to deal with\n \u003e affinity and anti affinity fo resouce providers.\n\nDepends how we intend to handle (anti-)affinity.\n\n \u003e - (affinity) for requesting 2 resource units from the same\n \u003e *physical device* or\n\nMeaning two VFs/VGPUs/etc. from the same SRIOV_PF/PGPU/etc.? Once we get to virtual, I *do* expect all of the virtual functions from a single physical function to be represented in a single inventory of multiple units.\n\nAffinity use cases like \"same network\" are addressed by traits.\n\nFor affinity use cases like \"same SAN switch port\" are only helped by collating device inventories if the devices in question are truly identical in every other (interesting) way. Otherwise their trait sets will be non-overlapping and it\u0027s truly broken for them to be represented in the same inventory at all. More on this below.\n\nFor affinity use cases where we can\u0027t pool the inventories, we still have placement enablement work to do. We\u0027ve discussed a couple of options here in the past, including using an intermediate child provider with a trait representing the type of grouping (but not the specific group - e.g. CUSTOM_SAN_PORT_GROUPING, not CUSTOM_SAN_PORT_4CF1) and a new option to GET /allocation_candidates like ?same_ancestor_by_trait\u003dCUSTOM_SAN_PORT_GROUPING.\n\n \u003e - (anti-affinity) for requesting 2 SR-IOV VFs from different NICs\n \u003e for HA\n \u003e aggregating would break it.\n\nAgain, the VFs would be collated on a single PF provider.\n\nAgain, NICs on separate networks would have the networks identified by traits.\n\nAnd again, anything beyond that would require the same placement work as identified above.\n\n \u003e It makes sense to me to follow the logic of merging inventories if\n \u003e the device traits are the same, because this leaves it up to the\n \u003e operator to annotate each device with a special trait if he cares\n \u003e to separate them.\n\nYeah, I mean, I get that this *might* work, if you have multiple *truly* identical devices. Which I *guess* is a realistic possibility. It just seems like it\u0027s going to be difficult to figure out, and brittle.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_b0ef8f1c","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"in_reply_to":"3f79a3b5_0e8c317d","updated":"2018-08-13 23:31:30.000000000","message":"Right, this is a contentious point. We decided to do one-provider-per-device in PowerVM because we have actual use cases where customers want to be able to designate a specific device for their (pet) VM.\n\nBut also because, as kosamara implies, it makes it trivial (in fact unnecessary) to backtrace which *specific* device was plugged into your VM based on the placement data. Perhaps it\u0027s possible to think of different devices as being completely interchangeable, but, as kosamara says, you would have to do it based on the union of all the provider information, not just the resource class. And that is a lot harder to do.\n\nAFAICT, assuming our nested resource provider code works as it should, there is no technical downside to doing one provider per resource. The only possible objections are \"aesthetic\" ones. (I\u0027m sure someone will argue otherwise.)","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"1644c8b5a9de29af3fcf7b6afab75c4cc880fa52","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_02cb8ba4","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"in_reply_to":"3f79a3b5_4c20dcac","updated":"2018-08-14 17:05:54.000000000","message":"It makes sense to me to follow the logic of merging inventories if the device traits are the same, because this leaves it up to the operator to annotate each device with a special trait if he cares to separate them.\n\nOTOH, if there is a use case:\n  - (affinity) for requesting 2 resource units from the same *physical device* or\n  - (anti-affinity) for requesting 2 SR-IOV VFs from different NICs for HA\naggregating would break it.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"b277888f482f7a8de27347f709f86a5603565af4","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_0e8c317d","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"in_reply_to":"3f79a3b5_7a3803ed","updated":"2018-08-13 17:13:35.000000000","message":"This sounds like an extra step in the algorithm (`update_provider_tree`_):\n4. Merge (sum/concatenate) the RCs of devices with the same traits into 1 RP inventory.\n\nIn this case would you even care for vendor_id and product_id? I would expect 2 devices with the same traits (maybe none) and different IDs, like 2 different GPU models that the operator doesn\u0027t want to distinguish, to concatenate their RCs (or add them, if same RC) into a single RP inventory.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"04d4b7fb4d7aed137d2b640b1ab4cff53bb2a528","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_dcb1cf45","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"in_reply_to":"3f79a3b5_86a0ef43","updated":"2018-08-16 07:44:06.000000000","message":"\u003e It sounds like you\u0027re now arguing *against* aggregating identical\n \u003e devices.\nI am. My full thought: aggregating sounds like a more concise model and also this reason:\n \u003e Is the only reason a\n \u003e philosophical one, that placement is \"supposed\" to present\n \u003e identical resources in a single inventory?\nAt the same time, Sean identified a use case that would break, and in hindsight I value the use case more than conciseness / philosophical arguments.\n\n \u003e If that\u0027s the only reason pro aggregation, then given how many\n \u003e reasons we have con, I say we don\u0027t do it, at least not yet. If we\n \u003e come up with a good reason - and a good non-awkward design - we can\n \u003e enhance in the future, cool?\nAgreed!","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f643fd1372bb677c576c816c0ff3179978e67637","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_4c20dcac","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"in_reply_to":"3f79a3b5_b0ef8f1c","updated":"2018-08-14 15:44:55.000000000","message":"well that gets a little more complicated depending if we are using the numbered resource provider syntax and we have to deal with affinity and anti affinity fo resouce providers.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"fab60ef6bbdd2a3c81088443d569742421fd5fdb","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Resource Providers"},{"line_number":188,"context_line":"------------------"},{"line_number":189,"context_line":"The libvirt driver will create nested resource providers, one per device,"},{"line_number":190,"context_line":"as children of the compute node provider."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":".. note:: NVlink and similar device interfaces are seen by Linux as a set of"},{"line_number":193,"context_line":"  associated PCI devices. To benefit from these special interfaces, all the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_86a0ef43","line":190,"range":{"start_line":189,"start_character":0,"end_line":190,"end_character":41},"in_reply_to":"3f79a3b5_c5334413","updated":"2018-08-15 21:16:09.000000000","message":"It sounds like you\u0027re now arguing *against* aggregating identical devices.\n\nI still hold that trying to do that *automatically* is going to be excessively complex and brittle.\n\n[Forgive my stream of consciousness dump below. Keeping it around because future me will find today me\u0027s thought process useful. You can skip to [END] without loss.]\n\nBut I think by stealing Sean\u0027s idea of device pools we can make this work. Why don\u0027t we just do it by adding a `device_pool: \u003cname\u003e` field to the rule paragraph? Same device_pool, same resource provider. Then we should come up with a namespacing scheme for the resource provider so that we can still detect and remove ones that have gone away. And if device_pool is omitted, we use a single provider per device.\n\nI think there\u0027s still a danger here in that the operator could pool devices with conflicting generated traits. Perhaps that should be an error.\n\nAnd it also means that specified traits would have to match - and thus be repeated - in all paragraphs for a single pool. Which sucks. So never mind, let\u0027s not do that.\n\n[END]\n\nBut remind me why we care in the first place? Is the only reason a philosophical one, that placement is \"supposed\" to present identical resources in a single inventory?\n\nIf that\u0027s the only reason pro aggregation, then given how many reasons we have con, I say we don\u0027t do it, at least not yet. If we come up with a good reason - and a good non-awkward design - we can enhance in the future, cool?\n\n(BTW, anti-affinity and/or QoS may be farfetched with VGPUs, but certainly not with e.g. SR-IOV VFs, which I hope will eventually be handled through this same mechanism.)","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":198,"context_line":"  This is future work which this spec doesn\u0027t address."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The provider name will be generated as"},{"line_number":201,"context_line":"  ``PCI device %(vendor_id):%(product_id) @%(pci_address)``"},{"line_number":202,"context_line":"e.g. ``PCI device 10de:1b80 @0000:02:00.0``. We shall let the placement service"},{"line_number":203,"context_line":"generate the UUID. This naming scheme allows us to identify the full set of"},{"line_number":204,"context_line":"providers we \"own\". This includes identifying providers we may have created on a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_70433714","line":201,"range":{"start_line":201,"start_character":4,"end_line":201,"end_character":14},"updated":"2018-08-13 23:31:30.000000000","message":"This namespace should be tagged to indicate that nova+libvirt \"owns\" the provider. See expanded discussion at [1].\n\n[1] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst@192","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"1644c8b5a9de29af3fcf7b6afab75c4cc880fa52","unresolved":false,"context_lines":[{"line_number":198,"context_line":"  This is future work which this spec doesn\u0027t address."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"The provider name will be generated as"},{"line_number":201,"context_line":"  ``PCI device %(vendor_id):%(product_id) @%(pci_address)``"},{"line_number":202,"context_line":"e.g. ``PCI device 10de:1b80 @0000:02:00.0``. We shall let the placement service"},{"line_number":203,"context_line":"generate the UUID. This naming scheme allows us to identify the full set of"},{"line_number":204,"context_line":"providers we \"own\". This includes identifying providers we may have created on a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_5d2e4492","line":201,"range":{"start_line":201,"start_character":4,"end_line":201,"end_character":14},"in_reply_to":"3f79a3b5_70433714","updated":"2018-08-14 17:05:54.000000000","message":"agree","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":219,"context_line":"  allocation_ratio: 1.0"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"of the `resource_class`_ specified in the config file for the paragraph"},{"line_number":222,"context_line":"matching this device (``CUSTOM_PCI_DEVICE`` by default)."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":".. note:: **Future:** Some day we will provide SR-IOV VFs, vGPUs, FPGA"},{"line_number":225,"context_line":"          regions/functions, etc. At that point we will conceivably have"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_f04e6736","line":222,"range":{"start_line":222,"start_character":24,"end_line":222,"end_character":41},"updated":"2018-08-13 23:31:30.000000000","message":"PCI_DEVICE","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":231,"context_line":"the ``LibvirtDriver.update_provider_tree`` method. The algorithm will be as"},{"line_number":232,"context_line":"follows:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* Parse the config file."},{"line_number":235,"context_line":"* Discover pci devices (``pci_passthrough_devices`` key of"},{"line_number":236,"context_line":"  ``LibvirtDriver.get_available_resources``, which calls libvirt)."},{"line_number":237,"context_line":"* Merge the config data with the discovered devices to produce a list of"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_500cfbea","line":234,"range":{"start_line":234,"start_character":0,"end_line":234,"end_character":24},"updated":"2018-08-13 23:31:30.000000000","message":"As discussed at [1], we should make the config dynamically reloadable via SIGHUP, like for mutable oslo.config options [2].\n\n[1] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst@246\n[2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"916c255e6284b7ca124450fe606da1cd50609c96","unresolved":false,"context_lines":[{"line_number":231,"context_line":"the ``LibvirtDriver.update_provider_tree`` method. The algorithm will be as"},{"line_number":232,"context_line":"follows:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* Parse the config file."},{"line_number":235,"context_line":"* Discover pci devices (``pci_passthrough_devices`` key of"},{"line_number":236,"context_line":"  ``LibvirtDriver.get_available_resources``, which calls libvirt)."},{"line_number":237,"context_line":"* Merge the config data with the discovered devices to produce a list of"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_61dd9ade","line":234,"range":{"start_line":234,"start_character":0,"end_line":234,"end_character":24},"in_reply_to":"3f79a3b5_076f1dc5","updated":"2018-08-14 19:47:54.000000000","message":"Well, tbc, detecting removed devices needs to be done by prefix, not by diffing the (dict parsed from the) file before and after the SIGHUP. Because we still need to be able to remove obsolete devices on compute service startup (think cold unplug).\n\nFor a device that still has allocations, we\u0027ve agreed on the design point of setting reserved\u003dtotal to disable new allocations; and once usages go to zero we can remove the provider.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f643fd1372bb677c576c816c0ff3179978e67637","unresolved":false,"context_lines":[{"line_number":231,"context_line":"the ``LibvirtDriver.update_provider_tree`` method. The algorithm will be as"},{"line_number":232,"context_line":"follows:"},{"line_number":233,"context_line":""},{"line_number":234,"context_line":"* Parse the config file."},{"line_number":235,"context_line":"* Discover pci devices (``pci_passthrough_devices`` key of"},{"line_number":236,"context_line":"  ``LibvirtDriver.get_available_resources``, which calls libvirt)."},{"line_number":237,"context_line":"* Merge the config data with the discovered devices to produce a list of"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_076f1dc5","line":234,"range":{"start_line":234,"start_character":0,"end_line":234,"end_character":24},"in_reply_to":"3f79a3b5_500cfbea","updated":"2018-08-14 15:44:55.000000000","message":"+1 that sound like a good idea to do right from the start.\nit does make some of the logic a little harder in the case where a device was removed but resouces where in use from that device. but it elimitates periodic jobs to poll the file for changes and means we dont have to restart the agent to make a change.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":243,"context_line":"  from those in the provider tree whose names are prefixed with ``PCI device``"},{"line_number":244,"context_line":"  and delete the resulting \"orphans\"."},{"line_number":245,"context_line":""},{"line_number":246,"context_line":".. note:: Should the config file be parsed on every periodic_task ?"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"This is in addition to the standard ``update_provider_tree`` contract of"},{"line_number":249,"context_line":"ensuring appropriate ``VCPU``, ``MEMORY_MB``, and ``DISK_GB`` resources on the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_10fa03bc","line":246,"range":{"start_line":246,"start_character":0,"end_line":246,"end_character":67},"updated":"2018-08-13 23:31:30.000000000","message":"see above.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":261,"context_line":"  resources:MEMORY_MB\u003d2048"},{"line_number":262,"context_line":"  resources:DISK_GB\u003d100"},{"line_number":263,"context_line":"  resources1:CUSTOM_GPU\u003d1"},{"line_number":264,"context_line":"  traits1:CUSTOM_PCI_VENDOR_ID_10de\u003drequired"},{"line_number":265,"context_line":"  traits1:CUSTOM_PCI_PRODUCT_ID_1b80\u003drequired"},{"line_number":266,"context_line":"  resources2:CUSTOM_GPU\u003d1"},{"line_number":267,"context_line":"  traits2:CUSTOM_PCI_ALIAS_nvP100\u003drequired"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"Notice above the usability of PCI aliases in this scheme."},{"line_number":270,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_d0ffaba8","line":267,"range":{"start_line":264,"start_character":0,"end_line":267,"end_character":42},"updated":"2018-08-13 23:31:30.000000000","message":"These all need to be uppercase (to conform to the schema for traits).\n\nBut great example.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":266,"context_line":"  resources2:CUSTOM_GPU\u003d1"},{"line_number":267,"context_line":"  traits2:CUSTOM_PCI_ALIAS_nvP100\u003drequired"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"Notice above the usability of PCI aliases in this scheme."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Device allocation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_f0fc27b6","line":269,"range":{"start_line":269,"start_character":0,"end_line":269,"end_character":57},"updated":"2018-08-13 23:31:30.000000000","message":"++ very nice","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"a4fdbf33035593e96c75442988add97359cac619","unresolved":false,"context_lines":[{"line_number":266,"context_line":"  resources2:CUSTOM_GPU\u003d1"},{"line_number":267,"context_line":"  traits2:CUSTOM_PCI_ALIAS_nvP100\u003drequired"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"Notice above the usability of PCI aliases in this scheme."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Device allocation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_5992c358","line":269,"range":{"start_line":269,"start_character":0,"end_line":269,"end_character":57},"in_reply_to":"3f79a3b5_a1b65289","updated":"2018-08-15 16:59:52.000000000","message":"exactly, that\u0027s even better usage","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"916c255e6284b7ca124450fe606da1cd50609c96","unresolved":false,"context_lines":[{"line_number":266,"context_line":"  resources2:CUSTOM_GPU\u003d1"},{"line_number":267,"context_line":"  traits2:CUSTOM_PCI_ALIAS_nvP100\u003drequired"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"Notice above the usability of PCI aliases in this scheme."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Device allocation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_a1b65289","line":269,"range":{"start_line":269,"start_character":0,"end_line":269,"end_character":57},"in_reply_to":"3f79a3b5_e7c30188","updated":"2018-08-14 19:47:54.000000000","message":"Traits don\u0027t have to be *just* capabilities. An alias (in the legacy PCI code) is just a tag to group several devices together so they can be specified in a resource request.\n\nI agree it\u0027s closer to a resource class, philosophically. But note that the schema would in fact allow you to do it that way. I.e. come up with a unique custom resource class for each such grouping specify it in your inventory rule for each device you wanted in that grouping.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f643fd1372bb677c576c816c0ff3179978e67637","unresolved":false,"context_lines":[{"line_number":266,"context_line":"  resources2:CUSTOM_GPU\u003d1"},{"line_number":267,"context_line":"  traits2:CUSTOM_PCI_ALIAS_nvP100\u003drequired"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"Notice above the usability of PCI aliases in this scheme."},{"line_number":270,"context_line":""},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Device allocation"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_e7c30188","line":269,"range":{"start_line":269,"start_character":0,"end_line":269,"end_character":57},"in_reply_to":"3f79a3b5_f0fc27b6","updated":"2018-08-14 15:44:55.000000000","message":"a pcie alias is not really a capablity e.g. trait\nits close to a resouce class. at least that what i think if when i hear alas as alase are often things like x520 or GTX1080 and correspond to product names hence resouce_class not trait.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a47148536d776c6cca2b3fe0fbfa632e54ebf8c","unresolved":false,"context_lines":[{"line_number":313,"context_line":"to get the hypervisor\u0027s resources."},{"line_number":314,"context_line":""},{"line_number":315,"context_line":".. note:: During the implementation, we may discover that both of these are"},{"line_number":316,"context_line":"          avoidable."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_d0180b1f","line":316,"updated":"2018-08-13 23:31:30.000000000","message":"Note that in the powervm implementation, we reuse the device information that was already discovered a few LOC earlier in the get_available_resource flow [1]. I would imagine libvirt could do similar.\n\n[1] https://review.openstack.org/#/c/589668/4/nova_powervm/virt/powervm/driver.py@1007","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"fab60ef6bbdd2a3c81088443d569742421fd5fdb","unresolved":false,"context_lines":[{"line_number":313,"context_line":"to get the hypervisor\u0027s resources."},{"line_number":314,"context_line":""},{"line_number":315,"context_line":".. note:: During the implementation, we may discover that both of these are"},{"line_number":316,"context_line":"          avoidable."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_a633ab13","line":316,"in_reply_to":"3f79a3b5_857c6c72","updated":"2018-08-15 21:16:09.000000000","message":"In powervm, host_wrapper is a data object gleaned via a call to the hypervisor. It\u0027s just an arbitrary attribute that we stuff on the driver object itself. If you were to do the same - save whatever you interpret in get_available_resource into a driver attribute - then you could reuse it in update_provider_tree. No method signature changes needed.\n\nThis is assuming get_available_resource is already pulling device information, which I assume it is.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"04d4b7fb4d7aed137d2b640b1ab4cff53bb2a528","unresolved":false,"context_lines":[{"line_number":313,"context_line":"to get the hypervisor\u0027s resources."},{"line_number":314,"context_line":""},{"line_number":315,"context_line":".. note:: During the implementation, we may discover that both of these are"},{"line_number":316,"context_line":"          avoidable."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_1cc3c78a","line":316,"in_reply_to":"3f79a3b5_a633ab13","updated":"2018-08-16 07:44:06.000000000","message":"It is. And yes, but I actually assumed extra driver state to be more harmful than changing method signatures. I\u0027ll keep this note and we can discuss it on the implementation.","commit_id":"41260e1b210ce23fba06e714c769822477362168"},{"author":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"change_message_id":"a4fdbf33035593e96c75442988add97359cac619","unresolved":false,"context_lines":[{"line_number":313,"context_line":"to get the hypervisor\u0027s resources."},{"line_number":314,"context_line":""},{"line_number":315,"context_line":".. note:: During the implementation, we may discover that both of these are"},{"line_number":316,"context_line":"          avoidable."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_857c6c72","line":316,"in_reply_to":"3f79a3b5_d0180b1f","updated":"2018-08-15 16:59:52.000000000","message":"In powervm the information is cached in self.host_wrapper?\nLibvirt\u0027s get_available_resource calls the host wrapper, which\ncalls libvirt, with no caching.\nAFAICT the only way not to refresh is to plumb the device\ninformation through the resource_tracker to update_provider_tree.\nThat would add 1 extra argument to a few methods:\n  - resource_tracker._update\n  - resource_tracker._update_to_placement\n  - driver.update_provider_tree\n\nDo you think it\u0027s worth it?","commit_id":"41260e1b210ce23fba06e714c769822477362168"}]}