)]}'
{"id":"openstack%2Fnova-specs~597601","triplet_id":"openstack%2Fnova-specs~master~Iafdb0eab9b41f4c34c93cada08a4da27cf4b1499","project":"openstack/nova-specs","branch":"master","topic":"bp/placement-resource-provider-request-group-mapping-in-allocation-candidates","hashtags":[],"change_id":"Iafdb0eab9b41f4c34c93cada08a4da27cf4b1499","subject":"Resource provider - request group mapping in allocation candidate","status":"ABANDONED","created":"2018-08-29 17:02:16.000000000","updated":"2019-05-08 21:50:05.000000000","total_comment_count":57,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"f004378ea57fa404a36cc2ea68f8e5395e201179","_number":597601,"virtual_id_number":597601,"owner":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"actions":{},"labels":{"Verified":{"all":[{"date":"2019-05-07 11:55:13.000000000","_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","default_value":0,"optional":true},"Code-Review":{"all":[{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","default_value":0,"optional":true},"Workflow":{"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"date":"2019-05-08 21:50:05.000000000","_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true},"Review-Priority":{"all":[{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"}],"values":{" 0":"Default Priority","+1":"Contributor Review Promise","+2":"Core Review Promise"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2018-08-29 17:37:05.000000000","updated_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"reviewer":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2018-08-30 10:55:49.000000000","updated_by":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"reviewer":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"state":"REVIEWER"},{"updated":"2018-09-13 21:10:57.000000000","updated_by":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"reviewer":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"state":"REVIEWER"},{"updated":"2018-09-27 18:04:39.000000000","updated_by":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"reviewer":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"state":"REVIEWER"},{"updated":"2018-10-05 15:38:22.000000000","updated_by":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"reviewer":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"state":"REVIEWER"},{"updated":"2019-02-08 14:37:33.000000000","updated_by":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"reviewer":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"state":"REVIEWER"},{"updated":"2019-02-11 20:17:51.000000000","updated_by":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"reviewer":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"state":"REVIEWER"},{"updated":"2019-02-20 05:31:11.000000000","updated_by":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"reviewer":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"state":"REVIEWER"},{"updated":"2019-02-28 13:36:44.000000000","updated_by":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"reviewer":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"state":"REVIEWER"},{"updated":"2019-04-30 17:16:32.000000000","updated_by":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"reviewer":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"state":"REVIEWER"},{"updated":"2019-05-08 21:50:05.000000000","updated_by":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"reviewer":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"state":"REVIEWER"}],"messages":[{"id":"3a53c3225fb7ef65b81c9be91925756b6aa5106e","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-08-29 17:02:16.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"b42fbd21ca5f134432affbf9aa0bf7a0870ec92c","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-08-29 17:37:05.000000000","message":"Patch Set 1: Verified+1\n\nBuild succeeded (check pipeline).\n\n- build-openstack-sphinx-docs http://logs.openstack.org/01/597601/1/check/build-openstack-sphinx-docs/fca3182/html/ : SUCCESS in 5m 59s\n- openstack-tox-pep8 http://logs.openstack.org/01/597601/1/check/openstack-tox-pep8/0bfa849/ : SUCCESS in 5m 20s","accounts_in_message":[],"_revision_number":1},{"id":"709ca71d482c94c121d33f41ed89a0c277acf221","author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"working for Ericsson, UTC+1 (+DST)"},"date":"2018-08-30 10:55:49.000000000","message":"Patch Set 1:\n\n(8 comments)\n\nIt\u0027s good you wrote this up. This clearly needs to be discussed.","accounts_in_message":[],"_revision_number":1},{"id":"c381c811cd22be3c3414062d13a74aa899f2b307","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-08-30 11:59:00.000000000","message":"Patch Set 1:\n\n(8 comments)","accounts_in_message":[],"_revision_number":1},{"id":"6c16ee9b7c509e016c70a15c0f7757768515ee56","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-09-13 21:21:57.000000000","message":"Patch Set 1:\n\nI\u0027m afraid this doesn\u0027t go quite far enough.\n\nAny time the contributes_to contains more than one value, I\u0027m right back where I started, not being able to disambiguate which request group mapped to which chunk of the response.\n\nIf you use your last alternative, but key by the request group, you can solve this.","accounts_in_message":[],"_revision_number":1},{"id":"41b40bdec9913ee16554031566c35131c4cd6d7e","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-09-17 11:44:10.000000000","message":"Patch Set 1:\n\n\u003e I\u0027m afraid this doesn\u0027t go quite far enough.\n \u003e \n \u003e Any time the contributes_to contains more than one value, I\u0027m right\n \u003e back where I started, not being able to disambiguate which request\n \u003e group mapped to which chunk of the response.\n \u003e \n \u003e If you use your last alternative, but key by the request group, you\n \u003e can solve this.\n\nThe contributes_to field is added to each RP in each candidate in the a_c response so ambiguity only happens when an RP contributes to more than one request groups (e.g. group_policy\u003dnone). However that is a minor ambiguity as the individual contribution of that RP to multiple group can be calculated with a single subtraction on value of each allocated resource classes. Also your suggestion would not simplify this situation further.","accounts_in_message":[],"_revision_number":1},{"id":"bdb74635b5e9162f11e44f807d2a97381e7a05d6","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-09-18 18:26:57.000000000","message":"Patch Set 1:\n\n\u003e can be calculated with a single subtraction\n\nNot a fan of requiring the caller to reverse-engineer the response based on the request.\n\n\u003e your suggestion would not simplify\n\nJust so we\u0027re clear on what I\u0027m suggesting, consider request:\n\n ?resources1\u003dCUSTOM_FOO:1,CUSTOM_BAR:100\n \u0026resources2\u003dCUSTOM_FOO:2,CUSTOM_BAR:200\n \u0026resources3\u003dCUSTOM_FOO:1\n \u0026group_policy\u003dnone\n\nResponse your way:\n\n \"allocations\": {\n     $RP1: {\n         \"resources\": {\n             CUSTOM_FOO: 1,\n             CUSTOM_BAR: 100,\n         },\n         \"contributes_to\": [\"resources1\"]\n     },\n     $RP2: {\n         \"resources\": {\n             CUSTOM_FOO: 3,\n             CUSTOM_BAR: 200,\n         },\n         \"contributes_to\": [\"resources2\", \"resources3\"]\n     },\n }\n\nNow when processing RP2, I have to re-parse the resources2/3 I sent in the request to separate 3/200 into 2/200 and 1/0, right?\n\nResponse my way:\n\n \"allocations\": {\n     \"resources1\": {\n         $RP1: {\n             CUSTOM_FOO: 1,\n             CUSTOM_BAR: 100,\n         }\n     }\n     \"resources2\": {\n         $RP2: {\n             CUSTOM_FOO: 2,\n             CUSTOM_BAR: 200,\n         }\n     }\n     \"resources3\": {\n         $RP2: {\n             CUSTOM_FOO: 1,\n         }\n     }\n }\n\nNo subtraction necessary. Furthermore, no need to access, understand, or parse the original request in whatever format (e.g. flavor extra specs, RequestGroup dict, etc.)","accounts_in_message":[],"_revision_number":1},{"id":"40e04179fe6735cb1134bdf1725c4b3a7a940a5e","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2018-09-27 13:21:27.000000000","message":"Patch Set 1:\n\n\u003e Response my way:\n \u003e \n \u003e \"allocations\": {\n \u003e \"resources1\": {\n \u003e $RP1: {\n \u003e CUSTOM_FOO: 1,\n \u003e CUSTOM_BAR: 100,\n \u003e }\n \u003e }\n \u003e \"resources2\": {\n \u003e $RP2: {\n \u003e CUSTOM_FOO: 2,\n \u003e CUSTOM_BAR: 200,\n \u003e }\n \u003e }\n \u003e \"resources3\": {\n \u003e $RP2: {\n \u003e CUSTOM_FOO: 1,\n \u003e }\n \u003e }\n \u003e }\n\nThis format violates the contract of allocation_candidates which is that a single member of allocation_requests can be given back to  PUT /allocations without inspection.\n\nWe\u0027ve already broken this promise a bit by by requiring project and user in some microversions, but we can do that without much knowledge of the structure.","accounts_in_message":[],"_revision_number":1},{"id":"a31af04823b5bf865f06f27e223ab7753828654f","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-09-27 14:57:57.000000000","message":"Patch Set 1:\n\n\u003e This format violates the contract of allocation_candidates which is that a single member of allocation_requests can be given back to  PUT /allocations without inspection.\n\nObviously we will have to change PUT/POST /allocations to accept the new format, whether it\u0027s the one gibi suggests or the one I suggest. If you can think of a solution that *wouldn\u0027t* require PUT/POST /allocations to change, I\u0027m all ears.","accounts_in_message":[],"_revision_number":1},{"id":"1070078ce7095e364562db22d9e3f2ceab976e78","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2018-09-27 15:12:57.000000000","message":"Patch Set 1:\n\n\u003e \u003e This format violates the contract of allocation_candidates which\n \u003e is that a single member of allocation_requests can be given back to\n \u003e  PUT /allocations without inspection.\n \u003e \n \u003e Obviously we will have to change PUT/POST /allocations to accept\n \u003e the new format, whether it\u0027s the one gibi suggests or the one I\n \u003e suggest. If you can think of a solution that *wouldn\u0027t* require\n \u003e PUT/POST /allocations to change, I\u0027m all ears.\n\nThere\u0027s the \"*Alternatively* the mapping can be added as a separate top level key to the response.\"","accounts_in_message":[],"_revision_number":1},{"id":"76cf8b1034a9151ad9db53c2d89bbbcb0482377f","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-09-27 16:30:50.000000000","message":"Patch Set 1:\n\nPerhaps I\u0027m not understanding why it\u0027s a problem to change the GET /a_c format and the PUT/POST /allocations format in the same microversion.","accounts_in_message":[],"_revision_number":1},{"id":"0ca491118aa05a069c90632cf1eae4d7d942067e","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2018-09-27 17:14:15.000000000","message":"Patch Set 1:\n\n\u003e Perhaps I\u0027m not understanding why it\u0027s a problem to change the GET\n \u003e /a_c format and the PUT/POST /allocations format in the same\n \u003e microversion.\n\nBecause two things:\n\na) if the information is not needed in a PUT or POST to /allocations nor will be included in GET /allocations/{uuid} then it shouldn\u0027t be included. If those changes are expected and we are intended for this information to be _meaningful_ for allocations themselves, then we need to make that way more clear in this spec. As I understand things I thought this information was important with regards to how nova (or other clients) is grouping things, not to how placement is grouping things (when it persists allocations).\n\nb) We spent some significant amount of time when creating allocation_candidates saying that the allocations in the allocation_requests are \"opaque\" in some kind of hand-wavey sort of way, meaning they are capable of being PUT directly back to placement. If we want to change that we _can_ but the choice to do so should not be lightly taken.\n\nAll of this goes back to the early idea that allocations are supposed to be the lightest and fastest aspect of placement. A thing that many thousands of clients can throw at placement as fast and stupidly as they possibly can.\n\nAgain, this doesn\u0027t mean the nature of allocations can\u0027t change, but that changing them ought to be considered a big deal.","accounts_in_message":[],"_revision_number":1},{"id":"b55db81c8801cbf09f66f5fde35088fdfa5f5362","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-09-27 18:04:39.000000000","message":"Patch Set 1: Code-Review-1\n\n(1 comment)\n\n\u003e Because two things:\n\nOkay, I can buy that.\n\nThe way I see it, we\u0027ve got several alternative designs (including a new suggestion inline), all of which have significant flaws, and we don\u0027t seem to be close to a consensus on which is the best (or least awful, anyway). As Chris notes, the \"contributes_to\" option, which seems to be the one being advocated by this spec, would need a lot more detail/discussion about the implications on the GET/PUT/POST /allocs operations. So my downvote is saying we either need to flesh that out, or reorganize to put one of the other alternatives to the front.","accounts_in_message":[],"_revision_number":1},{"id":"0a4f24801af57a4dc0dd023703f5c538a10e113c","author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"date":"2018-10-05 15:38:22.000000000","message":"Patch Set 1: Code-Review-1\n\n(8 comments)\n\nVery soft -1 to bikeshed on the name of the proposed new attribute in the allocation_request:resource_provider dict. I would prefer to name this \"request_groups\" instead of \"contributes_to\".\n\nThat said, good spec, Gibi. ++","accounts_in_message":[],"_revision_number":1},{"id":"1a74262ab1e3c48e434079fb5b40bad877432df2","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2018-10-05 16:28:33.000000000","message":"Patch Set 1:\n\n(1 comment)\n\nI continue to have some concerns about putting the mapping info in the body of allocation_requests.\n\nFor the common case mappings are not important. This suggests to me they should go somewhere else.","accounts_in_message":[],"_revision_number":1},{"id":"7e38f9c118d0dbd4f8ad9998f12ed6b949a40385","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-10-05 22:02:40.000000000","message":"Patch Set 1:\n\n(2 comments)\n\nIt sounds like Jay would flip to +1 with a rename of the key. I still feel like we\u0027re not that close. See my previous review.","accounts_in_message":[],"_revision_number":1},{"id":"473e03e06f2d24549fedc0810c69a6ee6ad81f36","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-04 09:13:17.000000000","message":"Patch Set 1: Workflow-1","accounts_in_message":[],"_revision_number":1},{"id":"53faa6b76d405abdbcb2071dcf68524a9b93b773","author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"date":"2019-02-11 20:17:51.000000000","message":"Patch Set 1: Code-Review-1\n\n(3 comments)","accounts_in_message":[],"_revision_number":1},{"id":"047a36cb7f1ffab7e0b685493548639588778319","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-02-20 05:31:11.000000000","message":"Patch Set 1: Code-Review-1\n\n(2 comments)","accounts_in_message":[],"_revision_number":1},{"id":"e7a5470ab9b50788102edefafcdff5e26a29bad4","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-02-22 00:05:14.000000000","message":"Patch Set 1:\n\n(5 comments)\n\nRevisited after several months, wherein we\u0027ve developed some concrete examples of why this is needed.\n\nI started off sequentially and wound up repeating a bunch of the things I had said previously a bit further down. Tried to clean that up, but there may still be some dups, sorry.\n\nTL;DR: No question we need this, but I don\u0027t think the design is quite there yet. Last comment has a suggestion that hopefully satisfies most-function-for-least-ugly.","accounts_in_message":[],"_revision_number":1},{"id":"56cbf6d2af805592877df3ee8506b2262ceab610","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-02-28 13:36:44.000000000","message":"Patch Set 1: Code-Review-1\n\n(2 comments)\n\nA couple of comments within. The second (longer) one provides some thoughts on the response structure and why we want things to be particular ways.\n\nThe -1 is basically to flag \"yeah, we haven\u0027t decided this yet\"\n\nAlso: Are there already prototypes or even \"real\" code in place that is doing this the nova-or-neutron-side way? That is version of duplicating some placement work. Have we seen it yet to definitively say that it is horrible? I guess the in-progress bandwidth stuff is? How\u0027s it seem?\n\nI\u0027m asking because I\u0027m wondering there\u0027s a way to move this forward in two steps: do it the less than great way first, without a dependency on placement changing, learn from that, and do it the most informed way later.","accounts_in_message":[],"_revision_number":1},{"id":"94fd6990a06b04e2b996717e8ad9b33e6103aaf2","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-02-28 22:57:16.000000000","message":"Patch Set 1:\n\n(2 comments)\n\n\u003e Also: Are there already prototypes or even \"real\" code in place that is doing this the nova-or-neutron-side way? That is version of duplicating some placement work.\n\nYes.\n\n\u003e Have we seen it yet to definitively say that it is horrible? I guess the in-progress bandwidth stuff is? How\u0027s it seem?\n\nYes. It\u0027s horrible. I\u0027ve linked to some of it inline.\n\n\u003e I\u0027m asking because I\u0027m wondering there\u0027s a way to move this forward in two steps: do it the less than great way first, without a dependency on placement changing, learn from that, and do it the most informed way later.\n\nFrom having done it the horrible way, we have learned that having this feature as described would be helpful. I don\u0027t think the exercise of doing it the horrible way has changed anything significant about what we think the interface ought to look like; that is, I don\u0027t think it pushes the discussion we\u0027ve already been having in this spec in one direction or another.","accounts_in_message":[],"_revision_number":1},{"id":"07a0e4663b7afdf5112dd758175e119c356e654d","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-03-04 14:02:00.000000000","message":"Patch Set 1:\n\n(1 comment)\n\nWhile I\u0027ve used gabbi as an example within for why nested data structure changes are pad, it\u0027s just an example. Any other system that is accessing data-by-path would be impacted.","accounts_in_message":[],"_revision_number":1},{"id":"67e6fcea8c16f5194eba0922b94369dcf19b7111","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-03-04 22:51:16.000000000","message":"Patch Set 1:\n\n(1 comment)","accounts_in_message":[],"_revision_number":1},{"id":"228ac0e7460d946f9789f71ab776425a825ea660","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-03-05 01:50:43.000000000","message":"Patch Set 1:\n\n(1 comment)\n\npedantry bait taken","accounts_in_message":[],"_revision_number":1},{"id":"aa57510eae1b81a6bc103d42d60a129355b25ee1","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-04-02 15:08:48.000000000","message":"Patch Set 1:\n\nAs this is primarily a placement spec, we\u0027ll want to get this resubmitted to openstack/placement:doc/source/specs\n\nBut there\u0027s a lot of useful and undigested discussion here.  Any suggestions on how to proceed.","accounts_in_message":[],"_revision_number":1},{"id":"eb09a8dd24e6bf35c0ea0afc610731132f7a3c0e","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-04-02 15:22:17.000000000","message":"Patch Set 1:\n\n\u003e As this is primarily a placement spec, we\u0027ll want to get this resubmitted to openstack/placement:doc/source/specs\n\u003e \n\u003e But there\u0027s a lot of useful and undigested discussion here.  Any suggestions on how to proceed.\n\nYeah, good point Chris.\n\nI agree this needs to be moved to a placement spec, but we don\u0027t want to lose the history. We can point back to this review from the new incarnation. It\u0027s not ideal, but it\u0027ll work. And then abandon this one.\n\nIt would be nice if the first PS of the placement spec matched the last PS of this one, for diffability. IMO better to do that by updating this one and then copying it over, so that the latest updates can stay in context of the comments that prompted them.","accounts_in_message":[],"_revision_number":1},{"id":"00531253d6c880042a959fa0ac7c9d36c11f7338","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-04-10 14:39:06.000000000","message":"Patch Set 1:\n\n(1 comment)\n\nNote, this is being discussed in the ML: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004819.html","accounts_in_message":[],"_revision_number":1},{"id":"76820fd254ffd25067e7fde47bf35776ae55fd50","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-05-07 11:54:46.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"4fc8b2217954252615f2013db3b1f7acfd634cc8","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-05-07 11:54:56.000000000","message":"Patch Set 2:\n\n(11 comments)","accounts_in_message":[],"_revision_number":2},{"id":"44f6ea7e0a21ab95a81542f83feb9c0ff7603c38","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-05-07 11:55:13.000000000","message":"Patch Set 2:\n\nUpdate the spec based on the the recent discussions.","accounts_in_message":[],"_revision_number":2},{"id":"d8faa98f5c02a25f7574bffeed79235edc0330e1","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-05-07 11:55:48.000000000","message":"Abandoned\n\nPlacement development is moved to a separate repo as well as the spec process. So this patch is superseded by https://review.opendev.org/#/c/657582/","accounts_in_message":[],"_revision_number":2}],"current_revision_number":2,"current_revision":"ba003d6b57a402739796481f1cb385bd28dd1920","revisions":{"73a7bb04a7ee8226e42da9c17e8ae9961a85978b":{"kind":"REWORK","_number":1,"created":"2018-08-29 17:02:16.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/01/597601/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/01/597601/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/01/597601/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/01/597601/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/01/597601/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/01/597601/1"}}},"commit":{"parents":[{"commit":"5409bb5de3560f8a7b99562ac7be43e4aacc26bd","subject":"Create specs directory for Stein","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/5409bb5de3560f8a7b99562ac7be43e4aacc26bd"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-08-29 16:55:26.000000000","tz":120},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-08-29 17:01:45.000000000","tz":120},"subject":"Resource provider - request group mapping in allocation candidate","message":"Resource provider - request group mapping in allocation candidate\n\nTo support QoS minimum bandwidth policy during server scheduling\nNeutron needs to know which resource provider provides the bandwidth\nresource for each port in the server create request.\n\nbp placement-resource-provider-request-group-mapping-in-allocation-candidates\n\nChange-Id: Iafdb0eab9b41f4c34c93cada08a4da27cf4b1499\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/73a7bb04a7ee8226e42da9c17e8ae9961a85978b"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/73a7bb04a7ee8226e42da9c17e8ae9961a85978b"}]},"branch":"refs/heads/master"},"ba003d6b57a402739796481f1cb385bd28dd1920":{"kind":"REWORK","_number":2,"created":"2019-05-07 11:54:46.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/01/597601/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/01/597601/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/01/597601/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/01/597601/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/01/597601/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/01/597601/2"}}},"commit":{"parents":[{"commit":"5409bb5de3560f8a7b99562ac7be43e4aacc26bd","subject":"Create specs directory for Stein","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/5409bb5de3560f8a7b99562ac7be43e4aacc26bd"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-08-29 16:55:26.000000000","tz":120},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-05-07 11:47:19.000000000","tz":120},"subject":"Resource provider - request group mapping in allocation candidate","message":"Resource provider - request group mapping in allocation candidate\n\nTo support QoS minimum bandwidth policy during server scheduling\nNeutron needs to know which resource provider provides the bandwidth\nresource for each port in the server create request.\n\nbp placement-resource-provider-request-group-mapping-in-allocation-candidates\n\nChange-Id: Iafdb0eab9b41f4c34c93cada08a4da27cf4b1499\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/ba003d6b57a402739796481f1cb385bd28dd1920"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/ba003d6b57a402739796481f1cb385bd28dd1920"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}