)]}'
{"specs/rocky/approved/traits-on-list-resource-providers.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"9d9cbb39242c02fb73c324197f26714232cf47c1","unresolved":false,"context_lines":[{"line_number":54,"context_line":"---------------"},{"line_number":55,"context_line":"See `Proposed change`_.  The parameter is optional.  It does not result in the"},{"line_number":56,"context_line":"addition of any new response codes.  The only way to cause a 400 is to specify"},{"line_number":57,"context_line":"an empty trait value.  Otherwise, the format of a trait string is not checked."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Security impact"},{"line_number":60,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_e72d9b46","line":57,"updated":"2018-02-20 13:02:39.000000000","message":"I\u0027m not sure if we\u0027ve managed to be consistent about this in the past across all APIs, but in the case of traits and placement this looks to be in line with existing practice.\n\nThere have been discussion on some nova apis in the past about returning 400s when query params do not match formats, because otherwise how does the call know the different between \"there\u0027s none of that\" and \"you said it wrong\"?\n\nI\u0027m agnostic.","commit_id":"a4d66c47d56f57c86b057357527cdffdd6507f15"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2c2de77231b528819c6854d08726002f6be6cf7d","unresolved":false,"context_lines":[{"line_number":54,"context_line":"---------------"},{"line_number":55,"context_line":"See `Proposed change`_.  The parameter is optional.  It does not result in the"},{"line_number":56,"context_line":"addition of any new response codes.  The only way to cause a 400 is to specify"},{"line_number":57,"context_line":"an empty trait value.  Otherwise, the format of a trait string is not checked."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Security impact"},{"line_number":60,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_b59a525f","line":57,"in_reply_to":"3fa0c359_85cb6f48","updated":"2018-02-20 18:48:11.000000000","message":"Since [1] is getting a whiff of traction, I\u0027m going to say 400 here.","commit_id":"a4d66c47d56f57c86b057357527cdffdd6507f15"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7e41ddb4194d7d73dd6f24b583a379c15cbe53f4","unresolved":false,"context_lines":[{"line_number":54,"context_line":"---------------"},{"line_number":55,"context_line":"See `Proposed change`_.  The parameter is optional.  It does not result in the"},{"line_number":56,"context_line":"addition of any new response codes.  The only way to cause a 400 is to specify"},{"line_number":57,"context_line":"an empty trait value.  Otherwise, the format of a trait string is not checked."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Security impact"},{"line_number":60,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_85cb6f48","line":57,"in_reply_to":"3fa0c359_e72d9b46","updated":"2018-02-20 14:31:59.000000000","message":"I did go look at what GET /allocation_candidates is doing - and then consciously did the opposite.  For the record (and maybe this is worth including in the spec):\n\n- If you send an empty trait (e.g. two commas in a row), 400 (\"Invalid query string parameters: Expected \u0027required\u0027 parameter value of the form: HW_CPU_X86_VMX,CUSTOM_MAGIC. Got: %s\")\n- Once we get past that, we look up the traits in the Trait table (select name, id from Trait where name in \u003ctrait list\u003e).  If *any* are not found (if the length of that result doesn\u0027t match the length of \u003ctrait list\u003e), 400 (\"No such trait(s): %(names)s.\")\n\nI thought in this case it would be better not to error in the latter case so you didn\u0027t have to worry about making sure traits exist before calling - unlike GET /allocation_candidates, where you really oughtta (right?).\n\nIF we had proper error codes, I would say the 400 would be the better choice, to give the caller the most control.\n\nWithout error codes...  I\u0027m ambivalent.  And agnostic.  And on the fence.","commit_id":"a4d66c47d56f57c86b057357527cdffdd6507f15"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ebdffaabafa23e68269a55efb10979fa9465b90d","unresolved":false,"context_lines":[{"line_number":28,"context_line":"In a new microversion, allow the `GET /resource_providers`_ API to accept an"},{"line_number":29,"context_line":"additional query parameter, ``required``, which accepts a comma-separated list"},{"line_number":30,"context_line":"of string trait names.  When specified, the API results will be filtered to"},{"line_number":31,"context_line":"include only resource providers marked with *all* the specified traits."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"This is in addition to (logical ``AND``) any filtering based on other query"},{"line_number":34,"context_line":"parameters."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_2ce7aa14","line":31,"range":{"start_line":31,"start_character":44,"end_line":31,"end_character":71},"updated":"2018-02-22 15:37:41.000000000","message":"So the wording here is a bit different than the allocation candidates filter:\n\nhttps://developer.openstack.org/api-ref/placement/#list-allocation-candidates\n\n\"Accepts a list of comma-separated traits. Allocation requests in the response will be for resource providers that have capacity for all requested resources and the set of those resource providers will collectively contain all of the required traits.\"\n\nWhich is to say the allocation candidates returned are collectively satisfying the required traits, so they could be satisfied via aggregates or nested providers, right? But that would be different with how it works in GET /resource_providers.\n\nI assume there is good reason for that, but I\u0027m not sure how much it\u0027s prompted by tunnel vision on fixing a very specific problem. Either way, I think you should probably put something in here for posterity on why \u0027required\u0027 works differently between the two APIs.","commit_id":"56fb1a4580b8086857445c5a566536d2c592a680"}]}