)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ed5a43bc168c5040a3cf5adb7f7379f9b237e3a9","unresolved":false,"context_lines":[{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* arbitrary group suffixes"},{"line_number":27,"context_line":"* same_subtree query parameter"},{"line_number":28,"context_line":"* resourceless request groups"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bfb3d3c7_430deae5","line":28,"updated":"2019-05-31 16:03:41.000000000","message":"ack which would have helped me avoid a hack here:\n\nhttps://review.opendev.org/#/c/645316/\n\nand here:\n\nhttps://review.opendev.org/#/c/656885/","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"}],"doc/source/specs/train/approved/2005575-nested-magic-1.rst":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bf97f63188e536bfb1e0ae75cea2d902b121c6f4","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  like ``resources_PORT...``; we want to allow lowercase because openstack"},{"line_number":57,"context_line":"  consumers tend to use lowercase UUIDs and this makes them not have to convert"},{"line_number":58,"context_line":"  them. Placement will use the string in the form it is given and transform"},{"line_number":59,"context_line":"  it neither on input nor output. If the form does match constraints a ``400``"},{"line_number":60,"context_line":"  response will be returned."},{"line_number":61,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":62,"context_line":"* **Alternative** Uppercase only so we don\u0027t have to worry about case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_0316214a","line":59,"range":{"start_line":59,"start_character":46,"end_line":59,"end_character":56},"updated":"2019-05-30 22:41:04.000000000","message":"does not match","commit_id":"ca6988afecedd80a0177237aef47c806bbd5efb7"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ed5a43bc168c5040a3cf5adb7f7379f9b237e3a9","unresolved":false,"context_lines":[{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [*]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_83be82d2","line":17,"range":{"start_line":17,"start_character":22,"end_line":17,"end_character":26},"updated":"2019-05-31 16:03:41.000000000","message":"Is this meant to be a footnote because it doesn\u0027t render properly:\n\nhttp://logs.openstack.org/91/662191/2/check/openstack-tox-docs/97b4324/html/specs/train/approved/2005575-nested-magic-1.html\n\nhttp://docutils.sourceforge.net/docs/user/rst/quickref.html#footnotes","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"25f916fd166f53a4726682c5a14f53bbc0e42e66","unresolved":false,"context_lines":[{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [*]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_d63f4ab3","line":17,"range":{"start_line":17,"start_character":22,"end_line":17,"end_character":26},"in_reply_to":"9fb8cfa7_5bd14357","updated":"2019-05-31 20:10:37.000000000","message":"Erm, I declare that a theme issue. Would you feel better if it was a superscript \u00271\u0027 with an underline?","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"1eca248251858794c1b3e4473e760f9d9e9d5961","unresolved":false,"context_lines":[{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [*]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_5bd14357","line":17,"range":{"start_line":17,"start_character":22,"end_line":17,"end_character":26},"in_reply_to":"9fb8cfa7_ca93235c","updated":"2019-05-31 19:32:40.000000000","message":"I\u0027m not saying it\u0027s not working, it just looks weird as a * with an underscore rather than a real footnote (within the section, whatever).","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0f058a8a4ca26d21415cd72ae0edb68f3ec64749","unresolved":false,"context_lines":[{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [*]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_d6874ab6","line":17,"range":{"start_line":17,"start_character":22,"end_line":17,"end_character":26},"in_reply_to":"9fb8cfa7_d63f4ab3","updated":"2019-05-31 20:55:42.000000000","message":"I changed it to a number, fwiw. It\u0027s still not beautiful, but I think that\u0027s a theme thing.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8140743e2b0bb52c4ee33447f5177df89be7bc6d","unresolved":false,"context_lines":[{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [*]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_ca93235c","line":17,"range":{"start_line":17,"start_character":22,"end_line":17,"end_character":26},"in_reply_to":"bfb3d3c7_83be82d2","updated":"2019-05-31 16:58:02.000000000","message":"It\u0027s working fine for me. (The \"foot\"note is only at the bottom of this section, not at the bottom of the document.)","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ed5a43bc168c5040a3cf5adb7f7379f9b237e3a9","unresolved":false,"context_lines":[{"line_number":67,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""},{"line_number":70,"context_line":"group to \"unspecified\" or \"unsuffixed\", and anywhere we reference \"numbered\""},{"line_number":71,"context_line":"groups we can call them \"suffixed\" or \"granular\" (I think this label is already"},{"line_number":72,"context_line":"used in some places)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"same_subtree"},{"line_number":75,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_032a92d9","line":72,"range":{"start_line":70,"start_character":40,"end_line":72,"end_character":21},"updated":"2019-05-31 16:03:41.000000000","message":"Yup: https://docs.openstack.org/nova/latest/user/flavors.html#extra-specs-numbered-resource-groupings","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c33f4666b39b62ec60f1daae597342bd7cf40507","unresolved":false,"context_lines":[{"line_number":111,"context_line":""},{"line_number":112,"context_line":"a request including::"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":115,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":116,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":117,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"will produce candidates including::"},{"line_number":120,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_ca96c395","line":117,"range":{"start_line":114,"start_character":0,"end_line":117,"end_character":30},"updated":"2019-05-31 16:38:27.000000000","message":"English descriptions of these would be super. Something like:\n\n  Give me 2 vCPUs, 512mb of memory and an FPGA from the same\n  NUMA node.\n\n?\n\nDitto for the rest of the examples below","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0f058a8a4ca26d21415cd72ae0edb68f3ec64749","unresolved":false,"context_lines":[{"line_number":111,"context_line":""},{"line_number":112,"context_line":"a request including::"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":115,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":116,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":117,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"will produce candidates including::"},{"line_number":120,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_1683a206","line":117,"range":{"start_line":114,"start_character":0,"end_line":117,"end_character":30},"in_reply_to":"9fb8cfa7_ca96c395","updated":"2019-05-31 20:55:42.000000000","message":"Good call, done.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c33f4666b39b62ec60f1daae597342bd7cf40507","unresolved":false,"context_lines":[{"line_number":118,"context_line":""},{"line_number":119,"context_line":"will produce candidates including::"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":" - numa0: {VCPU:2, MEMORY_MB:512}, fpga0_0: {FPGA:1}"},{"line_number":122,"context_line":" - numa1: {VCPU:2, MEMORY_MB:512}, fpga1_0: {FPGA:1}"},{"line_number":123,"context_line":" - numa1: {VCPU:2, MEMORY_MB:512}, fpga1_1: {FPGA:1}"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"but *not*::"},{"line_number":126,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_8a620bd8","line":123,"range":{"start_line":121,"start_character":0,"end_line":123,"end_character":52},"updated":"2019-05-31 16:38:27.000000000","message":"These have to be dedented otherwise they\u0027ll render as block comments\n\nLater: I see this is actually a literal block. Odd, but fair.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8140743e2b0bb52c4ee33447f5177df89be7bc6d","unresolved":false,"context_lines":[{"line_number":118,"context_line":""},{"line_number":119,"context_line":"will produce candidates including::"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":" - numa0: {VCPU:2, MEMORY_MB:512}, fpga0_0: {FPGA:1}"},{"line_number":122,"context_line":" - numa1: {VCPU:2, MEMORY_MB:512}, fpga1_0: {FPGA:1}"},{"line_number":123,"context_line":" - numa1: {VCPU:2, MEMORY_MB:512}, fpga1_1: {FPGA:1}"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"but *not*::"},{"line_number":126,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_4a8e5328","line":123,"range":{"start_line":121,"start_character":0,"end_line":123,"end_character":52},"in_reply_to":"9fb8cfa7_8a620bd8","updated":"2019-05-31 16:58:02.000000000","message":"Yes, intentional","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ed5a43bc168c5040a3cf5adb7f7379f9b237e3a9","unresolved":false,"context_lines":[{"line_number":183,"context_line":" # NOTE: there is no resources_NIC_AFFINITY"},{"line_number":184,"context_line":" \u0026required_NIC_AFFINITY\u003dHW_NIC_ROOT"},{"line_number":185,"context_line":" \u0026same_subtree\u003d_VIF_NET1,_VIF_NET2,_NIC_AFFINITY"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"The returned candidates will include::"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":" - pf1_1: {VF:1}, pf1_2: {VF:1}"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_87c8c674","line":186,"updated":"2019-05-31 16:03:41.000000000","message":"Lord have mercy, at what point do we change from query params to a request json body to describe this stuff...","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"30ca6383d431517504052c7e38eb2be9ef04ed64","unresolved":false,"context_lines":[{"line_number":183,"context_line":" # NOTE: there is no resources_NIC_AFFINITY"},{"line_number":184,"context_line":" \u0026required_NIC_AFFINITY\u003dHW_NIC_ROOT"},{"line_number":185,"context_line":" \u0026same_subtree\u003d_VIF_NET1,_VIF_NET2,_NIC_AFFINITY"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"The returned candidates will include::"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":" - pf1_1: {VF:1}, pf1_2: {VF:1}"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_e2e39ea3","line":186,"in_reply_to":"9fb8cfa7_0a985b68","updated":"2019-06-03 10:47:39.000000000","message":"It\u0027s confusing to me why any of you think that a JSON representation of a complex query is going to be any less complex than a query param representation of the same thing; because that\u0027s what it is: a representation of something complex. JSON won\u0027t fix that; it will just move the complexity around.\n\nMy historical resistance on this front has been partially about not putting a body on a GET, but more about resisting the complexity wherever it may lie.\n\nWhen people say \"I can\u0027t express the complicated things I need to express in this limiting form\" my internal response is \"good, that probably means you should take a lesson about what you\u0027re trying to do\"\n\nWhere we end up is that the changes we do make have to pass through a bit of a crucible, and that\u0027s a good thing.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c33f4666b39b62ec60f1daae597342bd7cf40507","unresolved":false,"context_lines":[{"line_number":183,"context_line":" # NOTE: there is no resources_NIC_AFFINITY"},{"line_number":184,"context_line":" \u0026required_NIC_AFFINITY\u003dHW_NIC_ROOT"},{"line_number":185,"context_line":" \u0026same_subtree\u003d_VIF_NET1,_VIF_NET2,_NIC_AFFINITY"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"The returned candidates will include::"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":" - pf1_1: {VF:1}, pf1_2: {VF:1}"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_aab4af36","line":186,"in_reply_to":"9fb8cfa7_87c8c674","updated":"2019-05-31 16:38:27.000000000","message":"+1000. HTTP standards be damned, this is getting slightly crazy","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8140743e2b0bb52c4ee33447f5177df89be7bc6d","unresolved":false,"context_lines":[{"line_number":183,"context_line":" # NOTE: there is no resources_NIC_AFFINITY"},{"line_number":184,"context_line":" \u0026required_NIC_AFFINITY\u003dHW_NIC_ROOT"},{"line_number":185,"context_line":" \u0026same_subtree\u003d_VIF_NET1,_VIF_NET2,_NIC_AFFINITY"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"The returned candidates will include::"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":" - pf1_1: {VF:1}, pf1_2: {VF:1}"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_0a985b68","line":186,"in_reply_to":"9fb8cfa7_aab4af36","updated":"2019-05-31 16:58:02.000000000","message":"We go over this every release, and every release we find a way to do it that doesn\u0027t *force* us to use a JSON request payload, so we punt on it.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8ca87b52426e2861a64181ec8c9b8336d1b7fe40","unresolved":false,"context_lines":[{"line_number":183,"context_line":" # NOTE: there is no resources_NIC_AFFINITY"},{"line_number":184,"context_line":" \u0026required_NIC_AFFINITY\u003dHW_NIC_ROOT"},{"line_number":185,"context_line":" \u0026same_subtree\u003d_VIF_NET1,_VIF_NET2,_NIC_AFFINITY"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"The returned candidates will include::"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":" - pf1_1: {VF:1}, pf1_2: {VF:1}"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_f6583757","line":186,"in_reply_to":"9fb8cfa7_e2e39ea3","updated":"2019-06-03 18:19:05.000000000","message":"\u003e It\u0027s confusing to me why any of you think that a JSON\n \u003e representation of a complex query is going to be any less complex\n \u003e than a query param representation of the same thing; because that\u0027s\n \u003e what it is: a representation of something complex. JSON won\u0027t fix\n \u003e that; it will just move the complexity around.\n\nThis isn\u0027t the point. We* recognize that we\u0027re trying to represent something complex. It\u0027s just harder to do that with a flat dict (querystring) than with a nested one (JSON payload). Especially now that we\u0027re trying to request responses that represent nested things, it seems logical to be able to express the request in a nested form as well.\n\nThat said...\n\n \u003e Where we end up is that the changes we do make have to pass through\n \u003e a bit of a crucible, and that\u0027s a good thing.\n\nThis has proven to be good at forcing us to reduce the complexity of what we\u0027re able to ask for. Which always seems suffocating and restrictive initially, but always seems to result in us implementing only what we need.\n\nSo until we reach a point where the querystring syntax is untenably awkward (I\u0027ll go ahead and define that loosely as \"more than two internal delimiters in the value\" or \"encoding/escaping\", whichever comes first) I\u0027m content to keep conceding to stick with it.\n\n*Those of us in the pro-JSON query camp.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ed5a43bc168c5040a3cf5adb7f7379f9b237e3a9","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":"will return only one candidate::"},{"line_number":239,"context_line":""},{"line_number":240,"context_line":" - pf1: {VF:1}, pf2: {VF:1}"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"whereas the same request with ``group_policy\u003dnone``::"},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_e7cbc26f","line":240,"range":{"start_line":240,"start_character":3,"end_line":240,"end_character":6},"updated":"2019-05-31 16:03:41.000000000","message":"pf1_1 and pf1_2 in this example?","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0f058a8a4ca26d21415cd72ae0edb68f3ec64749","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":"will return only one candidate::"},{"line_number":239,"context_line":""},{"line_number":240,"context_line":" - pf1: {VF:1}, pf2: {VF:1}"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":"whereas the same request with ``group_policy\u003dnone``::"},{"line_number":243,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_3688261e","line":240,"range":{"start_line":240,"start_character":3,"end_line":240,"end_character":6},"in_reply_to":"9fb8cfa7_e7cbc26f","updated":"2019-05-31 20:55:42.000000000","message":"Yup, good catch, fixed.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ed5a43bc168c5040a3cf5adb7f7379f9b237e3a9","unresolved":false,"context_lines":[{"line_number":276,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":279,"context_line":"queries, but it should be negligible, especially since it should be relatively"},{"line_number":280,"context_line":"rare in the wild. However, in this case we may not be able to optimize."},{"line_number":281,"context_line":""},{"line_number":282,"context_line":"Documentation Impact"},{"line_number":283,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_a7c5ca5d","line":280,"range":{"start_line":279,"start_character":37,"end_line":280,"end_character":17},"updated":"2019-05-31 16:03:41.000000000","message":"I\u0027ve already linked a couple of cases where nova could have been using it frequently.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0f058a8a4ca26d21415cd72ae0edb68f3ec64749","unresolved":false,"context_lines":[{"line_number":276,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":279,"context_line":"queries, but it should be negligible, especially since it should be relatively"},{"line_number":280,"context_line":"rare in the wild. However, in this case we may not be able to optimize."},{"line_number":281,"context_line":""},{"line_number":282,"context_line":"Documentation Impact"},{"line_number":283,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_96ab1274","line":280,"range":{"start_line":279,"start_character":37,"end_line":280,"end_character":17},"in_reply_to":"9fb8cfa7_2ab67fdb","updated":"2019-05-31 20:55:42.000000000","message":"Thinking through this and looking at your links actually brought up a pretty important corner case: we need to ignore group_policy for resourceless request groups. Explanation in the \"Interactions\" section in the next PS.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8140743e2b0bb52c4ee33447f5177df89be7bc6d","unresolved":false,"context_lines":[{"line_number":276,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":279,"context_line":"queries, but it should be negligible, especially since it should be relatively"},{"line_number":280,"context_line":"rare in the wild. However, in this case we may not be able to optimize."},{"line_number":281,"context_line":""},{"line_number":282,"context_line":"Documentation Impact"},{"line_number":283,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_2ab67fdb","line":280,"range":{"start_line":279,"start_character":37,"end_line":280,"end_character":17},"in_reply_to":"9fb8cfa7_a7c5ca5d","updated":"2019-05-31 16:58:02.000000000","message":"Interesting, I was thinking of it in terms of \"request groups that don\u0027t have resources in them *and* will be satisfied by resource providers that aren\u0027t providing any resource to the request,\" which *should* be rare in the wild, and doesn\u0027t include the cases you linked.\n\nHowever, I agree that the performance impact noted here might still apply even given the above.\n\nWorth expanding on this a little in the doc.","commit_id":"344aebb5737d0acf7f75e8e4300f8f5297e217b6"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d582b22fb794fbc57d729a04c8cd86a6188b229e","unresolved":false,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"(Merged) code is here: https://review.opendev.org/#/c/657419/"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Granular groups are currently restricted to using integer suffixes. We will"},{"line_number":49,"context_line":"change this so they can be case-sensitive strings up to 64 characters long"},{"line_number":50,"context_line":"comprising alphanumeric (either case), underscore, and hyphen."},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_2128af84","line":48,"updated":"2019-06-04 22:34:01.000000000","message":"Note to self: this is described in the spec for example, \"resources1\", \"required1\", \"resources2\", \"required2\":\n\nhttp://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/granular-resource-requests.html#logical-representation","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d582b22fb794fbc57d729a04c8cd86a6188b229e","unresolved":false,"context_lines":[{"line_number":69,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""},{"line_number":70,"context_line":"group to \"unspecified\" or \"unsuffixed\", and anywhere we reference \"numbered\""},{"line_number":71,"context_line":"groups we can call them \"suffixed\" or \"granular\" (I think this label is already"},{"line_number":72,"context_line":"used in some places)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"same_subtree"},{"line_number":75,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_c138b3d4","line":72,"updated":"2019-06-04 22:34:01.000000000","message":"Not to self: this paragraph is just saying not to use the word \"numbered\" anymore because other suffixes that are not numbers will be allowed, according to this proposal.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d582b22fb794fbc57d729a04c8cd86a6188b229e","unresolved":false,"context_lines":[{"line_number":130,"context_line":" - numa1: {VCPU:2, MEMORY_MB:512}, fpga0_0: {FPGA:1}"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"The ``same_subtree`` query parameter may be repeated. Each grouping is treated"},{"line_number":133,"context_line":"independently."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Anti-affinity"},{"line_number":136,"context_line":"~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_e1a4d70a","line":133,"updated":"2019-06-04 22:34:01.000000000","message":"Good explanation and examples in the same_subtree section.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d582b22fb794fbc57d729a04c8cd86a6188b229e","unresolved":false,"context_lines":[{"line_number":194,"context_line":"but *not*::"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":" - pf1_1: {VF:1}, pf2_2: {VF:1}"},{"line_number":197,"context_line":" - pf2_1: {VF:1}, pf1_2: {VF:1}"},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"Interactions"},{"line_number":200,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_a1dc9f74","line":197,"updated":"2019-06-04 22:34:01.000000000","message":"Good explanation and examples in the resourceless request groups section.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"2ce726147b30713c404a900e175013ab25eb37f7","unresolved":false,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":" - pf1_1: {VF:1}, pf2_2: {VF:1}"},{"line_number":197,"context_line":" - pf2_1: {VF:1}, pf1_2: {VF:1}"},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"Interactions"},{"line_number":200,"context_line":"------------"},{"line_number":201,"context_line":"Some discussion on these can be found in the neighborhood of"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_4de4f2ac","line":198,"updated":"2019-06-05 05:30:27.000000000","message":"Should we show users the allocation request that corresponds to the resourceless request as non resource allocation request?\n\nThat said it helps placement callers to see from which provider the requested traits come from and it looks like it will appear naturally if we bring resource provider information within allocation requests into _merge_candidates, which is needed for same_subtree check? [1]\n\n[1] https://review.opendev.org/#/c/663009/","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"875b43bf62d80aeec5e42bf05eabc4041ace3e28","unresolved":false,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":" - pf1_1: {VF:1}, pf2_2: {VF:1}"},{"line_number":197,"context_line":" - pf2_1: {VF:1}, pf1_2: {VF:1}"},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"Interactions"},{"line_number":200,"context_line":"------------"},{"line_number":201,"context_line":"Some discussion on these can be found in the neighborhood of"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_92844260","line":198,"in_reply_to":"9fb8cfa7_4de4f2ac","updated":"2019-06-05 09:23:03.000000000","message":"I don\u0027t think the resourceless \"allocation\" will show up in the candidate at all, since it doesn\u0027t have any resources. Or are you thinking we should throw an empty dict in there?","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"0e26af0047f254773daeb5d69697c1a1645652b8","unresolved":false,"context_lines":[{"line_number":195,"context_line":""},{"line_number":196,"context_line":" - pf1_1: {VF:1}, pf2_2: {VF:1}"},{"line_number":197,"context_line":" - pf2_1: {VF:1}, pf1_2: {VF:1}"},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"Interactions"},{"line_number":200,"context_line":"------------"},{"line_number":201,"context_line":"Some discussion on these can be found in the neighborhood of"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_50ff9000","line":198,"in_reply_to":"9fb8cfa7_92844260","updated":"2019-06-06 04:29:25.000000000","message":"\u003e it looks like it will appear naturally if we bring resource\n \u003e provider information within allocation requests into\n \u003e _merge_candidates, which is needed for same_subtree check?\n\nNo, this was wrong, ignore me. Sorry for the noise.\n\n \u003e I don\u0027t think the resourceless \"allocation\" will show up in the\n \u003e candidate at all, since it doesn\u0027t have any resources.\n\nRight. Sounds reasonable enough.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"22deeaa932078bd70a4e9a41ca3a052f44dddff7","unresolved":false,"context_lines":[{"line_number":260,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":261,"context_line":"``group_policy`` is **ignored** (always ``none``) for resourceless request"},{"line_number":262,"context_line":"groups. The resource provider satisfying the resourceless request group may"},{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_a0ffc765","line":264,"range":{"start_line":263,"start_character":56,"end_line":264,"end_character":45},"updated":"2019-06-04 11:39:12.000000000","message":"I don\u0027t think making an exception is a good way to go (i.e. we want to take resourceless providers same as resourceful providers as much as possible not to mess up.)\n\nHowever, TBH I\u0027m not catching up why we need to make an exception, (as long as I looked into a brief PoC I didn\u0027t find why the restriction needed technically) so let me look into the links another day.\n\nBut let me ask in advance; does something like\n\n    ?isolate_policy\u003d${groupA}, ${groupB}\n\ninstead of group_policy help?\n\nMy question is that isn\u0027t the problem the group policy is applied to all the groups? If so it is not at least related to the resourceless feature?","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"73436e9498e986772049d45084360c713689f01c","unresolved":false,"context_lines":[{"line_number":260,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":261,"context_line":"``group_policy`` is **ignored** (always ``none``) for resourceless request"},{"line_number":262,"context_line":"groups. The resource provider satisfying the resourceless request group may"},{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_9108d328","line":264,"range":{"start_line":263,"start_character":56,"end_line":264,"end_character":45},"in_reply_to":"9fb8cfa7_a0ffc765","updated":"2019-06-04 14:11:24.000000000","message":"Yes, that would help, but I think we\u0027re trying to avoid having to introduce yet another syntax change if possible.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"f1aafb137a325ec2243530709d29d24798cb08a3","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_2d38c7d1","line":266,"updated":"2019-06-03 11:05:03.000000000","message":"The mental gymnastic I had to go through to process this paragraph limbered me up rather a lot.\n\nI think it is trying too hard. It might be easier to say:\n\nIf there is a resourceless request group, then group_policy must be none, otherwise a 400 is returned. The way you\u0027ve written the above it makes it sounds like there are multiple group_policy parameters. There are not.\n\nOr are you trying to say: Even if the group_policy is isolate, it\u0027s ignored for the resourceless group?\n\nThat\u0027s a bit of a logic flaw (like, if we writing a parser for these queries we\u0027d need a special case here which would change our parser from being near-to-lisp-like to near-to-perl-like).\n\nSo basically, I guess what I\u0027m saying is: This probably need a bit more clarity in description and a bit more thought about what we actually want.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0beff3639144f160326490d677636e5360b2b044","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_a77aefed","line":266,"in_reply_to":"9fb8cfa7_0b2c2faa","updated":"2019-06-12 09:39:59.000000000","message":"\u003e And (B) is a common and important enough thing that we should\n \u003e consider a special syntax for it, such as root_required\u003d/root_member_of\u003d.\n \u003e (root_in_tree is also needed, but we would want to spell it\n \u003e differently for it to make sense to humans.)\n\nI need more information on this one. It\u0027s not clear from the descriptions why the _root_ matters and not the whole tree. It will commonly be the case that it is the root that has the trait (e.g. MULTI_ATTACH) but that isn\u0027t the part that actually matters. What matters is that the host claims it supports MULTI_ATTACH. To me that is the meaning (and for inventory, the current behavior) of the unsuffixed group, is the behavior that Tetsuro described wanting in suffixed member_of when he brought up changing member_of in the pre-ptg discussions, and (scary word warning) intuitively what required ought to mean.\n\nSo why the additional syntax?\n\n \u003e All of the above without \"flow down\", which I (still) think breaks\n \u003e more things than it solves, no matter how \"intuitive\" it may seem\n \u003e to some.\n\nYou\u0027ll need to support this assertion much more strongly than you\u0027ve done so far, for a few reasons:\n\n* It is critically important that placement intuitively make sense to any service that might choose to use it. As you\u0027ve said we shouldn\u0027t need a PhD is nested providers to use it effectively. What\u0027s being described in your lettered list above is a list of a proposed solutions to nova problems, not a set of general placement use cases. We need to be able to make both sides of that divide happy with minimal cost.\n\n* We, as yet, have no substantial evidence of flow down breaking things. My speculative implementation failed no API tests. It\u0027s certain that we need more tests that model real things, but presumably there\u0027s at least some sense of \"this is what placement needs to do\" in the existing tests.\n\n* We, as yet, don\u0027t have a huge amount of real-world creation of nested topologies in placement and queries thereof. If there is a chance that we are going to break things, much of that breakage is in our minds, not on real computers.\n\n* Flow down is what people expect of traits and aggregates.\n\nThat said: I\u0027m not 100% sold on doing flow down, rather I returned to it when it came back up as a solution in one of the several discussion we\u0027ve had about this, when we hit a roadblock. Given that it had near universal support (as a thing that \"should just be true\" [1]) before we dismissed it near the end of the PTG, now that it is has reared its head again, I\u0027m less inclined to dismiss it as quickly.\n\n[1] I think this represents an important difference in how we are approaching this work, as usual both sides have a ton or merit and we need to meet somewhere in the middle. It is important to me that placement present a consistent model of itself that has coherence and only presents complexity when it must. When it does, it is important that mere mortals (of which efried and cdent are not, in this context) be able to reason about the behaviour of that complexity. That consistent model, then, becomes a _predictable_ thing to which clients must hew, sometimes bending their representations to fit, so that all potential clients can benefit from the consistency and predictability. \"Should just be true\", then, is a way of encapsulating an ineffable \"yeah, that way just makes sense\", a non-violation of what people think the model is.\n\nWe know all this, but if feels useful (at least to me) to repeat it regularly to not lose track of what we\u0027re trying to do.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"d72f3e741b75dc555d6eb295f0e025cb10ec8bea","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_9b6a2d7e","line":266,"in_reply_to":"9fb8cfa7_114aa354","updated":"2019-06-04 15:46:10.000000000","message":"Discussed in IRC [1]. Concluded:\n- mriedem\u0027s use case is (better) solved by adding the trait to the unsuffixed request group. (group_policy only applies to suffixed groups, so this works for all permutations of the use case, including future when the unsuffixed group may itself be resourceless.) This is only hard because of the way the code is currently structured in nova, and that\u0027s not something we should make placement behave strangely/inconsistently for.\n- So let\u0027s leave the behavior of isolate+resourceless consistent: if your resourceless request group is suffixed and your group_policy is isolate, the provider satisfying the request group will be isolated. This may not be what you meant, but it\u0027s what you said.\n- Using group_policy with granular groups of anything beyond very low complexity is a fiddly thing, to be undertaken with caution if at all. Therefore, at some point in this string of microversions, we should make group_policy no longer required, defaulting to \u0027none\u0027. (NB: this would let us get rid of hacks like [2].)\n- At some point in the future, we\u0027ll need to introduce something like what tetsuro describes above (isolate\u003d$suffix,$suffix -- repeatable) which will be mutually exclusive with group_policy. But not yet.\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-06-04.log.html#t2019-06-04T14:12:40\n[2] https://review.opendev.org/657796","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"ad84bc00dcd55d87d56caef8972b69414fd53d2c","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_7cbeb8b4","line":266,"in_reply_to":"9fb8cfa7_22c108e6","updated":"2019-06-13 04:56:11.000000000","message":"\u003e It makes no sense to say my PGPU is capable of MULTI_ATTACH\n\nIn addition, IIUC, there are SmartNICs [1] that have CPUs on cards. If someone will want to report/model those CPUs in placement, they will be scared that CPU traits on compute side flow down to those CPUs on NIC despite they are totally different CPUs.\n\n[1] https://www.netronome.com/products/smartnic/overview/\n\nIf we want trait flow down feature, why not prepare that flow down option explicitly being independent of this spec so that callers can choose to use (or not use) flow down feature. I don\u0027t know if it\u0027s good, but at least I don\u0027t want users to be forced to have any features implicitly without getting any other choices, which could produce problems described above whose workaround is difficult to create.\n\nThe option (B) Eric suggests has \"getting traits from unrelated cousin\" problem, but it looks like that we can workaround it using the \"same_subtree\" param properly, and I don\u0027t find any other serious problems to go with (B)?","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8ca87b52426e2861a64181ec8c9b8336d1b7fe40","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_9126a5b7","line":266,"in_reply_to":"9fb8cfa7_2d38c7d1","updated":"2019-06-03 18:19:05.000000000","message":"\u003e Or are you trying to say: Even if the group_policy is isolate, it\u0027s\n \u003e ignored for the resourceless group?\n\nThis. So it would help if we just deleted \"(always ``none``)\"?\n\n \u003e That\u0027s a bit of a logic flaw (like, if we writing a parser for\n \u003e these queries we\u0027d need a special case here which would change our\n \u003e parser from being near-to-lisp-like to near-to-perl-like).\n\nI don\u0027t understand what you\u0027re saying here.\n\n \u003e It might be easier to say:\n \u003e \n \u003e If there is a resourceless request group, then group_policy must be\n \u003e none, otherwise a 400 is returned.\n\nIf we\u0027re going here, we should just get rid of group_policy at this microversion. The way real use cases seem to be shaping up, `isolate` isn\u0027t practical or useful anyway. Eventually we\u0027ll need something new/richer in this space to express anti-affinity, but we haven\u0027t been able to define what that is yet, so let\u0027s cut bait and defer it.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"2e7f25cf0d94b8c2daf224459b7ccf4135b684c1","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_9ea3c09e","line":266,"in_reply_to":"9fb8cfa7_45dee211","updated":"2019-06-07 08:49:10.000000000","message":"\u003e \"All trait (and aggregate) filters must be satisfied by all\n \u003e providers of resources satisfying the group.\"\n\nThis is consistent and sounds nice, I\u0027m halfway sold, but soon I\u0027ve got another concern again, negative trait resourceless requests:\n\n* CN1(trait:MULTI_ATTACH) - NUMA1_1(VCPU:1) - NUMA1_2(VCPU:1)\n* CN2(trait:null) - NUMA2_1(VCPU:1) - NUMA2_2(VCPU:1)\n\n    request: ?trait\u003dMULTI_ATTACH\u0026resources1\u003dVCPU:1\n\n--\u003e I\u0027m agreed that this works well with the above constraints getting NUMAs only from CN1.\n\n    request: ?trait\u003d!MULTI_ATTACH\u0026resources1\u003dVCPU:1\n\n--\u003e What callers want here would be to get NUMAs only from CN2, but actually it would return NUMAs from CN1 because both NUMA1_1 and NUMA1_2 does satisfy the non-suffixed requirement, no multi attach trait on them.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a959012f8b0305af19b49d3ebce4aabbe7ce4434","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_22c108e6","line":266,"in_reply_to":"9fb8cfa7_62e705ae","updated":"2019-06-12 14:58:27.000000000","message":"To me the query\n\n ?resources\u003dA\u0026required\u003dX\n\nsays \"give me a provider with resources A and trait X\". Tree 1 above has such a provider, child1, so it should feature in the result. But tree 2 has no such provider, so it should not feature in the results. This is how it works today. This makes sense to me.\n\n\u003e asking for the solution to have trait X\n\nThis is where we differ, I think: in our definition of \"solution\".\n\nToday\u0027s definition is, \"the set of providers where the providers of the resources also satisfy the traits (+aggs etc).\" (This is clearly a retrofit from non-nested.)\n\nI could accept a definition more like, \"the set of providers satisfying all parts of the request.\" That would get us the result you\u0027re expecting in the above example - but it would also get us \"bad cousins\".\n\nWhat seems like a stretch to me is a definition like, \"the provider providing the resources, and any providers satisfying the other pieces of the request, as long as they\u0027re at or above the provider providing the resources in the tree.\"\n\n\u003d\u003d\u003d\u003d\u003d\n\nLet me throw out another (more or less unrelated) counterexample for the \"untuitiveness\" of \"flow down\".\n\nIt makes no sense to say my PGPU is capable of MULTI_ATTACH just because it\u0027s on a compute host that\u0027s capable of MULTI_ATTACH.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"d2550997e84a89a9186985ca8dd081a6115c0813","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_dcd912f3","line":266,"in_reply_to":"9fb8cfa7_639c106a","updated":"2019-06-11 05:28:41.000000000","message":"Looks like we have several alternatives to define resourceless + unsuffixed:\n\n(1) in the same *whole* tree there exists a provider to satisfy the unsuffixed request\n\n(2) in the OR\u0027ed set of ancestors of each RP there exists (snip) \n\n(3) in the same tree the root satisfies the unsuffixed request\n\n(4) Others?\n\nFrom implementation point of view, (2) needs a change that unsuffixed should be (re)evaluated after seeing what comes from suffixed groups. IMO, that is beyond the scope of each request group’s parameter, and should be a queryparam outside the group requests like group_policy or same_subtree. (BTW, even if we go with (1), I guess we can support the limitational behavior of (2) to some extent using combination of suffixed resourceless + same_subtree queryparam)\n\n(3) is also easy, but this is a bit weird since the behavior of resourceful + unsuffixed request group is not limited to root.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6df45b0d48e48c11b70321106319c2257e8b982e","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_e5f4f15d","line":266,"in_reply_to":"9fb8cfa7_9126a5b7","updated":"2019-06-04 10:54:33.000000000","message":"\u003e The way real use cases seem to be shaping up,\n \u003e `isolate` isn\u0027t practical or useful anyway. Eventually we\u0027ll need\n \u003e something new/richer in this space to express anti-affinity, but we\n \u003e haven\u0027t been able to define what that is yet, so let\u0027s cut bait and\n \u003e defer it.\n\nI don\u0027t understand this. To me \u0027isolate\u0027 is simple person\u0027s anti-affinity and we need/want to keep simple things simple.\n\n    resources1\u003dVPCU:1\u0026resource2\u003dVCPU:1\u0026group_policy\u003disolate\n\ngives me separated CPUs. Replace VCPU with PF and you get another simple thing.\n\nSure, we probably need richer expressiveness for the more complex things, but making everyone bear that complexity is not okay. Only the complex users should need to use the complex stuff.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"3401bf2e6787ae190a0405472430e72ad96e6d04","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_a6af887b","line":266,"in_reply_to":"9fb8cfa7_97207eb2","updated":"2019-06-09 07:42:20.000000000","message":"\u003e a) making your request ?required\u003dI_AM_THE_COMPUTE_HOST\u0026!MULTI_ATTACH;\n\nI don’t disagree.\n\n \u003e b) adding the forbidden trait to all of your request groups.\n\nThis can not be an alternative. \n\n    ?required\u003d!MULTI_ATTACH\n    \u0026resources1\u003dVCPU:1\n    \u0026required1\u003d!MULTI_ATTACH\n\nreturns the candidates from CN1 as well in the case above.\n\nc) Nova puts MULTI_ATTACH trait to the NUMA resource provider if NUMA is available\n\nThis could work, but doesn’t make much sense, does it?\n\nd) Redefine unsuffixed resourceless request as below:\n\nThe big difference between suffixed and unsuffixed group is that unsuffixed can have several rps while suffixed should have only one rp in the returned allocation_requests each brings up.\n\nTherefore, in \n\n    CN1(trait:MULTI_ATTACH) - NUMA1_1(VCPU:1) - NUMA1_2(VCPU:1)\n\nThe resourceless request,\n\n    ?required\u003dMULTI_ATTACH\n\nvirtually(internally) have all the permutations of candidates:\n\n * CN1\n * CN1 + NUMA1_1\n * CN1 + NUMA1_2\n * CN1 + NUMA1_2 + NUMA1_2\n\nbecause every RP satisfies the (empty) resource constraint and every permutation satisfies the existing trait constraints; trait should be satisfied by at least one of the resource provider for (unsuffixed) request.\n\nHowever, the list of the permutations is meaningless itself, which IMO is a good sign that we can redefine what is resourceless request in unsuffixed group like as follows;\n\nd) Resourceless request in unsuffixed requests ensures that, in the same tree of resource providers in returned allocation_requests (which come from the other suffixed request groups), there exists a resource provider that satisfies the unsuffixed trait/aggregate constraints; the negative expression of which is that there doesn’t exist any resource provider that satisfies traits/aggregate constraints in the same tree.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9227e4961de2cd8432c2e1243438a8fcfe744e40","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_c30e73e4","line":266,"in_reply_to":"9fb8cfa7_9b6a2d7e","updated":"2019-06-05 07:17:57.000000000","message":"\u003e Discussed in IRC [1]. Concluded:\n \u003e - mriedem\u0027s use case is (better) solved by adding the trait to the\n \u003e unsuffixed request group. (group_policy only applies to suffixed\n \u003e groups, so this works for all permutations of the use case,\n \u003e including future when the unsuffixed group may itself be\n \u003e resourceless.) This is only hard because of the way the code is\n \u003e currently structured in nova, and that\u0027s not something we should\n \u003e make placement behave strangely/inconsistently for.\n\n+1 for solving it with the unsuffixed group in nova even if it is hard to do in nova today.\n\n \u003e - So let\u0027s leave the behavior of isolate+resourceless consistent:\n \u003e if your resourceless request group is suffixed and your\n \u003e group_policy is isolate, the provider satisfying the request group\n \u003e will be isolated. This may not be what you meant, but it\u0027s what you\n \u003e said.\n \u003e - Using group_policy with granular groups of anything beyond very\n \u003e low complexity is a fiddly thing, to be undertaken with caution if\n \u003e at all. Therefore, at some point in this string of microversions,\n \u003e we should make group_policy no longer required, defaulting to\n \u003e \u0027none\u0027. (NB: this would let us get rid of hacks like [2].)\n\nInteresting outcome. Placement was so against defaulting group_policy in the past. And I asked to add the defaulting nova instead. https://review.opendev.org/#/c/657796/ \nAnyhow I\u0027m OK to default it in placement.\n\n \u003e - At some point in the future, we\u0027ll need to introduce something\n \u003e like what tetsuro describes above (isolate\u003d$suffix,$suffix --\n \u003e repeatable) which will be mutually exclusive with group_policy. But\n \u003e not yet.\n \u003e \n \u003e [1] http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-06-04.log.html#t2019-06-04T14:12:40\n \u003e [2] https://review.opendev.org/657796","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d582b22fb794fbc57d729a04c8cd86a6188b229e","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_81515bdb","line":266,"in_reply_to":"9fb8cfa7_9b6a2d7e","updated":"2019-06-04 22:34:01.000000000","message":"FWIW, I don\u0027t understand this paragraph in the spec at all.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"be89dbab49b3be3f9100fbdd9607601a1b6711c9","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_97207eb2","line":266,"in_reply_to":"9fb8cfa7_9ea3c09e","updated":"2019-06-07 15:40:44.000000000","message":"*Another* banana peel? What *is* this place in which we find ourselves?\n\nYou\u0027re right, Tetsuro, by the definition I described, we would hit CN1 because \"there exists a resource provider in the tree that satisfies !MULTI_ATTACH\".\n\nIs that the way the algorithm works today? Or can we somehow reword The Definition to encompass the intended behavior (\"must not exist anywhere in the tree\")?\n\nI don\u0027t know if this is enough to motivate all of \"traits flow down\" (where I suspect there will also be tygers). But I also don\u0027t want to special-case the behavior of \"forbidden traits on the unsuffixed request group\".\n\nUnder the existing definition, we could say you have to satisfy this use case either by\n\na) knowing the trait you want to forbid is on the root RP, and marking the root RP with a trait I_AM_THE_COMPUTE_HOST, and then making your request ?required\u003dI_AM_THE_COMPUTE_HOST\u0026!MULTI_ATTACH; or\n\nb) adding the forbidden trait to all of your request groups.\n\nBoth kind of suck.\n\nThoughts?","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"37a264602db5b634b26534124dca6a5a927f13c1","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_62e705ae","line":266,"in_reply_to":"9fb8cfa7_a27added","updated":"2019-06-12 10:43:18.000000000","message":"\u003e Brief, incomplete update. More later.\n \u003e \n \u003e I slept on it (though I\u0027m not done sleeping) and have convinced\n \u003e myself that \"flow down\" will cleanly and simply solve all the\n \u003e *nova-specific* use cases we care about. It muddies the waters in\n \u003e more generic cases that we don\u0027t have a known use case for, like\n \u003e \n \u003e root1\n \u003e |\n \u003e child1(rc A, trait X)\n \u003e \n \u003e root2(trait X)\n \u003e |\n \u003e child2(rc A)\n \u003e \n \u003e ?resources\u003dA\u0026required\u003dX\n \u003e \n \u003e Returns both child1 and child2 with \"flow down\", which makes no\n \u003e sense to me and never has.\n\nCan you explain why this makes no sense to you, because this is exactly where it _does_ make sense to me (in the general case) and if we can figure out what the difference of mind is here it might make things easier later on.\n\nWith that query we\u0027re asking for the solution to have trait X, in both cases it does.\n\nHow does the query mean something different to you?","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"682dcbad48e6b7ace1580c7107a41e01837934ff","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_639c106a","line":266,"in_reply_to":"9fb8cfa7_a6af887b","updated":"2019-06-10 18:06:27.000000000","message":"I\u0027m going to join the separate threads of conversation here, because it was getting too confusing for me to follow both at the same time since they\u0027ve converged to talking about the same thing.\n\n \u003e When you say \"tree (compute node) that has X trait anywhere\" I\n \u003e think you\u0027re meaning \"this request must land on a compute node\n \u003e where at least one single coherent subtree in the collection of\n \u003e trees rooted at the compute node has trait X\"\n\nMeaning \"trait X must exist somewhere in the subtrees contributing to the solution, or their ancestry to the root\"? I.e. \"cousins are not allowed\".\n\n- No, that\u0027s not what I was saying, and\n- that\u0027s not how it works today\n\nTo expand:\n\n- I was in fact saying \"anywhere in the tree\". But a) that\u0027s also a behavior change, and b) it\u0027s a sucky one, for the reasons Tetsuro points out.\n- Today the unsuffixed request group ensures that the trait(s), required or forbidden, are satisfied by the providers contributing to the resource requests in that group (I think?? [Later] Confirmed.) Which is nonsensical if the unsuffixed group is resourceless.\n\nSO any definition that we come up with for how unsuffixed+resourceless works must either a) change the behavior for unsuffixed+resourced; or b) be a special case for unsuffixed+resourceless. The latter is what (d) suggests, IIUC.\n\nToday, there is *no* interaction between the unsuffixed group and other groups. If I understand the suggestion (d), we\u0027re talking about making it so that unsuffixed+resourceless filters out candidates *conditionally* based on what is being contributed by the other request groups.\n\nI\u0027m okay with this as long as we can find some way to explain it (to ourselves and in usage docs) that doesn\u0027t take a friggin PhD (or years of placement dev experience) to understand.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"fc4a2e917b5481b2b0ab85d901adb86065bfdcd6","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_a27added","line":266,"in_reply_to":"9fb8cfa7_a77aefed","updated":"2019-06-12 10:35:27.000000000","message":"Brief, incomplete update. More later.\n\nI slept on it (though I\u0027m not done sleeping) and have convinced myself that \"flow down\" will cleanly and simply solve all the *nova-specific* use cases we care about. It muddies the waters in more generic cases that we don\u0027t have a known use case for, like \n\n root1\n    |\n child1(rc A, trait X)\n\n root2(trait X)\n    |\n child2(rc A)\n\n ?resources\u003dA\u0026required\u003dX\n\nReturns both child1 and child2 with \"flow down\", which makes no sense to me and never has.\n\n ?resources\u003dA\u0026required\u003d!X\n \nReturns no results with \"flow down\", likewise.\n\nBut nova doesn\u0027t model this way, and nova is the only game in town right now. So if we change it now,  future consumers will simply have to accept that this is the way it is and figure out a different way to achieve the behavior they expect out of the above if that\u0027s what they want.\n\nI hope it goes without saying (but I\u0027m saying it anyway) that we should make the \"flow down\" change in a microversion.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"13fe0035ccb43198b3d2c1744abb3acb12956454","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_d63b78ce","line":266,"in_reply_to":"9fb8cfa7_c30e73e4","updated":"2019-06-06 07:18:45.000000000","message":"\u003e mriedem\u0027s use case is (better) solved by adding the trait to the unsuffixed request group.\n\nThis is suspicious. This sounds like:\n\"In the new microversion we look into traits on all the resource providers in the same tree *regardless of* whether the resource provider is where resource come from.\"\n\nlike the following\n\n---------------------------------\nCompute(trait:A, resource:null), NUMA(trait:null, resource:VCPU\u003d1)\n---------------------------------\n\n* previous microversion: ?resources\u003dVCPU:1\u0026required\u003dA\n\n--\u003e   empty result\n\n* new mivroversion: ?resources\u003dVCPU:1\u0026required\u003dA\n\n--\u003e   returns allocation on NUMA as candidates\n\nBut this risks to break the current behavior with e.g. the following request\n\n---------------------------------\nNIC1(trait:A, resource:VF\u003d1), NIC2(trait:B, resource:VF\u003d1)\n---------------------------------\n\n* previous microversion: ?resources\u003dVF:1\u0026required\u003dA\n\n--\u003e   returns allocation on NIC1 as candidates\n\n* new mivroversion: ?resources\u003dVF:1\u0026required\u003dA\n\n--\u003e   returns allocation on NIC1 and NIC2 as candidates because for NIC2 the trait A is in the same tree\n\nSo I assume you are going to add traits flow down feature here?\nThat should be explicitly designed in the spec.\n* Is it implicit (we \"assume/hack\" it has traits on ancesters in allocation candidates) or explicit (set traits recursivly on descendent on trait set, which needs DB migration)\n* If implicit, does the feature apply on granular requests as well?\n\nMy preference is to provide a new parameter explicitly (isolate\u003d$groupA, $groupB) later or in this spec rather than changing behaviors of the existing API, because (a) I tend to feel changing the behavior of existing API without new param with microversion can produce performance degradation (b) Behavior changes with same queryparams confuse users.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f90711ee6ab21c304219e979c0f398e0cc54f1e6","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_45dee211","line":266,"in_reply_to":"9fb8cfa7_d63b78ce","updated":"2019-06-06 20:35:24.000000000","message":"Great observation as usual Tetsuro. I\u0027ll try to answer such that we get to a) still solve mriedem\u0027s use case the same way, b) not have to implement traits-flow-down or isolate\u003d{groups} right away.\n\nFirst, as you say, we should preserve the existing behavior of the unsuffixed group. I think we get away with this with the general statement:\n\n\"All trait (and aggregate) filters must be satisfied by all providers of resources satisfying the group.\"\n\nThis applies to suffixed groups (where \"all providers\" is always one provider) and the unsuffixed group; and it applies to resourceless groups (where \"resources satisfying\" is empty) as well as those with resources.\n\nSo mriedem\u0027s case, where we always add the trait to the unsuffixed group, always works:\n\n- No NUMA, VCPU/MEMORY_MB requested in the unsuffixed group. This is today\u0027s simple case. The trait and resources are on the compute RP, so we\u0027re good.\n- NUMA on the host and in the request. We should be requesting the VCPU and MEMORY_MB resources in a suffixed group for NUMA guests; those will be satisfied by the NUMA node providers. The trait is on the compute RP and requested in the (resourceless) unsuffixed group, so that\u0027s \"satisfied\" by the root RP.\n- Since we\u0027re not doing can_split, and we\u0027re only supporting NUMA guests to NUMA-aware hosts and vice versa, we should never have a situation where we\u0027ve requested the resources and trait in the unsuffixed group but expect to land on a NUMA-modeled host.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"bfc26297ab24f75a82afe77c3345b1f3b46bc67c","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_0b2c2faa","line":266,"in_reply_to":"9fb8cfa7_dcd912f3","updated":"2019-06-11 22:31:14.000000000","message":"I thought about this from the perspective of the use cases I think we care about, without trying to solve them (yet):\n\n(A+) Trait X must appear on a provider providing Y resource. E.g. \"my VCPU must be able to do AVX\" or \"my DISK_GB must be SSD\". This we can do today by putting the resource class and the trait in the same group (suffixed or not). We should be careful not to break this.\n\n(B+) Trait X must exist on the root, regardless of whether the root provides resource. E.g. \"land me on a host that supports MULTI_ATTACH\". In this case, I know the trait I want is on the root provider.\n\n(C+) Trait X must exist on a provider that is providing Y resource, or one of its ancestors. E.g. \"my VF must be handled by a VNIC_TYPE_DIRECT agent\". (We have been tempted to try to combine (B) and (C) in the past.)\n\n(D+) Trait X must exist on at least one of the providers providing resources to the request as a whole, but I don\u0027t care which. (I\u0027m actually not sure this is a use case we care about, because I can\u0027t come up with an example.)\n\nNow for the negative cases:\n\n(A-) Trait X must *not* appear on the provider providing Y resources. E.g. \"my VCPU must not be AVX2 because I\u0027m saving those\". This we can again do today by putting the resource class and the (forbidden) trait in the same group (suffixed or not).\n\n(B-) Trait X must *not* exist on the root. E.g. \"give me a non-Windows-licensed host\".\n\n(C-) Trait X must *not* exist on the provider that is providing Y resource, or *any* of its ancestors. I\u0027m stretching, but again I think the example here has to be \"I\u0027m saving everything under my X provider for special use.\"\n\n(D-) Trait X must *not* exist on *any* of the providers providing resources to the request as a whole. Again, not sure this is a real use case. Can anyone come up with an example?\n\nAnd here\u0027s one I\u0027ve been throwing around without really thinking about whether it makes sense:\n\n(E) Trait X must (or must not) appear on *any* provider in the *tree*. I think the only real uses for this are subsets that translate to the other cases above (like (B)). So IMO we should take this one off the board.\n\nIf we can also take (D) off the board, and since (A) can already be done, let\u0027s just look at (B) and (C).\n\nI contend that resourceless+same_subtree solves all cases of (C) that we care about.\n\nAnd (B) is a common and important enough thing that we should consider a special syntax for it, such as root_required\u003d/root_member_of\u003d. (root_in_tree is also needed, but we would want to spell it differently for it to make sense to humans.)\n\nAll of the above without \"flow down\", which I (still) think breaks more things than it solves, no matter how \"intuitive\" it may seem to some.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"73436e9498e986772049d45084360c713689f01c","unresolved":false,"context_lines":[{"line_number":263,"context_line":"also provide resources satisfying another request group, regardless of the"},{"line_number":264,"context_line":"value of the ``group_policy`` query parameter. This is because there are_"},{"line_number":265,"context_line":"cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":266,"context_line":"which other request group might be requesting resources from the same provider."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Impacts"},{"line_number":269,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_114aa354","line":266,"in_reply_to":"9fb8cfa7_e5f4f15d","updated":"2019-06-04 14:11:24.000000000","message":"Right, I\u0027m saying:\n- We have zero real use cases for group_policy\u003disolate today.\n- As soon as we do, group_policy\u003disolate will be insufficient and confusing for almost all of them.","commit_id":"37c202115e773ca89e734db3f1cf5aa01c30ae9a"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":13,"context_line":"This spec describes a cluster of Placement API work to support several"},{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [#]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_9d3efcbe","line":16,"range":{"start_line":16,"start_character":2,"end_line":16,"end_character":24},"updated":"2019-06-13 16:23:48.000000000","message":"I think we can already model those relationships. What we miss is how to query those complex models that include possibly more than a single level of relationship, that\u0027s it.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":13,"context_line":"This spec describes a cluster of Placement API work to support several"},{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [#]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_ff784890","line":16,"range":{"start_line":16,"start_character":2,"end_line":16,"end_character":24},"in_reply_to":"9fb8cfa7_9d3efcbe","updated":"2019-06-13 20:21:58.000000000","message":"True; I guess the point is that although you can model such things today, it doesn\u0027t do you much good because of the limited ways in which you can query against them (next bullet).","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [#]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"An additional spec, for a feature known as `can_split`_ has been separated out"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_5d3404de","line":18,"updated":"2019-06-13 16:23:48.000000000","message":"I\u0027m confused, what\u0027s the difference with the previous bullet point ?","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [#]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"An additional spec, for a feature known as `can_split`_ has been separated out"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_9f3eecb5","line":18,"in_reply_to":"9fb8cfa7_5d3404de","updated":"2019-06-13 20:21:58.000000000","message":"Previous is about modeling; this is about requesting.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [#]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"An additional spec, for a feature known as `can_split`_ has been separated out"},{"line_number":22,"context_line":"to its own spec to ensure that any delay in it does not impact these features,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_5db7243b","line":19,"updated":"2019-06-13 16:23:48.000000000","message":"FWIW, I\u0027d appreciate those bullet points be either :\n* real usecases for Nova (eg. NUMA affinity for PCI devices)\n\nor :\n\n* Placement specific features we need, like \u0027I want to ask for 2 RPs in the same subtree\u0027\n\nSince we\u0027re on a Placement spec, I\u0027d favor the latter.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity [#]_ between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"An additional spec, for a feature known as `can_split`_ has been separated out"},{"line_number":22,"context_line":"to its own spec to ensure that any delay in it does not impact these features,"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_bf6e50c6","line":19,"in_reply_to":"9fb8cfa7_5db7243b","updated":"2019-06-13 20:21:58.000000000","message":"We go into those details, use cases, and examples below in the body of the spec -- is that okay?","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":20,"context_line":""},{"line_number":21,"context_line":"An additional spec, for a feature known as `can_split`_ has been separated out"},{"line_number":22,"context_line":"to its own spec to ensure that any delay in it does not impact these features,"},{"line_number":23,"context_line":"which are less controversial."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":".. [#] The kind of affinity we\u0027re talking about is best understood by"},{"line_number":26,"context_line":"   referring to the use case for the `same_subtree`_ feature below."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_9d159c42","line":23,"range":{"start_line":23,"start_character":10,"end_line":23,"end_character":28},"updated":"2019-06-13 16:23:48.000000000","message":"technically less controversial. Not really that the usecase is controversial, you know.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":20,"context_line":""},{"line_number":21,"context_line":"An additional spec, for a feature known as `can_split`_ has been separated out"},{"line_number":22,"context_line":"to its own spec to ensure that any delay in it does not impact these features,"},{"line_number":23,"context_line":"which are less controversial."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":".. [#] The kind of affinity we\u0027re talking about is best understood by"},{"line_number":26,"context_line":"   referring to the use case for the `same_subtree`_ feature below."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_df71c4a9","line":23,"range":{"start_line":23,"start_character":10,"end_line":23,"end_character":28},"in_reply_to":"9fb8cfa7_9d159c42","updated":"2019-06-13 20:21:58.000000000","message":"Both, really.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":46,"context_line":"(Merged) code is here: https://review.opendev.org/#/c/657419/"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Granular groups are currently restricted to using integer suffixes. We will"},{"line_number":49,"context_line":"change this so they can be case-sensitive strings up to 64 characters long"},{"line_number":50,"context_line":"comprising alphanumeric (either case), underscore, and hyphen."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_5d1ac416","line":49,"range":{"start_line":49,"start_character":55,"end_line":49,"end_character":69},"updated":"2019-06-13 16:23:48.000000000","message":"That\u0027s cool, keeping in mind UUIDs are 16 bytes, this still leaves some room for other chars with UTF-8 (in particular given how standard codes are encoded by only a single byte or two)","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":46,"context_line":"(Merged) code is here: https://review.opendev.org/#/c/657419/"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Granular groups are currently restricted to using integer suffixes. We will"},{"line_number":49,"context_line":"change this so they can be case-sensitive strings up to 64 characters long"},{"line_number":50,"context_line":"comprising alphanumeric (either case), underscore, and hyphen."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_df7f8463","line":49,"range":{"start_line":49,"start_character":55,"end_line":49,"end_character":69},"in_reply_to":"9fb8cfa7_5d1ac416","updated":"2019-06-13 20:21:58.000000000","message":"\u003e That\u0027s cool, keeping in mind UUIDs are 16 bytes\n\nWe\u0027re talking about stringified UUIDs, so 36c (8-4-4-4-12), plus something convenient (like underscore) to separate them from other components of the string. 64 is pretty arbitrary; just important that it\u0027s \"bigger than 37\" by enough to be useful.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":69,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""},{"line_number":70,"context_line":"group to \"unspecified\" or \"unsuffixed\", and anywhere we reference \"numbered\""},{"line_number":71,"context_line":"groups we can call them \"suffixed\" or \"granular\" (I think this label is already"},{"line_number":72,"context_line":"used in some places)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"same_subtree"},{"line_number":75,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_5def24e8","line":72,"updated":"2019-06-13 16:23:48.000000000","message":"I guess we just get backwards compatibility for free since an integer is just a char, we\u0027re just not using the full space. Coolio, we don\u0027t need Nova to update their calls once the new Placemeent API microversion is created.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":69,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""},{"line_number":70,"context_line":"group to \"unspecified\" or \"unsuffixed\", and anywhere we reference \"numbered\""},{"line_number":71,"context_line":"groups we can call them \"suffixed\" or \"granular\" (I think this label is already"},{"line_number":72,"context_line":"used in some places)."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"same_subtree"},{"line_number":75,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_9f958c89","line":72,"in_reply_to":"9fb8cfa7_5def24e8","updated":"2019-06-13 20:21:58.000000000","message":"yup. If you have the time and inclination, some of the above links have discussions around that aspect and how we landed here.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"same_subtree"},{"line_number":75,"context_line":"------------"},{"line_number":76,"context_line":"**Use case:** I want to express affinity between/among allocations in separate"},{"line_number":77,"context_line":"request groups. For example, that a ``VGPU`` come from a GPU affined to the"},{"line_number":78,"context_line":"NUMA node that provides my ``VCPU`` and ``MEMORY_MB``; or that multiple network"},{"line_number":79,"context_line":"VFs come from the same NIC."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_70700f09","line":76,"range":{"start_line":76,"start_character":32,"end_line":76,"end_character":40},"updated":"2019-06-13 16:23:48.000000000","message":"hard affinity FWIW","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":78,"context_line":"NUMA node that provides my ``VCPU`` and ``MEMORY_MB``; or that multiple network"},{"line_number":79,"context_line":"VFs come from the same NIC."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"A new ``same_subtree`` query parameter will be accepted. The value is a"},{"line_number":82,"context_line":"comma-separated list of request group suffix strings ``$S``. Each must exactly"},{"line_number":83,"context_line":"match a suffix on a granular group somewhere else in the request.  Importantly,"},{"line_number":84,"context_line":"the identified request groups need not have a ``resources$S`` (see"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_5dc88472","line":81,"range":{"start_line":81,"start_character":0,"end_line":81,"end_character":55},"updated":"2019-06-13 16:23:48.000000000","message":"Alleliuah","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":88,"context_line":"request group must be rooted at one of the resource providers satisfying the"},{"line_number":89,"context_line":"request group\". Or put another way: \"one of the resource providers satisfying"},{"line_number":90,"context_line":"the request group must be the direct ancestor of all the other resource"},{"line_number":91,"context_line":"providers satisfying the request group\"."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"For example, given a model like::"},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_3da7d0bf","line":91,"updated":"2019-06-13 16:23:48.000000000","message":"++","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":112,"context_line":"to request \"two VCPUs, 512MB of memory, and one FPGA from the same NUMA"},{"line_number":113,"context_line":"node,\" my request could include::"},{"line_number":114,"context_line":""},{"line_number":115,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":116,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":117,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":118,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_70424fad","line":115,"range":{"start_line":115,"start_character":2,"end_line":115,"end_character":19},"updated":"2019-06-13 16:23:48.000000000","message":"I\u0027m glad it doesn\u0027t clash with the previous feature","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":116,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":117,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":118,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"This will produce candidates including::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_90fca370","line":117,"updated":"2019-06-13 16:23:48.000000000","message":"is that really a thing ?","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0de6c42cf88f1444ec05189801702f7ba92dec07","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":116,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":117,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":118,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"This will produce candidates including::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_90c9ec26","line":117,"in_reply_to":"9fb8cfa7_10ce5c62","updated":"2019-06-14 16:44:49.000000000","message":"im just suggesting allowing resouces3\nim suggestin requiring the _ but striping it","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":116,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":117,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":118,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"This will produce candidates including::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_bff17003","line":117,"in_reply_to":"9fb8cfa7_90fca370","updated":"2019-06-13 20:21:58.000000000","message":"Just pointing out that the underscore delimiter used here is part of the suffix, not part of the syntax. (This is a result of the backward compatibility aspect you\u0027ve approved of above :)","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6f1b1299ae63251fe526dcd341e71fb21aed3089","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":116,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":117,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":118,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"This will produce candidates including::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_ed1413eb","line":117,"in_reply_to":"9fb8cfa7_bff17003","updated":"2019-06-14 15:48:21.000000000","message":"ya its kind of ugly but its the simplest solution.\nim not sure its actully required as we could stip out the first undersore so and still keep backward compatablity but an underscoe would still need to be generated.\n\ni would personaly prefer to read the the group name as COMPUTE not _COMPUTE\n\nwith the numbered groups the group name for\n\nresouce_3 was 3 not _3 so i think you are not really perserving compatiablity by declareing the _ as part of the sufix.\n\ni think as you said the first occurance of _ is a delimter and should not be consiered part of the name if you really want it to be backward compatible.\n\nyou can make it work either way but i think we shoudl be passing COMPUTE and ACCEL to same_subtree not _COMPUTE and _ACCEL","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"656616c4f3a82f90eeedadb9fb0276eb79646917","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":116,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":117,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":118,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"This will produce candidates including::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_10ce5c62","line":117,"in_reply_to":"9fb8cfa7_ed1413eb","updated":"2019-06-14 16:35:38.000000000","message":"KISS. I don\u0027t want to worry about resources3 and resources_3 computing to the same suffix.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":128,"context_line":" - numa0: {VCPU:2, MEMORY_MB:512}, fpga1_0: {FPGA:1}"},{"line_number":129,"context_line":" - numa0: {VCPU:2, MEMORY_MB:512}, fpga1_1: {FPGA:1}"},{"line_number":130,"context_line":" - numa1: {VCPU:2, MEMORY_MB:512}, fpga0_0: {FPGA:1}"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"The ``same_subtree`` query parameter may be repeated. Each grouping is treated"},{"line_number":133,"context_line":"independently."},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_70f7af5a","line":131,"updated":"2019-06-13 16:23:48.000000000","message":"Cool for hard affinity. Users would want tho soft affinity sometimes but I guess we would just get it for free with not using same_subtree ?","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":128,"context_line":" - numa0: {VCPU:2, MEMORY_MB:512}, fpga1_0: {FPGA:1}"},{"line_number":129,"context_line":" - numa0: {VCPU:2, MEMORY_MB:512}, fpga1_1: {FPGA:1}"},{"line_number":130,"context_line":" - numa1: {VCPU:2, MEMORY_MB:512}, fpga0_0: {FPGA:1}"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"The ``same_subtree`` query parameter may be repeated. Each grouping is treated"},{"line_number":133,"context_line":"independently."},{"line_number":134,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_5fe07426","line":131,"in_reply_to":"9fb8cfa7_70f7af5a","updated":"2019-06-13 20:21:58.000000000","message":"\"soft affinity\" meaning \"include affinitized and non-affinitized candidates in the result\"?\n\nYes, you can get that by using existing (prior to this spec) syntax.\n\nFiltering to only affinitized results is the purpose of this work.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":137,"context_line":"There were discussions about supporting ``!`` syntax in ``same_subtree`` to"},{"line_number":138,"context_line":"express anti-affinity (e.g. ``same_subtree\u003d$X,!$Y`` meaning \"resources from"},{"line_number":139,"context_line":"group ``$Y`` shall *not* come from the same subtree as resources from group"},{"line_number":140,"context_line":"``$X``\"). This shall be deferred to a future release."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"resourceless request groups"},{"line_number":143,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_b0d8c7ee","line":140,"updated":"2019-06-13 16:23:48.000000000","message":"Ack.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":194,"context_line":"but *not*::"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":" - pf1_1: {VF:1}, pf2_2: {VF:1}"},{"line_number":197,"context_line":" - pf2_1: {VF:1}, pf1_2: {VF:1}"},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"Default group_policy to none"},{"line_number":200,"context_line":"----------------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_50914bf0","line":197,"updated":"2019-06-13 16:23:48.000000000","message":"++","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":209,"context_line":""},{"line_number":210,"context_line":".. _at least one hack: https://review.opendev.org/657796"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":".. _granular isolation:"},{"line_number":213,"context_line":""},{"line_number":214,"context_line":"(Future) Granular Isolation"},{"line_number":215,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_f015df49","line":212,"updated":"2019-06-13 16:23:48.000000000","message":"++","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"bb346a88f89b4c9b7606c568894707a9e6c33f3a","unresolved":false,"context_lines":[{"line_number":311,"context_line":"  request group will not be able to satisfy any other suffixed group."},{"line_number":312,"context_line":"* Since the unsuffixed group isn\u0027t isolated (even with"},{"line_number":313,"context_line":"  ``group_policy\u003disolate``) if it winds up being resourceless, it can be"},{"line_number":314,"context_line":"  satisfied by *any* provider in the tree. This is important because there are_"},{"line_number":315,"context_line":"  cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":316,"context_line":"  which other request group might be requesting resources from the same provider."},{"line_number":317,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_1985aa5a","line":314,"updated":"2019-06-07 09:14:18.000000000","message":"This feels like a less satisfying recapitulation of \"traits flow down\". (Satisfying in the sense of \"this provides me with a mental model to understand how things work.\")\n\nIs this \"traits flow anywhere in the tree from the unsuffixed group (if unresourced)\"? Is that too promiscuous?","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6f1b1299ae63251fe526dcd341e71fb21aed3089","unresolved":false,"context_lines":[{"line_number":311,"context_line":"  request group will not be able to satisfy any other suffixed group."},{"line_number":312,"context_line":"* Since the unsuffixed group isn\u0027t isolated (even with"},{"line_number":313,"context_line":"  ``group_policy\u003disolate``) if it winds up being resourceless, it can be"},{"line_number":314,"context_line":"  satisfied by *any* provider in the tree. This is important because there are_"},{"line_number":315,"context_line":"  cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":316,"context_line":"  which other request group might be requesting resources from the same provider."},{"line_number":317,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_6daca39e","line":314,"in_reply_to":"9fb8cfa7_1486b567","updated":"2019-06-14 15:48:21.000000000","message":"yes i agree with chris\u0027s refinement if the trait is on a RP that is not part of the subtree that i consume resouces form then that is not a vaild host e.g. if the trait is on the Dvice RP for a nic(not the pf a resoucelses RP that groups the pfs) on the seocnd numa ndoe and all my alocation include my nic come form the first you did not satisfy the tratis request. i cant express the above using a granular requst as the trait is from a parent RP to the one that the resouce cam from but i can with subtree.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"be89dbab49b3be3f9100fbdd9607601a1b6711c9","unresolved":false,"context_lines":[{"line_number":311,"context_line":"  request group will not be able to satisfy any other suffixed group."},{"line_number":312,"context_line":"* Since the unsuffixed group isn\u0027t isolated (even with"},{"line_number":313,"context_line":"  ``group_policy\u003disolate``) if it winds up being resourceless, it can be"},{"line_number":314,"context_line":"  satisfied by *any* provider in the tree. This is important because there are_"},{"line_number":315,"context_line":"  cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":316,"context_line":"  which other request group might be requesting resources from the same provider."},{"line_number":317,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_b70ee28a","line":314,"in_reply_to":"9fb8cfa7_1985aa5a","updated":"2019-06-07 15:40:44.000000000","message":"\u003e Is this \"traits flow anywhere in the tree from the unsuffixed group\n \u003e (if unresourced)\"?\n\nThat\u0027s a side effect, yes (though unclear whether the \"flow anywhere\" concept applies forbidden traits - see PS3 discussion) but fundamentally the definition hasn\u0027t changed.\n\n\u003e Is that too promiscuous?\n\nNo, it\u0027s actually exactly what we want to use it for. \"This request must land on a tree (compute node) that has X trait anywhere.\" If you want to get more specific than that, you can put the trait in with a resourced request group, or use it with same_subtree, or ...","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"3295a58fe1690aebc70efe7bb8886d3a11327ea1","unresolved":false,"context_lines":[{"line_number":311,"context_line":"  request group will not be able to satisfy any other suffixed group."},{"line_number":312,"context_line":"* Since the unsuffixed group isn\u0027t isolated (even with"},{"line_number":313,"context_line":"  ``group_policy\u003disolate``) if it winds up being resourceless, it can be"},{"line_number":314,"context_line":"  satisfied by *any* provider in the tree. This is important because there are_"},{"line_number":315,"context_line":"  cases_ where we want to require certain traits, but don\u0027t want to figure out"},{"line_number":316,"context_line":"  which other request group might be requesting resources from the same provider."},{"line_number":317,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_1486b567","line":314,"in_reply_to":"9fb8cfa7_b70ee28a","updated":"2019-06-10 09:51:47.000000000","message":"\u003e \u003e Is that too promiscuous?\n \u003e \n \u003e No, it\u0027s actually exactly what we want to use it for. \"This request\n \u003e must land on a tree (compute node) that has X trait anywhere.\" If\n \u003e you want to get more specific than that, you can put the trait in\n \u003e with a resourced request group, or use it with same_subtree, or ...\n\nWhen you say \"tree (compute node) that has X trait anywhere\" I think you\u0027re meaning \"this request must land on a compute node where at least one single coherent subtree in the collection of trees rooted at the compute node has trait X\" which, I agree, is super pedantic, but more correct. We do not want \"the compute node has trait X anywhere\" because that suggests the trait can be from a subtree that doesn\u0027t contribute to the solution.\n\nSo the more complete definition is pretty much what Tetsuro said in his (d): In this proposed solution tree there exists a provider which has the trait/aggregate required by the unsuffixed group.\n\n(Which is probably what you were saying too, but being super clear about it seems good.)\n\n(d) is good because it isn\u0027t a fundamental change. It\u0027s already the case that for a resourced unsuffixed group there exits a provider _somewhere_ in the proposed tree. We\u0027re just taking out the bit that says there needs to be inventory involved.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":334,"context_line":"python side as additional filtering under ``_merge_candidates``. This could"},{"line_number":335,"context_line":"have some performance impact especially on large data sets. Again, we should"},{"line_number":336,"context_line":"optimize requests without ``same_subtree``, where ``same_subtree`` refers to"},{"line_number":337,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":338,"context_line":""},{"line_number":339,"context_line":"Resourceless request groups may add a small additional burden to"},{"line_number":340,"context_line":"database queries, but it should be negligible. It should be relatively"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_7316d94b","line":337,"updated":"2019-06-13 16:23:48.000000000","message":"It\u0027s a performance impact on reads, right? This can be alleviated easily by operators then.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":334,"context_line":"python side as additional filtering under ``_merge_candidates``. This could"},{"line_number":335,"context_line":"have some performance impact especially on large data sets. Again, we should"},{"line_number":336,"context_line":"optimize requests without ``same_subtree``, where ``same_subtree`` refers to"},{"line_number":337,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":338,"context_line":""},{"line_number":339,"context_line":"Resourceless request groups may add a small additional burden to"},{"line_number":340,"context_line":"database queries, but it should be negligible. It should be relatively"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_9f482c2d","line":337,"in_reply_to":"9fb8cfa7_7316d94b","updated":"2019-06-13 20:21:58.000000000","message":"\"on reads\" meaning \"only in GET /allocation_candidates\"? Yes. And yes, the above sentence is trying to say that we can hopefully isolate the performance impact to only manifest if ``same_subtree`` is used, so you can avoid it by not using that syntax.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","unresolved":false,"context_lines":[{"line_number":372,"context_line":""},{"line_number":373,"context_line":"Upgrade impact"},{"line_number":374,"context_line":"--------------"},{"line_number":375,"context_line":"None"},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Implementation"},{"line_number":378,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_b310d14f","line":375,"updated":"2019-06-13 16:23:48.000000000","message":"do you see a single microversion for all of those in order to enable them ? (please, say yes)","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","unresolved":false,"context_lines":[{"line_number":372,"context_line":""},{"line_number":373,"context_line":"Upgrade impact"},{"line_number":374,"context_line":"--------------"},{"line_number":375,"context_line":"None"},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Implementation"},{"line_number":378,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_bf5890f9","line":375,"in_reply_to":"9fb8cfa7_b310d14f","updated":"2019-06-13 20:21:58.000000000","message":"Per L31-2, the plan is to do this in multiple microversions. (1.33 is already cut for the \"arbitrary suffix\" work.) Once we\u0027re done, the calling code can of course enable all of the features at once by using the latest of those microversions.","commit_id":"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"f128dcdf0d262af2d840350804b297f3eee7317d","unresolved":false,"context_lines":[{"line_number":37,"context_line":"-------------------------------"},{"line_number":38,"context_line":"The database model associates traits with providers, not with resources"},{"line_number":39,"context_line":"(inventories of resource classes). However, conceptually there are two"},{"line_number":40,"context_line":"different classes of traits to consider."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. _`resource traits`:"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_a126df15","line":40,"updated":"2019-06-19 15:24:45.000000000","message":"I think this is difficult naming, but I\u0027m not sure if there\u0027s any better way.\n\nThe problem is the use of the  term \"provider\" to mean something different from resource provider. Traits are always associated with resource providers, so splitting traits in \"resource traits\" and \"provide traits\" is bewildering if you already know that you add a trait by adding it to a resource provider.\n\nTo make it more clear here I would use the real terms here:\n\nThe database model associates traits with resource providers, not with inventories of resource classes; however,  ...\n\nAnd in general avoid the terms \"provider\" and \"resources\", so as to be explicit as often as possible. They are too easy for someone who is not fully indoctrinated to get confused.\n\nWe don\u0027t really need to change anything here in the spec but I do think we need to be aware of using terms accurately when documenting and otherwise communicating. Because in the last two-three months the amount of difference of opinion on the meaning of apparently simple words has been simultaneously hilarious and tragic to watch.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9820d09ad9530385068c4fb77a2004119115b346","unresolved":false,"context_lines":[{"line_number":37,"context_line":"-------------------------------"},{"line_number":38,"context_line":"The database model associates traits with providers, not with resources"},{"line_number":39,"context_line":"(inventories of resource classes). However, conceptually there are two"},{"line_number":40,"context_line":"different classes of traits to consider."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. _`resource traits`:"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_b8a365b1","line":40,"in_reply_to":"9fb8cfa7_a126df15","updated":"2019-06-19 23:09:21.000000000","message":"\u003e The database model associates traits with resource providers, not\n \u003e with inventories of resource classes; however,  ...\n\nDid this.\n\n \u003e for someone who\n \u003e is not fully indoctrinated to get confused.\n\nI would actually say confusion is more likely for the indoctrinated. (Mel\u0027s comment is a supporting data point.)","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"adfba8f3565d099b0c4fa493079b94e119accf56","unresolved":false,"context_lines":[{"line_number":37,"context_line":"-------------------------------"},{"line_number":38,"context_line":"The database model associates traits with providers, not with resources"},{"line_number":39,"context_line":"(inventories of resource classes). However, conceptually there are two"},{"line_number":40,"context_line":"different classes of traits to consider."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. _`resource traits`:"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_d7e8717d","line":40,"in_reply_to":"9fb8cfa7_a126df15","updated":"2019-06-19 16:56:11.000000000","message":"FWIW, the \"resource traits\" and \"provider traits\" makes sense to me anyway reading these paragraphs, even though all traits are on [resource] providers.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"adfba8f3565d099b0c4fa493079b94e119accf56","unresolved":false,"context_lines":[{"line_number":89,"context_line":".. _have: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005201.html"},{"line_number":90,"context_line":".. _been: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004817.html"},{"line_number":91,"context_line":".. _discussions: https://review.opendev.org/#/c/662191/3/doc/source/specs/train/approved/2005575-nested-magic-1.rst@266"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Group-Specific versus Request-Wide Query Parameters"},{"line_number":94,"context_line":"---------------------------------------------------"},{"line_number":95,"context_line":"`granular resource requests`_ introduced a divide between ``GET"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_5791e1f0","line":92,"updated":"2019-06-19 16:56:11.000000000","message":"Agreed that \"traits flow down\" sounds harder to reason about.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"adfba8f3565d099b0c4fa493079b94e119accf56","unresolved":false,"context_lines":[{"line_number":112,"context_line":"as `root_required`_ and `same_subtree`_) that make it important to keep this"},{"line_number":113,"context_line":"distinction in mind.  Moving forward, we should consider whether new features"},{"line_number":114,"context_line":"and syntax additions make more sense to be group-specific or request-wide."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":".. _`granular resource requests`: http://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/granular-resource-requests.html"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_1227f7b8","line":115,"updated":"2019-06-19 16:56:11.000000000","message":"Is group-specific vs request-wide just a concept that the end user needs to be aware of when they invoke features, so they know what will be the result of their request? Or is it something that affects the syntax that should be used? If it\u0027s the latter, the API could reject requests for a feature that uses the wrong syntax.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9820d09ad9530385068c4fb77a2004119115b346","unresolved":false,"context_lines":[{"line_number":112,"context_line":"as `root_required`_ and `same_subtree`_) that make it important to keep this"},{"line_number":113,"context_line":"distinction in mind.  Moving forward, we should consider whether new features"},{"line_number":114,"context_line":"and syntax additions make more sense to be group-specific or request-wide."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":".. _`granular resource requests`: http://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/granular-resource-requests.html"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_78df2d3a","line":115,"in_reply_to":"9fb8cfa7_1227f7b8","updated":"2019-06-19 23:09:21.000000000","message":"The former, though I don\u0027t think there\u0027s really a need for us to talk to the user in terms of \"group-specific versus request-wide\". We can just spell it out in context, like I\u0027m doing here [1].\n\n[1] https://review.opendev.org/#/c/665492/12/doc/source/usage/provider-tree.rst@488","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"581924ce591fb56babd7de66c9ac677d8bb3a5a9","unresolved":false,"context_lines":[{"line_number":299,"context_line":"          cases for resourceless *without* `same_subtree`_, so I\u0027m inclined to"},{"line_number":300,"context_line":"          suggest that, for now, we make it a 400 error if the suffix of any"},{"line_number":301,"context_line":"          resourceless group is not included in at least one `same_subtree`_"},{"line_number":302,"context_line":"          somewhere in the request."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"root_required"},{"line_number":305,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_1be15dff","line":302,"updated":"2019-06-19 08:28:40.000000000","message":"+1 for rejecting resourceless groups if they are not part of a same_subtree expression","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"31eedf503b8e0b10c48cf7893154b3bfce597d9b","unresolved":false,"context_lines":[{"line_number":299,"context_line":"          cases for resourceless *without* `same_subtree`_, so I\u0027m inclined to"},{"line_number":300,"context_line":"          suggest that, for now, we make it a 400 error if the suffix of any"},{"line_number":301,"context_line":"          resourceless group is not included in at least one `same_subtree`_"},{"line_number":302,"context_line":"          somewhere in the request."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"root_required"},{"line_number":305,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_be203f4b","line":302,"in_reply_to":"9fb8cfa7_1be15dff","updated":"2019-06-19 09:11:06.000000000","message":"There is one usecase I come up with.\n\nSince we decided (in Stein PTG?) that an aggregate on root doesn\u0027t span whole tree in *suffixed* requests. Therefore, in master, there is no way to specify aggregates in requests without unsuffixed group to get NUMA hosts where the aggregate is only on its root and that root has no resource.\n\nBut using resourceless member_of unsuffixed group we get one way to specify aggregates for NUMA aware hosts with resourceless root. \n\nFWIW, `root_member_of` can be substituted for this usecase.\nThoughts?","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"384e7fd93eba8f4e9c8859918ead07167804f1d0","unresolved":false,"context_lines":[{"line_number":299,"context_line":"          cases for resourceless *without* `same_subtree`_, so I\u0027m inclined to"},{"line_number":300,"context_line":"          suggest that, for now, we make it a 400 error if the suffix of any"},{"line_number":301,"context_line":"          resourceless group is not included in at least one `same_subtree`_"},{"line_number":302,"context_line":"          somewhere in the request."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"root_required"},{"line_number":305,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_e96b63ee","line":302,"in_reply_to":"9fb8cfa7_be203f4b","updated":"2019-06-19 10:40:39.000000000","message":"I thought we did implement \"flow down\" for member_of including granular. I\u0027ll have to take another look at the code. But yes, I think root_member_of is the right answer overall.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"adfba8f3565d099b0c4fa493079b94e119accf56","unresolved":false,"context_lines":[{"line_number":299,"context_line":"          cases for resourceless *without* `same_subtree`_, so I\u0027m inclined to"},{"line_number":300,"context_line":"          suggest that, for now, we make it a 400 error if the suffix of any"},{"line_number":301,"context_line":"          resourceless group is not included in at least one `same_subtree`_"},{"line_number":302,"context_line":"          somewhere in the request."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"root_required"},{"line_number":305,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_129a97c4","line":302,"in_reply_to":"9fb8cfa7_e96b63ee","updated":"2019-06-19 16:56:11.000000000","message":"+1 for rejecting any request that will not have an effect or does not have a useful effect","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9820d09ad9530385068c4fb77a2004119115b346","unresolved":false,"context_lines":[{"line_number":299,"context_line":"          cases for resourceless *without* `same_subtree`_, so I\u0027m inclined to"},{"line_number":300,"context_line":"          suggest that, for now, we make it a 400 error if the suffix of any"},{"line_number":301,"context_line":"          resourceless group is not included in at least one `same_subtree`_"},{"line_number":302,"context_line":"          somewhere in the request."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"root_required"},{"line_number":305,"context_line":"-------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_b878458f","line":302,"in_reply_to":"9fb8cfa7_e96b63ee","updated":"2019-06-19 23:09:21.000000000","message":"\u003e I thought we did implement \"flow down\" for member_of including\n \u003e granular.\n\nOkay, I misunderstood. Aggregate down-flowing is indeed implemented for granular member_of (tack a suffix on this gabbi\u0027s request [1] (Later: which seemed like a useful thing to have anyway, so I proposed it [2])). Tetsuro\u0027s point is that, if we make this restriction, that only helps you if you attach your member_of to another request group.\n\nBut I think with \"flow down\" that\u0027s a slightly better story than what we were talking about with traits, because you could basically attach it to *any* request group and it would work.\n\nAnd yes, root_member_of.\n\n[1] https://opendev.org/openstack/placement/src/branch/master/placement/tests/functional/gabbits/allocation-candidates-bug-1792503.yaml#L43\n[2] https://review.opendev.org/666460","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"f128dcdf0d262af2d840350804b297f3eee7317d","unresolved":false,"context_lines":[{"line_number":301,"context_line":"          resourceless group is not included in at least one `same_subtree`_"},{"line_number":302,"context_line":"          somewhere in the request."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"root_required"},{"line_number":305,"context_line":"-------------"},{"line_number":306,"context_line":"**Use case:** I want to limit allocation candidates to trees `whose root"},{"line_number":307,"context_line":"provider`_ has (or does not have) certain traits. For example, I want to limit"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_c1ad1332","line":304,"updated":"2019-06-19 15:24:45.000000000","message":"is root_member_of in scope for soonish, or is that later?","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"change_message_id":"f3e127a60faabb4e618e3d7111a06ccac294f968","unresolved":false,"context_lines":[{"line_number":301,"context_line":"          resourceless group is not included in at least one `same_subtree`_"},{"line_number":302,"context_line":"          somewhere in the request."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"root_required"},{"line_number":305,"context_line":"-------------"},{"line_number":306,"context_line":"**Use case:** I want to limit allocation candidates to trees `whose root"},{"line_number":307,"context_line":"provider`_ has (or does not have) certain traits. For example, I want to limit"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_11f6f0fa","line":304,"in_reply_to":"9fb8cfa7_b89da5bc","updated":"2019-06-21 11:54:53.000000000","message":"\u003e I think we should ask real consumers whether they care about this.\n \u003e Surya?\n \u003e \n \u003e That said, I think with the way I laid out the root_required\n \u003e framework, it would be a pretty simple addition.\n \u003e \n \u003e Anyway, I\u0027m adding it to the spec with \"dunno if we need this\"\n \u003e notes.\n\nI didn\u0027t read the whole spec, but I did read this part and discussed it with Belmiro. As ops at this point we don\u0027t care much about this because we don\u0027t use traits.\n\nAs a dev from what I understand \"root_member_of\" seems simple enough to add and I understand the use cases behind adding it so +1.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9820d09ad9530385068c4fb77a2004119115b346","unresolved":false,"context_lines":[{"line_number":301,"context_line":"          resourceless group is not included in at least one `same_subtree`_"},{"line_number":302,"context_line":"          somewhere in the request."},{"line_number":303,"context_line":""},{"line_number":304,"context_line":"root_required"},{"line_number":305,"context_line":"-------------"},{"line_number":306,"context_line":"**Use case:** I want to limit allocation candidates to trees `whose root"},{"line_number":307,"context_line":"provider`_ has (or does not have) certain traits. For example, I want to limit"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_b89da5bc","line":304,"in_reply_to":"9fb8cfa7_c1ad1332","updated":"2019-06-19 23:09:21.000000000","message":"I think we should ask real consumers whether they care about this. Surya?\n\nThat said, I think with the way I laid out the root_required framework, it would be a pretty simple addition.\n\nAnyway, I\u0027m adding it to the spec with \"dunno if we need this\" notes.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"adfba8f3565d099b0c4fa493079b94e119accf56","unresolved":false,"context_lines":[{"line_number":334,"context_line":"  that makes sense:"},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"  * A resourceless ``required$S\u003d!FOO`` would simply ensure that a provider"},{"line_number":337,"context_line":"    *anywhere in the tree* does not have ``FOO`` - which would end up not being"},{"line_number":338,"context_line":"    restrictive as intended in most cases."},{"line_number":339,"context_line":"  * We could define \"resourceless forbidden\" to mean \"nowhere in the tree\", but"},{"line_number":340,"context_line":"    this would be inconsistent and hard to explain."},{"line_number":341,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_b2938ba3","line":338,"range":{"start_line":337,"start_character":51,"end_line":338,"end_character":41},"updated":"2019-06-19 16:56:11.000000000","message":"I got curious about an example here.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9820d09ad9530385068c4fb77a2004119115b346","unresolved":false,"context_lines":[{"line_number":334,"context_line":"  that makes sense:"},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"  * A resourceless ``required$S\u003d!FOO`` would simply ensure that a provider"},{"line_number":337,"context_line":"    *anywhere in the tree* does not have ``FOO`` - which would end up not being"},{"line_number":338,"context_line":"    restrictive as intended in most cases."},{"line_number":339,"context_line":"  * We could define \"resourceless forbidden\" to mean \"nowhere in the tree\", but"},{"line_number":340,"context_line":"    this would be inconsistent and hard to explain."},{"line_number":341,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_985f81e4","line":338,"range":{"start_line":337,"start_character":51,"end_line":338,"end_character":41},"in_reply_to":"9fb8cfa7_b2938ba3","updated":"2019-06-19 23:09:21.000000000","message":"Yeah, didn\u0027t want to bloat the spec even more, but it looks something like this:\n\nMy paranoid security people want to make sure that flavor_a_hacker_could_use doesn\u0027t spawn on a host that\u0027s connected to my top secret network, even though we\u0027re not giving the VM access to that network, in case they manage to break out of their VM.\n\nYou might think that I could say \"don\u0027t land on a host connected to the top secret network\" by adding a resourceless request group like:\n\n required_avoid_top_secret_network\u003d!CUSTOM_PHYSNET_TOP_SECRET\n\nBut what the bullet is saying is that what that actually means is \"make sure a provider on the host doesn\u0027t have CUSTOM_PHYSNET_TOP_SECRET\".\n\nSo if a host has its NIC represented by a *child provider* with trait CUSTOM_PHYSNET_TOP_SECRET on it, I could still land on that host, because e.g. the root (or any other random provider in the tree) doesn\u0027t have that trait, and therefore satisfies that constraint.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"581924ce591fb56babd7de66c9ac677d8bb3a5a9","unresolved":false,"context_lines":[{"line_number":382,"context_line":""},{"line_number":383,"context_line":".. _`in IRC`: http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-06-12.log.html#t2019-06-12T15:04:48"},{"line_number":384,"context_line":".. _`the review for this spec`: https://review.opendev.org/#/c/662191/"},{"line_number":385,"context_line":""},{"line_number":386,"context_line":"Default group_policy to none"},{"line_number":387,"context_line":"----------------------------"},{"line_number":388,"context_line":"A single ``isolate`` setting that applies to the whole request has consistently"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_9bc54d5e","line":385,"updated":"2019-06-19 08:28:40.000000000","message":"+1","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"adfba8f3565d099b0c4fa493079b94e119accf56","unresolved":false,"context_lines":[{"line_number":502,"context_line":"  satisfied by *any* provider in the tree. This is important because there are_"},{"line_number":503,"context_line":"  cases_ where we want to require certain traits (usually `provider traits`_),"},{"line_number":504,"context_line":"  and don\u0027t want to figure out which other request group might be requesting"},{"line_number":505,"context_line":"  resources from the same provider."},{"line_number":506,"context_line":""},{"line_number":507,"context_line":"Impacts"},{"line_number":508,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_f2126309","line":505,"updated":"2019-06-19 16:56:11.000000000","message":"Is this paragraph describing the behavior of an unsuffixed resourceless request group? If so, I think it would have been clearer to begin with, \"If your resourceless request group is unsuffixed,\" as the counterpart to the first bullet point.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9820d09ad9530385068c4fb77a2004119115b346","unresolved":false,"context_lines":[{"line_number":502,"context_line":"  satisfied by *any* provider in the tree. This is important because there are_"},{"line_number":503,"context_line":"  cases_ where we want to require certain traits (usually `provider traits`_),"},{"line_number":504,"context_line":"  and don\u0027t want to figure out which other request group might be requesting"},{"line_number":505,"context_line":"  resources from the same provider."},{"line_number":506,"context_line":""},{"line_number":507,"context_line":"Impacts"},{"line_number":508,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_982d4148","line":505,"in_reply_to":"9fb8cfa7_f2126309","updated":"2019-06-19 23:09:21.000000000","message":"good suggestion, done.","commit_id":"adc8972d32c418ce9104dfa6866936168ab5bd13"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"9351c6c9adf0b60a0ceb3adf19f6063bd87d67ab","unresolved":false,"context_lines":[{"line_number":37,"context_line":"-------------------------------"},{"line_number":38,"context_line":"The database model associates traits with resource providers, not with"},{"line_number":39,"context_line":"inventories of resource classes. However, conceptually there are two different"},{"line_number":40,"context_line":"categories of traits to consider."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. _`resource traits`:"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_27298d9a","line":40,"updated":"2019-06-20 13:30:16.000000000","message":"yeah that\u0027s better, thanks","commit_id":"4ba0323625edd28c821576759ac8ec71be1e47f4"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"9351c6c9adf0b60a0ceb3adf19f6063bd87d67ab","unresolved":false,"context_lines":[{"line_number":409,"context_line":""},{"line_number":410,"context_line":".. note:: We can probably live without this because \"flow down\" was"},{"line_number":411,"context_line":"          `implemented for aggregates`_; so you can put your ``member_of``"},{"line_number":412,"context_line":"          restrictions into *any* (resourced) request group to the same effect."},{"line_number":413,"context_line":""},{"line_number":414,"context_line":".. _`implemented for aggregates`: https://review.opendev.org/#/c/602639/"},{"line_number":415,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_026317de","line":412,"updated":"2019-06-20 13:30:16.000000000","message":"we\u0027ll wanna tweak this (just noting it so there\u0027s a reminder here, I know you already know this)","commit_id":"4ba0323625edd28c821576759ac8ec71be1e47f4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b21cb0b8c23ab1dd593000a73653650cc2cfa37b","unresolved":false,"context_lines":[{"line_number":409,"context_line":""},{"line_number":410,"context_line":".. note:: We can probably live without this because \"flow down\" was"},{"line_number":411,"context_line":"          `implemented for aggregates`_; so you can put your ``member_of``"},{"line_number":412,"context_line":"          restrictions into *any* (resourced) request group to the same effect."},{"line_number":413,"context_line":""},{"line_number":414,"context_line":".. _`implemented for aggregates`: https://review.opendev.org/#/c/602639/"},{"line_number":415,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_a43496df","line":412,"in_reply_to":"9fb8cfa7_026317de","updated":"2019-06-20 15:17:41.000000000","message":"Done","commit_id":"4ba0323625edd28c821576759ac8ec71be1e47f4"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"e741835d760b23b5ea64a3abdd3c6ff29db406b0","unresolved":false,"context_lines":[{"line_number":411,"context_line":"          `implemented for aggregates`_; so you can put your ``member_of``"},{"line_number":412,"context_line":"          restrictions into *any* (resourced) request group to the same effect."},{"line_number":413,"context_line":""},{"line_number":414,"context_line":".. _`implemented for aggregates`: https://review.opendev.org/#/c/602639/"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Default group_policy to none"},{"line_number":417,"context_line":"----------------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_a44ca076","line":414,"updated":"2019-06-20 05:00:00.000000000","message":"I\u0027m not sure if I made myself understood in the last comment about why I tend to think root_member_of is needed, and I feel a bit uncomfortable to say that \"agg flow down\" is implemented, so I\u0027ve put my thoughts on https://review.opendev.org/#/c/666488/.","commit_id":"4ba0323625edd28c821576759ac8ec71be1e47f4"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"9351c6c9adf0b60a0ceb3adf19f6063bd87d67ab","unresolved":false,"context_lines":[{"line_number":411,"context_line":"          `implemented for aggregates`_; so you can put your ``member_of``"},{"line_number":412,"context_line":"          restrictions into *any* (resourced) request group to the same effect."},{"line_number":413,"context_line":""},{"line_number":414,"context_line":".. _`implemented for aggregates`: https://review.opendev.org/#/c/602639/"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Default group_policy to none"},{"line_number":417,"context_line":"----------------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_a2a7ab0b","line":414,"in_reply_to":"9fb8cfa7_2730ade8","updated":"2019-06-20 13:30:16.000000000","message":"Thank goodness, otherwise I\u0027d be worried about my memory.","commit_id":"4ba0323625edd28c821576759ac8ec71be1e47f4"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0b778374912b30d245ae8de31e6e2a37af4a2e54","unresolved":false,"context_lines":[{"line_number":411,"context_line":"          `implemented for aggregates`_; so you can put your ``member_of``"},{"line_number":412,"context_line":"          restrictions into *any* (resourced) request group to the same effect."},{"line_number":413,"context_line":""},{"line_number":414,"context_line":".. _`implemented for aggregates`: https://review.opendev.org/#/c/602639/"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Default group_policy to none"},{"line_number":417,"context_line":"----------------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_acd322d5","line":414,"in_reply_to":"9fb8cfa7_7b82c2ca","updated":"2019-06-20 12:14:55.000000000","message":"Just to confirm: we\u0027ve do or not have member_of flowing down off the root, but only when unsuffixed?","commit_id":"4ba0323625edd28c821576759ac8ec71be1e47f4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b55ce210f6536291e3c06713c8374a99643a59c6","unresolved":false,"context_lines":[{"line_number":411,"context_line":"          `implemented for aggregates`_; so you can put your ``member_of``"},{"line_number":412,"context_line":"          restrictions into *any* (resourced) request group to the same effect."},{"line_number":413,"context_line":""},{"line_number":414,"context_line":".. _`implemented for aggregates`: https://review.opendev.org/#/c/602639/"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Default group_policy to none"},{"line_number":417,"context_line":"----------------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_7b82c2ca","line":414,"in_reply_to":"9fb8cfa7_a44ca076","updated":"2019-06-20 08:38:51.000000000","message":"Ugh, I misunderstood the gabbit (and didn\u0027t look closely enough at the fixture). Thanks for putting that together.\n\nSo yeah, this statement is wrong and we\u0027ve got a stronger reason to implement root_member_of.\n\nAs I said earlier, I suspect it won\u0027t be that hard. But let me look into it.\n\n(Aesthetic note: it makes me (and Chris) sad to add syntax, but given that root_required is a thing, adding root_member_of makes for symmetry and therefore a net decrease in sadness, IMO.)","commit_id":"4ba0323625edd28c821576759ac8ec71be1e47f4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"23d001e10c75bf1ca2f055b1b48b0c22d23d5788","unresolved":false,"context_lines":[{"line_number":411,"context_line":"          `implemented for aggregates`_; so you can put your ``member_of``"},{"line_number":412,"context_line":"          restrictions into *any* (resourced) request group to the same effect."},{"line_number":413,"context_line":""},{"line_number":414,"context_line":".. _`implemented for aggregates`: https://review.opendev.org/#/c/602639/"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Default group_policy to none"},{"line_number":417,"context_line":"----------------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fb8cfa7_2730ade8","line":414,"in_reply_to":"9fb8cfa7_acd322d5","updated":"2019-06-20 12:28:24.000000000","message":"We *do* have member_of flowing down off the root for *unsuffixed*, as demonstrated in this gabbit [1].\n\nWe do *not* have member_of flowing down off the root for *suffixed*, as demonstrated in Tetsuro\u0027s DNM [2].\n\n[1] https://opendev.org/openstack/placement/src/branch/master/placement/tests/functional/gabbits/allocation-candidates-bug-1792503.yaml\n[2] https://review.opendev.org/#/c/666488/","commit_id":"4ba0323625edd28c821576759ac8ec71be1e47f4"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"64648a63ed942c45ed8271b3a4eee7316f5e84dc","unresolved":false,"context_lines":[{"line_number":27,"context_line":".. [#] The kind of affinity we\u0027re talking about is best understood by"},{"line_number":28,"context_line":"   referring to the use case for the `same_subtree`_ feature below."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Principles"},{"line_number":31,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":32,"context_line":"In developing this design, some fundamental concepts have come to light. These"},{"line_number":33,"context_line":"are not really changes from the existing architecture, but understanding them"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9fb8cfa7_35174548","line":30,"updated":"2019-06-24 13:51:03.000000000","message":"thanks for adding this","commit_id":"c00d043376811c0b4b42fbe845fa8f093351b0b5"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"64648a63ed942c45ed8271b3a4eee7316f5e84dc","unresolved":false,"context_lines":[{"line_number":64,"context_line":"**provider traits** must stick to their provider, regardless of where resources"},{"line_number":65,"context_line":"inventories are placed. For example, ``COMPUTE_VOLUME_MULTI_ATTACH`` should"},{"line_number":66,"context_line":"always be on the root provider, as the root provider conceptually represents"},{"line_number":67,"context_line":"\"the compute host\"."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. _`Traits Flow Down`:"},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"9fb8cfa7_3530a5e8","line":67,"updated":"2019-06-24 13:51:03.000000000","message":"Sure, OK, but dI don\u0027t understand whether we should then implement something here.","commit_id":"c00d043376811c0b4b42fbe845fa8f093351b0b5"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"260eeef206379df6ce6ee55163f454521496ae0f","unresolved":false,"context_lines":[{"line_number":64,"context_line":"**provider traits** must stick to their provider, regardless of where resources"},{"line_number":65,"context_line":"inventories are placed. For example, ``COMPUTE_VOLUME_MULTI_ATTACH`` should"},{"line_number":66,"context_line":"always be on the root provider, as the root provider conceptually represents"},{"line_number":67,"context_line":"\"the compute host\"."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. _`Traits Flow Down`:"},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"9fb8cfa7_1591e199","line":67,"in_reply_to":"9fb8cfa7_3530a5e8","updated":"2019-06-24 13:56:40.000000000","message":"This paragraph serves two purposes:\n\n- To advise the placement *consumer* (such as Nova) on how to model.\n- Assuming the placement consumer follows that ^ advice, to justify/motivate the ``root_required`` feature, and all the brainwork that went into it.","commit_id":"c00d043376811c0b4b42fbe845fa8f093351b0b5"}]}