)]}'
{"specs/stein/approved/placement-resource-provider-request-group-mapping-in-allocation-candidates.rst":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Provide resource provider - request group mapping in allocation candidates"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/placement-resource-provider-request-group-mapping-in-allocation-candidates"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"To support QoS minimum bandwidth policy during server scheduling Neutron needs"},{"line_number":14,"context_line":"to know which resource provider provides the bandwidth resource for each port"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_7230b4e9","line":11,"range":{"start_line":11,"start_character":44,"end_line":11,"end_character":118},"updated":"2018-10-05 15:38:22.000000000","message":"that\u0027s a mouthful :)","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7a5470ab9b50788102edefafcdff5e26a29bad4","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"To support QoS minimum bandwidth policy during server scheduling Neutron needs"},{"line_number":14,"context_line":"to know which resource provider provides the bandwidth resource for each port"},{"line_number":15,"context_line":"in the server create request."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_0ef1f101","line":15,"updated":"2019-02-22 00:05:14.000000000","message":"As noted below, this isn\u0027t the only use case. By now both vgpu and cyborg have demonstrated a need for the same.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"To support QoS minimum bandwidth policy during server scheduling Neutron needs"},{"line_number":14,"context_line":"to know which resource provider provides the bandwidth resource for each port"},{"line_number":15,"context_line":"in the server create request."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_0b63421c","line":15,"in_reply_to":"9fdfeff1_0ef1f101","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"709ca71d482c94c121d33f41ed89a0c277acf221","unresolved":false,"context_lines":[{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Placement supports granular request groups in the ``GET allocation_candidates``"},{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_bef60bd8","line":21,"range":{"start_line":21,"start_character":45,"end_line":21,"end_character":49},"updated":"2018-08-30 10:55:49.000000000","message":"nit: do","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","unresolved":false,"context_lines":[{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Placement supports granular request groups in the ``GET allocation_candidates``"},{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2a9952cf","line":21,"range":{"start_line":21,"start_character":45,"end_line":21,"end_character":49},"updated":"2018-10-05 15:38:22.000000000","message":"s/does/do/","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Placement supports granular request groups in the ``GET allocation_candidates``"},{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_eb710ee2","line":21,"range":{"start_line":21,"start_character":45,"end_line":21,"end_character":49},"in_reply_to":"3f79a3b5_2a9952cf","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"709ca71d482c94c121d33f41ed89a0c277acf221","unresolved":false,"context_lines":[{"line_number":20,"context_line":"Placement supports granular request groups in the ``GET allocation_candidates``"},{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"},{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d96441e8","line":26,"range":{"start_line":23,"start_character":11,"end_line":26,"end_character":57},"updated":"2018-08-30 10:55:49.000000000","message":"I see this problem as not specific to Neutron. As soon as more than one OpenStack components contribute parts to a complex allocation candidate request the same problem arises. Request parts have to be assembled to a single query (so the query can be atomic). Then the response have to be disassembled and the response parts have to be lined up with the corresponding request parts.\n\nThe assembly is clearly the responsibility of nova since nova knows how the parts contribute to a VM/instance. For symmetry we could make nova do the disassembly, but that seems to me foolish consistency, and I\u0027d prefer placement to support back-references to request parts for reasons below.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","unresolved":false,"context_lines":[{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"},{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_aa48022e","line":26,"range":{"start_line":24,"start_character":59,"end_line":26,"end_character":57},"updated":"2018-10-05 15:38:22.000000000","message":"while this is true that Neutron needs this information, placement isn\u0027t the thing that determines this. Placement does not know which of multiple ports that requested similar resources are going to go on which resource provider. All that placement knows is that the allocation candidates it returned to the caller contain *enough* providers with the *necessary* traits and group membership to meet the requested resource and trait constraints.\n\nPlacement does not decide which port gets mapped to which provider. Only the nova-compute node, in combination with Neutron and os-vif, can make that determination. All placement can do is return each provider\u0027s traits and group memberships to give those components the information they need to make the actual port-to-provider decisions.\n\nIn other words, we\u0027re conflating the process of filtering port providers with the process of binding a port.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7e38f9c118d0dbd4f8ad9998f12ed6b949a40385","unresolved":false,"context_lines":[{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"},{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_fe46d57e","line":26,"range":{"start_line":24,"start_character":59,"end_line":26,"end_character":57},"in_reply_to":"3f79a3b5_aa48022e","updated":"2018-10-05 22:02:40.000000000","message":"I disagree with this, and it\u0027s the whole point of this spec.\n\nTrue that placement doesn\u0027t know anything specifically about \"ports\" or whatever. But it knows more than just\n\n \u003e allocation candidates it returned to the caller contain *enough*\n \u003e providers with the *necessary* traits and group membership to meet\n \u003e the requested resource and trait constraints.\n\nPlacement also knows - for the duration of the GET /a_c operation - which parts of the response correspond to which parts of the request. If you asked for two similar things in separate request groups that could be satisfied by two different providers, placement *does* know the difference between\n\n RP_A: { thingy_from_request_group_X },\n RP_B: { thingy_from_request_group_Y }\n\nand\n\n RP_A: { thingy_from_request_group_X },\n RP_B: { thingy_from_request_group_Y }\n\nPrior to this blueprint, those two results would be indistinguishable, and in fact would be consolidated into one allocation request in the response. After this blueprint, they\u0027ll be distinct.\n\nAnd with that information, the caller, who knows that request group X was for a port it knows of as X and request group Y was for port Y, knows whether to attach X\u003c\u003d\u003eRP_A,Y\u003c\u003d\u003eRP_B or X\u003c\u003d\u003eRP_B,Y\u003c\u003d\u003eRP_A.\n\nWhich, to beat a dead horse, is the whole point of this effort.\n\n(This is a pedantic example to illustrate a point. One could argue that, if both of the above candidates are viable, it doesn\u0027t matter which port goes with which. But not everything about RP_A and RP_B, or about request group X and request group Y, is necessarily equivalent; and those distinctions can be used by a post-filter/weigher to decide which of those candidates is preferred.)","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c381c811cd22be3c3414062d13a74aa899f2b307","unresolved":false,"context_lines":[{"line_number":20,"context_line":"Placement supports granular request groups in the ``GET allocation_candidates``"},{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"},{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_7100a1ac","line":26,"range":{"start_line":23,"start_character":11,"end_line":26,"end_character":57},"in_reply_to":"3f79a3b5_d96441e8","updated":"2018-08-30 11:59:00.000000000","message":"Good point. It is not neutron specific. I guess cyborg will have the same situation in the future.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"047a36cb7f1ffab7e0b685493548639588778319","unresolved":false,"context_lines":[{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"},{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_179053ed","line":26,"range":{"start_line":24,"start_character":59,"end_line":26,"end_character":57},"in_reply_to":"3f79a3b5_fe46d57e","updated":"2019-02-20 05:31:11.000000000","message":"I\u0027m on Jay side...I don\u0027t get why we need this spec. For Eric\u0027s example, if RP_A and RP_B provide same resource, and the request X and Y are request same amount resource, we needn\u0027t care which allocate from which RP. If X and Y request are different amount, we can compare the request and the response of allocate_candidate which include consuming amount for each RP.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"94fd6990a06b04e2b996717e8ad9b33e6103aaf2","unresolved":false,"context_lines":[{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"},{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_bfcabe16","line":26,"range":{"start_line":24,"start_character":59,"end_line":26,"end_character":57},"in_reply_to":"9fdfeff1_084e446e","updated":"2019-02-28 22:57:16.000000000","message":"\u003e On the calling side, are resource groups deterministic and\n \u003e repeatable? Or are we going to have to maintain yet more state\n \u003e which maps resource group identifier to... I don\u0027t know. What is\n \u003e that thing? Who remembers that thing and that mapping?\n\nYes, they\u0027re saved as instances of RequestGroup [1] on RequestSpec.requested_resources [2]. Right now (in merged code) we\u0027re only storing the bandwidth-related RequestGroups; but the goal is to store all of them, especially as we start using more nesty requests, like for cyborg [3] and multiple VGPU types [4]. Prior to scheduling, we shove a \u0027requester_id\u0027 into the RequestGroup. In the bandwidth case, that\u0027s the port ID [5]; in the cyborg case, it\u0027s the actual request group number [6] associated with the device profile. And after we get the allocation back, we\u0027re doing the duplication-of-placement-logic thing [7] (well, part of it - this still doesn\u0027t take forbidden traits or aggregates into account) to set the RequestGroup.provider_uuids, which finally get to be used by the driver to figure out which actual thingy to attach to the instance.\n\n[1] https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/objects/request_spec.py#L978\n[2] https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/objects/request_spec.py#L93-L100\n[3] https://review.openstack.org/#/c/631243/15/nova/objects/request_spec.py@489\n[4] http://specs.openstack.org/openstack/nova-specs/specs/stein/approved/vgpu-stein.html (this is light on details, but will clearly need to use granular request groups to work)\n[5] https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/objects/request_spec.py#L1041\n[6] https://review.openstack.org/#/c/631243/15/nova/scheduler/utils.py@221\n[7] https://github.com/openstack/nova/blame/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/objects/request_spec.py#L687-L849","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"56cbf6d2af805592877df3ee8506b2262ceab610","unresolved":false,"context_lines":[{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"},{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_084e446e","line":26,"range":{"start_line":24,"start_character":59,"end_line":26,"end_character":57},"in_reply_to":"9fdfeff1_0e3fb187","updated":"2019-02-28 13:36:44.000000000","message":"Let\u0027s say, for sake of discussion, we do this. Somewhere in the allocation_candidates response is a mapping of resource provider to resource request group.\n\nOn the calling side, are resource groups deterministic and repeatable? Or are we going to have to maintain yet more state which maps resource group identifier to... I don\u0027t know. What is that thing? Who remembers that thing and that mapping?","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7a5470ab9b50788102edefafcdff5e26a29bad4","unresolved":false,"context_lines":[{"line_number":21,"context_line":"query but the returned allocation candidates does not contain explicit"},{"line_number":22,"context_line":"information about which granular request group is fulfilled by which RP in the"},{"line_number":23,"context_line":"candidate. The resource request of a Neutron port is mapped to a granular"},{"line_number":24,"context_line":"request group by Nova towards Placement during scheduling. After scheduling"},{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_0e3fb187","line":26,"range":{"start_line":24,"start_character":59,"end_line":26,"end_character":57},"in_reply_to":"9fdfeff1_179053ed","updated":"2019-02-22 00:05:14.000000000","message":"\u003e If X and Y request are different amount, we\n \u003e can compare the request and the response of allocate_candidate\n \u003e which include consuming amount for each RP.\n\nWe could, and the same for matching traits and aggregates an any other filterables that exist in the future. But that\u0027s duplicating placement logic on the client side, like [1] (which btw doesn\u0027t even handle forbidden traits, or aggregates, or the unnumbered request group). We shouldn\u0027t do that, and we shouldn\u0027t *need* to do that.\n\n[1] https://review.openstack.org/#/c/616239/33/nova/objects/request_spec.py","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"709ca71d482c94c121d33f41ed89a0c277acf221","unresolved":false,"context_lines":[{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"},{"line_number":30,"context_line":"`Non-scalable Nova based solution`_ section with detailed examples and"},{"line_number":31,"context_line":"analysis."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5f2ed1fa","line":28,"range":{"start_line":28,"start_character":0,"end_line":28,"end_character":38},"updated":"2018-08-30 10:55:49.000000000","message":"That would be duplicating placement logic in nova.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c381c811cd22be3c3414062d13a74aa899f2b307","unresolved":false,"context_lines":[{"line_number":25,"context_line":"Neutron needs the information which port got allocation from which RP to set up"},{"line_number":26,"context_line":"the proper port binding towards those network device RPs."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Doing this mapping in Nova is possible but scales pretty badly even for small"},{"line_number":29,"context_line":"amount of ports in a single server create request. See the"},{"line_number":30,"context_line":"`Non-scalable Nova based solution`_ section with detailed examples and"},{"line_number":31,"context_line":"analysis."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5131e5a1","line":28,"range":{"start_line":28,"start_character":0,"end_line":28,"end_character":38},"in_reply_to":"3f79a3b5_5f2ed1fa","updated":"2018-08-30 11:59:00.000000000","message":"which is possible ;)","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","unresolved":false,"context_lines":[{"line_number":30,"context_line":"`Non-scalable Nova based solution`_ section with detailed examples and"},{"line_number":31,"context_line":"analysis."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"In the other hand when Placement builds an allocation candidate it does that by"},{"line_number":34,"context_line":"`building allocations for each granular request group`_. Therefore Placement"},{"line_number":35,"context_line":"could include the necessary mapping information in the response with"},{"line_number":36,"context_line":"significantly less effort."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_86c6819c","line":33,"range":{"start_line":33,"start_character":0,"end_line":33,"end_character":2},"updated":"2018-10-05 15:38:22.000000000","message":"s/In/On/g\n\nyeah, I know... English is a terrible language. :)","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":30,"context_line":"`Non-scalable Nova based solution`_ section with detailed examples and"},{"line_number":31,"context_line":"analysis."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"In the other hand when Placement builds an allocation candidate it does that by"},{"line_number":34,"context_line":"`building allocations for each granular request group`_. Therefore Placement"},{"line_number":35,"context_line":"could include the necessary mapping information in the response with"},{"line_number":36,"context_line":"significantly less effort."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_8b2412c8","line":33,"range":{"start_line":33,"start_character":0,"end_line":33,"end_character":2},"in_reply_to":"3f79a3b5_86c6819c","updated":"2019-05-07 11:54:56.000000000","message":"Hungarian would be equally bad for this text, I guess. :D","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"709ca71d482c94c121d33f41ed89a0c277acf221","unresolved":false,"context_lines":[{"line_number":33,"context_line":"In the other hand when Placement builds an allocation candidate it does that by"},{"line_number":34,"context_line":"`building allocations for each granular request group`_. Therefore Placement"},{"line_number":35,"context_line":"could include the necessary mapping information in the response with"},{"line_number":36,"context_line":"significantly less effort."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Use Cases"},{"line_number":39,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_f9b33d09","line":36,"range":{"start_line":36,"start_character":0,"end_line":36,"end_character":25},"updated":"2018-08-30 10:55:49.000000000","message":"Yes. This information must be produced in order to answer the allocation candidate request in the first place. And then it\u0027s another (and possibly complex) question that it\u0027s  buried deep in a sql query IIUC.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":33,"context_line":"In the other hand when Placement builds an allocation candidate it does that by"},{"line_number":34,"context_line":"`building allocations for each granular request group`_. Therefore Placement"},{"line_number":35,"context_line":"could include the necessary mapping information in the response with"},{"line_number":36,"context_line":"significantly less effort."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Use Cases"},{"line_number":39,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_eb182e82","line":36,"range":{"start_line":36,"start_character":0,"end_line":36,"end_character":25},"in_reply_to":"3f79a3b5_71ee61ee","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c381c811cd22be3c3414062d13a74aa899f2b307","unresolved":false,"context_lines":[{"line_number":33,"context_line":"In the other hand when Placement builds an allocation candidate it does that by"},{"line_number":34,"context_line":"`building allocations for each granular request group`_. Therefore Placement"},{"line_number":35,"context_line":"could include the necessary mapping information in the response with"},{"line_number":36,"context_line":"significantly less effort."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Use Cases"},{"line_number":39,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_71ee61ee","line":36,"range":{"start_line":36,"start_character":0,"end_line":36,"end_character":25},"in_reply_to":"3f79a3b5_f9b33d09","updated":"2018-08-30 11:59:00.000000000","message":"Fortunately it is in the python code[11]. I will link to the placement python code where the grouping is available until a certain point in the candidate generation algorithm\n\n[1] https://github.com/openstack/nova/blob/6522ea3ecfe99cca3fb33258b11e5a1f34e6e8f0/nova/api/openstack/placement/objects/resource_provider.py#L4113","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7a5470ab9b50788102edefafcdff5e26a29bad4","unresolved":false,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The use case of the `bandwidth resource provider spec`_ applies here because to"},{"line_number":42,"context_line":"fulfill that use case in a scalable way we need to consider the change proposed"},{"line_number":43,"context_line":"in this spec."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_6e619da8","line":43,"updated":"2019-02-22 00:05:14.000000000","message":"add use cases for vgpu and cyborg","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The use case of the `bandwidth resource provider spec`_ applies here because to"},{"line_number":42,"context_line":"fulfill that use case in a scalable way we need to consider the change proposed"},{"line_number":43,"context_line":"in this spec."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_ab0a3623","line":43,"in_reply_to":"9fdfeff1_6e619da8","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"709ca71d482c94c121d33f41ed89a0c277acf221","unresolved":false,"context_lines":[{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d9c0c17f","line":50,"range":{"start_line":49,"start_character":67,"end_line":50,"end_character":18},"updated":"2018-08-30 10:55:49.000000000","message":"You mean N in resourcesN and requiredN, right?\n\nI see your example below. I can\u0027t say I like always adding the \u0027resources\u0027 prefix.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c381c811cd22be3c3414062d13a74aa899f2b307","unresolved":false,"context_lines":[{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_91c45d61","line":50,"range":{"start_line":49,"start_character":67,"end_line":50,"end_character":18},"in_reply_to":"3f79a3b5_d9c0c17f","updated":"2018-08-30 11:59:00.000000000","message":"technically N would be enough, but that would mean that the unnumbered requrest group is referred by the empty string. Which is weird.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"709ca71d482c94c121d33f41ed89a0c277acf221","unresolved":false,"context_lines":[{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_f981fdfc","line":51,"updated":"2018-08-30 10:55:49.000000000","message":"Thinking out loud: The way above nova makes up the identifiers placement will provide back-references to. Shall we open this up for other users of placement? So for example they could pass in a request group id or equivalent? If we do that do we need to persist the back-references in the allocation? If we don\u0027t this information will always have to be channeled trough nova.\n\nFor example neutron could pass in an id (e.g. the port id, but that would be opaque for nova and placement) as the request group id. If that gets stored in the allocation, neutron could update its allocations if needed without channeling this through nova.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"1a74262ab1e3c48e434079fb5b40bad877432df2","unresolved":false,"context_lines":[{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_9c6fb0c3","line":51,"in_reply_to":"3f79a3b5_06991179","updated":"2018-10-05 16:28:33.000000000","message":"I agree persistence would be unfortunate.\n\nThe suffix of a request group is in the RequestGroup object and could be carried through the construction of the response to GET /a_c? and then forgotten so I\u0027m not sure what request_group_names adds? We could instead change the schema to change the constraints on the format of the suffix.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7e38f9c118d0dbd4f8ad9998f12ed6b949a40385","unresolved":false,"context_lines":[{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_9ed241cf","line":51,"in_reply_to":"3f79a3b5_9c6fb0c3","updated":"2018-10-05 22:02:40.000000000","message":"Yes, I remember deciding to use integers, but specifically designing to make it really easy to change/extend. In fact, I *think* the only thing we would need to change is the schema, but don\u0027t quote me on that.\n\nAgree we should not persist the group names beyond the GET /a_c call - but we *can* persist them through to the output of that call, which is exactly what this spec is suggesting we do, no matter which output format we choose.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"53faa6b76d405abdbcb2071dcf68524a9b93b773","unresolved":false,"context_lines":[{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_b2482387","line":51,"in_reply_to":"3f79a3b5_9ed241cf","updated":"2019-02-11 20:17:51.000000000","message":"I would prefer either of the following:\n\n - Don\u0027t bother with separate names; just return the number as the grouping, and let the client maintain the association.\n - Change the granular pattern to \u0027resources*\u0027, where you can put anything in the wildcard, and that will be returned as the label for the grouping. \n\nI\u0027d strongly prefer *not* to have another layer of indirection, such as you\u0027d get with \u0027request_group_names\u0027.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","unresolved":false,"context_lines":[{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_06991179","line":51,"in_reply_to":"3f79a3b5_d1c6554a","updated":"2018-10-05 15:38:22.000000000","message":"I\u0027m not OK with placement persisting the name of a request group, since the request group name is an ephemeral thing (just like an allocation_request is an ephemeral thing and isn\u0027t something we persist in the placement DB).\n\nI could, however, go along with a (future) change to the placement GET /a_c API that would allow a request group to be \"named\", either by just replacing \"{N}\" with some string tag or by passing some kind of mapping in the query parameters to GET /a_c. Something like this:\n\n GET /a_c?resources\u003dVCPU:2\\\n  \u0026resources1\u003dPCPU:1\\\n  \u0026resources2\u003dPCPU:1\\\n  \u0026request_group_names\u003d0:default,1:guest-numa-0,2:guest-numa-1\n\nThe request_group_names query parameter would be optional, and if not present, the request group name would just be \"\" (for the unnumbered group) or the number for numbered groups.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c381c811cd22be3c3414062d13a74aa899f2b307","unresolved":false,"context_lines":[{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d1c6554a","line":51,"in_reply_to":"3f79a3b5_f981fdfc","updated":"2018-08-30 11:59:00.000000000","message":"GET /allocaton_candidates?required\u003cport_uuid\u003e\u003dNET_BANDWIDTH_EGRESS_KILOBITS_PER_SECOND\u003d2000\n\nI think extending the schema of the group id from positive integers to uuid\u0027s or simply strings with a length limit would not be hard.\n\nHowever persisting that group id in placement when the allocation is persisted is a bit more controversial, I guess. \n\nFor me that would mean placement starts supporting hierarchical consumers. Today each allocation is identified by a single consumer_uuid. After we implement what you propose it would be a tree of consumers. For atomicity we would still need a root consumer to handle the whole consumption but placement would also store sub consumers that individually own only some part of the whole consumption.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7a5470ab9b50788102edefafcdff5e26a29bad4","unresolved":false,"context_lines":[{"line_number":48,"context_line":"Extend the response of the ``GET /allocation_candidates`` API with"},{"line_number":49,"context_line":"an extra field ``contributes_to`` for each RP. This field contains the names of"},{"line_number":50,"context_line":"the request groups an RP from a given allocation candidate provides resources"},{"line_number":51,"context_line":"for."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_ae66a5ba","line":51,"in_reply_to":"9fdfeff1_b2482387","updated":"2019-02-22 00:05:14.000000000","message":"++ Ed\u0027s summary","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"53faa6b76d405abdbcb2071dcf68524a9b93b773","unresolved":false,"context_lines":[{"line_number":63,"context_line":"  Compute RP (name\u003dcompute1, uuid\u003dcompute_uuid)"},{"line_number":64,"context_line":"   +    CPU \u003d 1"},{"line_number":65,"context_line":"   |    MEMORY \u003d 1024"},{"line_number":66,"context_line":"   |    DSIK \u003d 10"},{"line_number":67,"context_line":"   |"},{"line_number":68,"context_line":"   +--+Network agent RP (for SRIOV agent),"},{"line_number":69,"context_line":"          +    uuid\u003dsriov_agent_uuid"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_d230470a","line":66,"range":{"start_line":66,"start_character":8,"end_line":66,"end_character":13},"updated":"2019-02-11 20:17:51.000000000","message":"DISK","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":63,"context_line":"  Compute RP (name\u003dcompute1, uuid\u003dcompute_uuid)"},{"line_number":64,"context_line":"   +    CPU \u003d 1"},{"line_number":65,"context_line":"   |    MEMORY \u003d 1024"},{"line_number":66,"context_line":"   |    DSIK \u003d 10"},{"line_number":67,"context_line":"   |"},{"line_number":68,"context_line":"   +--+Network agent RP (for SRIOV agent),"},{"line_number":69,"context_line":"          +    uuid\u003dsriov_agent_uuid"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_2652fd14","line":66,"range":{"start_line":66,"start_character":8,"end_line":66,"end_character":13},"in_reply_to":"9fdfeff1_d230470a","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Filter scheduler selects the first candidate that points to"},{"line_number":147,"context_line":"uuid5(compute1:eth0)"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"Nova needs to find the RP in the selected allocation candidate which"},{"line_number":150,"context_line":"provides the resources the Neutron port is requested. Nova does this"},{"line_number":151,"context_line":"by checking which RP provides the matching resource classes and resource"},{"line_number":152,"context_line":"amounts."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"During port binding nova updates the port with that network device RP::"},{"line_number":155,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a048212e","line":152,"range":{"start_line":149,"start_character":0,"end_line":152,"end_character":8},"updated":"2018-10-05 15:38:22.000000000","message":"Please be as explicit here as possible. When you say \"Nova needs to find...\", you are referring to the nova-compute worker and the Neutron SR-IOV agent (not the nova scheduler or nova conductor, etc).\n\nAlso, it\u0027s not that nova-compute \"needs to find the RP in the selected allocation candidate\". What nova-compute needs to do is simply pass the resource provider UUID to the Neutron SR-IOV agent so that the SR-IOV agent can identify which physical network interface to place the instance\u0027s port on, right? nova-compute actually doesn\u0027t really need to do much at all other than pass the identifier along to the SR-IOV agent...\n\nThe only place where this gets complicated/messy is when there are multiple ports and nova-compute will need to look at the port binding request information for those ports, look at the allocation candidate resources and provider summary traits and determine which resource provider UUID to pass to the SR-IOV agent for a particular Neutron port.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Filter scheduler selects the first candidate that points to"},{"line_number":147,"context_line":"uuid5(compute1:eth0)"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"Nova needs to find the RP in the selected allocation candidate which"},{"line_number":150,"context_line":"provides the resources the Neutron port is requested. Nova does this"},{"line_number":151,"context_line":"by checking which RP provides the matching resource classes and resource"},{"line_number":152,"context_line":"amounts."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"During port binding nova updates the port with that network device RP::"},{"line_number":155,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_a6d90d84","line":152,"range":{"start_line":149,"start_character":0,"end_line":152,"end_character":8},"in_reply_to":"3f79a3b5_a048212e","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"047a36cb7f1ffab7e0b685493548639588778319","unresolved":false,"context_lines":[{"line_number":269,"context_line":"* port1 - uuid5(compute1:eth0)"},{"line_number":270,"context_line":"* port2 - uuid5(compute1:eth1)"},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"When Nova tries to map the first port, port1, then both"},{"line_number":273,"context_line":"uuid5(compute1:eth0) and uuid5(compute1:eth1) still has enough"},{"line_number":274,"context_line":"resources in the allocation request to match with the request of port1. So at"},{"line_number":275,"context_line":"that point Nova can map port1 to uuid5(compute1:eth1). However this means"},{"line_number":276,"context_line":"that Nova will not find any viable mapping later for port2 and therefore Nova"},{"line_number":277,"context_line":"has to go back an retry to create the  mapping with port1 mapped to the other"},{"line_number":278,"context_line":"alternative. This means that Nova needs to implement a full backtracking"},{"line_number":279,"context_line":"algorithm to find the proper mapping."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Scaling considerations"},{"line_number":282,"context_line":"......................"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_9759a38f","line":279,"range":{"start_line":272,"start_character":0,"end_line":279,"end_character":37},"updated":"2019-02-20 05:31:11.000000000","message":"Why we don\u0027t check the request with the response of allocation_candidates? The port2 wants 2000 ingresss bandwidth, and the response of allocation_candidates tell you that 2000 ingress is allocated from eth1, line 239. Then we won\u0027t have this problem.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":269,"context_line":"* port1 - uuid5(compute1:eth0)"},{"line_number":270,"context_line":"* port2 - uuid5(compute1:eth1)"},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"When Nova tries to map the first port, port1, then both"},{"line_number":273,"context_line":"uuid5(compute1:eth0) and uuid5(compute1:eth1) still has enough"},{"line_number":274,"context_line":"resources in the allocation request to match with the request of port1. So at"},{"line_number":275,"context_line":"that point Nova can map port1 to uuid5(compute1:eth1). However this means"},{"line_number":276,"context_line":"that Nova will not find any viable mapping later for port2 and therefore Nova"},{"line_number":277,"context_line":"has to go back an retry to create the  mapping with port1 mapped to the other"},{"line_number":278,"context_line":"alternative. This means that Nova needs to implement a full backtracking"},{"line_number":279,"context_line":"algorithm to find the proper mapping."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Scaling considerations"},{"line_number":282,"context_line":"......................"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_26899d74","line":279,"range":{"start_line":272,"start_character":0,"end_line":279,"end_character":37},"in_reply_to":"9fdfeff1_9759a38f","updated":"2019-05-07 11:54:56.000000000","message":"In general ordering by resource size is problematic for two reasons:\n1) two groups might be fulfilled from the same RP (if group_policy\u003dNone)\n2) we have more than one resource class (IGR, EGR) so if one port has bigger allocation from IGR and the other has bigger allocation from EGR then there is no good ordering to start with.\n\nAlso see examples in the test in [1] https://review.opendev.org/#/c/616239/33/nova/tests/unit/objects/test_request_spec.py@1305\n\n[1]","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c381c811cd22be3c3414062d13a74aa899f2b307","unresolved":false,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Note that our example uses the group_policy\u003disolate query param"},{"line_number":291,"context_line":"so the RPs in the allocation candidate cannot overlap. If we set"},{"line_number":292,"context_line":"group_policy\u003dnone and therefore allow RP overlapping then in the"},{"line_number":293,"context_line":"worst case we have 4^4 (256) possible mappings. With 4 steps to"},{"line_number":294,"context_line":"generate each the number of steps in the worst case are 1024."},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"Note that even if having more than 4 ports for an server considered"},{"line_number":297,"context_line":"unrealistic, additional granular request groups can appear in the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_11edad8a","line":294,"range":{"start_line":292,"start_character":61,"end_line":294,"end_character":61},"updated":"2018-08-30 11:59:00.000000000","message":"I got a bit unsure that there would be a realization of such exponential worst case because if an RP is returned in a candidate then we can be sure that something will allocate from it. Still the factorial grows pretty rapidly.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Note that our example uses the group_policy\u003disolate query param"},{"line_number":291,"context_line":"so the RPs in the allocation candidate cannot overlap. If we set"},{"line_number":292,"context_line":"group_policy\u003dnone and therefore allow RP overlapping then in the"},{"line_number":293,"context_line":"worst case we have 4^4 (256) possible mappings. With 4 steps to"},{"line_number":294,"context_line":"generate each the number of steps in the worst case are 1024."},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"Note that even if having more than 4 ports for an server considered"},{"line_number":297,"context_line":"unrealistic, additional granular request groups can appear in the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_866969bf","line":294,"range":{"start_line":292,"start_character":61,"end_line":294,"end_character":61},"in_reply_to":"3f79a3b5_11edad8a","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","unresolved":false,"context_lines":[{"line_number":331,"context_line":"                    \"NET_BANDWIDTH_EGRESS_KILOBITS_PER_SECOND\":1000,"},{"line_number":332,"context_line":"                    \"NET_BANDWIDTH_INGRESS_KILOBITS_PER_SECOND\":1000"},{"line_number":333,"context_line":"                 },"},{"line_number":334,"context_line":"                \"contributes_to\": [\"resources1\"]"},{"line_number":335,"context_line":"              },"},{"line_number":336,"context_line":"              uuid5(compute1:eth1):{"},{"line_number":337,"context_line":"                \"resources\":{"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_66fb2548","line":334,"range":{"start_line":334,"start_character":16,"end_line":334,"end_character":48},"updated":"2018-10-05 15:38:22.000000000","message":"This is fine. I would support calling the attribute \"request_groups\" instead of \"contributes_to\", though.\n\n\"request_groups\" is clearer to me that \"this provider\u0027s resources (and traits) match the constraints for THESE request groups\".","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"00531253d6c880042a959fa0ac7c9d36c11f7338","unresolved":false,"context_lines":[{"line_number":331,"context_line":"                    \"NET_BANDWIDTH_EGRESS_KILOBITS_PER_SECOND\":1000,"},{"line_number":332,"context_line":"                    \"NET_BANDWIDTH_INGRESS_KILOBITS_PER_SECOND\":1000"},{"line_number":333,"context_line":"                 },"},{"line_number":334,"context_line":"                \"contributes_to\": [\"resources1\"]"},{"line_number":335,"context_line":"              },"},{"line_number":336,"context_line":"              uuid5(compute1:eth1):{"},{"line_number":337,"context_line":"                \"resources\":{"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_e282f9c6","line":334,"range":{"start_line":334,"start_character":16,"end_line":334,"end_character":48},"in_reply_to":"3f79a3b5_66fb2548","updated":"2019-04-10 14:39:06.000000000","message":"Agree with this.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","unresolved":false,"context_lines":[{"line_number":358,"context_line":""},{"line_number":359,"context_line":""},{"line_number":360,"context_line":"If the ``group_policy\u003disolate`` is in the request then every RP can only"},{"line_number":361,"context_line":"contribute to a single group. However when ``group_policy\u003dNone`` is in"},{"line_number":362,"context_line":"the request a single RP might contribute to more than one request group."},{"line_number":363,"context_line":""},{"line_number":364,"context_line":"Note that this new field is not part of the POST /allocations schema so the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e6c65516","line":361,"range":{"start_line":361,"start_character":58,"end_line":361,"end_character":59},"updated":"2018-10-05 15:38:22.000000000","message":"none","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"709ca71d482c94c121d33f41ed89a0c277acf221","unresolved":false,"context_lines":[{"line_number":424,"context_line":"     }"},{"line_number":425,"context_line":""},{"line_number":426,"context_line":"     \"resource_provider-request_group-mappings\":["},{"line_number":427,"context_line":"         {"},{"line_number":428,"context_line":"             uuid5(compute1:eth0): [\"resources1\"],"},{"line_number":429,"context_line":"             uuid5(compute1:eth1): [\"resources2\"],"},{"line_number":430,"context_line":"             compute_uuid: [\"resources\"]"},{"line_number":431,"context_line":"         },"},{"line_number":432,"context_line":"         {"},{"line_number":433,"context_line":"             uuid5(compute1:eth0): [\"resources2\"],"},{"line_number":434,"context_line":"             uuid5(compute1:eth1): [\"resources1\"],"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_ffaf9d7a","line":431,"range":{"start_line":427,"start_character":0,"end_line":431,"end_character":11},"updated":"2018-08-30 10:55:49.000000000","message":"I\u0027d choose the \u0027contributes_to\u0027 syntax if we want to persist the back-references. But choose this syntax, if we don\u0027t.\n\nIf we choose this, I\u0027d recommend reversing the dict:\n\n {resource_group_name: [rp, ...], ...}\n\nBecause that yields to more straightforward lookups.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":424,"context_line":"     }"},{"line_number":425,"context_line":""},{"line_number":426,"context_line":"     \"resource_provider-request_group-mappings\":["},{"line_number":427,"context_line":"         {"},{"line_number":428,"context_line":"             uuid5(compute1:eth0): [\"resources1\"],"},{"line_number":429,"context_line":"             uuid5(compute1:eth1): [\"resources2\"],"},{"line_number":430,"context_line":"             compute_uuid: [\"resources\"]"},{"line_number":431,"context_line":"         },"},{"line_number":432,"context_line":"         {"},{"line_number":433,"context_line":"             uuid5(compute1:eth0): [\"resources2\"],"},{"line_number":434,"context_line":"             uuid5(compute1:eth1): [\"resources1\"],"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_460291b6","line":431,"range":{"start_line":427,"start_character":0,"end_line":431,"end_character":11},"in_reply_to":"3f79a3b5_b18639ba","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c381c811cd22be3c3414062d13a74aa899f2b307","unresolved":false,"context_lines":[{"line_number":424,"context_line":"     }"},{"line_number":425,"context_line":""},{"line_number":426,"context_line":"     \"resource_provider-request_group-mappings\":["},{"line_number":427,"context_line":"         {"},{"line_number":428,"context_line":"             uuid5(compute1:eth0): [\"resources1\"],"},{"line_number":429,"context_line":"             uuid5(compute1:eth1): [\"resources2\"],"},{"line_number":430,"context_line":"             compute_uuid: [\"resources\"]"},{"line_number":431,"context_line":"         },"},{"line_number":432,"context_line":"         {"},{"line_number":433,"context_line":"             uuid5(compute1:eth0): [\"resources2\"],"},{"line_number":434,"context_line":"             uuid5(compute1:eth1): [\"resources1\"],"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_b18639ba","line":431,"range":{"start_line":427,"start_character":0,"end_line":431,"end_character":11},"in_reply_to":"3f79a3b5_ffaf9d7a","updated":"2018-08-30 11:59:00.000000000","message":"can be done.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"change_message_id":"709ca71d482c94c121d33f41ed89a0c277acf221","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_3fdbd521","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"updated":"2018-08-30 10:55:49.000000000","message":"I don\u0027t get this. Could you clarify?","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c381c811cd22be3c3414062d13a74aa899f2b307","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_f13831ef","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"3f79a3b5_3fdbd521","updated":"2018-08-30 11:59:00.000000000","message":"The response of GET /allocation_candidates contains one or more allocation_requests (e.g. one or more candidates). Each candidate contains one or more RPs. For each candidate we need to return a mapping between groups in the request and RPs in the candidate. So there will the same number of mappings returned as candidates. The connection between the a candidate and the related mapping is that they have the same list index in their respective lists.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"53faa6b76d405abdbcb2071dcf68524a9b93b773","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_4daefae7","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"3f79a3b5_b1528367","updated":"2019-02-11 20:17:51.000000000","message":"An allocation request is ideally a black box, and consumers shouldn\u0027t have to muck with it in order to claim resources. If you want to add the mappings, it should be at the level of \"provider_summaries\" somehow.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b55db81c8801cbf09f66f5fde35088fdfa5f5362","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_b1528367","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"3f79a3b5_f13831ef","updated":"2018-09-27 18:04:39.000000000","message":"Yeah, that\u0027s pretty gross.\n\nYou could split the difference and make the mapping information a key at the same level as \"allocations\":\n\n\n  {\n     \"allocation_requests\":[\n        {\n           \"allocations\":{\n               // unchanged\n           }\n           \"mappings: {\n               // new info goes here\n           }\n        },\n        ...,\n     ],\n     \"provider_summaries\":{\n         // unchanged\n     }\n }\n\nAt that point, we would have to do one of:\n\n- Modify PUT/POST /allocations to accept but ignore the \"mappings\" key (ew), or\n- Require the API consumer to remove the \"mappings\" item before sending the allocation (also ew).\n- Modify PUT/POST /allocations to accept just the inner dict - why do we need the outer {\"allocations\":{...}} wrapper anyway? :P","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"94fd6990a06b04e2b996717e8ad9b33e6103aaf2","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_bf3abe94","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"9fdfeff1_08072484","updated":"2019-02-28 22:57:16.000000000","message":"\u003e So, for example the process for the scheduler making a claim (an\n \u003e operation we most want to not be noisy and complicated) would be:\n \u003e \n \u003e * remove the mappings key\n \u003e * add the generation and project/user keys\n \u003e * PUT\n\nSorry, I completely don\u0027t understand why\n\n alloc_req \u003d resp.json()[\u0027allocation_requests\u0027][N]\n # This is new\n del alloc_req[\u0027mappings\u0027]\n add_generation_proj_user(alloc_req, ...)\n put(alloc_req)\n\nis more desirable than\n\n # [\u0027allocation_request\u0027] is new\n alloc_req \u003d resp.json()[\u0027allocation_requests\u0027][N][\u0027allocation_request\u0027]\n add_generation_proj_user(alloc_req, ...)\n put(alloc_req)\n\nIMO either one is equally (minimally) disruptive to the calling code. But the former violates the black-box-ness of the allocation request.\n\nThat said, I\u0027ll go on record, in case I haven\u0027t already done so somewhere, as saying that I feel the whole black box thing is an artificial and unnecessary restriction, is being violated already, and will continue to be violated in the future, and we should let it go. So for me, either way is fine. I would also be fine with updating PUT /allocations to accept and ignore the new mappings dict.\n\nMy hard -1 is on anything that requires us to track mappings from waay over there against allocation requests from waay over here by matching their list indices. That is suck.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"56cbf6d2af805592877df3ee8506b2262ceab610","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_08072484","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"9fdfeff1_2ee875b1","updated":"2019-02-28 13:36:44.000000000","message":"We need to keep in mind that even with microversions, changing the structure of the response, internally, has an outsized impact on clients that make requests of the resource. Sure, they can choose to use an older microversion, but what if they want the feature that comes after the microversion that supports _this_?\n\nWe especially don\u0027t want to make people have to change code that descends a dict mapping: \"no\" to key1.key2.key3 -\u003e key1.newkey.key2.key3 and things like that.\n\nInstead we want to make it easy for people to say \"if microversion X, process the result like Y\" and that\u0027s _way_ easier when the new information is added as a top level key (as Ed suggests).\n\nHowever as many have pointed out that makes the linking between specific allocation requests and the mappings a bit icky, including on the server side where we would have to care about order of different things while serializing (which would be nice to avoid).\n\nTherefore, Eric\u0027s first suggestion (\u0027mappings\u0027 at the level of \u0027allocations\u0027) might be the right thing because:\n\n* In the same overall dict, so the association is clear\n* at the same \"height\" in the dict of consumer_generation, and project and user uuid, which end up getting manipulated at that height, despite our hopes for black boxing.\n\nSo, for example the process for the scheduler making a claim (an operation we most want to not be noisy and complicated) would be:\n\n* remove the mappings key\n* add the generation and project/user keys\n* PUT\n\n(We _might_ (might!) even consider allowing an allocation to be PUT with mappings intact, they would get ignored.)\n\nIf we didn\u0027t already have the generation and user/project stuff, I\u0027d be very much against this, but it might be right (not saying it is, saying it is worth more thought and discussion).\n\nBut definitely no to \"jam another level of dict\".","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7a5470ab9b50788102edefafcdff5e26a29bad4","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_2ee875b1","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"9fdfeff1_4daefae7","updated":"2019-02-22 00:05:14.000000000","message":"\u003e An allocation request is ideally a black box, and consumers\n \u003e shouldn\u0027t have to muck with it in order to claim resources.\n\nUgh, right, because the \"black box\" actually extends to the { } containing the \"allocations\" key.\n\n \u003e If you\n \u003e want to add the mappings, it should be at the level of\n \u003e \"provider_summaries\" somehow.\n\nBut then we have the same problem of needing to map each mapping back to its appropriate allocation request by index (or something else).\n\nWe could jam another level of dict in the allocation_requests list:\n\n  {\n     \"allocation_requests\":[\n        {\n           \"allocation_request\": {\n              \"allocations\":{\n                  // unchanged\n              }\n           },\n           \"mappings: {\n               // new info goes here\n           }\n        },\n        ...,        \n     ],\n     \"provider_summaries\":{\n         // unchanged\n     }\n }\n\nSo now allocation_requests[n][\u0027mappings\u0027] tells us which rg belongs to which RP; and we PUT /allocs with allocation_requests[n][\u0027allocation_request\u0027] instead of allocation_requests[n] - same black box.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"67e6fcea8c16f5194eba0922b94369dcf19b7111","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_74351ddb","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"9fdfeff1_6321f3fc","updated":"2019-03-04 22:51:16.000000000","message":"Not to be pedantic [1], but we did something like this (only more disruptive) to flip allocations from list-ish to dict-ish, and we didn\u0027t change the existing gabbi tests, because they were still valid at the old microversion. Rather, we added new tests for the new format at the new microversion.\n\nLikewise, other calling code that was using the old format would continue to do so by taking no action. If it actually needed the new format, it would bump the request microversion (1LOC) and change the response payload processing (1LOC) for that one code path; and then do whatever to use the new bits.\n\nAnyway, like I said, I don\u0027t care either way on that as long as we don\u0027t do it by list index.\n\n[1] Okay, to be pedantic","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_c6276164","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"9fdfeff1_6a59b659","updated":"2019-05-07 11:54:56.000000000","message":"Done","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"228ac0e7460d946f9789f71ab776425a825ea660","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_6a59b659","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"9fdfeff1_74351ddb","updated":"2019-03-05 01:50:43.000000000","message":"Sorry, I was being implicit when I should have been explicit. And because we seem to be down a hole of pedantry, I\u0027ll go all in.\n\nWhen I said \"think of it from the standpoint of ... gabbi\" I wasn\u0027t meaning the actual changes _we_ would need to _our_ gabbi, but rather changes someone else would need to make in their code that uses a similar path oriented approach as the one that gabbi makes visible.\n\nYes, we have microversions that helps ride over this stuff, but every time we do a microversion we are inspiring a delta to the various bits of client code that might exist out there [1] and where possible we\u0027d like to make that delta as small as possible. I\u0027m trying to suggest, but I guess not succeeding all that well, that there is a principle at play here which is that breadth oriented change is easier to manage than depth oriented change when working with graph-like data structures (which we are). Especially in the context of HTTP apis and [1].\n\nI\u0027m willing to accept that I\u0027ve gotten wrong the application of the general ideas I\u0027m stating here. It might be that in the case of the allocation_candidates response the impact is different. However, I\u0027m quite certain about the general ideas.\n\n[1] Even when it is not really the case, I think it is useful and important to consider and remember that the point of an HTTP is not to provide resource interaction for \"my\" client. It is for any clients, and those clients may have an interaction model that is different from what we\u0027ve conceived in our local environment. If we accept that, then it is useful and important to follow some good rules of thumb about how you\u0027re changing the structure of data.","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"07a0e4663b7afdf5112dd758175e119c356e654d","unresolved":false,"context_lines":[{"line_number":443,"context_line":"to do the allocation."},{"line_number":444,"context_line":""},{"line_number":445,"context_line":"This has the disadvantage that one mapping in the"},{"line_number":446,"context_line":"``resource_provider-request_group-mappings`` connected to one candidate"},{"line_number":447,"context_line":"in the allocation_requests list by the list index only."},{"line_number":448,"context_line":""},{"line_number":449,"context_line":"Security impact"},{"line_number":450,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_6321f3fc","line":447,"range":{"start_line":446,"start_character":45,"end_line":447,"end_character":55},"in_reply_to":"9fdfeff1_bf3abe94","updated":"2019-03-04 14:02:00.000000000","message":"Perhaps think of it from the standpoint of how many gabbi tests you would have to change to account for the new nested-ness versus what you would need to change to account for a new field that was not nested?","commit_id":"73a7bb04a7ee8226e42da9c17e8ae9961a85978b"}]}