)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2a550f10e049314b7660e1f05eb15655eb60551b","unresolved":false,"context_lines":[{"line_number":11,"context_line":"associated story) when requesting affinity (e.g. multiple devices"},{"line_number":12,"context_line":"affined to the same NUMA node, or multiple VFs from PFs on the same NIC)"},{"line_number":13,"context_line":"especially when not requesting resources from the subtree root provider"},{"line_number":14,"context_line":"itself. See for example [1], where HW_NIC_ROOT is glibly named"},{"line_number":15,"context_line":"I_AM_A_NIC."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006059.html"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"bfb3d3c7_1f719b44","line":14,"range":{"start_line":14,"start_character":35,"end_line":14,"end_character":46},"updated":"2019-05-30 17:34:06.000000000","message":"HW_DEVICE_ROOT?\nthe usecase makes sense and the comment on the act change looks fine but maybe we should just add a generic\nHW_DEVICE_ROOT which can be used for any device rather then makeing this nic specific.","commit_id":"2f9154ec11645104b07fcdaa169dd19d27eef673"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c4298dd66da6f52b36991df9cfbabad4c85240b5","unresolved":false,"context_lines":[{"line_number":11,"context_line":"associated story) when requesting affinity (e.g. multiple devices"},{"line_number":12,"context_line":"affined to the same NUMA node, or multiple VFs from PFs on the same NIC)"},{"line_number":13,"context_line":"especially when not requesting resources from the subtree root provider"},{"line_number":14,"context_line":"itself. See for example [1], where HW_NIC_ROOT is glibly named"},{"line_number":15,"context_line":"I_AM_A_NIC."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006059.html"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"bfb3d3c7_31160e4b","line":14,"range":{"start_line":14,"start_character":35,"end_line":14,"end_character":46},"in_reply_to":"bfb3d3c7_1f719b44","updated":"2019-05-30 21:37:25.000000000","message":"Good idea, Sean.\n\nI\u0027m trying to think of a situation where that would be too broad, and would fail to give us affinity as tightly as we need it.\n\nI guess it comes down to: will we ever have a device descended from a device?\n\nPerhaps there will come a day when we need to model\n\n compute\n |\n +--\u003e card\n      |\n      +--\u003e PF (has VF inventory)\n\nwhere both the \u0027card\u0027 and \u0027PF\u0027 providers could be considered HW_DEVICE_ROOTs.\n\nBut I guess we can always add more traits if that becomes an issue. So sure, will change.","commit_id":"2f9154ec11645104b07fcdaa169dd19d27eef673"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"11a33ff8b18db3a85a4f78153862cfaea383b5c7","unresolved":false,"context_lines":[{"line_number":13,"context_line":"requesting resources from the subtree root provider itself. See for"},{"line_number":14,"context_line":"example [2], where HW_DEVICE_ROOT is glibly named I_AM_A_NIC."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"[1] https://review.opendev.org/#/c/662191/"},{"line_number":17,"context_line":"[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006059.html"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Change-Id: If5478e797b7bec2d8ebe78dd959dcf179a2834f4"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"bfb3d3c7_11abca74","line":16,"updated":"2019-05-30 22:06:13.000000000","message":"Shouldn\u0027t there be a depends-on for this then?","commit_id":"87d216d0d6841f5ee74b420f8aea9ea5719e8b33"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2a0e6cfef4f0eed8c38bec792f0b09dd1975f80e","unresolved":false,"context_lines":[{"line_number":13,"context_line":"requesting resources from the subtree root provider itself. See for"},{"line_number":14,"context_line":"example [2], where HW_DEVICE_ROOT is glibly named I_AM_A_NIC."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"[1] https://review.opendev.org/#/c/662191/"},{"line_number":17,"context_line":"[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006059.html"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Change-Id: If5478e797b7bec2d8ebe78dd959dcf179a2834f4"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"bfb3d3c7_31a5ae47","line":16,"in_reply_to":"bfb3d3c7_11abca74","updated":"2019-05-30 22:29:35.000000000","message":"You mean so we don\u0027t merge this patch until the spec merges? Nah, we\u0027ve not been holding to that in Placement (even to the point of merging a whole microversion [1] while the spec (the same spec in fact) was still open).\n\n[1] https://review.opendev.org/#/c/657419/","commit_id":"87d216d0d6841f5ee74b420f8aea9ea5719e8b33"}],"os_traits/hw/device/__init__.py":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0a2f3857a518bd54a6f5679ac2bcc6f6d75e3fb","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    # When a device (e.g. a NIC) supplies multiple physical functions (PFs),"},{"line_number":19,"context_line":"    # each PF should be modeled as a separate resource provider. In such cases,"},{"line_number":20,"context_line":"    # the device itself can be modeled as a parent provider of the PFs and"},{"line_number":21,"context_line":"    # expose this trait so that requests can express affinity requirements. See"},{"line_number":22,"context_line":"    # https://review.opendev.org/#/c/662191/"},{"line_number":23,"context_line":"    \u0027ROOT\u0027,"},{"line_number":24,"context_line":"]"}],"source_content_type":"text/x-python","patch_set":3,"id":"9fb8cfa7_4d341b4b","line":21,"updated":"2019-06-03 11:37:22.000000000","message":"While this is all sounds logical. I have to note that today neutron does not model PFs from the same NIC with a common NIC parent RP. So this trait will not be used today until somebody improves how neutron models PFs from the same NIC.","commit_id":"87d216d0d6841f5ee74b420f8aea9ea5719e8b33"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"823cc804e13605f26b39cb0a1c86d7b81f5b3997","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    # When a device (e.g. a NIC) supplies multiple physical functions (PFs),"},{"line_number":19,"context_line":"    # each PF should be modeled as a separate resource provider. In such cases,"},{"line_number":20,"context_line":"    # the device itself can be modeled as a parent provider of the PFs and"},{"line_number":21,"context_line":"    # expose this trait so that requests can express affinity requirements. See"},{"line_number":22,"context_line":"    # https://review.opendev.org/#/c/662191/"},{"line_number":23,"context_line":"    \u0027ROOT\u0027,"},{"line_number":24,"context_line":"]"}],"source_content_type":"text/x-python","patch_set":3,"id":"9fb8cfa7_b6363fb4","line":21,"in_reply_to":"9fb8cfa7_4d341b4b","updated":"2019-06-03 17:35:07.000000000","message":"Okay, I reduced this patch to just HW_NUMA_ROOT. I\u0027ll propose HW_DEVICE_ROOT separately and we can wait for it to have a use case.","commit_id":"87d216d0d6841f5ee74b420f8aea9ea5719e8b33"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0c7f19a35976371fd950a2be0f1b07351d0c6018","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    # When a device (e.g. a NIC) supplies multiple physical functions (PFs),"},{"line_number":19,"context_line":"    # each PF should be modeled as a separate resource provider. In such cases,"},{"line_number":20,"context_line":"    # the device itself can be modeled as a parent provider of the PFs and"},{"line_number":21,"context_line":"    # expose this trait so that requests can express affinity requirements. See"},{"line_number":22,"context_line":"    # https://review.opendev.org/#/c/662191/"},{"line_number":23,"context_line":"    \u0027ROOT\u0027,"},{"line_number":24,"context_line":"]"}],"source_content_type":"text/x-python","patch_set":3,"id":"9fb8cfa7_f6efd7e6","line":21,"in_reply_to":"9fb8cfa7_b6363fb4","updated":"2019-06-03 17:42:40.000000000","message":"Done via https://review.opendev.org/662811","commit_id":"87d216d0d6841f5ee74b420f8aea9ea5719e8b33"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a109c914c022eabefd1042aeaa37874c6c12aedd","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    # When a device (e.g. a NIC) supplies multiple physical functions (PFs),"},{"line_number":19,"context_line":"    # each PF should be modeled as a separate resource provider. In such cases,"},{"line_number":20,"context_line":"    # the device itself can be modeled as a parent provider of the PFs and"},{"line_number":21,"context_line":"    # expose this trait so that requests can express affinity requirements. See"},{"line_number":22,"context_line":"    # https://review.opendev.org/#/c/662191/"},{"line_number":23,"context_line":"    \u0027ROOT\u0027,"},{"line_number":24,"context_line":"]"}],"source_content_type":"text/x-python","patch_set":3,"id":"9fb8cfa7_c0451b19","line":21,"in_reply_to":"9fb8cfa7_cc047ac9","updated":"2019-06-04 11:21:36.000000000","message":"i should point out that this would have been used by nova when we start rpresenting PF and vf for sriov in placmeent not by neutron but ok","commit_id":"87d216d0d6841f5ee74b420f8aea9ea5719e8b33"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"46efa153abd29b6a8dfc50822c5436ffc56a35f9","unresolved":false,"context_lines":[{"line_number":18,"context_line":"    # When a device (e.g. a NIC) supplies multiple physical functions (PFs),"},{"line_number":19,"context_line":"    # each PF should be modeled as a separate resource provider. In such cases,"},{"line_number":20,"context_line":"    # the device itself can be modeled as a parent provider of the PFs and"},{"line_number":21,"context_line":"    # expose this trait so that requests can express affinity requirements. See"},{"line_number":22,"context_line":"    # https://review.opendev.org/#/c/662191/"},{"line_number":23,"context_line":"    \u0027ROOT\u0027,"},{"line_number":24,"context_line":"]"}],"source_content_type":"text/x-python","patch_set":3,"id":"9fb8cfa7_cc047ac9","line":21,"in_reply_to":"9fb8cfa7_f6efd7e6","updated":"2019-06-04 08:10:57.000000000","message":"WFM. Thanks Eric.","commit_id":"87d216d0d6841f5ee74b420f8aea9ea5719e8b33"}]}