)]}'
{"specs/pike/approved/placement-allocation-requests.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"39e529f15c75e04617eb77b06e43b5daca68dd26","unresolved":false,"context_lines":[{"line_number":47,"context_line":"We propose adding a new `GET /allocation_requests` REST API endpoint that will"},{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f0e0f27_033db1ba","line":50,"updated":"2017-06-09 12:27:49.000000000","message":"What\u0027s the plan for how the scheduler is using the information? I get that the allocation bodies can be used raw to make an allocation based on a choice of provider(s). What\u0027s less clear is how the scheduler will be processing the extra info.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1d80e6a381bbf4ebbc970fe8d36b2a299b5ffb03","unresolved":false,"context_lines":[{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"},{"line_number":54,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_560d8f3c","line":51,"updated":"2017-06-08 14:51:54.000000000","message":"Since placement can\u0027t rank or otherwise prefer one resource over another, it would have to return all possible child providers of that resource.\n\nConsider the case of a compute node with an FPGA that has 8 programmable slots, all flashed with the same program, and each slot can supply multiple VFs. The slot in this scenario is the ultimate resource provider, and the VFs are its inventroy. So the relationship is CN -\u003e FPGA -\u003e multiple slots -\u003e multiple VFs. And if there were more than one FPGA on a compute node... :)\n\nPlacement doesn\u0027t have the logic to select one slot over another, so it would have to return all of them that have inventory for the requested VF. Wouldn\u0027t this mean that this compute node, assuming it met the request\u0027s requirements, would have to be returned 8 times, each with a different RP, representing one of the programmed slots? The only other alternative is to pick one of them at random, but this would take away the ability of the calling service to do the specific filtering and weighing required to optimally use that device.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"6c63cdea4a03717b64915ebe4729357e7d01ac65","unresolved":false,"context_lines":[{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"},{"line_number":54,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f0e0f27_b6b40137","line":51,"in_reply_to":"bf091321_3e2e6aa5","updated":"2017-06-09 13:29:31.000000000","message":"OK, *if* they all have the same algorithm and *if* that never changes, and *if* there is no involvement with SR-IOV/NUMA, that would be true. I\u0027m not terribly confident that this will always be true, especially in the future.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d64e03cdc4347afee94668e55741c91faea5de32","unresolved":false,"context_lines":[{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"},{"line_number":54,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_3e2e6aa5","line":51,"in_reply_to":"bf091321_560d8f3c","updated":"2017-06-09 01:17:19.000000000","message":"Not sure if you\u0027re asking a question here or just commenting that the list of possible alternatives may be large... which is definitely true.\n\nAlso, for the record, what you are describing above with the FPGAs is actually considerably less complex than you describe. If the FPGA slots are all flashed with the same accelerated algorithm, then the resource provider would be the FPGA itself, not the slot, and the inventory record would be (FPGA_UUID, CUSTOM_ACCEL_ALGO, $NUM_GUEST_CONTEXTS). The FPGA would be a child of the compute node, but there\u0027d be no need to have further levels of nested.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2efc842f04449e493d33e95a92d29258f823720e","unresolved":false,"context_lines":[{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"},{"line_number":54,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_9e87b6d8","line":51,"in_reply_to":"bf091321_560d8f3c","updated":"2017-06-08 18:29:08.000000000","message":"What you describe is the duty of the nova scheduler: to weigh all the options that have space to find the best one. We don\u0027t have to return all of them, we have to support paginated results and let the nova scheduler decide how many it wants to look through.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"97067d5904878d49ed25d84fa3df45a9e5780057","unresolved":false,"context_lines":[{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"},{"line_number":54,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_ea994c1f","line":51,"in_reply_to":"bf091321_9e87b6d8","updated":"2017-06-08 20:52:26.000000000","message":"Or, we could just do things the way they currently work, getting the information from the HostState object to make these decisions.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1d80e6a381bbf4ebbc970fe8d36b2a299b5ffb03","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"There were a number of alternative approaches considered by the team."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Alternative 1 was to have the Placement API transparently claim resources on"},{"line_number":59,"context_line":"more than one provider. The scheduler would pick the primary resource provider"},{"line_number":60,"context_line":"(compute node), attempt to `POST /allocations/{consumer_uuid}` to claim"},{"line_number":61,"context_line":"resources against that compute node, and the placement API would write"},{"line_number":62,"context_line":"allocation records for resources against *that* compute node resource provider"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_b72ce647","line":59,"range":{"start_line":58,"start_character":0,"end_line":59,"end_character":23},"updated":"2017-06-08 14:51:54.000000000","message":"Alternative One was to have no change to the placement API -\n GET /resource_providers would work exactly the same, and return compute node UUIDs as it does now. The scheduler would use those to create HostState objects, as it does now, and use the information in those objects to make its filtering and weighing calculations, as it does now. When it chose a host, it would claim those resources by a POST /allocations{consumer_id}, as it does now.\n\nThe one change is that the placement engine would then use the same sort of logic that it does when determining if a compute node has sufficient resources from shared and/or nested providers. It would run the same query to get a list of the providers that would be used to satisfy the request for that primary provider, and then claim against those providers instead of just the compute node.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"1764c64339cf5e0cd42d6bf2edbd48013a2792c8","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"There were a number of alternative approaches considered by the team."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Alternative 1 was to have the Placement API transparently claim resources on"},{"line_number":59,"context_line":"more than one provider. The scheduler would pick the primary resource provider"},{"line_number":60,"context_line":"(compute node), attempt to `POST /allocations/{consumer_uuid}` to claim"},{"line_number":61,"context_line":"resources against that compute node, and the placement API would write"},{"line_number":62,"context_line":"allocation records for resources against *that* compute node resource provider"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f0e0f27_b672c110","line":59,"range":{"start_line":58,"start_character":0,"end_line":59,"end_character":23},"in_reply_to":"9f0e0f27_96d1fd5a","updated":"2017-06-09 13:43:21.000000000","message":"\"It would run the same query to get a list of the providers that would be used to satisfy the request for that primary provider, and then claim against those providers instead of just the compute node.\"\n\nHow is the above not \"proposing the placement engine select anything\"?","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"6c63cdea4a03717b64915ebe4729357e7d01ac65","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"There were a number of alternative approaches considered by the team."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Alternative 1 was to have the Placement API transparently claim resources on"},{"line_number":59,"context_line":"more than one provider. The scheduler would pick the primary resource provider"},{"line_number":60,"context_line":"(compute node), attempt to `POST /allocations/{consumer_uuid}` to claim"},{"line_number":61,"context_line":"resources against that compute node, and the placement API would write"},{"line_number":62,"context_line":"allocation records for resources against *that* compute node resource provider"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f0e0f27_96d1fd5a","line":59,"range":{"start_line":58,"start_character":0,"end_line":59,"end_character":23},"in_reply_to":"bf091321_9abfb7fa","updated":"2017-06-09 13:29:31.000000000","message":"I didn\u0027t propose that the placement engine select anything. It was just a small clarification of what you wrote, which I felt did not clearly explain that alternative. Of course there will be more details involved, but I wasn\u0027t attempting to write an alternative spec. I just wanted to respond to a spec that I felt was written before we understood the implications of these decisions.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d64e03cdc4347afee94668e55741c91faea5de32","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"There were a number of alternative approaches considered by the team."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Alternative 1 was to have the Placement API transparently claim resources on"},{"line_number":59,"context_line":"more than one provider. The scheduler would pick the primary resource provider"},{"line_number":60,"context_line":"(compute node), attempt to `POST /allocations/{consumer_uuid}` to claim"},{"line_number":61,"context_line":"resources against that compute node, and the placement API would write"},{"line_number":62,"context_line":"allocation records for resources against *that* compute node resource provider"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_9abfb7fa","line":59,"range":{"start_line":58,"start_character":0,"end_line":59,"end_character":23},"in_reply_to":"bf091321_b72ce647","updated":"2017-06-09 01:17:19.000000000","message":"Ed, the placement engine won\u0027t be able to *select* which child provider to consume from, though. The scheduler is the thing that chooses from the alternatives that the placement API has said match the required resource capacities and trait associations. The placement API does not do sorting/choosing. It merely advises the scheduler what resource providers have the capacity to fulfill a particular request.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1d80e6a381bbf4ebbc970fe8d36b2a299b5ffb03","unresolved":false,"context_lines":[{"line_number":211,"context_line":"        }"},{"line_number":212,"context_line":"        }"},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    ]"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Security impact"},{"line_number":217,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_347d74b1","line":214,"updated":"2017-06-08 14:51:54.000000000","message":"In this example, you added traits that allowed placement to choose between SRIOV_PF0 and SRIOV_PF1. In the case where both PFs could satisfy the request, or multiple NICs were present that could satify the request, this would have to be repeated for each possible combination that could satisfy the request. Additionally, this is just for *1* possible compute node. In a deployment with many hosts that have NICs, this could return hundreds or thousands of hosts.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5f234a89cb3ddbbb5214e3c60ad85072db63ac3b","unresolved":false,"context_lines":[{"line_number":211,"context_line":"        }"},{"line_number":212,"context_line":"        }"},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    ]"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Security impact"},{"line_number":217,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_52cb74a4","line":214,"updated":"2017-06-07 22:20:11.000000000","message":"So I think I\u0027m pretty much fine with this as it is, assuming we\u0027re going to leave this here, try to implement it and see how it goes.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2efc842f04449e493d33e95a92d29258f823720e","unresolved":false,"context_lines":[{"line_number":211,"context_line":"        }"},{"line_number":212,"context_line":"        }"},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    ]"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Security impact"},{"line_number":217,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_7e550250","line":214,"in_reply_to":"bf091321_347d74b1","updated":"2017-06-08 18:29:08.000000000","message":"Yeah, we said that on the hangout right? We\u0027d have to return a lot of things, paginated, but that\u0027s okay and kindof what we want/need in scheduler. It\u0027s not any different with this approach vs just doing all of this in the scheduler, other than that placement is returning coherent options that would be laborious for the scheduler to build without all the information that placement has.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"6c63cdea4a03717b64915ebe4729357e7d01ac65","unresolved":false,"context_lines":[{"line_number":211,"context_line":"        }"},{"line_number":212,"context_line":"        }"},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    ]"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Security impact"},{"line_number":217,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f0e0f27_d6c41543","line":214,"in_reply_to":"bf091321_7e550250","updated":"2017-06-09 13:29:31.000000000","message":"The pagination would be sorted, but not in a useful way. Rather, it would be the implicit sort as returned by the database. This means that there is no guarantee that the choice that the scheduler would make would be on any particular page of the results. So pagination is not a solution; it\u0027s simply an implementation detail to deal with the fact that this proposal changes the information that the scheduler receives from placement from, say, thousands of UUIDs to thousands of JSON blobs. A quick calculation shows that even if you remove all the spaces and newlines from the above, this increases the size of the response almost 40-fold.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"1d80e6a381bbf4ebbc970fe8d36b2a299b5ffb03","unresolved":false,"context_lines":[{"line_number":235,"context_line":"request for resources/traits and allowing the Nova scheduler to iterate over"},{"line_number":236,"context_line":"these allocation requests, retrying them if a concurrent claim happens, should"},{"line_number":237,"context_line":"actually increase the throughput of the Nova scheduler by reducing the amount"},{"line_number":238,"context_line":"of time between resource constraint retries."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Other deployer impact"},{"line_number":241,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_d413d865","line":238,"updated":"2017-06-08 14:51:54.000000000","message":"It doesn\u0027t seem to be significantly different as compared to the generic \"scheduler does the claiming\" pattern.\n\nThere may also be a performance impact when returning alternatives to the conductor, as this allocation structure will have to be passed to the cell conductors in the event that a build fails and it needs to retry. This is needed so that the cell conductor can a) unclaim the resources for the failed build, and b) claim them for any retries.\n\nUsing the Alternative 1 mentioned above, none of this logic would have to change. The flow from scheduler to super conductor to cell conductor would work exactly the same.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"1764c64339cf5e0cd42d6bf2edbd48013a2792c8","unresolved":false,"context_lines":[{"line_number":235,"context_line":"request for resources/traits and allowing the Nova scheduler to iterate over"},{"line_number":236,"context_line":"these allocation requests, retrying them if a concurrent claim happens, should"},{"line_number":237,"context_line":"actually increase the throughput of the Nova scheduler by reducing the amount"},{"line_number":238,"context_line":"of time between resource constraint retries."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Other deployer impact"},{"line_number":241,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f0e0f27_56136567","line":238,"in_reply_to":"9f0e0f27_f63719e3","updated":"2017-06-09 13:43:21.000000000","message":"\"The only reason to pass the implementation details of placement to the scheduler is so that it knows how to make direct claims against the ultimate RPs, rather than the root RP. Any of the information for filtering/weighing will continue to be provided by HostState. If more information about the host is required, then it is HostState that needs to be updated to include it.\"\n\nSo you\u0027re saying above that the HostState object should be updated to understand that a compute node is on shared storage or that a compute node? Or that the HostState object should contain information about the relationship between SR-IOV physical functions to each other? The Placement API, with the shared-resources-pike and nested-resource-providers blueprints, is the thing that is being updated by the resource trackers to understand this type of information. Are you recommending that we undo all of that and have the resource trackers send that information to the scheduler so that it can update its HostState objects? That seems like it\u0027s pretty much the opposite direction we\u0027ve been trying to go...\n\n\"Wouldn\u0027t it make more sense to simply add either a new API or augment the existing POST /allocations to include that information?\"\n\nTo include *what* information exactly, though? It sounds like you\u0027re asking the Placement API to add all the mess that the current filter scheduler currently contains (in the weighers).","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"12813f50f94573f6135010f10181188705da6a06","unresolved":false,"context_lines":[{"line_number":235,"context_line":"request for resources/traits and allowing the Nova scheduler to iterate over"},{"line_number":236,"context_line":"these allocation requests, retrying them if a concurrent claim happens, should"},{"line_number":237,"context_line":"actually increase the throughput of the Nova scheduler by reducing the amount"},{"line_number":238,"context_line":"of time between resource constraint retries."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Other deployer impact"},{"line_number":241,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_fa391341","line":238,"in_reply_to":"bf091321_0af00067","updated":"2017-06-09 01:41:56.000000000","message":"\"What this design proposes is passing around the internal implementation details of placement to every service that uses it. How complex RP relationships are modeled in placement should be irrelevant to any service that uses placement.\"\n\nI understand your concern about the placement API leaking implementation details. However, in this case, we\u0027re not leaking implementation details per-se. We\u0027re simply returning information about the providers the meet the request. The alternative to this is bringing in all the sorting logic and weigher stuff into the Placement API, and I\u0027m not keen to do that.\n\nKeep in mind that above, when you say \"it can run that exact same SQL to see if there are any shared/child providers involved, and then allocated to those providers\", that simply isn\u0027t true :) Sure, the placement API can run the SQL and get the providers that meet the requested constraints. But having placement then automatically allocate against one or more of those resource providers means that the placement API needs to pick which of the child providers (e.g. which of the SRIOV physical functions to place a workload on). And there\u0027s complex logic involved in that kind of a decision that currently exists in the PciPassthroughFilter, the NUMATopologyFilter, etc that uses information that the Placement API simply doesn\u0027t have.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"97067d5904878d49ed25d84fa3df45a9e5780057","unresolved":false,"context_lines":[{"line_number":235,"context_line":"request for resources/traits and allowing the Nova scheduler to iterate over"},{"line_number":236,"context_line":"these allocation requests, retrying them if a concurrent claim happens, should"},{"line_number":237,"context_line":"actually increase the throughput of the Nova scheduler by reducing the amount"},{"line_number":238,"context_line":"of time between resource constraint retries."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Other deployer impact"},{"line_number":241,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_0af00067","line":238,"in_reply_to":"bf091321_3ee42aac","updated":"2017-06-08 20:52:26.000000000","message":"No, it won\u0027t. The alternative is to have the same logic in the placement engine. When the cell conductor claims/unclaims resources for a host, it just passes the CN uuid and VM uuid.\n\nPlacement already has the knowledge about shared/nested resources for a provider - that\u0027s how it\u0027s able to determine that a particular CN can meet the requirements of a request. When a claim is made, it can run that exact same SQL to see if there are any shared/child providers involved, and then allocated to those providers. For simple CNs, the SQL will return the CN uuid for all resources; for complex, it will return the CN for some, and the shared/nested for others.\n\nWhat this design proposes is passing around the internal implementation details of placement to every service that uses it. How complex RP relationships are modeled in placement should be irrelevant to any service that uses placement.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2efc842f04449e493d33e95a92d29258f823720e","unresolved":false,"context_lines":[{"line_number":235,"context_line":"request for resources/traits and allowing the Nova scheduler to iterate over"},{"line_number":236,"context_line":"these allocation requests, retrying them if a concurrent claim happens, should"},{"line_number":237,"context_line":"actually increase the throughput of the Nova scheduler by reducing the amount"},{"line_number":238,"context_line":"of time between resource constraint retries."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Other deployer impact"},{"line_number":241,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf091321_3ee42aac","line":238,"in_reply_to":"bf091321_d413d865","updated":"2017-06-08 18:29:08.000000000","message":"The scheduler is still doing the claiming here.\n\nIMHO, this massively simplifies what cell conductor is going to have to do to claim the next thing in line. Since cell conductor doesn\u0027t have the visbility of the whole setup like scheduler does, just getting a host (RP) is going to cause it to have to figure out which sub-resources to claim, which is not going to be easy.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"6c63cdea4a03717b64915ebe4729357e7d01ac65","unresolved":false,"context_lines":[{"line_number":235,"context_line":"request for resources/traits and allowing the Nova scheduler to iterate over"},{"line_number":236,"context_line":"these allocation requests, retrying them if a concurrent claim happens, should"},{"line_number":237,"context_line":"actually increase the throughput of the Nova scheduler by reducing the amount"},{"line_number":238,"context_line":"of time between resource constraint retries."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Other deployer impact"},{"line_number":241,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f0e0f27_f63719e3","line":238,"in_reply_to":"bf091321_fa391341","updated":"2017-06-09 13:29:31.000000000","message":"\"The alternative to this is bringing in all the sorting logic and weigher stuff into the Placement API, and I\u0027m not keen to do that.\"\n\nFalse dichotomy. No one has suggested that. The only reason to pass the implementation details of placement to the scheduler is so that it knows how to make direct claims against the ultimate RPs, rather than the root RP. Any of the information for filtering/weighing will continue to be provided by HostState. If more information about the host is required, then it is HostState that needs to be updated to include it.\n\n\"But having placement then automatically allocate against one or more of those resource providers means that the placement API needs to pick which of the child providers (e.g. which of the SRIOV physical functions to place a workload on). And there\u0027s complex logic involved in that kind of a decision that currently exists in the PciPassthroughFilter, the NUMATopologyFilter, etc that uses information that the Placement API simply doesn\u0027t have.\"\n\nLet\u0027s assume that\u0027s the case. Wouldn\u0027t it make more sense to simply add either a new API or augment the existing POST /allocations to include that information? For 99.9% of the cases this will be empty, but in the few where that information is needed, it is provided. Then, *nothing else* in the current design needs to be overhauled, as you are proposing to do in this spec.","commit_id":"e664d58ee3c1acd6b9788fe00574e70c07825a79"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"94982db74818d8492a69d4a5841bff0afa466ebb","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"We propose to have the placement API return to the scheduler a set of"},{"line_number":14,"context_line":"alternative allocation choices that the scheduler may then use to both make a"},{"line_number":15,"context_line":"fitment decision as well as attempt a claim of resources on multiple complex"},{"line_number":16,"context_line":"resource providers."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_5e5d8de7","line":15,"range":{"start_line":15,"start_character":0,"end_line":15,"end_character":7},"updated":"2017-06-12 22:00:10.000000000","message":"fitment (n): An activity tracker stapped to the forehead, recording the number of times per day you bang your head against your desk.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d5f7179620275c354f5b4657a57cbbd7310809f5","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"We propose to have the placement API return to the scheduler a set of"},{"line_number":14,"context_line":"alternative allocation choices that the scheduler may then use to both make a"},{"line_number":15,"context_line":"fitment decision as well as attempt a claim of resources on multiple complex"},{"line_number":16,"context_line":"resource providers."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f436f4f_709be965","line":15,"range":{"start_line":15,"start_character":0,"end_line":15,"end_character":7},"in_reply_to":"7f231b9d_5e5d8de7","updated":"2017-08-21 08:07:17.000000000","message":"Done","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"f2b6968581428ad51f309882cec5b42255b6061f","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"We propose to have the placement API return to the scheduler a set of"},{"line_number":14,"context_line":"alternative allocation choices that the scheduler may then use to both make a"},{"line_number":15,"context_line":"fitment decision as well as attempt a claim of resources on multiple complex"},{"line_number":16,"context_line":"resource providers."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_889c005e","line":15,"range":{"start_line":15,"start_character":0,"end_line":15,"end_character":7},"in_reply_to":"7f231b9d_5e5d8de7","updated":"2017-06-13 06:18:34.000000000","message":"From the dict, \u0027fitment\u0027 has same meaning with \u0027furniture\u0027 and \u0027equipment\u0027. I may need more imagination to understand this word :)","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2a4721342c26d21f3139d984dd41baf2fc4cab3b","unresolved":false,"context_lines":[{"line_number":28,"context_line":"want the Nova scheduler to be able to claim resources against these nested or"},{"line_number":29,"context_line":"sharing resource providers."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"In order for this to happen, we propose creating a new REST API endpoint in the"},{"line_number":32,"context_line":"Placement API called `GET /allocation_requests` that will return a collection"},{"line_number":33,"context_line":"of opaque (to the Nova scheduler) HTTP request bodies that can be provided to a"},{"line_number":34,"context_line":"`POST /allocations/{consumer_uuid}` request along with a set of information the"},{"line_number":35,"context_line":"Nova scheduler can use to make fitment choices for the launch requests."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Use Cases"},{"line_number":38,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_b513b30d","line":35,"range":{"start_line":31,"start_character":0,"end_line":35,"end_character":71},"updated":"2017-06-12 13:05:23.000000000","message":"duplicate with L40, I guess you can skip this.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2a4721342c26d21f3139d984dd41baf2fc4cab3b","unresolved":false,"context_lines":[{"line_number":39,"context_line":""},{"line_number":40,"context_line":"This is an internal blueprint/spec, not intended to implement for any"},{"line_number":41,"context_line":"particular use case but rather simplify and structure the communication between"},{"line_number":42,"context_line":"the Nova scheduler and the Placement API."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Proposed change"},{"line_number":45,"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":3,"id":"7f231b9d_55021fb6","line":42,"updated":"2017-06-12 13:05:23.000000000","message":"nit: put just N/A","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2a4721342c26d21f3139d984dd41baf2fc4cab3b","unresolved":false,"context_lines":[{"line_number":45,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"We propose adding a new `GET /allocation_requests` REST API endpoint that will"},{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_75e3db06","line":48,"range":{"start_line":48,"start_character":28,"end_line":48,"end_character":34},"updated":"2017-06-12 13:05:23.000000000","message":"not sure you should explain the opacity. Just say that Placement returns some possible allocation requests that the scheduler could push back to the Placement for only one.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"1b10f2d9e96806e2343f6436d0818a9ef35dd111","unresolved":false,"context_lines":[{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"},{"line_number":54,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_ca76b33f","line":51,"updated":"2017-06-09 18:19:57.000000000","message":"From PS1: What\u0027s the plan for how the scheduler is using the information? I get that the allocation bodies can be used raw to make an allocation based on a choice of provider(s). What\u0027s less clear is how the scheduler will be processing the extra info.\n\nWith an addendum: I\u0027m not after detail here, just a hand wavey notions of what pieces of the puzzle will be getting the extra info.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d5f7179620275c354f5b4657a57cbbd7310809f5","unresolved":false,"context_lines":[{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"},{"line_number":54,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f436f4f_f0bfd9a7","line":51,"in_reply_to":"7f231b9d_ca76b33f","updated":"2017-08-21 08:07:17.000000000","message":"Done","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5b90e665fe5755cc7047aaefb116ed0788d57e73","unresolved":false,"context_lines":[{"line_number":48,"context_line":"return both a collection of opaque request bodies that can be sent to the `POST"},{"line_number":49,"context_line":"/allocations/{consumer_uuid}` endpoint as well as a collection of information"},{"line_number":50,"context_line":"that the scheduler can use to determine best fit for an instance launch"},{"line_number":51,"context_line":"request."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Alternatives"},{"line_number":54,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_e8214d4f","line":51,"in_reply_to":"7f231b9d_ca76b33f","updated":"2017-06-12 13:50:08.000000000","message":"Good question/topic. My initial thoughts would be that the scheduler would at first just pick the first allocation request that matched its \"target destination host pick\". Over time, the scheduler would be able to examine the \"providers\" part of the HTTP response and correlate those resource provider UUIDs and traits/capacities with the sorters/weighers it already uses.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"94982db74818d8492a69d4a5841bff0afa466ebb","unresolved":false,"context_lines":[{"line_number":75,"context_line":"REST API endpoint to return information about sharing providers and child"},{"line_number":76,"context_line":"providers and have the scheduler reporting client contain the necessary logic"},{"line_number":77,"context_line":"to build provider hierarchies, determine which sharing provider is associated"},{"line_number":78,"context_line":"with which providers, and essentially re-building a representation of usage and"},{"line_number":79,"context_line":"inventory records in memory. This alternative kept the Placement API free of"},{"line_number":80,"context_line":"much complex logic but came at the cost of dramatically changing the returned"},{"line_number":81,"context_line":"response from an established REST API endpoint and making the usage of that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_fe9e9961","line":78,"range":{"start_line":78,"start_character":46,"end_line":78,"end_character":49},"updated":"2017-06-12 22:00:10.000000000","message":"strike","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d5f7179620275c354f5b4657a57cbbd7310809f5","unresolved":false,"context_lines":[{"line_number":75,"context_line":"REST API endpoint to return information about sharing providers and child"},{"line_number":76,"context_line":"providers and have the scheduler reporting client contain the necessary logic"},{"line_number":77,"context_line":"to build provider hierarchies, determine which sharing provider is associated"},{"line_number":78,"context_line":"with which providers, and essentially re-building a representation of usage and"},{"line_number":79,"context_line":"inventory records in memory. This alternative kept the Placement API free of"},{"line_number":80,"context_line":"much complex logic but came at the cost of dramatically changing the returned"},{"line_number":81,"context_line":"response from an established REST API endpoint and making the usage of that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f436f4f_d005f57b","line":78,"range":{"start_line":78,"start_character":46,"end_line":78,"end_character":49},"in_reply_to":"7f231b9d_fe9e9961","updated":"2017-08-21 08:07:17.000000000","message":"Done","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"94982db74818d8492a69d4a5841bff0afa466ebb","unresolved":false,"context_lines":[{"line_number":96,"context_line":"  for each class of resource requested. Example:"},{"line_number":97,"context_line":"  `?resources\u003dVCPU:1,MEMORY_MB:1024,SRIOV_NET_VF:1`"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* `required`: A comma-delimited string of traits that must be required by at"},{"line_number":100,"context_line":"  least one provider matched by the request. Example:"},{"line_number":101,"context_line":"  `?required\u003dSTORAGE_DISK_SSD,HW_CPU_X68_AVX2`"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"* `uuid`: A string UUID to filter providers by. The string may begin with the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_9e4fa591","line":100,"range":{"start_line":99,"start_character":74,"end_line":100,"end_character":20},"updated":"2017-06-12 22:00:10.000000000","message":"At least one?  I\u0027m probably misunderstanding, but does this mean I could get back several providers, and maybe only one of them matches the trait?","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d5f7179620275c354f5b4657a57cbbd7310809f5","unresolved":false,"context_lines":[{"line_number":96,"context_line":"  for each class of resource requested. Example:"},{"line_number":97,"context_line":"  `?resources\u003dVCPU:1,MEMORY_MB:1024,SRIOV_NET_VF:1`"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* `required`: A comma-delimited string of traits that must be required by at"},{"line_number":100,"context_line":"  least one provider matched by the request. Example:"},{"line_number":101,"context_line":"  `?required\u003dSTORAGE_DISK_SSD,HW_CPU_X68_AVX2`"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"* `uuid`: A string UUID to filter providers by. The string may begin with the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9f436f4f_50f9057e","line":100,"range":{"start_line":99,"start_character":74,"end_line":100,"end_character":20},"in_reply_to":"7f231b9d_9e4fa591","updated":"2017-08-21 08:07:17.000000000","message":"Done. I removed the traits parameters and left a note about tackling traits in future patches.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"f2b6968581428ad51f309882cec5b42255b6061f","unresolved":false,"context_lines":[{"line_number":96,"context_line":"  for each class of resource requested. Example:"},{"line_number":97,"context_line":"  `?resources\u003dVCPU:1,MEMORY_MB:1024,SRIOV_NET_VF:1`"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* `required`: A comma-delimited string of traits that must be required by at"},{"line_number":100,"context_line":"  least one provider matched by the request. Example:"},{"line_number":101,"context_line":"  `?required\u003dSTORAGE_DISK_SSD,HW_CPU_X68_AVX2`"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"* `uuid`: A string UUID to filter providers by. The string may begin with the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_a8469c7b","line":100,"range":{"start_line":99,"start_character":74,"end_line":100,"end_character":20},"in_reply_to":"7f231b9d_9e4fa591","updated":"2017-06-13 06:18:34.000000000","message":"It should be mean that to return the resource provider or its nested resource provider or related shared resource provider have those traits.\n\nSo it shouldn\u0027t be \u0027one provider\u0027.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"94982db74818d8492a69d4a5841bff0afa466ebb","unresolved":false,"context_lines":[{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* `required`: A comma-delimited string of traits that must be required by at"},{"line_number":100,"context_line":"  least one provider matched by the request. Example:"},{"line_number":101,"context_line":"  `?required\u003dSTORAGE_DISK_SSD,HW_CPU_X68_AVX2`"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"* `uuid`: A string UUID to filter providers by. The string may begin with the"},{"line_number":104,"context_line":"  prefix \"in:\", followed by a comma-delimited list of UUIDs, in which case the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_7e46097f","line":101,"range":{"start_line":101,"start_character":13,"end_line":101,"end_character":45},"updated":"2017-06-12 22:00:10.000000000","message":"AND or OR?","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"f2b6968581428ad51f309882cec5b42255b6061f","unresolved":false,"context_lines":[{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* `required`: A comma-delimited string of traits that must be required by at"},{"line_number":100,"context_line":"  least one provider matched by the request. Example:"},{"line_number":101,"context_line":"  `?required\u003dSTORAGE_DISK_SSD,HW_CPU_X68_AVX2`"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"* `uuid`: A string UUID to filter providers by. The string may begin with the"},{"line_number":104,"context_line":"  prefix \"in:\", followed by a comma-delimited list of UUIDs, in which case the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_687764d6","line":101,"range":{"start_line":101,"start_character":13,"end_line":101,"end_character":45},"in_reply_to":"7f231b9d_7e46097f","updated":"2017-06-13 06:18:34.000000000","message":"Same as above comment, It isn\u0027t AND or OR.\n\nIt means that to return the resource provider or its nested resource provider or related shared resource provider have those traits.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"94982db74818d8492a69d4a5841bff0afa466ebb","unresolved":false,"context_lines":[{"line_number":101,"context_line":"  `?required\u003dSTORAGE_DISK_SSD,HW_CPU_X68_AVX2`"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"* `uuid`: A string UUID to filter providers by. The string may begin with the"},{"line_number":104,"context_line":"  prefix \"in:\", followed by a comma-delimited list of UUIDs, in which case the"},{"line_number":105,"context_line":"  Placemnet API will filter for any resource providers that have matching"},{"line_number":106,"context_line":"  UUIDs. Examples: `?uuid\u003d$UUID1` or `?uuid\u003din:$UUID1,$UUID2`"},{"line_number":107,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_413c8cc7","line":104,"range":{"start_line":104,"start_character":10,"end_line":104,"end_character":13},"updated":"2017-06-12 22:00:10.000000000","message":"Unless we\u0027re following some existing paradigm elsewhere, \"in:\" seems unnecessary; implied by \u0027,\u0027 in uuid.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"7e094279ac532d3aa9d1634968ad9470a95ae3e7","unresolved":false,"context_lines":[{"line_number":102,"context_line":""},{"line_number":103,"context_line":"* `uuid`: A string UUID to filter providers by. The string may begin with the"},{"line_number":104,"context_line":"  prefix \"in:\", followed by a comma-delimited list of UUIDs, in which case the"},{"line_number":105,"context_line":"  Placemnet API will filter for any resource providers that have matching"},{"line_number":106,"context_line":"  UUIDs. Examples: `?uuid\u003d$UUID1` or `?uuid\u003din:$UUID1,$UUID2`"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Given an HTTP request of:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_b3c1af31","line":105,"updated":"2017-06-09 23:38:44.000000000","message":"Placement","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"7e094279ac532d3aa9d1634968ad9470a95ae3e7","unresolved":false,"context_lines":[{"line_number":103,"context_line":"* `uuid`: A string UUID to filter providers by. The string may begin with the"},{"line_number":104,"context_line":"  prefix \"in:\", followed by a comma-delimited list of UUIDs, in which case the"},{"line_number":105,"context_line":"  Placemnet API will filter for any resource providers that have matching"},{"line_number":106,"context_line":"  UUIDs. Examples: `?uuid\u003d$UUID1` or `?uuid\u003din:$UUID1,$UUID2`"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Given an HTTP request of:"},{"line_number":109,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_13f9837f","line":106,"updated":"2017-06-09 23:38:44.000000000","message":"Are these uuids of root (and not shared) providers or all of root, shared, child?\n\nSince every object in the list of allocations_requests is a group of one or more resource providers, to what part of that does the filter apply?\n\nI agree we would want this, but I\u0027m struggling to conceptualize \"which ones?\"","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"7e094279ac532d3aa9d1634968ad9470a95ae3e7","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Given an HTTP request of:"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"`GET /allocation_requests?resources\u003d$RESOURCES\u0026required\u003d$REQUIRED`"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"where `$RESOURCES` \u003d \"VCPU:4,MEMORY_MB:16384,DISK_GB:50,SRIOV_NET_VF:1\" and"},{"line_number":113,"context_line":"`$REQUIRED` \u003d \"HW_CPU_X86_AVX2,HW_NET_SRIOV_MULTIQUEUE,CUSTOM_PHYSNET_INTRANET\""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_53349b4a","line":110,"updated":"2017-06-09 23:38:44.000000000","message":"We\u0027ve had a bit of discussion about pagination and limits to constrain this from being a huge result set.\n\nIf we do set a limit by some mechanism (what mechanism isn\u0027t relevant at this point) on what are we ordering so that we can expect the same results for the same request to different systems containing identical resource providers?","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2a4721342c26d21f3139d984dd41baf2fc4cab3b","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"Given an HTTP request of:"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"`GET /allocation_requests?resources\u003d$RESOURCES\u0026required\u003d$REQUIRED`"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"where `$RESOURCES` \u003d \"VCPU:4,MEMORY_MB:16384,DISK_GB:50,SRIOV_NET_VF:1\" and"},{"line_number":113,"context_line":"`$REQUIRED` \u003d \"HW_CPU_X86_AVX2,HW_NET_SRIOV_MULTIQUEUE,CUSTOM_PHYSNET_INTRANET\""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_f5bc8bbc","line":110,"in_reply_to":"7f231b9d_53349b4a","updated":"2017-06-12 13:05:23.000000000","message":"Agreed, we should possibly provide some pagination for the API given it could be a huge request body back (not just list of UUIDs)","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"f2b6968581428ad51f309882cec5b42255b6061f","unresolved":false,"context_lines":[{"line_number":144,"context_line":"                }"},{"line_number":145,"context_line":"            },"},{"line_number":146,"context_line":"        ],"},{"line_number":147,"context_line":"        \"providers\": {"},{"line_number":148,"context_line":"            $COMPUTE_NODE_UUID: {"},{"line_number":149,"context_line":"                \"traits\": ["},{"line_number":150,"context_line":"                    \"HW_CPU_X86_SSE42\","}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_5b747468","line":147,"range":{"start_line":147,"start_character":21,"end_line":147,"end_character":22},"updated":"2017-06-13 06:18:34.000000000","message":"I thought this should be a list? This API will return all the RPs matches the requirement. Of course, we can put all the RPs in this dict, you expect the user to build a tree?","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7e20cef3f0162c24c42dde3b83114f2a4eeeb30f","unresolved":false,"context_lines":[{"line_number":144,"context_line":"                }"},{"line_number":145,"context_line":"            },"},{"line_number":146,"context_line":"        ],"},{"line_number":147,"context_line":"        \"providers\": {"},{"line_number":148,"context_line":"            $COMPUTE_NODE_UUID: {"},{"line_number":149,"context_line":"                \"traits\": ["},{"line_number":150,"context_line":"                    \"HW_CPU_X86_SSE42\","}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_22ccd568","line":147,"range":{"start_line":147,"start_character":21,"end_line":147,"end_character":22},"in_reply_to":"7f231b9d_5b747468","updated":"2017-06-13 15:19:08.000000000","message":"This is for a *single* matching provider. What will be returned is a list of these things. IOW, for each UUID that is currently being returned, at least one of these JSON blobs will be returned. In the case where a compute node has multiple nested child providers that can provide the requested resources, there will be one of these JSON blobs for *each* potential match.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2a4721342c26d21f3139d984dd41baf2fc4cab3b","unresolved":false,"context_lines":[{"line_number":145,"context_line":"            },"},{"line_number":146,"context_line":"        ],"},{"line_number":147,"context_line":"        \"providers\": {"},{"line_number":148,"context_line":"            $COMPUTE_NODE_UUID: {"},{"line_number":149,"context_line":"                \"traits\": ["},{"line_number":150,"context_line":"                    \"HW_CPU_X86_SSE42\","},{"line_number":151,"context_line":"                    \"HW_CPU_X86_AVX2\""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_5521fffa","line":148,"updated":"2017-06-12 13:05:23.000000000","message":"Why are you providing a separate key for \"providers\" if you already pass the providers in the \"allocation_requests\" key?\n\nHaving the same resource passed separatly would mean that we need to make sure that for example $COMPUTE_NODE_UUID is there too and that doesn\u0027t really look REST to me.\n\nAlso, if we would be providing paginations, it could be a bit more difficult IMHO for paginating but I could be wrong.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"94982db74818d8492a69d4a5841bff0afa466ebb","unresolved":false,"context_lines":[{"line_number":145,"context_line":"            },"},{"line_number":146,"context_line":"        ],"},{"line_number":147,"context_line":"        \"providers\": {"},{"line_number":148,"context_line":"            $COMPUTE_NODE_UUID: {"},{"line_number":149,"context_line":"                \"traits\": ["},{"line_number":150,"context_line":"                    \"HW_CPU_X86_SSE42\","},{"line_number":151,"context_line":"                    \"HW_CPU_X86_AVX2\""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_81a50407","line":148,"in_reply_to":"7f231b9d_5521fffa","updated":"2017-06-12 22:00:10.000000000","message":"Looks to me like the \"providers\" are not included in \"allocation_requests\" - only their UUIDs - which you would then use to cross-reference into \"providers\" to get more detail on them.\n\nI hope allocation requests are always going to be small enough that pagination isn\u0027t a consideration.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7e20cef3f0162c24c42dde3b83114f2a4eeeb30f","unresolved":false,"context_lines":[{"line_number":145,"context_line":"            },"},{"line_number":146,"context_line":"        ],"},{"line_number":147,"context_line":"        \"providers\": {"},{"line_number":148,"context_line":"            $COMPUTE_NODE_UUID: {"},{"line_number":149,"context_line":"                \"traits\": ["},{"line_number":150,"context_line":"                    \"HW_CPU_X86_SSE42\","},{"line_number":151,"context_line":"                    \"HW_CPU_X86_AVX2\""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_82096996","line":148,"in_reply_to":"7f231b9d_81a50407","updated":"2017-06-13 15:19:08.000000000","message":"This is for providing the scheduler with more information about each of these providers. It is assumed that the scheduler filters/weighers will be re-written to use this information instead of the current method of HostState objects.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2a4721342c26d21f3139d984dd41baf2fc4cab3b","unresolved":false,"context_lines":[{"line_number":235,"context_line":"request for resources/traits and allowing the Nova scheduler to iterate over"},{"line_number":236,"context_line":"these allocation requests, retrying them if a concurrent claim happens, should"},{"line_number":237,"context_line":"actually increase the throughput of the Nova scheduler by reducing the amount"},{"line_number":238,"context_line":"of time between resource constraint retries."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Other deployer impact"},{"line_number":241,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7f231b9d_506d8d96","line":238,"updated":"2017-06-12 13:05:23.000000000","message":"well, you should maybe explain in the proposal (and not only here) that Placement could provide some stale response (I mean wrong RPs because concurrency), but that\u0027s fine given we retry.","commit_id":"fac4a34359e24490f855018d1456829673cb72f6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8314fe33d34e857f9591efd4ac50dd5e52fc50a8","unresolved":false,"context_lines":[{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The scheduler shall then proceed to choose an appropriate destination host for"},{"line_number":62,"context_line":"a build request (or more than one destination host if the"},{"line_number":63,"context_line":"`RequestSpec.num_instances` is greater than 1). However, instead of immediately"},{"line_number":64,"context_line":"returning this destination host, the scheduler will now work with the placement"},{"line_number":65,"context_line":"API to claim resources on the chosen host **before** sending its decision back"},{"line_number":66,"context_line":"to the conductor."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The scheduler will claim resources against the destination host by choosing an"},{"line_number":69,"context_line":"allocation request that contains the UUID of the destination host and calling"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f287b81_0293de5c","line":66,"range":{"start_line":63,"start_character":48,"end_line":66,"end_character":17},"updated":"2017-08-28 16:28:02.000000000","message":"This is really not about this spec, but rather the claims in the scheduler spec, which we left pretty open ended when we merged it:\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/pike/approved/placement-claims.html\n\nBut this is fine to reinforce.","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"268c41a547967ce39f4bc4dac59b4b8f7319bb3a","unresolved":false,"context_lines":[{"line_number":177,"context_line":"                ],"},{"line_number":178,"context_line":"            },"},{"line_number":179,"context_line":"        ],"},{"line_number":180,"context_line":"        \"provider_summariess\": {"},{"line_number":181,"context_line":"            $COMPUTE_NODE1_UUID: {"},{"line_number":182,"context_line":"                \"resources\": {"},{"line_number":183,"context_line":"                    \"VCPU\": {"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f436f4f_1cceefb3","line":180,"range":{"start_line":180,"start_character":27,"end_line":180,"end_character":28},"updated":"2017-08-21 12:56:24.000000000","message":"strike","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0a4ddbaac3b14ce2e14614ef297f26f9ec6b181e","unresolved":false,"context_lines":[{"line_number":243,"context_line":"Other deployer impact"},{"line_number":244,"context_line":"---------------------"},{"line_number":245,"context_line":""},{"line_number":246,"context_line":"None."},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"Developer impact"},{"line_number":249,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f287b81_c24956b7","line":246,"updated":"2017-08-28 16:39:49.000000000","message":"The Placement service will have to be upgraded before the nova-scheduler service to use the new microversion.","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8314fe33d34e857f9591efd4ac50dd5e52fc50a8","unresolved":false,"context_lines":[{"line_number":261,"context_line":"Work Items"},{"line_number":262,"context_line":"----------"},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"TODO"},{"line_number":265,"context_line":""},{"line_number":266,"context_line":"Dependencies"},{"line_number":267,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f287b81_42e9e6b4","line":264,"updated":"2017-08-28 16:28:02.000000000","message":"We could say this was implemented in Pike, or just:\n\n* Add the API and related logic to the Placement service.\n* Integrate the usage of the API in the FilterScheduler.","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8314fe33d34e857f9591efd4ac50dd5e52fc50a8","unresolved":false,"context_lines":[{"line_number":268,"context_line":""},{"line_number":269,"context_line":"* shared-resource-pike (pretty much completed)"},{"line_number":270,"context_line":""},{"line_number":271,"context_line":"* nested-resource-providers (otherwise this is all kind of moot)"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"Testing"},{"line_number":274,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f287b81_a22c0a02","line":271,"updated":"2017-08-28 16:28:02.000000000","message":"This isn\u0027t really a dependency, as this change stands on it\u0027s own, especially since we did it without the nested RPs stuff done.","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"268c41a547967ce39f4bc4dac59b4b8f7319bb3a","unresolved":false,"context_lines":[{"line_number":273,"context_line":"Testing"},{"line_number":274,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"Moar functional testing."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Documentation Impact"},{"line_number":279,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f436f4f_bc5363e2","line":276,"range":{"start_line":276,"start_character":0,"end_line":276,"end_character":4},"updated":"2017-08-21 12:56:24.000000000","message":"More","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"454d3c1f7d49f833ffd04b3a3f34013bad9d9f3d","unresolved":false,"context_lines":[{"line_number":273,"context_line":"Testing"},{"line_number":274,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"Moar functional testing."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Documentation Impact"},{"line_number":279,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f436f4f_53d46247","line":276,"range":{"start_line":276,"start_character":0,"end_line":276,"end_character":4},"in_reply_to":"9f436f4f_9f165149","updated":"2017-08-21 15:34:35.000000000","message":"D\u0027oh!","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"72acd0596212ff69e5a0d45fe083f946cbcb059c","unresolved":false,"context_lines":[{"line_number":273,"context_line":"Testing"},{"line_number":274,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"Moar functional testing."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Documentation Impact"},{"line_number":279,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f436f4f_9f165149","line":276,"range":{"start_line":276,"start_character":0,"end_line":276,"end_character":4},"in_reply_to":"9f436f4f_bc5363e2","updated":"2017-08-21 13:31:01.000000000","message":"I see that efried has no sense of humor :)","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8314fe33d34e857f9591efd4ac50dd5e52fc50a8","unresolved":false,"context_lines":[{"line_number":293,"context_line":"History"},{"line_number":294,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"None."}],"source_content_type":"text/x-rst","patch_set":4,"id":"7f287b81_821a2ec9","line":296,"updated":"2017-08-28 16:28:02.000000000","message":"This should be Pike: Introduced, however we format that.","commit_id":"7607f9508b2ed867d6cf3c7e4edc39c3f483bf43"}]}