)]}'
{"id":"openstack%2Fplacement~662191","triplet_id":"openstack%2Fplacement~master~I55973aa7de4a85b63dff4a7d1afb6c36796af71a","project":"openstack/placement","branch":"master","topic":"story/2005575-30949","hashtags":[],"change_id":"I55973aa7de4a85b63dff4a7d1afb6c36796af71a","subject":"Spec for nested magic 1","status":"MERGED","created":"2019-05-30 12:13:14.000000000","updated":"2019-06-24 15:45:54.000000000","submitted":"2019-06-24 15:45:54.000000000","submitter":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"total_comment_count":115,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"662191-1561391154867-f9ed76da","meta_rev_id":"f60f1fd95f20092d1413ba548abb6f6d62b1df1c","_number":662191,"virtual_id_number":662191,"owner":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"actions":{},"labels":{"Verified":{"approved":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"value":2,"date":"2019-06-24 15:45:54.000000000","post_submit":true,"permitted_voting_range":{"min":2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"value":0,"date":"2019-06-21 11:54:53.000000000","_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},{"value":0,"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"value":0,"date":"2019-06-24 13:56:40.000000000","_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},{"value":0,"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"}],"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":{"approved":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"all":[{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":2,"date":"2019-06-20 15:21:12.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":2,"date":"2019-06-24 13:51:03.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"value":0,"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},{"value":0,"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"value":0,"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},{"value":0,"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"}],"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":{"approved":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"all":[{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":1,"date":"2019-06-24 13:51:03.000000000","permitted_voting_range":{"min":1,"max":1},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"value":0,"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},{"value":0,"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"value":0,"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},{"value":0,"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true},"Review-Priority":{"all":[{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"value":0,"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},{"value":0,"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"value":0,"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},{"value":0,"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"}],"values":{" 0":"Default Priority","+1":"Contributor Review Promise","+2":"Core Review Promise"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"_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":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},{"_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":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"_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":"2019-05-31 16:38:27.000000000","updated_by":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"reviewer":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"state":"REVIEWER"},{"updated":"2019-05-31 19:32:40.000000000","updated_by":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"reviewer":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"state":"REVIEWER"},{"updated":"2019-06-12 16:04:10.000000000","updated_by":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"reviewer":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"state":"REVIEWER"},{"updated":"2019-06-14 16:44:49.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-06-19 08:28:40.000000000","updated_by":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"reviewer":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"state":"REVIEWER"},{"updated":"2019-06-19 16:56:11.000000000","updated_by":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"reviewer":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"state":"REVIEWER"},{"updated":"2019-06-20 05:00:00.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-06-21 11:54:53.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"},{"updated":"2019-06-24 13:51:03.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":"2019-06-24 13:56:40.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":"2019-06-24 15:45:54.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"}],"messages":[{"id":"1130afc0b15d2155f093386c5cde5dd1ba8141d2","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-05-30 12:13:14.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"31c10628e5e85dbe66d9efa2c2da7a025761e21f","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-05-30 12:27:41.000000000","message":"Patch Set 1: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/91/662191/1/check/openstack-tox-docs/2642448/html/ : SUCCESS in 4m 06s\n- openstack-tox-pep8 http://logs.openstack.org/91/662191/1/check/openstack-tox-pep8/ac6858d/ : SUCCESS in 4m 29s","accounts_in_message":[],"_revision_number":1},{"id":"2e023fa38cabf4f2f95aa609d434a18a7e020e8d","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-05-30 12:42:32.000000000","message":"Patch Set 1: Code-Review+2\n\nThe split looks clean. The spec contains the same_subtree definitions so as I promised: +2\ngibi","accounts_in_message":[],"_revision_number":1},{"id":"bf97f63188e536bfb1e0ae75cea2d902b121c6f4","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-05-30 22:41:04.000000000","message":"Patch Set 1: Code-Review+1\n\n(1 comment)\n\nI don\u0027t get to +2 this because I wrote most of it (co-author in commit message?) but I checked the delta from the original and the changes look great (other than one \u0027not\u0027 noted inline).","accounts_in_message":[],"_revision_number":1},{"id":"662067a9ff8e6ecd8e1efd7e367104b4a0f90904","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-05-31 08:26:00.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"ac1c0fce62bcf0704c6808cb71df8afd122365fc","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-05-31 08:55:59.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/91/662191/2/check/openstack-tox-docs/97b4324/html/ : SUCCESS in 3m 48s\n- openstack-tox-pep8 http://logs.openstack.org/91/662191/2/check/openstack-tox-pep8/c228c53/ : SUCCESS in 5m 08s","accounts_in_message":[],"_revision_number":2},{"id":"91bf4579f5a79d42b4594de7839e5b642093909b","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-05-31 11:49:44.000000000","message":"Patch Set 2: Code-Review+2\n\nstill looks good","accounts_in_message":[],"_revision_number":2},{"id":"ed5a43bc168c5040a3cf5adb7f7379f9b237e3a9","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-05-31 16:03:41.000000000","message":"Patch Set 2:\n\n(6 comments)\n\nSome nits and questions inline, but overall I don\u0027t feel qualified to vote on this, per the IRC discussion today:\n\nhttp://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-05-31.log.html#t2019-05-31T15:18:19","accounts_in_message":[],"_revision_number":2},{"id":"c33f4666b39b62ec60f1daae597342bd7cf40507","author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"date":"2019-05-31 16:38:27.000000000","message":"Patch Set 2: Code-Review+1\n\n(3 comments)\n\nSome nits and a request for English examples to accompany the API calls but nothing I\u0027d block on. Leaving at +1 since mriedem has spotted an issue with a footnote and I\u0027m sure there are things I haven\u0027t thought of","accounts_in_message":[],"_revision_number":2},{"id":"8140743e2b0bb52c4ee33447f5177df89be7bc6d","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-05-31 16:58:02.000000000","message":"Patch Set 2:\n\n(4 comments)","accounts_in_message":[],"_revision_number":2},{"id":"1eca248251858794c1b3e4473e760f9d9e9d5961","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-05-31 19:32:40.000000000","message":"Patch Set 2:\n\n(1 comment)","accounts_in_message":[],"_revision_number":2},{"id":"25f916fd166f53a4726682c5a14f53bbc0e42e66","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-05-31 20:10:37.000000000","message":"Patch Set 2:\n\n(1 comment)","accounts_in_message":[],"_revision_number":2},{"id":"c1cc9a2944de7677efa4193c1f05eb83443a569b","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-05-31 20:55:14.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"0f058a8a4ca26d21415cd72ae0edb68f3ec64749","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-05-31 20:55:42.000000000","message":"Patch Set 2:\n\n(4 comments)","accounts_in_message":[],"_revision_number":2},{"id":"8d75fbccf2f1f9e0615e24a46c3b827ac685d494","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-05-31 23:58:33.000000000","message":"Patch Set 3: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/91/662191/3/check/openstack-tox-docs/685b2e7/html/ : SUCCESS in 3m 57s\n- openstack-tox-pep8 http://logs.openstack.org/91/662191/3/check/openstack-tox-pep8/e60fe12/ : SUCCESS in 3m 57s","accounts_in_message":[],"_revision_number":3},{"id":"30ca6383d431517504052c7e38eb2be9ef04ed64","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-03 10:47:39.000000000","message":"Patch Set 2:\n\n(1 comment)","accounts_in_message":[],"_revision_number":2},{"id":"f1aafb137a325ec2243530709d29d24798cb08a3","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-03 11:05:03.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"8ca87b52426e2861a64181ec8c9b8336d1b7fe40","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-03 18:19:05.000000000","message":"Patch Set 3:\n\n(2 comments)","accounts_in_message":[],"_revision_number":3},{"id":"6df45b0d48e48c11b70321106319c2257e8b982e","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-04 10:54:33.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"22deeaa932078bd70a4e9a41ca3a052f44dddff7","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-04 11:39:12.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"73436e9498e986772049d45084360c713689f01c","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-04 14:11:24.000000000","message":"Patch Set 3:\n\n(2 comments)","accounts_in_message":[],"_revision_number":3},{"id":"d72f3e741b75dc555d6eb295f0e025cb10ec8bea","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-04 15:46:10.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"d582b22fb794fbc57d729a04c8cd86a6188b229e","author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"date":"2019-06-04 22:34:01.000000000","message":"Patch Set 3:\n\n(5 comments)\n\nI have very limited knowledge of this topic but am interested in enabling NUMA affinity for vGPUs for our customers. Most of this spec reads nicely, even for me, and everything (except the section on group_policy) makes sense as pretty intuitive and sounds like a good approach.","accounts_in_message":[],"_revision_number":3},{"id":"2ce726147b30713c404a900e175013ab25eb37f7","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-05 05:30:27.000000000","message":"Patch Set 3: Code-Review-1\n\n(1 comment)\n\nThe conclusion on isolate+resourceless looks good to me, but needs to be reflected in the spec, plus one question within.","accounts_in_message":[],"_revision_number":3},{"id":"9227e4961de2cd8432c2e1243438a8fcfe744e40","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-06-05 07:17:57.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"875b43bf62d80aeec5e42bf05eabc4041ace3e28","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-05 09:23:03.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"0e26af0047f254773daeb5d69697c1a1645652b8","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-06 04:29:25.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"13fe0035ccb43198b3d2c1744abb3acb12956454","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-06 07:18:45.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"b1ba492d969c9c641a778dcda101429365acee06","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-06 20:35:08.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"f90711ee6ab21c304219e979c0f398e0cc54f1e6","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-06 20:35:24.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"9b7503927a802780ce93e10b5cbce81ef3c6494d","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-06-07 01:59:07.000000000","message":"Patch Set 4: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/91/662191/4/check/openstack-tox-docs/895778b/html/ : SUCCESS in 4m 45s\n- openstack-tox-pep8 http://logs.openstack.org/91/662191/4/check/openstack-tox-pep8/b0a056a/ : SUCCESS in 4m 15s","accounts_in_message":[],"_revision_number":4},{"id":"2e7f25cf0d94b8c2daf224459b7ccf4135b684c1","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-07 08:49:10.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"bb346a88f89b4c9b7606c568894707a9e6c33f3a","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-07 09:14:18.000000000","message":"Patch Set 4:\n\n(1 comment)\n\nA not enough coffee yet comment within.","accounts_in_message":[],"_revision_number":4},{"id":"be89dbab49b3be3f9100fbdd9607601a1b6711c9","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-07 15:40:44.000000000","message":"Patch Set 4:\n\n(2 comments)","accounts_in_message":[],"_revision_number":4},{"id":"3401bf2e6787ae190a0405472430e72ad96e6d04","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-09 07:42:20.000000000","message":"Patch Set 4:\n\n(1 comment)","accounts_in_message":[],"_revision_number":4},{"id":"3295a58fe1690aebc70efe7bb8886d3a11327ea1","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-10 09:51:47.000000000","message":"Patch Set 4:\n\n(1 comment)\n\nI\u0027m pretty sure (d) is good. More within.","accounts_in_message":[],"_revision_number":4},{"id":"682dcbad48e6b7ace1580c7107a41e01837934ff","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-10 18:06:27.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"d2550997e84a89a9186985ca8dd081a6115c0813","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-11 05:28:41.000000000","message":"Patch Set 4:\n\n(1 comment)","accounts_in_message":[],"_revision_number":4},{"id":"43b91fdd49893edc457ed0e39e77b858ccd62798","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-11 08:27:32.000000000","message":"Patch Set 4:\n\nEric and I had some discussion in IRC about some of this:\n\nhttp://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-06-10.log.html#t2019-06-10T18:06:55\n\nWe\u0027ll likely discuss this more at office hours on wednesday (1500 UTC), but I suggested it might be useful to review some of the pre-ptg discussion before hand. See, for example:\n\n* http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004782.html\n* http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004787.html\n* http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005823.html","accounts_in_message":[],"_revision_number":4},{"id":"071dbd111abbdba2712d7c3db0969cf7bc92aef4","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-11 11:26:08.000000000","message":"Patch Set 4:\n\nI\u0027ve done some experimenting on https://review.opendev.org/657510 which has been illuminating and a bit surprising (at least to me).\n\nI started out with just gabbi and a containerized placement with the yaml that is now in gabbits/traits-flow-down-experiment.yaml in the above patch, trying to model a simple something that has resourceless contributors (with traits) as well as bad cousins (members of the tree that we don\u0027t want to impact results).\n\nI then moved that file into the my resourceless WIP and at first it wouldn\u0027t work becuase there was an early exit in _alloc_candidates_multiple_providers if there were no rp_candidates. Skipping the filtering got things moving, and let the filtering I added in _check_traits_for_alloc_request to have enough inputs to filter things as desired.\n\nI\u0027m not exactly sure what we should conclude from this but it seems like useful info.","accounts_in_message":[],"_revision_number":4},{"id":"bfc26297ab24f75a82afe77c3345b1f3b46bc67c","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-11 22:31:14.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"0beff3639144f160326490d677636e5360b2b044","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-12 09:39:59.000000000","message":"Patch Set 3:\n\n(1 comment)\n\nRequest for clarification within, along with a bit of (I think important) rambling abot design.","accounts_in_message":[],"_revision_number":3},{"id":"fc4a2e917b5481b2b0ab85d901adb86065bfdcd6","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-12 10:35:27.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"37a264602db5b634b26534124dca6a5a927f13c1","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-12 10:43:18.000000000","message":"Patch Set 3:\n\n(1 comment)\n\nanother clarifying question within","accounts_in_message":[],"_revision_number":3},{"id":"a959012f8b0305af19b49d3ebce4aabbe7ce4434","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-12 14:58:27.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"4f5b63e58bec291b5a8494b0ef950b7c54807ca9","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-12 17:52:46.000000000","message":"Patch Set 4:\n\nLink to today\u0027s office hour+ [1]. Much was discussed. Some things were resolved. Some things are still unresolved.\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-06-12.log.html#t2019-06-12T14:56:00","accounts_in_message":[],"_revision_number":4},{"id":"ad84bc00dcd55d87d56caef8972b69414fd53d2c","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-13 04:56:11.000000000","message":"Patch Set 4:\n\n(1 comment)","accounts_in_message":[],"_revision_number":4},{"id":"f5dec6aa637ef6471059fd28fb42f353e84c7745","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-13 08:42:35.000000000","message":"Patch Set 4:\n\nEric\u0027s comments at http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-06-12.log.html#t2019-06-12T21:20:48 plus tetsuro\u0027s latest points about CPUs on NICs, and the office hours discussion that created the term \"solution path\" help crystallise a few things.\n\nEspecially with regard to the distinction between request-wide and group-oriented query params.\n\nThe nic cpu thing seems to kill flow-down for traits, but for aggregates we may need to continue thinking, because of the containership/target notions discussed during office hours.\n\nI think I can be convinced that some kind of \u0027already_found_solution_paths_(requires|member_of)\u003d(FOO|!FOO)\u0027 is a legit thing for solving [1], but it makes me a bit sad because that\u0027s how unsuffixed \u0027required\u0027 reads to me. When I make a query that has \u0027required\u0027 in it, it reads as \"I need a target that has FOO\" or \"make sure my host as FOO\".\n\nA question worth asking is: If we added a \u0027already_found..\u0027 why wouldn\u0027t I use that all the time instead of unsuffixed required? And if that\u0027s the case maybe unsuffixed required _is_ (that is should act like, but with the name required) \u0027already_found..\u0027?\n\nI know if feels like we are belabouring this stuff, but it feels like each day we uncover a new wrinkle, and while that is still happening it is uncomfortable to commit to anything. Those wrinkles have proved educational and illuminating.\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-06-12.log.html#t2019-06-12T21:20:48-2","accounts_in_message":[],"_revision_number":4},{"id":"32a246fd1bc3465689562539fe311c91e9936bdd","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-06-13 09:28:17.000000000","message":"Patch Set 4:\n\nMy brain dump based on yesterday\u0027s office hours discussion:\nTheory1: In openstack we have two kind of traits today:\n* trait that defines a property of a resource class\n  e.g.: HW_CPU_HYPERTHREADING -\u003e talks about the property of the [VP]CPU resource, trait attached to NUMA RP or root RP\n  other examples:\n  * CUSTOM_PHYSNET_1, CUSTOM_VNIC_TYPE_DIRECT -\u003e NET_BW_EGR_KILOBIT_PER_SEC\n  * STORAGE_DISK_SSD -\u003e DISK_GB\n  * HW_NIC_SRIOV_TRUSTED -\u003e SRIOV_NET_VF\n  * COMPUTE_VOLUME_MULTI_ATTACH -\u003e a cinder related disk resource not yet managed in placement. Until it is not managed in placement this trait could belong to the second group instead.\n\n\n* trait that defines the capability of the compute host /  hypervisor but does not tight to a specific resource the request consumes\n  e.g.: COMPUTE_TRUSTED_CERT -\u003e virt driver capability that does not connected to any specific consumable on the host\n  DEVICE_TAGGING -\u003e virt capability\n  COMPUTE_IMAGE_TYPE_*\n\nTheory2:\n* The resource specific traits (first group) has definite place in the tree (the RP that provides the related resource) and requesting these traits only meaningful if the related resource is also requested. e.g.: required1\u003dCUSTOM_PHYSNET_1 is meaningless without resources1\u003dNET_BW_EGR_KILOBIT_PER_SEC:1000.\n* In the other hand traits in the second group tend to simply be on the root RP as they are not related to any particular RP. Also these traits can be required without requesting any specific resource.\n\n\nEric\u0027s example:\n\nR() -  A(rc:X, trait:FOO)\n \\  -  B(rc:X, trait:BAR)\n\n?resources\u003dX\u0026required_1\u003dFOO\n\n* If in this example FOO and BAR are from the first group, relating to resource class X then the ?resources\u003dX\u0026required_1\u003dFOO query is not meaningful to me as it does not express the connection between X and the FO\nO trait and therefore leads to wrong results like A -\u003e FOO + B -\u003e X.\n\n* If in this example FOO is from the second trait group, then the example RP model is faulty as non resource related traits tend to be on the root RP.\n\n\nMapping Eric\u0027s example to some real life situation with:\n\nR() - NUMA0(rc:VCPU, trait:HW_CPU_X86_AVX)\n \\  - NUMA1(rc:VCPU, trait:HW_CPU_HYPERTHREADING)\n\n?resources\u003dVCPU:1\u0026required_1\u003dHW_CPU_X86_AVX  \n\nI think this request is wrong as the client knows that HW_CPU_X86_AVX is a property of the VCPU resource so it should request the rc and the trait in the same group.\n\nFor example the above query structure cannot be extended to two different type of cpu resources without start using the good formulation:  \n  ?resources_1\u003dVCPU:1\u0026required_1\u003dHW_CPU_X86_AVX\u0026resources_2:VCPU:1\u0026required_2\u003dHW_CPU_HYPERTHREADING\n\n\nIn the other hand if FOO is mapped to COMPUTE_TRUSTED_CERT then the tree feels wrong:\nR() - NUMA0(rc:VCPU, trait:COMPUTE_TRUSTED_CERT)\n \\  - NUMA1(rc:VCPU, trait:HW_CPU_HYPERTHREADING)\n\n\nSo my current view is that placement cannot be made generic and supporting both type of traits meaningfully without distinguishing them. Can we rely on the client not to create wrong trees or sends wrong queries (as in the above examples)? Unfortunately placement cannot detect that the tree / query is wrong as for placement the two types of traits are indistinguishable.","accounts_in_message":[],"_revision_number":4},{"id":"394263ddd445c01e6548187302a1a21ded5f3fa3","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-13 13:56:29.000000000","message":"Patch Set 4:\n\nI think we\u0027re getting somewhere with \"two different classes of traits\" + \"group-oriented vs request-wide query params\" + \"need a late trait(/agg) filter\" + what tetsuro refers to as (B) (which was a use case, not a solution, but I think he meant \"we only need a special case to solve (B)\"). As follows:\n\nThe only use case we care about in the context of this discussion is \"ROOT must satisfy {+/- trait/agg}, regardless of whether ROOT contributes resource\" [1].\n\nThe expression of ^ is \"request-wide\" thing.\n\nWe could think of ^ as applying to \"the solution path\". That means we have to introduce the \"solution path\" concept itself, which involves some form of \"flow\".\n- We would rather not actually \"flow down\" traits, for reasons previously discussed [2].\n- We could instead conceptualize \"solution path\" as more of a \"flow up\" - that is, we implicitly include all ancestry lines of providers otherwise involved in the solution.\n\nor\n\nWe could ditch the \"solution path\" concept and simply state that \"ROOT is always implicitly involved in the solution\".\n\nI agree with cdent\u0027s sadness that the unsuffixed \"required\" *feels* like the thing that should convey this meaning, but \"required\" is already taken. So we have two sucky choices: overload/redefine \"required\"; or come up with a new key. But if we go with the above (\"ROOT is always involved\" rather than \"solution path\"), then we can simplify from \u0027already_found_solution_paths_(requires|member_of)\u0027 to \u0027root_(required|member_of)\u0027.\n\nSo, assuming we can agree on the problem space as distilled \u0026 stated above, I\u0027m proposing the following two alternatives:\n\n- Overload the meaning of unsuffixed \"required\" and \"member_of\". Today, they mean \"providers of unsuffixed `resources` must also satisfy these trait/agg requirements\". Proposed, they mean \"providers of unsuffixed `resources` OR THE ROOT PROVIDER must also satisfy these trait/agg requirements\" [3] [4].\n- Introduce `root_(required|member_of)`, which are request-wide query params, which perform a distinct check on the root provider only [5].\n\n[1] Any other use cases can be solved via proper modeling+requesting (paraphrasing gibi: make sure your resource-specific trait is on the provider of that trait, and request that trait in the same group as that resource); or via resourceless+same_subtree (this addresses NUMA_ROOT or DEVICE_ROOT cases); or via other mechanisms already extant in master. (We should probably triple-check that this is true before we pull the trigger on anything.)\n[2] like tetsuro\u0027s \"CPU on a NIC\" thing; and gibi\u0027s \"resource-related traits should stick [only] with their resources\".\n[3] Note that this definition works when the unsuffixed group is resourceless too.\n[4] Um, for the negative cases s/OR/AND/ in your head.\n[5] Note that in this form the check could actually be done *first*, which may be a nontrivial performance boon.","accounts_in_message":[],"_revision_number":4},{"id":"ee3aa1d0b52360f45a1a2f2bc929eebd09d4ec3b","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-06-13 16:23:48.000000000","message":"Patch Set 4: Code-Review+1\n\n(17 comments)\n\nA few comments on the formatting of the spec, but not worth -1ing them. IF people are cool with a FUP, I\u0027m okay with +2ing this spec.","accounts_in_message":[],"_revision_number":4},{"id":"65d20b91c74a38b824b638a903bd0b5b55746ce6","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-13 20:21:58.000000000","message":"Patch Set 4:\n\n(10 comments)\n\nThank you for reviewing, Sylvain.","accounts_in_message":[],"_revision_number":4},{"id":"6f1b1299ae63251fe526dcd341e71fb21aed3089","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-06-14 15:48:21.000000000","message":"Patch Set 4:\n\n(2 comments)","accounts_in_message":[],"_revision_number":4},{"id":"656616c4f3a82f90eeedadb9fb0276eb79646917","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-14 16:35:38.000000000","message":"Patch Set 4:\n\n(1 comment)","accounts_in_message":[],"_revision_number":4},{"id":"0de6c42cf88f1444ec05189801702f7ba92dec07","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-06-14 16:44:49.000000000","message":"Patch Set 4:\n\n(1 comment)","accounts_in_message":[],"_revision_number":4},{"id":"938ebb41e89071037a0b3c9caf71628e8622acef","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-16 09:36:39.000000000","message":"Patch Set 4:\n\nFeedback to Eric\u0027s proposals in PS4;\n\n \u003e “providers of unsuffixed `resources` OR THE ROOT PROVIDER\n \u003e must also satisfy these trait/agg requirements”\n\nThis will have a change in the existing API (i.e. with already supported query). Not sure we want to have microversion for that. Plus, personally I don’t love “implicit” trait/aggregate ideas as I said in [1].\n\n[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004909.html\n\n \u003e Introduce `root_required`, which are request-wide query params,\n \u003e which perform a distinct check on the root provider only.\n\nThis is clearer and is my preference between the two, but why request-wide? Being request-wide, it’s a bit confusing to define if this means either “anchor_root_required” or “root_required” or both. Please also refer to my comments in [2].\n\n[2] https://review.opendev.org/#/c/665492/4/placement/tests/functional/gabbits/allocation-candidates-root_required.yaml@84","accounts_in_message":[],"_revision_number":4},{"id":"2c8aa016a445c6bcbe41dde4bb45bdd6398d1031","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-16 12:44:17.000000000","message":"Patch Set 4:\n\n\u003e why request-wide? \n\nSo that I can specify it without worrying which of my request groups will be satisfied by sharing or non-sharing providers. E.g. in a model where DISK_GB exists both on the host and on a sharing provider.\n\n\u003e Being request-wide, it’s a bit confusing to define if this means either “anchor_root_required” or “root_required” or both.\n\nI agree about the confusion. I definitely mean \"anchor_root_required\". I\u0027m (at least currently) not interested in the use case where a) sharing providers are nested and b) I care about traits on *their* roots.\n\nThat being the case, do you agree it makes sense for it to be request-wide?\n\n Let\u0027s find a way, either through naming or docs, to make this clear.","accounts_in_message":[],"_revision_number":4},{"id":"0c3a11e095b164b6597c21e99c7847da4619678c","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-17 09:55:49.000000000","message":"Patch Set 4:\n\n\u003e That being the case, do you agree it makes sense for it to be request-wide?\n\nYes. Thanks for the clarification.","accounts_in_message":[],"_revision_number":4},{"id":"d42825834b73b15ef7eda17e46b76ce9c2907233","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-17 11:20:44.000000000","message":"Patch Set 4:\n\n\u003e \u003e Being request-wide, it’s a bit confusing to define if this means\n \u003e either “anchor_root_required” or “root_required” or both.\n\nAre \"anchor\" and \"target\" synonyms?","accounts_in_message":[],"_revision_number":4},{"id":"c6485105efd208fd1f9217b90b15d2c6823dbe51","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-06-17 14:29:02.000000000","message":"Patch Set 4:\n\nExplicit tend to be better than implicit so the new request-wide-required key works for me. I\u0027m happy to ignore the case when only a subtree root has a trait but no resources. I don\u0027t see any real examples today for that.\n\nDo we want to specify request-wide-forbidden as well?","accounts_in_message":[],"_revision_number":4},{"id":"14c50c572b1b6dc1a247b8c0588abc03e0eacf0f","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-18 18:35:28.000000000","message":"Uploaded patch set 5.","accounts_in_message":[],"_revision_number":5},{"id":"fa8c3c31ff9d61aaeb9eea892accd9e7cc93f0d2","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-18 18:38:01.000000000","message":"Patch Set 5:\n\nThis patch set hopefully incorporates the conclusions of all the\ndiscussions since the previous one. In particular:\n\n- Describes \"resource vs. provider traits\"\n- Describes \"group-specific vs. request-wide query parameters\"\n- Suggests what we should do about resourceless *without* same_subtree\n  (response requested please).\n- Adds ``root_required``.\n\nSpecific questions answered:\n\n\u003e Are \"anchor\" and \"target\" synonyms?\n\nI don\u0027t have a definition of \"target\" in my head. It\u0027s not a term used\nin the docs anywhere; and in the code it\u0027s used in a very localized way\nto refer to \"whatever thingy we\u0027re dealing with in this method\".\n\nBy now I strongly believe that there is no single word that, without\nadditional explanation, embodies the concept of \"root of the non-sharing\ntree involved in the allocation candidate\". (\"host\" comes close, but\nthat\u0027s a specific nova-centric instance of the idea.) So since \"anchor\"\nis what\u0027s already being used in the code, we might as well go with it\nwithin the dev team. But we should continue to refrain as long as\npossible from needing that term to be user-facing.\n\n\u003e Do we want to specify request-wide-forbidden as well?\n\nThis is incorporated in ``root_required``, which accepts the ``!``\nprefix on trait names just like ``required[$S]``.","accounts_in_message":[],"_revision_number":5},{"id":"7ccd99bc1b0ef7cc343a0fc95b83e93ac10186de","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-06-19 03:42:34.000000000","message":"Patch Set 5: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/91/662191/5/check/openstack-tox-docs/3a68c24/html/ : SUCCESS in 4m 25s\n- openstack-tox-pep8 http://logs.openstack.org/91/662191/5/check/openstack-tox-pep8/b95112f/ : SUCCESS in 5m 59s","accounts_in_message":[],"_revision_number":5},{"id":"581924ce591fb56babd7de66c9ac677d8bb3a5a9","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-06-19 08:28:40.000000000","message":"Patch Set 5: Code-Review+2\n\n(2 comments)\n\nLGTM! Thanks Eric!","accounts_in_message":[],"_revision_number":5},{"id":"31eedf503b8e0b10c48cf7893154b3bfce597d9b","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-19 09:11:06.000000000","message":"Patch Set 5:\n\n(1 comment)","accounts_in_message":[],"_revision_number":5},{"id":"384e7fd93eba8f4e9c8859918ead07167804f1d0","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-19 10:40:39.000000000","message":"Patch Set 5:\n\n(1 comment)","accounts_in_message":[],"_revision_number":5},{"id":"d61a2b740228107c4990371c74f68ab5791a1b9c","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-19 14:59:22.000000000","message":"Patch Set 5:\n\n\u003e This patch set hopefully incorporates the conclusions of all the\n \u003e discussions since the previous one. In particular:\n\nWill respond in stages. This is before actually reading the spec, just wanted to get to a particular question.\n\n \u003e \u003e Are \"anchor\" and \"target\" synonyms?\n \u003e \n \u003e I don\u0027t have a definition of \"target\" in my head. It\u0027s not a term\n \u003e used\n \u003e in the docs anywhere; and in the code it\u0027s used in a very localized\n \u003e way\n \u003e to refer to \"whatever thingy we\u0027re dealing with in this method\".\n\nYour (and my) confusion is part of why I asked. I\u0027ve never understood what \"anchor\" means in the code but it appears to mean \"the place where a request workload lands, as identified by the root provider id of the non-sharing provider\". Is that right?\n\nExternal to the code \"target\" (or something else) makes more sense for \"a place where this workload might land (as identified by the root provider)\" than anchor. An anchor is a thing other providers in the current tree care about.\n\nTarget is a thing the client cares about: Where I can _place_ this.\n\nSo, based on that, it might be they are not quite synonyms but might both be useful. If we want to use \"anchor\" as the term for both I\u0027m happy with that if we want to settle that way.","accounts_in_message":[],"_revision_number":5},{"id":"f128dcdf0d262af2d840350804b297f3eee7317d","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-19 15:24:45.000000000","message":"Patch Set 5: Code-Review+1\n\n(2 comments)\n\nWe seem to be nearing consensus and also seem to pushed the number of invested people down to 4. That feels risky but I don\u0027t think there\u0027s an alternative.\n\nWe may find ourselves in some corners with dragons. In fact, I think it is inevitable, but we\u0027ve been there before and survived. We need to keep things moving and deal with the warts as they happen.\n\nI\u0027m still a bit sad about adding yet more syntax, but it\u0027s good that we are keeping it contained to what I consider \"specialist\" use cases and existing simple cases will continue to work as is.\n\nI want to read it again tomorrow, but I\u0027m happy enough to signal a +1 to just say \"yeah\"","accounts_in_message":[],"_revision_number":5},{"id":"adfba8f3565d099b0c4fa493079b94e119accf56","author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"date":"2019-06-19 16:56:11.000000000","message":"Patch Set 5: Code-Review+1\n\n(6 comments)\n\nI was waiting for the deep dive discussions to settle before reading again. Looks reasonable to me, soft +1 as I\u0027m not well versed in placement.","accounts_in_message":[],"_revision_number":5},{"id":"ec3a1415f4def09295e3a317be2f18f6c9274550","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-19 23:08:56.000000000","message":"Uploaded patch set 6.","accounts_in_message":[],"_revision_number":6},{"id":"9820d09ad9530385068c4fb77a2004119115b346","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-19 23:09:21.000000000","message":"Patch Set 5:\n\n(6 comments)","accounts_in_message":[],"_revision_number":5},{"id":"00bc4d8c4a30172ca909c2f0208a3efda2d6ea29","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-06-20 02:56:58.000000000","message":"Patch Set 6: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/91/662191/6/check/openstack-tox-docs/7c1fdb7/html/ : SUCCESS in 3m 44s\n- openstack-tox-pep8 http://logs.openstack.org/91/662191/6/check/openstack-tox-pep8/e1b5ddd/ : SUCCESS in 13m 37s","accounts_in_message":[],"_revision_number":6},{"id":"e741835d760b23b5ea64a3abdd3c6ff29db406b0","author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"date":"2019-06-20 05:00:00.000000000","message":"Patch Set 6:\n\n(1 comment)","accounts_in_message":[],"_revision_number":6},{"id":"b55ce210f6536291e3c06713c8374a99643a59c6","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-20 08:38:51.000000000","message":"Patch Set 6:\n\n(1 comment)","accounts_in_message":[],"_revision_number":6},{"id":"0b778374912b30d245ae8de31e6e2a37af4a2e54","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-20 12:14:55.000000000","message":"Patch Set 6:\n\n(1 comment)\n\nquestion for explicit clarification within\n\n(this is like my full time job now)\n\nback again with more review shortly","accounts_in_message":[],"_revision_number":6},{"id":"23d001e10c75bf1ca2f055b1b48b0c22d23d5788","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-20 12:28:24.000000000","message":"Patch Set 6:\n\n(1 comment)","accounts_in_message":[],"_revision_number":6},{"id":"9351c6c9adf0b60a0ceb3adf19f6063bd87d67ab","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-20 13:30:16.000000000","message":"Patch Set 6:\n\n(3 comments)\n\nOther than the fixup on the member_of discussion, I guess we got a runner here.","accounts_in_message":[],"_revision_number":6},{"id":"b21cb0b8c23ab1dd593000a73653650cc2cfa37b","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-20 15:17:41.000000000","message":"Patch Set 6:\n\n(1 comment)","accounts_in_message":[],"_revision_number":6},{"id":"3f13a487bdc874ec536257fb6d9f550e24add9dd","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-20 15:18:08.000000000","message":"Uploaded patch set 7.","accounts_in_message":[],"_revision_number":7},{"id":"48515a92c014998a9f29a4e820177049f2d4565a","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-06-20 15:21:12.000000000","message":"Patch Set 7: Code-Review+2\n\nWith the caveat that we\u0027ll likely find creepy things creeping as we work with things, let\u0027s make it happen. I think we\u0027ve clarified a lot of language and goals and that\u0027s good.","accounts_in_message":[],"_revision_number":7},{"id":"d34bd0811bea198cc0c3263cec9fb2c48947a2f9","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-06-20 20:55:40.000000000","message":"Patch Set 7: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/91/662191/7/check/openstack-tox-docs/f2c1f13/html/ : SUCCESS in 6m 23s\n- openstack-tox-pep8 http://logs.openstack.org/91/662191/7/check/openstack-tox-pep8/044d7c0/ : SUCCESS in 4m 24s","accounts_in_message":[],"_revision_number":7},{"id":"f3e127a60faabb4e618e3d7111a06ccac294f968","author":{"_account_id":26936,"name":"Surya Seetharaman","email":"suryaseetharaman.9@gmail.com","username":"tssurya"},"date":"2019-06-21 11:54:53.000000000","message":"Patch Set 7:\n\n(1 comment)","accounts_in_message":[],"_revision_number":7},{"id":"64648a63ed942c45ed8271b3a4eee7316f5e84dc","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-06-24 13:51:03.000000000","message":"Patch Set 7: Code-Review+2 Workflow+1\n\n(2 comments)\n\nHonestly, I still have some wonders about what we could do, but let\u0027s just accept this spec now, review the implementation changes and just pass a spec follow-up if something needs it.\n\nThanks,\n-Sylvain","accounts_in_message":[],"_revision_number":7},{"id":"d7cc7f6dc22d483b2200f8845ff6eaec24d25ef4","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-06-24 13:51:22.000000000","message":"Patch Set 7: -Verified\n\nStarting gate jobs.","accounts_in_message":[],"_revision_number":7},{"id":"260eeef206379df6ce6ee55163f454521496ae0f","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-24 13:56:40.000000000","message":"Patch Set 7:\n\n(1 comment)\n\nThanks Sylvain.","accounts_in_message":[],"_revision_number":7},{"id":"dfba7f5fdb9da712e07cf3e8fed491f19a6a9db4","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-06-24 15:45:54.000000000","message":"Change has been successfully merged by Zuul","accounts_in_message":[],"_revision_number":7},{"id":"1b38f755a5978e207e5fc82755c08e883347a2f6","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-06-24 15:45:54.000000000","message":"Patch Set 7: Verified+2\n\nBuild succeeded (gate pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/91/662191/7/gate/openstack-tox-docs/98a4e1f/html/ : SUCCESS in 5m 49s\n- openstack-tox-pep8 http://logs.openstack.org/91/662191/7/gate/openstack-tox-pep8/96ee3dd/ : SUCCESS in 5m 14s","accounts_in_message":[],"_revision_number":7}],"current_revision_number":7,"current_revision":"c00d043376811c0b4b42fbe845fa8f093351b0b5","revisions":{"ca6988afecedd80a0177237aef47c806bbd5efb7":{"kind":"REWORK","_number":1,"created":"2019-05-30 12:13:14.000000000","uploader":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"ref":"refs/changes/91/662191/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/placement","ref":"refs/changes/91/662191/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/placement refs/changes/91/662191/1"}}},"commit":{"parents":[{"commit":"7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4","subject":"Reuse cache result for sharing providers capacity","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4"}]}],"author":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-30 12:10:19.000000000","tz":60},"committer":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-30 12:10:19.000000000","tz":60},"subject":"Spec for nested magic 1","message":"Spec for nested magic 1\n\nThis is a spec for several nested features which has been split\noff from the original spec for nested magic [1] in an effort to\nnot delay progress on these features while \u0027can_split\u0027 is being\ndiscussed.\n\nThis spec describes a cluster of Placement API work to support several\ninterrelated use cases for Train around:\n\n* Modeling complex trees such as NUMA layouts, multiple devices,\n  networks.\n* Requesting affinity (in the NUMA sense) between/among the various\n  providers/allocations in allocation candidates against such layouts.\n* Describing granular groups more richly to facilitate the above.\n\nIn particular, it describes the new GET /allocation_candidates\nfeatures:\n\n* arbitrary group suffixes\n* same_subtree query parameter\n* resourceless request groups\n\n[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e\n\nChange-Id: I55973aa7de4a85b63dff4a7d1afb6c36796af71a\nStory: #2005575\nTask: #30949\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/ca6988afecedd80a0177237aef47c806bbd5efb7"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/ca6988afecedd80a0177237aef47c806bbd5efb7"}]},"branch":"refs/heads/master"},"344aebb5737d0acf7f75e8e4300f8f5297e217b6":{"kind":"REWORK","_number":2,"created":"2019-05-31 08:26:00.000000000","uploader":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"ref":"refs/changes/91/662191/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/placement","ref":"refs/changes/91/662191/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/placement refs/changes/91/662191/2"}}},"commit":{"parents":[{"commit":"7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4","subject":"Reuse cache result for sharing providers capacity","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4"}]}],"author":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-30 12:10:19.000000000","tz":60},"committer":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-31 08:25:23.000000000","tz":60},"subject":"Spec for nested magic 1","message":"Spec for nested magic 1\n\nThis is a spec for several nested features which has been split\noff from the original spec for nested magic [1] in an effort to\nnot delay progress on these features while \u0027can_split\u0027 is being\ndiscussed.\n\nThis spec describes a cluster of Placement API work to support several\ninterrelated use cases for Train around:\n\n* Modeling complex trees such as NUMA layouts, multiple devices,\n  networks.\n* Requesting affinity (in the NUMA sense) between/among the various\n  providers/allocations in allocation candidates against such layouts.\n* Describing granular groups more richly to facilitate the above.\n\nIn particular, it describes the new GET /allocation_candidates\nfeatures:\n\n* arbitrary group suffixes\n* same_subtree query parameter\n* resourceless request groups\n\n[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e\n\nCo-Authored-By: Eric Fried \u003copenstack@fried.cc\u003e\nChange-Id: I55973aa7de4a85b63dff4a7d1afb6c36796af71a\nStory: #2005575\nTask: #30949\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/344aebb5737d0acf7f75e8e4300f8f5297e217b6"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/344aebb5737d0acf7f75e8e4300f8f5297e217b6"}]},"branch":"refs/heads/master"},"37c202115e773ca89e734db3f1cf5aa01c30ae9a":{"kind":"REWORK","_number":3,"created":"2019-05-31 20:55:14.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/91/662191/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/placement","ref":"refs/changes/91/662191/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/placement refs/changes/91/662191/3"}}},"commit":{"parents":[{"commit":"7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4","subject":"Reuse cache result for sharing providers capacity","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4"}]}],"author":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-30 12:10:19.000000000","tz":60},"committer":{"name":"Eric Fried","email":"openstack@fried.cc","date":"2019-05-31 20:55:11.000000000","tz":-300},"subject":"Spec for nested magic 1","message":"Spec for nested magic 1\n\nThis is a spec for several nested features which has been split\noff from the original spec for nested magic [1] in an effort to\nnot delay progress on these features while \u0027can_split\u0027 is being\ndiscussed.\n\nThis spec describes a cluster of Placement API work to support several\ninterrelated use cases for Train around:\n\n* Modeling complex trees such as NUMA layouts, multiple devices,\n  networks.\n* Requesting affinity (in the NUMA sense) between/among the various\n  providers/allocations in allocation candidates against such layouts.\n* Describing granular groups more richly to facilitate the above.\n\nIn particular, it describes the new GET /allocation_candidates\nfeatures:\n\n* arbitrary group suffixes\n* same_subtree query parameter\n* resourceless request groups\n\n[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e\n\nCo-Authored-By: Eric Fried \u003copenstack@fried.cc\u003e\nChange-Id: I55973aa7de4a85b63dff4a7d1afb6c36796af71a\nStory: #2005575\nTask: #30949\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/37c202115e773ca89e734db3f1cf5aa01c30ae9a"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/37c202115e773ca89e734db3f1cf5aa01c30ae9a"}]},"branch":"refs/heads/master"},"40ea95bcfedf3b4e08e9a3a2363c0099c16fde36":{"kind":"REWORK","_number":4,"created":"2019-06-06 20:35:08.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/91/662191/4","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/placement","ref":"refs/changes/91/662191/4","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/placement refs/changes/91/662191/4"}}},"commit":{"parents":[{"commit":"7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4","subject":"Reuse cache result for sharing providers capacity","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4"}]}],"author":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-30 12:10:19.000000000","tz":60},"committer":{"name":"Eric Fried","email":"openstack@fried.cc","date":"2019-06-06 20:35:06.000000000","tz":-300},"subject":"Spec for nested magic 1","message":"Spec for nested magic 1\n\nThis is a spec for several nested features which has been split\noff from the original spec for nested magic [1] in an effort to\nnot delay progress on these features while \u0027can_split\u0027 is being\ndiscussed.\n\nThis spec describes a cluster of Placement API work to support several\ninterrelated use cases for Train around:\n\n* Modeling complex trees such as NUMA layouts, multiple devices,\n  networks.\n* Requesting affinity (in the NUMA sense) between/among the various\n  providers/allocations in allocation candidates against such layouts.\n* Describing granular groups more richly to facilitate the above.\n\nIn particular, it describes the new GET /allocation_candidates\nfeatures:\n\n* arbitrary group suffixes\n* same_subtree query parameter\n* resourceless request groups\n\n[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e\n\nCo-Authored-By: Eric Fried \u003copenstack@fried.cc\u003e\nChange-Id: I55973aa7de4a85b63dff4a7d1afb6c36796af71a\nStory: #2005575\nTask: #30949\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/40ea95bcfedf3b4e08e9a3a2363c0099c16fde36"}]},"branch":"refs/heads/master"},"adc8972d32c418ce9104dfa6866936168ab5bd13":{"kind":"REWORK","_number":5,"created":"2019-06-18 18:35:28.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/91/662191/5","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/placement","ref":"refs/changes/91/662191/5","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/placement refs/changes/91/662191/5"}}},"commit":{"parents":[{"commit":"7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4","subject":"Reuse cache result for sharing providers capacity","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4"}]}],"author":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-30 12:10:19.000000000","tz":60},"committer":{"name":"Eric Fried","email":"openstack@fried.cc","date":"2019-06-18 18:32:04.000000000","tz":-300},"subject":"Spec for nested magic 1","message":"Spec for nested magic 1\n\nThis is a spec for several nested features which has been split\noff from the original spec for nested magic [1] in an effort to\nnot delay progress on these features while \u0027can_split\u0027 is being\ndiscussed.\n\nThis spec describes a cluster of Placement API work to support several\ninterrelated use cases for Train around:\n\n* Modeling complex trees such as NUMA layouts, multiple devices,\n  networks.\n* Requesting affinity (in the NUMA sense) between/among the various\n  providers/allocations in allocation candidates against such layouts.\n* Describing granular groups more richly to facilitate the above.\n* Requesting candidates based on traits that are not necessarily\n  associated with resources.\n\nIn particular, it describes the new GET /allocation_candidates\nfeatures:\n\n* arbitrary group suffixes\n* same_subtree query parameter\n* resourceless request groups\n* root_required\n\n[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e\n\nCo-Authored-By: Eric Fried \u003copenstack@fried.cc\u003e\nChange-Id: I55973aa7de4a85b63dff4a7d1afb6c36796af71a\nStory: #2005575\nTask: #30949\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/adc8972d32c418ce9104dfa6866936168ab5bd13"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/adc8972d32c418ce9104dfa6866936168ab5bd13"}]},"branch":"refs/heads/master"},"4ba0323625edd28c821576759ac8ec71be1e47f4":{"kind":"REWORK","_number":6,"created":"2019-06-19 23:08:56.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/91/662191/6","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/placement","ref":"refs/changes/91/662191/6","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/placement refs/changes/91/662191/6"}}},"commit":{"parents":[{"commit":"7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4","subject":"Reuse cache result for sharing providers capacity","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4"}]}],"author":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-30 12:10:19.000000000","tz":60},"committer":{"name":"Eric Fried","email":"openstack@fried.cc","date":"2019-06-19 23:08:07.000000000","tz":-300},"subject":"Spec for nested magic 1","message":"Spec for nested magic 1\n\nThis is a spec for several nested features which has been split\noff from the original spec for nested magic [1] in an effort to\nnot delay progress on these features while \u0027can_split\u0027 is being\ndiscussed.\n\nThis spec describes a cluster of Placement API work to support several\ninterrelated use cases for Train around:\n\n* Modeling complex trees such as NUMA layouts, multiple devices,\n  networks.\n* Requesting affinity (in the NUMA sense) between/among the various\n  providers/allocations in allocation candidates against such layouts.\n* Describing granular groups more richly to facilitate the above.\n* Requesting candidates based on traits/aggregates that are not\n  necessarily associated with resources.\n\nIn particular, it describes the new GET /allocation_candidates\nfeatures:\n\n* arbitrary group suffixes\n* same_subtree query parameter\n* resourceless request groups\n* root_required, root_member_of\n\n[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e\n\nCo-Authored-By: Eric Fried \u003copenstack@fried.cc\u003e\nChange-Id: I55973aa7de4a85b63dff4a7d1afb6c36796af71a\nStory: #2005575\nTask: #30949\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/4ba0323625edd28c821576759ac8ec71be1e47f4"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/4ba0323625edd28c821576759ac8ec71be1e47f4"}]},"branch":"refs/heads/master"},"c00d043376811c0b4b42fbe845fa8f093351b0b5":{"kind":"REWORK","_number":7,"created":"2019-06-20 15:18:08.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/91/662191/7","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/placement","ref":"refs/changes/91/662191/7","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/placement refs/changes/91/662191/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/placement refs/changes/91/662191/7"}}},"commit":{"parents":[{"commit":"7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4","subject":"Reuse cache result for sharing providers capacity","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/7b8e2a8a6b8814dbe236f3d0debeea68033c1ae4"}]}],"author":{"name":"Chris Dent","email":"cdent@anticdent.org","date":"2019-05-30 12:10:19.000000000","tz":60},"committer":{"name":"Eric Fried","email":"openstack@fried.cc","date":"2019-06-20 15:18:06.000000000","tz":-300},"subject":"Spec for nested magic 1","message":"Spec for nested magic 1\n\nThis is a spec for several nested features which has been split\noff from the original spec for nested magic [1] in an effort to\nnot delay progress on these features while \u0027can_split\u0027 is being\ndiscussed.\n\nThis spec describes a cluster of Placement API work to support several\ninterrelated use cases for Train around:\n\n* Modeling complex trees such as NUMA layouts, multiple devices,\n  networks.\n* Requesting affinity (in the NUMA sense) between/among the various\n  providers/allocations in allocation candidates against such layouts.\n* Describing granular groups more richly to facilitate the above.\n* Requesting candidates based on traits/aggregates that are not\n  necessarily associated with resources.\n\nIn particular, it describes the new GET /allocation_candidates\nfeatures:\n\n* arbitrary group suffixes\n* same_subtree query parameter\n* resourceless request groups\n* root_required, root_member_of\n\n[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e\n\nCo-Authored-By: Eric Fried \u003copenstack@fried.cc\u003e\nChange-Id: I55973aa7de4a85b63dff4a7d1afb6c36796af71a\nStory: #2005575\nTask: #30949\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/c00d043376811c0b4b42fbe845fa8f093351b0b5"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/placement/commit/c00d043376811c0b4b42fbe845fa8f093351b0b5"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}