)]}'
{"doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6ab380e23e3507733848a58f542732d977e45920","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Resources of the same class, but with different attributes (traits), must be"},{"line_number":20,"context_line":"inventoried in separate resource providers. For example, if VGPUs of different"},{"line_number":21,"context_line":"types are provided by separate PGPUs, each PGPU is represented by a separate"},{"line_number":22,"context_line":"resource provider."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"The concept of provider trees has thus far only been used as an aid for humans"},{"line_number":25,"context_line":"to visualize components of a compute host in a hierarchical fashion. Beyond"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_c8f51b85","line":22,"updated":"2019-04-17 10:13:39.000000000","message":"Another reason to have different RPs for different physical devices is structural. Some physical device are part of the NUMA topology of the host. So if two physical device are close to two different NUMA nodes then this structural different can be expressed by two nested physical device RPs under different NUMA parent RPs.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6ab380e23e3507733848a58f542732d977e45920","unresolved":false,"context_lines":[{"line_number":24,"context_line":"The concept of provider trees has thus far only been used as an aid for humans"},{"line_number":25,"context_line":"to visualize components of a compute host in a hierarchical fashion. Beyond"},{"line_number":26,"context_line":"knowing which provider is the root, there is as yet no logic that treats a"},{"line_number":27,"context_line":"provider tree as anything other than an unstructured bag of providers."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"However, provider trees were conceived to facilitate modeling true hierarchies"},{"line_number":30,"context_line":"such as the proc, memory, and PCI devices associated with a NUMA node. We could"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_8844f3b8","line":27,"updated":"2019-04-17 10:13:39.000000000","message":"The bandwidth feature already depends on having nested RPs and defines multi level nesting, with specific traits on different leaf RPs in the nested tree.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"a672d93263e6f39c4184bfda3eed1316a35f3cd0","unresolved":false,"context_lines":[{"line_number":27,"context_line":"provider tree as anything other than an unstructured bag of providers."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"However, provider trees were conceived to facilitate modeling true hierarchies"},{"line_number":30,"context_line":"such as the proc, memory, and PCI devices associated with a NUMA node. We could"},{"line_number":31,"context_line":"have implemented (and `could still implement`_) other ways of creating subgroup"},{"line_number":32,"context_line":"associations, but this spec assumes we\u0027re going to use the tree structure we\u0027ve"},{"line_number":33,"context_line":"already enabled."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_df2286a3","line":30,"range":{"start_line":30,"start_character":12,"end_line":30,"end_character":16},"updated":"2019-04-06 05:23:27.000000000","message":"Processors? Please spell out in full.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6ab380e23e3507733848a58f542732d977e45920","unresolved":false,"context_lines":[{"line_number":50,"context_line":"           +-----+  +-----+              +-----+  +-----+"},{"line_number":51,"context_line":"           |PF0_0|  |PF0_1|              |PF1_0|  |PF1_1|"},{"line_number":52,"context_line":"           |VF:4 |  |VF:4 |              |VF:4 |  |VF:4 |"},{"line_number":53,"context_line":"           +-----+  +-----+              +-----+  +-----+"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"The host has two sockets and two NICs. Each NIC has two PFs. One NIC is affined"},{"line_number":56,"context_line":"to each socket."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_4b0925db","line":53,"updated":"2019-04-17 10:13:39.000000000","message":"I need to note that here that PFs already modeled as RPs in placement by neutron for the bandwidth feature. Still this is good as an example tree, but please note that this is not how the current tree looks like.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"7ede4389ad6ca45073c4dbc092a304535f203bc1","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"::"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":" ?resources\u003dDISK_GB:10\u0026resources1\u003dVCPU:2,MEMORY_MB:128\u0026resources2\u003dVF:2\u0026group_policy\u003d\u003cwhatever\u003e"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":" pseudo-response:"},{"line_number":79,"context_line":" ["}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_1132f1a7","line":76,"range":{"start_line":76,"start_character":84,"end_line":76,"end_character":94},"updated":"2019-04-10 17:33:43.000000000","message":"?","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":73,"context_line":""},{"line_number":74,"context_line":"::"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":" ?resources\u003dDISK_GB:10\u0026resources1\u003dVCPU:2,MEMORY_MB:128\u0026resources2\u003dVF:2\u0026group_policy\u003d\u003cwhatever\u003e"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":" pseudo-response:"},{"line_number":79,"context_line":" ["}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_ccb02f8f","line":76,"range":{"start_line":76,"start_character":84,"end_line":76,"end_character":94},"in_reply_to":"5fc1f717_1132f1a7","updated":"2019-04-10 20:22:33.000000000","message":"Meaning either group_policy gives us the same result, because the resources are in separate providers anyway.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"7ede4389ad6ca45073c4dbc092a304535f203bc1","unresolved":false,"context_lines":[{"line_number":92,"context_line":"As an end user, I want to be able to boot a VM that takes advantage of the"},{"line_number":93,"context_line":"performance gains provided by NUMA affinity."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"As an operator, I want to be able to define a flavor requesting (groups of)"},{"line_number":96,"context_line":"resources affined to the same NUMA node(s)."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"As a cloud provider, I want my user\u0027s boot requests to be efficient, maximizing"},{"line_number":99,"context_line":"the probability of a boot request landing, and minimizing retries and late"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_51139901","line":96,"range":{"start_line":95,"start_character":0,"end_line":96,"end_character":43},"updated":"2019-04-10 17:33:43.000000000","message":"this is an implementation detail. the use case is the end-user one, which is properly described above.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1811f2bf792c41115c48d71dbeebf13ee98dea60","unresolved":false,"context_lines":[{"line_number":103,"context_line":"Proposed change"},{"line_number":104,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":105,"context_line":"In a new microversion, a mechanism whereby the root of each subtree requiring"},{"line_number":106,"context_line":"affinity is decorated with a trait (the *same* trait); and a grouping of"},{"line_number":107,"context_line":"resources can be marked as needing to be satisfied by providers with a common"},{"line_number":108,"context_line":"subtree root decorated with that trait."},{"line_number":109,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_8cb268e4","line":106,"range":{"start_line":106,"start_character":12,"end_line":106,"end_character":34},"updated":"2019-04-09 14:18:17.000000000","message":"This has a really, really bad smell to it. I understand that it is a hack to get around the limitations of the relational way we store placement data, but you should at least acknowledge that this is an undesireable but necessary hack. And I stress \"unnecessary\" because it is not needed when modeling placement data in a graph database, as I demonstrated in https://blog.leafe.com/placement-graph-examples/","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":103,"context_line":"Proposed change"},{"line_number":104,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":105,"context_line":"In a new microversion, a mechanism whereby the root of each subtree requiring"},{"line_number":106,"context_line":"affinity is decorated with a trait (the *same* trait); and a grouping of"},{"line_number":107,"context_line":"resources can be marked as needing to be satisfied by providers with a common"},{"line_number":108,"context_line":"subtree root decorated with that trait."},{"line_number":109,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_a53abb30","line":106,"range":{"start_line":106,"start_character":12,"end_line":106,"end_character":34},"in_reply_to":"5fc1f717_8cb268e4","updated":"2019-04-10 20:22:33.000000000","message":"\u003e This has a really, really bad smell to it.\n\nNo argument. I like some of the proposed alternatives, discussed further below.\n\n \u003e it is not needed when modeling placement data in a graph database,\n \u003e as I demonstrated in https://blog.leafe.com/placement-graph-examples/\n\nWhile I very much appreciate this as an intellectual exercise, are you seriously proposing that we cut placement over to a graph database?","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"7ede4389ad6ca45073c4dbc092a304535f203bc1","unresolved":false,"context_lines":[{"line_number":103,"context_line":"Proposed change"},{"line_number":104,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":105,"context_line":"In a new microversion, a mechanism whereby the root of each subtree requiring"},{"line_number":106,"context_line":"affinity is decorated with a trait (the *same* trait); and a grouping of"},{"line_number":107,"context_line":"resources can be marked as needing to be satisfied by providers with a common"},{"line_number":108,"context_line":"subtree root decorated with that trait."},{"line_number":109,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_516f195f","line":106,"range":{"start_line":106,"start_character":12,"end_line":106,"end_character":34},"in_reply_to":"5fc1f717_8cb268e4","updated":"2019-04-10 17:33:43.000000000","message":"I don\u0027t see why there is a need to decorate a resource provider with this trait at all.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"9d3aa88f9ccb418f36a8f597b2ad268d4d88b83b","unresolved":false,"context_lines":[{"line_number":103,"context_line":"Proposed change"},{"line_number":104,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":105,"context_line":"In a new microversion, a mechanism whereby the root of each subtree requiring"},{"line_number":106,"context_line":"affinity is decorated with a trait (the *same* trait); and a grouping of"},{"line_number":107,"context_line":"resources can be marked as needing to be satisfied by providers with a common"},{"line_number":108,"context_line":"subtree root decorated with that trait."},{"line_number":109,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffb9cba7_4caadd85","line":106,"range":{"start_line":106,"start_character":12,"end_line":106,"end_character":34},"in_reply_to":"5fc1f717_a53abb30","updated":"2019-04-22 13:29:04.000000000","message":"I am seriously proposing that we actively clean up the mixing of SQL code with Placement logic so that we can experiment and get a better idea of what would be involved. There is no way that could be done in a single step, of course. But after reading the results of nested queries I documented, do you see how much cleaner that solution is?","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"60cde2fafbe7a1ab85bd2462bb63e2faf5ced09b","unresolved":false,"context_lines":[{"line_number":132,"context_line":"``resources$N``.  Today, the implicit group policy for a single request group"},{"line_number":133,"context_line":"is, \"This entire group must be satisfied by a single provider.\" With this"},{"line_number":134,"context_line":"proposal, it will be possible to express, \"This request group must be satisfied"},{"line_number":135,"context_line":"by providers with a common ancestor marked with $TRAIT.\""},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The syntax is::"},{"line_number":138,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_3e2b7aeb","line":135,"updated":"2019-04-08 11:43:42.000000000","message":"Can you provide a bit more information on how the client will (and will know to):\n\n* establish the inventory such that this trait is present\n* determine that it needs to make a query containing that trait and learn what that trait is\n\nWhile that\u0027s not really placement\u0027s concern in any specific way, knowing the hoops the client has to go through to make use of the functionality is an important part of evaluating the usefulness of the scenario.\n\nWherever possible (sometimes it is not) it is good to avoid requiring explicit knowledge or explicit configuration and rely instead on info that can be extracted from the hardware. This is a similar argument to \"how do we avoid a flavor explosion\".","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"bf99ed5daad8703eb551a8999226f32522aba478","unresolved":false,"context_lines":[{"line_number":132,"context_line":"``resources$N``.  Today, the implicit group policy for a single request group"},{"line_number":133,"context_line":"is, \"This entire group must be satisfied by a single provider.\" With this"},{"line_number":134,"context_line":"proposal, it will be possible to express, \"This request group must be satisfied"},{"line_number":135,"context_line":"by providers with a common ancestor marked with $TRAIT.\""},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The syntax is::"},{"line_number":138,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_957f86aa","line":135,"in_reply_to":"3fce034c_ec72cbe3","updated":"2019-04-10 22:15:00.000000000","message":"The intent of my comment was to try to tease out if there is an implicit coupling going on that is limiting the solution to terms of the primary NUMA use case, rather than terms of \"a way that placement can work that happens to satisfy NUMA\". I suspect we\u0027re being good about that, but I\u0027m not entirely certain.\n\nI\u0027m too tired now to properly digest all of this now, but wanted to clarify that point, because it also applies to the discussion at http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004923.html \n\nI\u0027m trying to drive more of the NUMA and EPA related discussion to email (particularly that thread) so that we can talk about these topics in a more holistic sense. In gerrit we tend to focus on just these changes, and just the details being discussed here, and I really think we need to work/talk in a more integrated fashion to reach a really good solution on the several topics in the general sphere that this spec is in.\n\nI was thinking that email might help that, perhaps not for everyone. But for me at least, I _really_ struggle to engage in earnest discussion about anything other than specific details in gerrit.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"7ede4389ad6ca45073c4dbc092a304535f203bc1","unresolved":false,"context_lines":[{"line_number":132,"context_line":"``resources$N``.  Today, the implicit group policy for a single request group"},{"line_number":133,"context_line":"is, \"This entire group must be satisfied by a single provider.\" With this"},{"line_number":134,"context_line":"proposal, it will be possible to express, \"This request group must be satisfied"},{"line_number":135,"context_line":"by providers with a common ancestor marked with $TRAIT.\""},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The syntax is::"},{"line_number":138,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_713fb524","line":135,"in_reply_to":"5fc1f717_3e2b7aeb","updated":"2019-04-10 17:33:43.000000000","message":"There\u0027s no reason to use a trait at all, IMHO.\n\nHow about making the API something like this?\n\n GET /allocation_candidates?resources1\u003dPCPU:2,MEMORY_MB:2048\\\n   \u0026resources2\u003dSRIOV_NET_VF:1\\\n   \u0026group_resources\u003d2:1\n\nthe \u0026group_resources query parameter would indicate the requestgroup identifiers to group resources with. For example, group_resources\u003d2:1 means \"the providers of resources in request group \u00272\u0027 should be in the same tree as providers of resources in request group \u00271\u0027\"\n\nNo traits needed at all and the API call has more imperative clarity, since the caller is saying exactly how they expect the placement service to group related resources.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":132,"context_line":"``resources$N``.  Today, the implicit group policy for a single request group"},{"line_number":133,"context_line":"is, \"This entire group must be satisfied by a single provider.\" With this"},{"line_number":134,"context_line":"proposal, it will be possible to express, \"This request group must be satisfied"},{"line_number":135,"context_line":"by providers with a common ancestor marked with $TRAIT.\""},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The syntax is::"},{"line_number":138,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_ec72cbe3","line":135,"in_reply_to":"5fc1f717_713fb524","updated":"2019-04-10 20:22:33.000000000","message":"\u003e Can you provide a bit more information on how the client will (and\n \u003e will know to):\n \u003e \n \u003e * establish the inventory such that this trait is present\n\nKnowing to split inventory into NUMA nodes is the subject of [1], not this spec. Once the virt driver knows it\u0027s going to do that, it would know it needs to decorate the NUMA providers with the trait.\n\n \u003e * determine that it needs to make a query containing that trait and\n\nRight, that would be based on interpreting the hw: extra specs that currently describe NUMA splits and affinity.\n\n \u003e learn what that trait is\n\nIt\u0027s part of the same feature, a contract between n-sch and n-cpu (virt).\n\n[1] https://review.openstack.org/552924\n\n \u003e group_resources\u003d2:1 means \"the providers of resources in request\n \u003e group \u00272\u0027 should be in the same [sub?]tree as providers of resources in\n \u003e request group \u00271\u0027\"\n\nThis suffers from the \"non-root\" and \"group numbers in the querystring\" problems - see below.\n\n[Later] Okay, so the non-root thing is a non-problem. But the group numbers thing still applies - see below.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1811f2bf792c41115c48d71dbeebf13ee98dea60","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The syntax is::"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":" group_policy$N\u003dcommon_subtree_by_trait:$TRAIT"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"For example::"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_8cd108cf","line":139,"range":{"start_line":139,"start_character":16,"end_line":139,"end_character":39},"updated":"2019-04-09 14:18:17.000000000","message":"ugh. This is as bad a phrasing as MISC_SHARES_VIA_AGGREGATE","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2038bef7c96da22ac4576f53ecfb6d416305d30c","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The syntax is::"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":" group_policy$N\u003dcommon_subtree_by_trait:$TRAIT"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"For example::"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_5de73513","line":139,"range":{"start_line":139,"start_character":16,"end_line":139,"end_character":39},"in_reply_to":"5fc1f717_12f0bc90","updated":"2019-04-10 10:42:12.000000000","message":"by the way i should proably expand on the semantics fo subtree in my proposal.\n\nsubtree:4,5\n\nmeans that resouce groups 4 and 5 must be in the same subtree and one of them must be the root of the subtree.\n\nthe second part is not obvious but its what prevent everythign form pass as due to the fact that all subtrees on a comptue node have the compute node RP as a parent.\n\nwe could also defien subtree as stating that all RPs selected by the resouces request must form a subtree that does not contain the compute node RP too and that would also work\n\nso the stricted form would be\n\nall resouce goups with the subtree policy would form a tree, that does not contian the root RP and has one of the resource group RPs as the root of the sub tree.\n\n\nthe other thing that may not be obvious is its fine to repeate polices or resouce groups in my synatx.\n\nso these would all be vaild exaamples\n\ngroup_policy\u003dnone;subtree:2,3;subtree:4,5;\nor\ngroup_policy\u003dnone;isolate:2,3;isolate:4,5; \nor\ngroup_policy\u003dnone;isolate:2,3;subtree:2,3;","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The syntax is::"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":" group_policy$N\u003dcommon_subtree_by_trait:$TRAIT"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"For example::"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_bb809cf8","line":139,"range":{"start_line":139,"start_character":16,"end_line":139,"end_character":39},"in_reply_to":"5fc1f717_5de73513","updated":"2019-04-10 20:22:33.000000000","message":"My problem with \"non-root\" and \"one of them must be the root of the subtree\" is that there *will* be situations where the affinity needs to happen below the second tier. For example, there\u0027s a proposal to model last-level cache as a resource [1]. IIUC, procs and caches are grouped together in \"packages\" within NUMA nodes. So if we need to model both NUMA and LLC at the same time, we have a tree like:\n\n                            compute\n\n              NUMA1                            NUMA2\n\n  pkg1.1  pkg1.2 nic1.3 fpga1.4   pkg2.1 pkg2.2 nic2.3 nic2.4 fpga2.5\n\nIn this case it\u0027s possible that *all* the resources will be at the third level down (except DISK_GB, unless sharing). And we need to be able to express {[\"CPU+LLC from the same package\" x N] + VF + FPGA} all from the same NUMA node.\n\nA subset of Sean\u0027s suggestion would support this:\n\n\u003e group_policy\u003dnone;isolate:2,3;NUMA_NODE:4,5\n\nBut including request group numbers in the query is icky for the reasons stated below (see L223-5 and Sundar\u0027s comment there).\n\n[Later] Okay, so this scenario actually doesn\u0027t conflict with the \"non-root\" suggestion. And since a stated goal of this effort is to KISS rather than solve the world, and we don\u0027t actually have a use case for other-than-second-tier affinity, I\u0027m good with it.\n\nHowever, it still has request group numbers in the query.\n\n[1] https://review.openstack.org/#/c/651233/","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6267935c99ffdeb6e933d45513e3f914e4dfa678","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"The syntax is::"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":" group_policy$N\u003dcommon_subtree_by_trait:$TRAIT"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"For example::"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_12f0bc90","line":139,"range":{"start_line":139,"start_character":16,"end_line":139,"end_character":39},"in_reply_to":"5fc1f717_8cd108cf","updated":"2019-04-10 10:06:53.000000000","message":"so i was going to propse this in the numa in pacement spec but this might be a better place.\n\n\nin addtion to doing common_subtree_by_trait we could also do something like this \n\ngroup_policy\u003dnone;isolate:2,3;subtree:4,5;\n\nthis would declare the default group policy for requst groups is none, groups 2 and 3 must come form different RPs and groups 4 and 5 must have a common subtree\n\nthe new syntax would be \n\"group_policy\u003d\" \u003cgloabal defaul none or isoalte\u003e \";\" \u003cpolicy\u003e \":\" \u003ccomma seperated list of group numbers\u003e \";\"\n\nso semi colons deplimts each of the policies and colon delimits the policy name form the list of groups its applies too. or explained as a regex\n\n\"group_policy\u003d(none|isolate)?(;)?((none|isolate|subtree):([0-9])(,[0-9])+(;)?)+\"\n\ni think this could be complementry to your proposal instead of an alternitive. \n\nif we wanted to also go with trits we could alter it to alow a common trait to be specified instead of a policy.\n\nso \ngroup_policy\u003dnone;isolate:2,3;NUMA_NODE:4,5;\n\n\"group_policy\u003d(none|isolate)?(;)?(((none|isolate|subtree)|([A-Z_0-9])):([0-9])(,[0-9])+(;)?)+\"","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"a672d93263e6f39c4184bfda3eed1316a35f3cd0","unresolved":false,"context_lines":[{"line_number":169,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA0: {VCPU: 2, MEMORY_MB: 128}, NUMA1: {VCPU: 3}, PF0_1: {VF: 2}},"},{"line_number":170,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA1: {VCPU: 2, MEMORY_MB: 128}, NUMA0: {VCPU: 3}, PF1_0: {VF: 2}},"},{"line_number":171,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA1: {VCPU: 2, MEMORY_MB: 128}, NUMA0: {VCPU: 3}, PF1_1: {VF: 2}},"},{"line_number":172,"context_line":" ]"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":".. _limitation:"},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_7f6cb235","line":172,"updated":"2019-04-06 05:23:27.000000000","message":"Say I want an FPGA, VCPU and memory to come from the same NUMA node. The request group (RG) for the FPGA will come from a Cyborg device profile, and hence will never be in the same RG as VCPU and memory. If the FPGA\u0027s RG looks like::\n{ resources:CUSTOM_FPGA\u003d1, trait:T\u003drequired,\n  group_policy\u003dcommon_subtree_by_trait:NUMA_NODE\n}\n\nthen it is possible for VCPU/memory to come from one NUMA node, and FPGA from another NUMA node -- unless I am missing something.\n\nThe same applies to NICs when they are represented as RPs and their request groups come from Neutron.\n\nWe could solve this by adding another constraint. The FPGA (or NIC) case could say::\n    group_policy\u003dcommon_subtree_as_vcpu\n\nIf NUMA is not required for VCPUs, then this is a no-op: FPGA/NIC still come from the same subtree as VCPUs, i.e., the compute node. This allows NIC/FPGA RGs to be independent of the flavor RGs. Downside: this assumes Placement picks an RP for VCPUs before it gets to NIC/FPGA/GPUs etc.\n\nAn independent question: how do devices get affined to NUMA nodes, i.e., if a device RP is getting created, how does it parented to one NUMA node vs another?","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":169,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA0: {VCPU: 2, MEMORY_MB: 128}, NUMA1: {VCPU: 3}, PF0_1: {VF: 2}},"},{"line_number":170,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA1: {VCPU: 2, MEMORY_MB: 128}, NUMA0: {VCPU: 3}, PF1_0: {VF: 2}},"},{"line_number":171,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA1: {VCPU: 2, MEMORY_MB: 128}, NUMA0: {VCPU: 3}, PF1_1: {VF: 2}},"},{"line_number":172,"context_line":" ]"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":".. _limitation:"},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_fb062486","line":172,"in_reply_to":"5fc1f717_7f6cb235","updated":"2019-04-10 20:22:33.000000000","message":"\u003e Say I want an FPGA, VCPU and memory to come from the same NUMA\n \u003e node. The request group (RG) for the FPGA will come from a Cyborg\n \u003e device profile, and hence will never be in the same RG as VCPU and\n \u003e memory.\n\nAs currently architected, this is true. We would have to find a way to combine them.\n\n \u003e We could solve this by adding another constraint. The FPGA (or NIC)\n \u003e case could say::\n \u003e group_policy\u003dcommon_subtree_as_vcpu\n\nI dig the \"common ancestor providing resource class\" idea. It provides *almost* the same capability as what\u0027s proposed here, with less of the smell. However, it still doesn\u0027t work for the LLC/NUMA scenario described above.\n\n \u003e An independent question: how do devices get affined to NUMA nodes,\n \u003e i.e., if a device RP is getting created, how does it parented to\n \u003e one NUMA node vs another?\n\nThe virt driver knows about the affinities by querying the hardware, same way it does today (though I don\u0027t know the details).","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"a672d93263e6f39c4184bfda3eed1316a35f3cd0","unresolved":false,"context_lines":[{"line_number":170,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA1: {VCPU: 2, MEMORY_MB: 128}, NUMA0: {VCPU: 3}, PF1_0: {VF: 2}},"},{"line_number":171,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA1: {VCPU: 2, MEMORY_MB: 128}, NUMA0: {VCPU: 3}, PF1_1: {VF: 2}},"},{"line_number":172,"context_line":" ]"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":".. _limitation:"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"**Limitation:** This doesn\u0027t provide a way to express a request for VFs from"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_1f67ae4f","line":173,"updated":"2019-04-06 05:23:27.000000000","message":"When we add forbidden traits, that is going to exclude some RPs in the tree. So, I could have a RP p1 with traits t1, t2 and a RP p2 with traits t1, t3. Bot provide the same RC named c. Both have a parent RP with trait PARENT. Now this request group::\n{ resources:c\u003d1,\n  trait:t1\u003drequired, trait:t2\u003dforbidden,\n  group_policy\u003dcommon_subtree_by_trait:PARENT\n}\nshould match the RP p2 but not p1. Is that your expectation too?","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":170,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA1: {VCPU: 2, MEMORY_MB: 128}, NUMA0: {VCPU: 3}, PF1_0: {VF: 2}},"},{"line_number":171,"context_line":"   {COMPUTE_HOST: {DISK_GB: 10}, NUMA1: {VCPU: 2, MEMORY_MB: 128}, NUMA0: {VCPU: 3}, PF1_1: {VF: 2}},"},{"line_number":172,"context_line":" ]"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":".. _limitation:"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"**Limitation:** This doesn\u0027t provide a way to express a request for VFs from"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_5b4098a2","line":173,"in_reply_to":"5fc1f717_1f67ae4f","updated":"2019-04-10 20:22:33.000000000","message":"Nope, that\u0027ll break. It\u0027s a good fundamental reason we can\u0027t combine requests for resources that we know need to come from different providers into the same request group. Also leads to the limitation below.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"60cde2fafbe7a1ab85bd2462bb63e2faf5ced09b","unresolved":false,"context_lines":[{"line_number":179,"context_line":""},{"line_number":180,"context_line":".. _`could still implement`:"},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"Alternatives"},{"line_number":183,"context_line":"------------"},{"line_number":184,"context_line":"More complicated syntax"},{"line_number":185,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_7ed6e2f4","line":182,"updated":"2019-04-08 11:43:42.000000000","message":"Is \"share an ancestor that is not a root\" an option here? I\u0027m guessing that is probably too limiting , but it would satisfy (at least some of) the examples given in this spec.\n\nOr \"share nearest ancestor that provides resource class X\" (in these examples that would be \"share VCPU\".[1]\n\nBoth of these options are trying to come at ways of not putting a trait on a resource provider if its sole purpose is to identify it as \"special\" in some queries. Clearly, if there is a trait that is going to be there anyway, that\u0027s a different matter.\n\nmerely riffing at this point...\n\n\n[1] I still have some concerns about making sure that we _only_ put vcpu on the numa node (and represent numa nodes at all) when people explicitly configure for it (which isn\u0027t necessarily _nova_ configuration, but maybe bios config).","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"693e76564b14bad81daa923d1de03967d1dc3a82","unresolved":false,"context_lines":[{"line_number":179,"context_line":""},{"line_number":180,"context_line":".. _`could still implement`:"},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"Alternatives"},{"line_number":183,"context_line":"------------"},{"line_number":184,"context_line":"More complicated syntax"},{"line_number":185,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_fb935ba2","line":182,"in_reply_to":"3fce034c_7550da33","updated":"2019-04-10 23:42:23.000000000","message":"\u003e I was able to track the second \"see above\" direction on \"share\n \u003e ancestor with resource class\", but not the first one. Where were\n \u003e you pointing? (see above about me being tired)\n\nL139, the one that starts with, \u0027my problem with \"non-root\"...\u0027. Though I have since recanted having a problem with that. If, once you\u0027re not tired, you would be so good as to read all my comments and emails in the order they were written, you will understand perfectly that I am now advocating exactly that: a \"share an ancestor that is not a root\" solution.\n\n \u003e I really think this is a horrible idea. It adds tons of rows to the\n \u003e placement db and for many people it matters not one iota.\n\nAck. I\u0027ll let whoever it was fight for it.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":179,"context_line":""},{"line_number":180,"context_line":".. _`could still implement`:"},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"Alternatives"},{"line_number":183,"context_line":"------------"},{"line_number":184,"context_line":"More complicated syntax"},{"line_number":185,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_9b512065","line":182,"in_reply_to":"5fc1f717_7ed6e2f4","updated":"2019-04-10 20:22:33.000000000","message":"\u003e Is \"share an ancestor that is not a root\" an option here? I\u0027m\n \u003e guessing that is probably too limiting , but it would satisfy (at\n \u003e least some of) the examples given in this spec.\n\nSee above.\n\n \u003e Or \"share nearest ancestor that provides resource class X\" (in\n \u003e these examples that would be \"share VCPU\".[1]\n\nSee above.\n\n \u003e [1] I still have some concerns about making sure that we _only_ put\n \u003e vcpu on the numa node (and represent numa nodes at all) when people\n \u003e explicitly configure for it (which isn\u0027t necessarily _nova_\n \u003e configuration, but maybe bios config).\n\nActually, somebody (maybe Sean?) suggested that it would be simpler if we *always* create a NUMA tree, even on a system with only one NUMA node. I can see the merit there. Because we need to deal with \"request that doesn\u0027t care about affinity\" landing on NUMA-structured nodes anyway, right? I guess there\u0027s a performance concern there, but that can be dealt with.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"bf99ed5daad8703eb551a8999226f32522aba478","unresolved":false,"context_lines":[{"line_number":179,"context_line":""},{"line_number":180,"context_line":".. _`could still implement`:"},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"Alternatives"},{"line_number":183,"context_line":"------------"},{"line_number":184,"context_line":"More complicated syntax"},{"line_number":185,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_7550da33","line":182,"in_reply_to":"5fc1f717_9b512065","updated":"2019-04-10 22:15:00.000000000","message":"I was able to track the second \"see above\" direction on \"share ancestor with resource class\", but not the first one. Where were you pointing? (see above about me being tired)\n\n\u003e Actually, somebody (maybe Sean?) suggested that it would be simpler\n \u003e if we *always* create a NUMA tree, even on a system with only one\n \u003e NUMA node. I can see the merit there. Because we need to deal with\n \u003e \"request that doesn\u0027t care about affinity\" landing on\n \u003e NUMA-structured nodes anyway, right? I guess there\u0027s a performance\n \u003e concern there, but that can be dealt with.\n\nI really think this is a horrible idea. It adds tons of rows to the placement db and for many people it matters not one iota.\n\n(This is an example of one of the general topics that would be better served in email (I think).)","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"a672d93263e6f39c4184bfda3eed1316a35f3cd0","unresolved":false,"context_lines":[{"line_number":222,"context_line":""},{"line_number":223,"context_line":"Aside from the hideous queryparam key and the egregious overuse of internal"},{"line_number":224,"context_line":"delimiters, using request group numbers this way feels like a violation (though"},{"line_number":225,"context_line":"I can\u0027t put my finger on exactly why)."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"We have discussed supporting a JSON request payload instead of a querystring"},{"line_number":228,"context_line":"for ``GET /allocation_candidates``. For example, we could instead express the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_bf09ba84","line":225,"updated":"2019-04-06 05:23:27.000000000","message":"This use of group numbers is not good because:\n* Request groups from Neutron for bw provider and from Cyborg device profiles will not have explicit group numbers.\n* Neutron/Cyborg devices should be affined with VCPU/memory, but we shouldn\u0027t assume the number of the RG that asks for VCPU/memory.\n* When those request groups are merged with those from the flavor, the flavor group numbering *could* change. To avoid that, Nova should make an explicit guarantee that the Neutron/Cyborg groups get added after the flavor RGs.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":222,"context_line":""},{"line_number":223,"context_line":"Aside from the hideous queryparam key and the egregious overuse of internal"},{"line_number":224,"context_line":"delimiters, using request group numbers this way feels like a violation (though"},{"line_number":225,"context_line":"I can\u0027t put my finger on exactly why)."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"We have discussed supporting a JSON request payload instead of a querystring"},{"line_number":228,"context_line":"for ``GET /allocation_candidates``. For example, we could instead express the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_fbc70411","line":225,"in_reply_to":"5fc1f717_bf09ba84","updated":"2019-04-10 20:22:33.000000000","message":"Thanks Sundar, that\u0027s a good explanation.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"b01d8ad64fb25e72a557abc8b711372fad3ac905","unresolved":false,"context_lines":[{"line_number":222,"context_line":""},{"line_number":223,"context_line":"Aside from the hideous queryparam key and the egregious overuse of internal"},{"line_number":224,"context_line":"delimiters, using request group numbers this way feels like a violation (though"},{"line_number":225,"context_line":"I can\u0027t put my finger on exactly why)."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"We have discussed supporting a JSON request payload instead of a querystring"},{"line_number":228,"context_line":"for ``GET /allocation_candidates``. For example, we could instead express the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_c5274e12","line":225,"in_reply_to":"5fc1f717_fbc70411","updated":"2019-04-16 05:48:53.000000000","message":"I think the problem isn\u0027t group numbers. The problem is we didn\u0027t tell know the cyborg device want to attach to which guest numa node.\n\nEven you use the common subtree by tratis, you still can\u0027t tell nova which guest numa node you want to attach to.\n\nI prefer the way using extra spec to tell which numa node cyborg device want to attach.\n\nfor example:\n\nflavor\n vcpus: 8\n memory: 128\n extra specs:\n      hw:numa_nodes\u003d2\n      accel:device_profile.0\u003d\u003cprofile_name\u003e\n\nThis means the cyborg device will attach to the first numa node.\n\nThis is coming from when I walk through another idea, i talk about the detail in maillist http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005115.html","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"60cde2fafbe7a1ab85bd2462bb63e2faf5ced09b","unresolved":false,"context_lines":[{"line_number":226,"context_line":""},{"line_number":227,"context_line":"We have discussed supporting a JSON request payload instead of a querystring"},{"line_number":228,"context_line":"for ``GET /allocation_candidates``. For example, we could instead express the"},{"line_number":229,"context_line":"above as::"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":" { groups: ["},{"line_number":232,"context_line":"       { requests: ["}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_be276a12","line":229,"updated":"2019-04-08 11:43:42.000000000","message":"I reckon we should punt on this until after a first implementation, to keep ourselves somewhat focused.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"b01d8ad64fb25e72a557abc8b711372fad3ac905","unresolved":false,"context_lines":[{"line_number":226,"context_line":""},{"line_number":227,"context_line":"We have discussed supporting a JSON request payload instead of a querystring"},{"line_number":228,"context_line":"for ``GET /allocation_candidates``. For example, we could instead express the"},{"line_number":229,"context_line":"above as::"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":" { groups: ["},{"line_number":232,"context_line":"       { requests: ["}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_a571e20e","line":229,"in_reply_to":"5fc1f717_3b8fcccd","updated":"2019-04-16 05:48:53.000000000","message":"Just thinking, If we can use body, then we can describe the request by a tree structure, why we need group_policy to describe the subtree affinity anymore, at least it isn\u0027t easy to be read by human.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1811f2bf792c41115c48d71dbeebf13ee98dea60","unresolved":false,"context_lines":[{"line_number":226,"context_line":""},{"line_number":227,"context_line":"We have discussed supporting a JSON request payload instead of a querystring"},{"line_number":228,"context_line":"for ``GET /allocation_candidates``. For example, we could instead express the"},{"line_number":229,"context_line":"above as::"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":" { groups: ["},{"line_number":232,"context_line":"       { requests: ["}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_cc99501f","line":229,"in_reply_to":"5fc1f717_be276a12","updated":"2019-04-09 14:18:17.000000000","message":"Yeah, this is a distraction to the central issue, and feels like an assumption that this spec is a given.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":226,"context_line":""},{"line_number":227,"context_line":"We have discussed supporting a JSON request payload instead of a querystring"},{"line_number":228,"context_line":"for ``GET /allocation_candidates``. For example, we could instead express the"},{"line_number":229,"context_line":"above as::"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":" { groups: ["},{"line_number":232,"context_line":"       { requests: ["}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_3b8fcccd","line":229,"in_reply_to":"5fc1f717_cc99501f","updated":"2019-04-10 20:22:33.000000000","message":"That\u0027s a chicken/egg argument. As we\u0027re seeing above, it\u0027s really hard to do this with a querystring.\n\nIf we use a change in data model (see below) then maybe it\u0027s not anymore.\n\nBut otherwise, this would make it easy to implement the \"subtree implicitly starts one down from the root\" idea to remove the \"trait smell\" while also avoiding the \"group numbers in the query\" problem. It looks almost identical to L231-48:\n\n { groups: [\n       { requests: [\n             { resources: {DISK_GB: 10} }\n         ]\n       }\n       { requests: [\n             { resources: {VCPU: 2, MEMORY_MB: 128} }\n             { resources: {VF: 1},\n               required: [NET_A] },\n             { resources: {VF: 1},\n               required: [NET_B] },\n         ],\n         group_policy: subtree_affinity\n       },\n   ]\n }","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"a672d93263e6f39c4184bfda3eed1316a35f3cd0","unresolved":false,"context_lines":[{"line_number":247,"context_line":"   ]"},{"line_number":248,"context_line":" }"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"This seems like a large additional effort for a small gain in functionality."},{"line_number":251,"context_line":"Can we live with the stated limitation_ for a while?"},{"line_number":252,"context_line":""},{"line_number":253,"context_line":"Aggregates (with metadata)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_da0ff436","line":250,"updated":"2019-04-06 05:23:27.000000000","message":"This would not enable device affinity, again because Neutron and Cyborg request groups are independent.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":247,"context_line":"   ]"},{"line_number":248,"context_line":" }"},{"line_number":249,"context_line":""},{"line_number":250,"context_line":"This seems like a large additional effort for a small gain in functionality."},{"line_number":251,"context_line":"Can we live with the stated limitation_ for a while?"},{"line_number":252,"context_line":""},{"line_number":253,"context_line":"Aggregates (with metadata)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_fbbe2463","line":250,"in_reply_to":"5fc1f717_da0ff436","updated":"2019-04-10 20:22:33.000000000","message":"Right, they would have to not be, see above.\n\nBut this is just an example. Being able to express nesting in the request would give us a lot more power.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"change_message_id":"a672d93263e6f39c4184bfda3eed1316a35f3cd0","unresolved":false,"context_lines":[{"line_number":259,"context_line":"we don\u0027t accidentally get results across, say, a whole AZ); and then restrict"},{"line_number":260,"context_line":"the use of intra-tree aggregates so this can\u0027t be broken."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"Aggregate metadata could give us the power to make the above distinctions. But"},{"line_number":263,"context_line":"then we would need aggregate metadata."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Explicitly trait all the RPs in the subgroup"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_1ab81cc6","line":262,"range":{"start_line":262,"start_character":0,"end_line":262,"end_character":18},"updated":"2019-04-06 05:23:27.000000000","message":"Please provide some pointers to this concept.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1811f2bf792c41115c48d71dbeebf13ee98dea60","unresolved":false,"context_lines":[{"line_number":259,"context_line":"we don\u0027t accidentally get results across, say, a whole AZ); and then restrict"},{"line_number":260,"context_line":"the use of intra-tree aggregates so this can\u0027t be broken."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"Aggregate metadata could give us the power to make the above distinctions. But"},{"line_number":263,"context_line":"then we would need aggregate metadata."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Explicitly trait all the RPs in the subgroup"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_ec8d2cd4","line":262,"range":{"start_line":262,"start_character":0,"end_line":262,"end_character":18},"in_reply_to":"5fc1f717_1ab81cc6","updated":"2019-04-09 14:18:17.000000000","message":"It\u0027s a Nova-ism. When Placement was created, we explicitly did not implement it.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":259,"context_line":"we don\u0027t accidentally get results across, say, a whole AZ); and then restrict"},{"line_number":260,"context_line":"the use of intra-tree aggregates so this can\u0027t be broken."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"Aggregate metadata could give us the power to make the above distinctions. But"},{"line_number":263,"context_line":"then we would need aggregate metadata."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Explicitly trait all the RPs in the subgroup"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_5ba3b843","line":262,"range":{"start_line":262,"start_character":0,"end_line":262,"end_character":18},"in_reply_to":"5fc1f717_ec8d2cd4","updated":"2019-04-10 20:22:33.000000000","message":"If we had a way to flag an aggregate as saying \"this is a NUMA node\", then we could encircle each group of NUMA-affined providers in such an aggregate, and provide some kind of member_of query that says [these request groups] must be satisfied by providers in the same [aggregate tagged with \"this is a NUMA node\"].\n\nI didn\u0027t explain too far because people freak out when aggregate metadata in placement is suggested, so I assumed it was a nonstarter.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1811f2bf792c41115c48d71dbeebf13ee98dea60","unresolved":false,"context_lines":[{"line_number":268,"context_line":"``CUSTOM_NUMA_NODE_0`` trait and then require that trait across all the request"},{"line_number":269,"context_line":"groups wanting affined resources. But then we would need separate flavors for"},{"line_number":270,"context_line":"each possible NUMA node trait; or a clever way to generate separate requests"},{"line_number":271,"context_line":"with all possible NUMA node traits; and then a way to avoid favoring hosts with"},{"line_number":272,"context_line":"fewer NUMA nodes."},{"line_number":273,"context_line":""},{"line_number":274,"context_line":"Non-boolean traits"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_0ca4384a","line":271,"updated":"2019-04-09 14:18:17.000000000","message":"For all the reasons that the original proposal smells like a hack, this just multiplies the smells.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1811f2bf792c41115c48d71dbeebf13ee98dea60","unresolved":false,"context_lines":[{"line_number":273,"context_line":""},{"line_number":274,"context_line":"Non-boolean traits"},{"line_number":275,"context_line":"~~~~~~~~~~~~~~~~~~"},{"line_number":276,"context_line":"If we had traits with values, we could decorate all the providers in one"},{"line_number":277,"context_line":"affinity group with a trait with the same key but different values, like"},{"line_number":278,"context_line":"``NUMA_NODE\u003d0``, ``NUMA_NODE\u003d1``, and add ``GET /allocation_candidates`` syntax"},{"line_number":279,"context_line":"like ``trait_values_equal:NUMA_NODE``."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_8c6d8804","line":276,"range":{"start_line":276,"start_character":0,"end_line":276,"end_character":28},"updated":"2019-04-09 14:18:17.000000000","message":"I stopped reading this option after these words.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1811f2bf792c41115c48d71dbeebf13ee98dea60","unresolved":false,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Data model impact"},{"line_number":291,"context_line":"-----------------"},{"line_number":292,"context_line":"No new database modeling should be required. We may wish to represent a"},{"line_number":293,"context_line":"\"subtree\" as a pseudo-object in the code."},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"API impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_0c52f835","line":292,"range":{"start_line":292,"start_character":0,"end_line":292,"end_character":43},"updated":"2019-04-09 14:18:17.000000000","message":"I would welcome a change to the database model as preferable to codifying a hack to the current design.","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"9d3aa88f9ccb418f36a8f597b2ad268d4d88b83b","unresolved":false,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Data model impact"},{"line_number":291,"context_line":"-----------------"},{"line_number":292,"context_line":"No new database modeling should be required. We may wish to represent a"},{"line_number":293,"context_line":"\"subtree\" as a pseudo-object in the code."},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"API impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffb9cba7_4cb17de1","line":292,"range":{"start_line":292,"start_character":0,"end_line":292,"end_character":43},"in_reply_to":"3fce034c_ac8e03ce","updated":"2019-04-22 13:29:04.000000000","message":"Sure! https://i1.wp.com/blog.leafe.com/wp-content/uploads/2018/05/match_disk_ram.png?w\u003d618\u0026ssl\u003d1","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"170da280f848a2bbbc4a829a3da91a231af3d944","unresolved":false,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Data model impact"},{"line_number":291,"context_line":"-----------------"},{"line_number":292,"context_line":"No new database modeling should be required. We may wish to represent a"},{"line_number":293,"context_line":"\"subtree\" as a pseudo-object in the code."},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"API impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fce034c_ac8e03ce","line":292,"range":{"start_line":292,"start_character":0,"end_line":292,"end_character":43},"in_reply_to":"5fc1f717_0c52f835","updated":"2019-04-10 20:22:33.000000000","message":"Nice, let\u0027s talk about that. Can you suggest a nice clean data model change that would do the trick?","commit_id":"033e52d68bc7df2334fd77240efdab9ff7e94138"}]}