)]}'
{"id":"openstack%2Fnova-specs~612497","triplet_id":"openstack%2Fnova-specs~master~I3b3f3227bc8c0c6a1057122a3014131b1baf72a6","project":"openstack/nova-specs","branch":"master","topic":"bp/provider-config-file","hashtags":[],"change_id":"I3b3f3227bc8c0c6a1057122a3014131b1baf72a6","subject":"Spec: Provider config YAML file","status":"MERGED","created":"2018-10-22 20:16:31.000000000","updated":"2019-07-19 18:34:34.000000000","submitted":"2019-07-19 18:34:34.000000000","submitter":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"total_comment_count":367,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"612497-1563561274814-ef2d6f53","meta_rev_id":"9a374b930e59c880cd49f02dcc92bc12453b1c5c","_number":612497,"virtual_id_number":612497,"owner":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"actions":{},"labels":{"Verified":{"approved":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"value":0,"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},{"value":0,"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":0,"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},{"value":0,"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"value":2,"date":"2019-07-19 18:34:34.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},{"value":0,"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},{"value":0,"_account_id":29745,"name":"Dustin Cowles","email":"cowlesd@gmail.com","username":"dustinc","status":"inactive"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"date":"2019-07-19 18:05:39.000000000","_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},{"value":0,"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},{"value":0,"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"}],"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":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"all":[{"value":0,"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},{"value":0,"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":0,"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},{"value":2,"date":"2019-07-19 18:06:00.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},{"value":0,"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},{"value":0,"_account_id":29745,"name":"Dustin Cowles","email":"cowlesd@gmail.com","username":"dustinc","status":"inactive"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},{"value":0,"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},{"value":0,"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"}],"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":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"all":[{"value":0,"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},{"value":0,"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":0,"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},{"value":1,"date":"2019-07-19 18:06:00.000000000","permitted_voting_range":{"min":1,"max":1},"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},{"value":0,"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},{"value":0,"_account_id":29745,"name":"Dustin Cowles","email":"cowlesd@gmail.com","username":"dustinc","status":"inactive"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},{"value":0,"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},{"value":0,"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true},"Review-Priority":{"all":[{"value":0,"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},{"value":0,"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":0,"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},{"value":0,"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},{"value":0,"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},{"value":0,"_account_id":29745,"name":"Dustin Cowles","email":"cowlesd@gmail.com","username":"dustinc","status":"inactive"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},{"value":0,"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},{"value":0,"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"}],"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":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},{"_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":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},{"_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":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},{"_account_id":29745,"name":"Dustin Cowles","email":"cowlesd@gmail.com","username":"dustinc","status":"inactive"},{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2018-10-23 13:34:45.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":"2018-10-24 10:37:24.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-12-04 18:33:47.000000000","updated_by":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"reviewer":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"state":"REVIEWER"},{"updated":"2018-12-04 18:34:06.000000000","updated_by":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"reviewer":{"_account_id":21672,"name":"Sundar Nadathur","email":"sundar.nadathur@intel.com","username":"nsundar"},"state":"REVIEWER"},{"updated":"2018-12-04 18:34:38.000000000","updated_by":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"reviewer":{"_account_id":27961,"name":"Konstantinos Samaras-Tsakiris","email":"konstantinos.samaras-tsakiris@cern.ch","username":"kosamara"},"state":"REVIEWER"},{"updated":"2019-01-14 19:32:24.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-05-31 18:26:26.000000000","updated_by":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"reviewer":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"state":"REVIEWER"},{"updated":"2019-07-03 16:34:29.000000000","updated_by":{"_account_id":29745,"name":"Dustin Cowles","email":"cowlesd@gmail.com","username":"dustinc","status":"inactive"},"reviewer":{"_account_id":29745,"name":"Dustin Cowles","email":"cowlesd@gmail.com","username":"dustinc","status":"inactive"},"state":"REVIEWER"},{"updated":"2019-07-17 09:57:07.000000000","updated_by":{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},"reviewer":{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},"state":"REVIEWER"},{"updated":"2019-07-18 01:03:38.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-07-18 07:59:04.000000000","updated_by":{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},"reviewer":{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},"state":"REVIEWER"},{"updated":"2019-07-18 11:17:59.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-07-18 19:35:10.000000000","updated_by":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"reviewer":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"state":"REVIEWER"},{"updated":"2019-07-19 14:19:24.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-07-19 18:06:00.000000000","updated_by":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"reviewer":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"state":"REVIEWER"},{"updated":"2019-07-19 18:34:34.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":"990d6cf66bb592183279df6cb9587afc3d86ab52","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-10-22 20:16:31.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"f5a034b4fa1c3fe4e61d80088490564962483863","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-10-22 21:14:18.000000000","message":"Patch Set 1: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/1/check/openstack-tox-docs/5de3f5a/html/ : SUCCESS in 6m 37s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/1/check/openstack-tox-pep8/826d3cd/ : SUCCESS in 6m 00s","accounts_in_message":[],"_revision_number":1},{"id":"52800a549649b310cc9fae615a06f0fb204c0fa2","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2018-10-23 13:34:45.000000000","message":"Patch Set 1:\n\n(4 comments)\n\nI like this feature, some questions.","accounts_in_message":[],"_revision_number":1},{"id":"36f5cd2cf410c89b70744ae0eead84e5a4137f8c","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2018-10-23 20:00:29.000000000","message":"Patch Set 1:\n\n(2 comments)\n\nNeed to think about this harder, but meandering comment within about my first reaction.","accounts_in_message":[],"_revision_number":1},{"id":"88215ad5e59261d1cbd054b9afb9587421612c54","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2018-10-24 10:37:24.000000000","message":"Patch Set 1: Code-Review-1\n\n(8 comments)\n\nWhile I agree with the objective, I think we shouldn\u0027t block other specs because of this spec.\n\nDeprecating config options is simple, so we could just do something like :\n- create the YAML file\n- for a specific usecase (say PCI passthrough), deprecate the option and add the YAML needed version\n- next cycle, remove the deprecated option\n\nThat way, it wouldn\u0027t really block the other specs.\n\nAlso, we really need to think about upgrades, FFU and reshape in this spec.","accounts_in_message":[],"_revision_number":1},{"id":"b83499b3fb9559f5758559d989f302f009b484eb","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-10-24 23:03:57.000000000","message":"Patch Set 1:\n\n(12 comments)\n\n\u003e While I agree with the objective, I think we shouldn\u0027t block other specs because of this spec.\n\nNot sure what gave you the impression that we would be doing that.\n\n\u003e Deprecating config options is simple, so we could just do something like :\n\u003e \n\u003e create the YAML file\n\u003e for a specific usecase (say PCI passthrough), deprecate the option and add the YAML needed version\n\u003e next cycle, remove the deprecated option\n\u003e That way, it wouldn\u0027t really block the other specs.\n\nYes, that\u0027s exactly how I would expect things to go. Otherwise we would be holding up nearly every feature in the queue, which is clearly not realistic.\n\n\u003e Also, we really need to think about upgrades, FFU and reshape in this spec.\n\nNo, we do not. The work outlined in this spec is deliberately narrowly scoped to defining the format of the file. The code product is a schema/parser/validator/sample. The file could be used in a million ways by a million features in this and future cycles. We cannot and should not attempt to design all of them now. The Use Cases section describes a few of the features we know about that *might* use this at *some* point, and we\u0027ve designed the file with those in mind. But this document was born in part out of complaints that the spec that attempted to design the file and one (just one) use case for it was too long [1].\n\nNow, I don\u0027t think it\u0027s unreasonable for us to write up at least one spec that will depend on this work. I intend to modify the device-placement-model spec to that end. That spec will have to address upgrade concerns for migrating from [pci]passthrough_whitelist. And it\u0027s not out of the question that iterating on that spec will necessitate changes to the file format outlined here. That\u0027s fine, and it\u0027s why we define versioning.\n\n[1] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst@234","accounts_in_message":[],"_revision_number":1},{"id":"2650f775a43e8543261e27d838caf03a1a1e63c2","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-12-04 18:33:37.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"0ebf184bb1f1e37dbcb1b9eca75794f4fb7a981d","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-04 18:53:16.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/2/check/openstack-tox-docs/1060128/html/ : SUCCESS in 6m 14s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/2/check/openstack-tox-pep8/7b5b8cb/ : SUCCESS in 5m 17s","accounts_in_message":[],"_revision_number":2},{"id":"63ba40f9c8ee9643e15d4f682b30839495bc1c4f","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2018-12-04 23:56:38.000000000","message":"Patch Set 2:\n\n(7 comments)\n\nCode is at [1]. Other than fleshing out the tests, that\u0027s truly all that will be involved with this blueprint.\n\n[1] https://review.openstack.org/#/c/622622/","accounts_in_message":[],"_revision_number":2},{"id":"c471be8170b0e5c2de388459d515bbc1b7f713a7","author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"date":"2019-01-10 02:16:28.000000000","message":"Patch Set 2:\n\n(5 comments)\n\njust saving comments... this is a long one.","accounts_in_message":[],"_revision_number":2},{"id":"d1f74e0d6a2915c2aa00c88edc13df7116be53d4","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-01-10 03:32:11.000000000","message":"Patch Set 2:\n\n(3 comments)","accounts_in_message":[],"_revision_number":2},{"id":"be9d0303b22cdf4f4462a1770cc2dfa5239dc973","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-01-12 21:46:53.000000000","message":"Patch Set 2:\n\n(4 comments)","accounts_in_message":[],"_revision_number":2},{"id":"9e1c94fce7f292889258856ab1ed7eac40451c72","author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"date":"2019-01-14 19:32:24.000000000","message":"Patch Set 2:\n\n(2 comments)","accounts_in_message":[],"_revision_number":2},{"id":"4a3c9454a7b42fa27edf1b7e4fb3343ee14c7182","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-05-31 08:48:49.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"ec4d125dde061288aea986b3522570a184b3df4a","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-05-31 08:58:22.000000000","message":"Patch Set 3: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/3/check/openstack-tox-docs/0778875/html/ : SUCCESS in 8m 39s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/3/check/openstack-tox-pep8/ffe5135/ : SUCCESS in 6m 26s","accounts_in_message":[],"_revision_number":3},{"id":"09aa959bea6d0157051dfa7e1551476770378609","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-05-31 18:25:52.000000000","message":"Patch Set 3:\n\nThanks for picking this up, Dakshina.\n\nSomewhere (possibly in this spec, possibly in a dependent spec) we should have a discussion of how nova will consume the file.","accounts_in_message":[],"_revision_number":3},{"id":"0ab7b79481dd43557881e439831ba6f396f4aa43","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-06-04 12:11:46.000000000","message":"Patch Set 3:\n\n(18 comments)","accounts_in_message":[],"_revision_number":3},{"id":"cae34baa330f4e06f8026e895aa2ed647d00d93f","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-06-06 12:12:07.000000000","message":"Patch Set 3:\n\n(7 comments)","accounts_in_message":[],"_revision_number":3},{"id":"8ed34dc4ea32e71d7d0fc4cad7bfad1164e10dc6","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-06-06 12:17:37.000000000","message":"Patch Set 3:\n\n\u003e (7 comments)\n\n@Eric please help clarify, the only consumer of concern is here is the virt driver,\n\nso question is if we keep the file generic or hypervisor specific, for instance to include pci information for libvirt","accounts_in_message":[],"_revision_number":3},{"id":"9c4ba13f37e52e4a1e19965d8db1493aeaff6348","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-06 16:58:05.000000000","message":"Patch Set 3: Code-Review-1\n\n(22 comments)\n\nThanks for the thorough look, gibi.\n\nSummary of what I think needs to be done with this spec:\n- Explicitly state that the file is to be consumed exclusively by nova-compute, and more specifically virt drivers, which will a) definitely use it in update_provider_tree to effect changes in placement representations of things; and b) possibly use it in instance lifecycle operations e.g. to map \"provider\" to \"real thing on system\".\n- Enumerate some *specific* use cases we want to support initially via ^, with samples of what the file looks like for them (this exists at the bottom of the doc; move it closer to the top). For the first pass, this might be limited to \"add inventory of new resource classes on providers that already exist\" and \"add or remove traits on providers that already exist\", which would both feed into the specific use cases for RMD (LLC, p-state). We can extend later to handle VGPU, generic PCI passthrough, adding new nested providers, removing providers, etc.\n- Make \"real thing on system\" a freeform subsection of \"identification\".\n- Simplify, simplify, simplify the schema. Remove \u0027owner\u0027, \u0027passthrough\u0027, \u0027rename\u0027, the real-thing-on-system bits of \u0027identification\u0027, etc. Keep only what\u0027s needed for the specific use cases noted above.","accounts_in_message":[],"_revision_number":3},{"id":"eed3f2c2596db3ff7a7d9de99aa3e7dfd828d98f","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2019-06-12 16:01:22.000000000","message":"Patch Set 3: Code-Review-1\n\n(10 comments)\n\nFWIW, I think that what is described here gives the operator too much power. I get that we _can_ provide a full DSL for ultimate translation of every possible thing that u-p-t is going to do, but that doesn\u0027t mean we should. I would much prefer to lay out just the sorts of things we want to override and support those, but with a syntax/schema that allows us to grow in the future. Patching random bits of inventory when the average operator will *never* understand the full gravity of what they\u0027re doing makes no sense to me. Allowing them to remove traits from the provider that has no purpose other than to break nova in subtle ways is more harmful than useful, IMHO.\n\nStory time...\n\nI remember a bug I was working on, where someone ended up with inconsistent data in the database. I was chasing the root cause with them for a long time, trying to figure out how they could have one object that referenced an instance that didn\u0027t exist when our DB schema clearly had a constraint requiring it. We finally realized that, months ago, they had followed instructions from \"an expert\" in another bug, related to something mundane. Those instructions were to disable constraint checking in mysql, do a few update queries (which in themselves were wrong) and then re-enable the constraint checking. On a live system. The few minutes those were disabled completely effed their production database and caused a majorly expensive bug-chasing exercise upstream where I thought we had major problems.\n\nNow, I know we can\u0027t prevent people from cutting off their own hands, or disabling constraint checking in the database, but we *can* choose what tools to provide them (which will be seen as blessed) and some of this seems to be a little too powerful to me.","accounts_in_message":[],"_revision_number":3},{"id":"df3f40b07498a3eed286c3b75864d6255e72a11b","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-06-19 11:15:37.000000000","message":"Patch Set 3:\n\n(9 comments)","accounts_in_message":[],"_revision_number":3},{"id":"1920795567061f4252106c4e38399513ccab7583","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-06-19 11:19:26.000000000","message":"Patch Set 3:\n\nThank you for the discussion.\n\nFew opens before I publish the simplified version. Hopefully we could close on the open comments too.\n\n1. When we identify multiple rps, wouldn\u0027t we repeat the customization on each compute node, if the same file is deployed?\n2. Any specific reason behind having minor version for file (no structural changes e.t.c?)? Would we need a nova config to say minimum supported version since with every major version bump, we need code changes.","accounts_in_message":[],"_revision_number":3},{"id":"89c22cfebcfda20a47bb2603d0b1bff16dc13c66","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-19 18:01:11.000000000","message":"Patch Set 3:\n\n(11 comments)\n\n\u003e 1. When we identify multiple rps, wouldn\u0027t we repeat the customization on each compute node, if the same file is deployed?\n\nNot sure I understand the question. I\u0027ve noted inline that we should support a $COMPUTE_HOST meta-uuid, which would conceivably allow you to deploy the actual same file to multiple compute hosts. But otherwise I would assume the file would be templated and customized per host, yeah?\n\n\u003e 2. Any specific reason behind having minor version for file (no structural changes e.t.c?)? Would we need a nova config to say minimum supported version since with every major version bump, we need code changes.\n\nOverall I like $major for breaking changes and $minor for backward-compatible changes, even if it\u0027s just for human comprehensibility. And why not? It\u0027s not like it\u0027s particularly harder than a single version number. And the nova compat/upgrade/lockstepping is the same either way. But I\u0027m not going to fall on my sword over this issue.","accounts_in_message":[],"_revision_number":3},{"id":"e9cbaa0674f3efc9666e0778caa4c9d0c6647247","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-06-21 08:43:45.000000000","message":"Patch Set 3:\n\n(7 comments)","accounts_in_message":[],"_revision_number":3},{"id":"47b84576ae6e811aec4db47e3094d082c84dba86","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-24 16:52:20.000000000","message":"Patch Set 3:\n\n(4 comments)","accounts_in_message":[],"_revision_number":3},{"id":"0e60a79e48d5e4404038d4204fc78daec2115df5","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-06-28 10:40:31.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"a35df854b767259d2383043a603460b6f78d4afd","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-06-28 10:45:26.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"2a1a00ef1855364f1f67d911c4b28d0c17fe86ee","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-06-28 10:53:30.000000000","message":"Patch Set 4: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/4/check/openstack-tox-docs/b1a8e94/ : FAILURE in 3m 09s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/4/check/openstack-tox-pep8/3c8096a/ : FAILURE in 3m 19s","accounts_in_message":[],"_revision_number":4},{"id":"f5c39f389021c30f7048dc6e8dffe24faaafb475","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-28 22:04:59.000000000","message":"Patch Set 4: Code-Review-1\n\n(50 comments)\n\nDramatic reduction in size on this iteration \\o/\n\nMore work to do.\n\nI\u0027ve identified a number of other bits that need to be trimmed.\n\nBut one major thing needs to be added: the description of how this is going to be consumed by Nova.","accounts_in_message":[],"_revision_number":4},{"id":"3167795cf5ad7847f072808fb4b5d3b22e81f251","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-06-28 22:08:15.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"aea7e0d2c9ef2c5f4c9e5ff80f410425c36cc199","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-03 13:50:23.000000000","message":"Patch Set 4:\n\n(6 comments)","accounts_in_message":[],"_revision_number":4},{"id":"b0cf0c662434d83640c9c929534cefe28a9fa909","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-03 14:00:39.000000000","message":"Uploaded patch set 5.","accounts_in_message":[],"_revision_number":5},{"id":"efdd57085c79d1eb0f86b2a0953abd268c796412","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-03 14:12:33.000000000","message":"Patch Set 5: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/5/check/openstack-tox-docs/14986d0/ : FAILURE in 4m 31s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/5/check/openstack-tox-pep8/a4b2ee7/ : FAILURE in 3m 32s","accounts_in_message":[],"_revision_number":5},{"id":"8065dd291af072af517091e73cb6fd788cb77bd8","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-03 14:36:05.000000000","message":"Uploaded patch set 6.","accounts_in_message":[],"_revision_number":6},{"id":"ab1908951ac3d22f7aa2fdf15d113c9c8b89bf02","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-03 14:41:36.000000000","message":"Patch Set 6: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/6/check/openstack-tox-docs/889bd9b/ : FAILURE in 3m 59s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/6/check/openstack-tox-pep8/0017d0e/ : FAILURE in 3m 21s","accounts_in_message":[],"_revision_number":6},{"id":"3ba8e22e2724c942c543d2a86da9937876f1fbe0","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-03 14:43:11.000000000","message":"Patch Set 6:\n\nOld changes that were removed\n\nRemoved device passthrough section\nRemoved Collab Tree Mgmt section - nova only\nRemoved sharing providers?\nRemoved pci/trait/aggregate identification\nRemoved ownership section\nRemoved name/uuid customization\nRemoved remove inventory customization\nRemoved usecases not corresponding to current schema features\nRemoved support for create new provider/child providers\n\nFew closing questions on this patch\n1. Describe how file is consumed by nova compute - Code snippet? Can this code be generalized to Nova? Not sure why this has to be specific to virt driver implementations. Are we talking about spawn() changes?\n2. Create and customize child provider in schema, Remove NUMA inventory from root and introduce in child provider - LLC usecase. Need thoughts.\n3. Customization inventory/trait involving non-native resources. Is it ok to introduce remove and rename?\n4. TBD: LLC and P-state examples in schema format.","accounts_in_message":[],"_revision_number":6},{"id":"75e652326143c9b159b362e0d21aeeb30fde217d","author":{"_account_id":29745,"name":"Dustin Cowles","email":"cowlesd@gmail.com","username":"dustinc","status":"inactive"},"date":"2019-07-03 16:34:29.000000000","message":"Patch Set 6: Code-Review-1\n\n(6 comments)","accounts_in_message":[],"_revision_number":6},{"id":"f2c2181b4f5f702334873fe9e5f82e123aba1274","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-03 19:55:43.000000000","message":"Patch Set 6: Code-Review-1\n\n(22 comments)\n\nThanks Dakshina, this is coming together very nicely and is really close now I think.\n\n\u003e 1. Describe how file is consumed by nova compute - Code snippet?\n\nI think what you have in the document is probably enough. I may be interpolating a lot because I\u0027m familiar, though, so let\u0027s get other reviewers to weigh in.\n\n\u003e Can this code be generalized to Nova? Not sure why this has to be specific to virt driver implementations. Are we talking about spawn() changes?\n\nNot spawn changes... yet. spawn would have to be able to figure out physical resources on the system and know what to do with them. That\u0027s a direction we\u0027re heading with this, e.g. to replace [pci]passthrough_whitelist and [pci]alias. But we\u0027re not doing it for this pass.\n\nIt\u0027s virt driver specific because update_provider_tree is virt driver specific; and update_provider_tree is the source of truth for Placement\u0027s representation of the compute node.\n\nBut (as mentioned inline) we may at this stage be able to do the loading/parsing and schema validation in common code, and pass the processed object to the virt driver. We can discuss that further, but (as mentioned inline) it may be okay to defer those details to implementation time.\n\n\u003e 2. Create and customize child provider in schema, Remove NUMA inventory from root and introduce in child provider - LLC usecase. Need thoughts.\n\nSee response inline. TL;DR: I can be convinced that we should reinstate the ability to create child providers for purposes of grouping, as long as we don\u0027t try to claim any ability to use them for NUMA affinity yet.\n\n\u003e 3. Customization inventory/trait involving non-native resources. Is it ok to introduce remove and rename?\n\nResponses inline: these add complexity, and we don\u0027t need them yet, so let\u0027s leave them out.\n\n\u003e 4. TBD: LLC and P-state examples in schema format.\n\nYes please.\n\nSummary of the main changes I\u0027m looking for in the next rev:\n- Reinstate ability to create child providers, if you are convinced the benefit outweighs the cost.\n- Examples per #4 above.\n- Clean up formatting (tabs, trailing whitespace, long lines).","accounts_in_message":[],"_revision_number":6},{"id":"967ba5136955a2575134e1491cdb520cd2486465","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-07-04 11:19:25.000000000","message":"Patch Set 6: Code-Review-1\n\n(8 comments)\n\nSome formatting and relatively minor comments within. Some questions out here which may have been discussed on earlier revisions, sorry if I missed them:\n\n* It\u0027s hard to grok from this spec how this is supposed to work. The format requires a uuid of a resource provider or $COMPUTE_HOST. If the latter is used the added inventory and traits are always on the compute node. If the former is used a) what is discovering those uuids, did something else already create the providers associated with those uuids? b) those providers are presumably children of $COMPUTE_HOST who/what is managing that topology?\n\n* Given the above, it seems the extra providers need to already exist, somehow, and what this file is doing is saying to the virt driver: \"If you stumble across a provider in your provider tree with an identifier in this file, I want it updated to have attributes as described by the file\".\n\nThe above doesn\u0027t really impact on the format of the file (which seems fine for the limited use cases described) but it does impact on judging whether having the file at all is the best fit for purpose, so is useful info.\n\n(The -1 is mostly for the whitespace issues)","accounts_in_message":[],"_revision_number":6},{"id":"2d6097ab887072d56eae82aed00bb69778df6349","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-08 16:33:11.000000000","message":"Patch Set 6:\n\n(3 comments)","accounts_in_message":[],"_revision_number":6},{"id":"7172f020080586458fc7004943901a9c560572a8","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-10 14:02:51.000000000","message":"Patch Set 6:\n\n(3 comments)\n\n\u003e (8 comments)\n \u003e \n \u003e Some formatting and relatively minor comments within. Some\n \u003e questions out here which may have been discussed on earlier\n \u003e revisions, sorry if I missed them:\n \u003e \n \u003e * It\u0027s hard to grok from this spec how this is supposed to work.\n \u003e The format requires a uuid of a resource provider or $COMPUTE_HOST.\n \u003e If the latter is used the added inventory and traits are always on\n \u003e the compute node. If the former is used a) what is discovering\n \u003e those uuids, did something else already create the providers\n \u003e associated with those uuids? b) those providers are presumably\n \u003e children of $COMPUTE_HOST who/what is managing that topology?\n \u003e \n \u003e * Given the above, it seems the extra providers need to already\n \u003e exist, somehow, and what this file is doing is saying to the virt\n \u003e driver: \"If you stumble across a provider in your provider tree\n \u003e with an identifier in this file, I want it updated to have\n \u003e attributes as described by the file\".\n \u003e \n \u003e The above doesn\u0027t really impact on the format of the file (which\n \u003e seems fine for the limited use cases described) but it does impact\n \u003e on judging whether having the file at all is the best fit for\n \u003e purpose, so is useful info.\n \u003e \n \u003e (The -1 is mostly for the whitespace issues)\n\nSome formatting and relatively minor comments within. Some questions out here which may have been discussed on earlier revisions, sorry if I missed them:\n\nIt\u0027s hard to grok from this spec how this is supposed to work. The format requires a uuid of a resource provider or $COMPUTE_HOST. If the latter is used the added inventory and traits are always on the compute node. If the former is used a) what is discovering those uuids, did something else already create the providers associated with those uuids? b) those providers are presumably children of $COMPUTE_HOST who/what is managing that topology?\nGiven the above, it seems the extra providers need to already exist, somehow, and what this file is doing is saying to the virt driver: \"If you stumble across a provider in your provider tree with an identifier in this file, I want it updated to have attributes as described by the file\".\nThe above doesn\u0027t really impact on the format of the file (which seems fine for the limited use cases described) but it does impact on judging whether having the file at all is the best fit for purpose, so is useful info.\n\n@Chris, Currently, this spec does not support a use-case that needs creation of resource providers using the file. Having said this, if not for compute resource provider (at the root), the sys-admin or supporting external process should identify and provide the UUID of a child rp (that already exists).","accounts_in_message":[],"_revision_number":6},{"id":"e8e91eff29b6b8fa0795f85f4d671563b2b6dd4c","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-10 14:15:20.000000000","message":"Patch Set 6:\n\nPS4, Line 194:\n\nNo, I mean something so that whatever agent is doing the assignment of *physical* resources can know which physical resource to use based on the placement allocation.\n\nFor example if we were managing PCI devices, we need some way to tie the placement resources in a provider inventory to the real devices on the system. That\u0027s what the PCI address business was about in previous revs of this spec.\n\nWe\u0027re not trying to manage PCI devices specifically right now - but on the other hand we\u0027re not explicitly restricting what can be supported either. The question is: do our known use cases require the ability to map specific *physical* resources from a specific resource provider inventory? And if so, does that mapping require any kind of special affordance in this file?\n\nFor now, I\u0027m going to say no, because you can do this association with custom traits -- which we\u0027re already supporting via this file.\n\n@Eric, I\u0027m not sure if I understand the argument well, but If you are talking about what the agent (like RMD) or virt-driver (overrides in future), should do next to manage the resources reported from file, \n\nThis should be per use-case and can be translated from flavor/flavor-extra specs?\n\nNot sure if any identification should come from the file.","accounts_in_message":[],"_revision_number":6},{"id":"66a820ae75e26a1e870ebd10f4cfc205b35562a8","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-10 14:49:35.000000000","message":"Patch Set 6:\n\nPS4, Line 109:\nI sympathize with the problem here. I\u0027m trying to find every possible way to reduce the scope of this work for the current release.\n\nThe max_unit trick is clever, but a) it still won\u0027t prevent you from getting allocations that can only be satisfied by spanning multiple NUMA nodes; and \n\nb) it easily breaks when more than one isolated guest NUMA node is requested. (The max_unit is enforced for the whole allocation, not per request group.)\n\n\u003e\u003e\u003e If we request cores from more the one NUMA, we need to ensure, LLC allocations from each of those NUMA. This goes back to our problem of reporting LLC per NUMA in placement\n\nWe\u0027re going to have to deal with reshaping regardless of whether the resources start off on the compute node RP or nested RPs, so that aspect is moot.\n\nRejecting a scheduling request because we can\u0027t allocate the requested amount of LLC from a single NUMA node is an improvement (though far from a complete solution since it\u0027s still possible to allocate from the *wrong* NUMA node(s)). \n\n\u003e\u003e\u003e We must get the specific NUMA information at the time of scheduling\n\nSo it\u0027s really just a question of whether that improvement is worth the added complexity of supporting creation of new providers at this time.\n\nIf we decide the answer is yes, the use case should be phrased in terms of the ability to group/split resources to reflect how they exist on the host, *not* in terms of topology/affinity, because we absolutely have no way to affect that yet.\n\n\u003e\u003e\u003e Few possibilities, please help evaluate\n\n1. Support flavor to extend to numa_llc? Can you clarify how NUMA based CPUs and memory is modeled in placement today?\n\n$ openstack flavor set m1.large --property hw:numa_nodes\u003d2\n$ openstack flavor set m1.large \\  # configure guest node 0\n  --property hw:numa_cpus.0\u003d0,1 \\\n  --property hw:numa_mem.0\u003d2048\n$ openstack flavor set m1.large \\  # configure guest node 1\n  --property hw:numa_cpus.1\u003d2,3,4,5 \\\n  --property hw:numa_mem.1\u003d4096\n\n2. If we create child rps for LLC, they should still be associated with cores that can use them. Which means moving core information from compute rp to child rps (to later apply granular resource requests to co-locate LLC and CPU cores). Not sure how can we can model LLC without considering topology.","accounts_in_message":[],"_revision_number":6},{"id":"7b79302f295dbe9882a5ace22acef0be09519d82","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-10 14:52:06.000000000","message":"Uploaded patch set 7.","accounts_in_message":[],"_revision_number":7},{"id":"04dfab57c6229554bcc4af2be3fb7b3e3e79ab93","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-07-10 15:02:35.000000000","message":"Patch Set 4:\n\n(2 comments)","accounts_in_message":[],"_revision_number":4},{"id":"b80888caf4edec05f2189fca3701cf93b16f4df3","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-10 15:08:55.000000000","message":"Patch Set 7: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/7/check/openstack-tox-docs/d5f0598/html/ : SUCCESS in 7m 28s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/7/check/openstack-tox-pep8/893f402/ : SUCCESS in 4m 46s","accounts_in_message":[],"_revision_number":7},{"id":"d7516c7d7c77df05fe0aa39fa79e911b1a2c32ac","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-10 15:57:41.000000000","message":"Patch Set 7: Code-Review-1\n\n(5 comments)\n\n\u003e @Chris, Currently, this spec does not support a use-case that needs creation of resource providers using the file.\n\nUnless you go with (B) inline. But given the suckiness of both alternatives, my opinion is that we should go with (A) since it\u0027s simpler.\n\nDownvote is for formatting (convert tabs) and missing examples.\n\nDiscussion of where/how to manage the processing (RT vs upt etc) is interesting, but can be resolved in the implementation; no need to finalize it here.","accounts_in_message":[],"_revision_number":7},{"id":"b2adf74ca2809ff0bca98b3cd07914f3609b567e","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-10 17:50:33.000000000","message":"Uploaded patch set 8.","accounts_in_message":[],"_revision_number":8},{"id":"9bb614501a7c15c6325a6c496977a3b1d84275f4","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-10 18:00:11.000000000","message":"Uploaded patch set 9.","accounts_in_message":[],"_revision_number":9},{"id":"8db2fa8a56bb4355606e93beb2d80231ccb0e9b0","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-10 18:11:12.000000000","message":"Patch Set 9: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/9/check/openstack-tox-docs/a8baecd/html/ : SUCCESS in 6m 15s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/9/check/openstack-tox-pep8/802ae3a/ : SUCCESS in 3m 54s","accounts_in_message":[],"_revision_number":9},{"id":"d26816c85f4e5cf81870c5fb9f53ca057049fbb1","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-10 20:07:41.000000000","message":"Patch Set 9: Code-Review-1\n\nCool, whitespace is fixed; just need the examples filled out and I think this is good to go.","accounts_in_message":[],"_revision_number":9},{"id":"84c2a210a9692f97c034a3ca809e29d42f6b8504","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-11 10:40:47.000000000","message":"Patch Set 9:\n\nSorry Eric, I will update it shortly.","accounts_in_message":[],"_revision_number":9},{"id":"447423ad8269902bfe0bace632f59d38e3eb58e5","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-11 23:09:22.000000000","message":"Patch Set 9:\n\nEric, an open question, may be incorrect, do we have support to report traits per CPU core? For instance report a subset of CPUs with P-state enabled/disabled?","accounts_in_message":[],"_revision_number":9},{"id":"d9ed54585dc01aaac9f539cd83503e198bf58528","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-12 02:33:20.000000000","message":"Patch Set 9:\n\nNo. You can either a) depend on the PCPU blueprint, and make PCPUs p-state capable, but still only have all p-state or all non p-state CPUs in your VM; or b) depend on the PCPU-and-VCPU-in-one-VM spec to lift that limitation.","accounts_in_message":[],"_revision_number":9},{"id":"b99903fd6b25e3e731bf79de103f8bc0c13690a9","author":{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},"date":"2019-07-16 16:21:40.000000000","message":"Patch Set 9:\n\nThe particular \"P-States capable\" example is not applicable, all the cores in the CPU will be P-States capable, then you can use system deployment tool or the resource manager to enable or disable it on specific cores.\nHowever, for SST-BF (base frequency split) it would make sense. I think that could be a future discussion.","accounts_in_message":[],"_revision_number":9},{"id":"5c8679433939b3c96c684a6e9d6e41d1ff34bbea","author":{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},"date":"2019-07-16 17:58:43.000000000","message":"Patch Set 9:\n\n(2 comments)\n\n@efried, if you help me with and example of the base structure \n\"-\u003ehost-\u003eNUMA\" as in supported by [1], I can extend it to represent the core p-states capability and contribute to Dakshina\u0027s examples. \n\nOther than my two comments I think it looks good.\n\n[1]https://docs.openstack.org/placement/latest/placement-api-microversion-history.html#support-same-subtree-queryparam-on-get-allocation-candidates","accounts_in_message":[],"_revision_number":9},{"id":"15f536839ecee45522662f4ce4ec97779f99bce1","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-17 08:14:18.000000000","message":"Patch Set 9:\n\nIt seems like we can address a complex problem on the same lines as SST-BF proposal but it could be a separate discussion - also leading to new specs.\n\n1. Enabling LLC support\n\nThe current apporach as Eric suggested is to let the LLC be modeled in the root resource provider. Considering that we have multiple LLC, we can live with a max\u003dsize of single LLC, total\u003dsum of size of all LLC approach. This is not clean but we can late fail the spawn for the following cases\n\nA. CPU pinning information not available to choose the right NUMA\nB. Not enough cache on the desired NUMA (if cores are on different NUMA or insufficient LLC)\nC. Any other fragmentation that implies incorrect total\n\nIn future, we could extend NUMATopologyFilter and virt-driver to support LLC as a NUMA bound resource as described in [1]\n\nIs this a direction for NUMA bound resources or is something better coming up?\n\n2. P-state usecases\n\nOne other possibility is to expose a subset of cores as P-state enabled/disabled as dictated by a node policy(that can also work in conjunction with SST-BF tiers as determined by the virt driver [2])\n\nThis will also require changes to virt-driver, NUMATopologyFilter and creation of new child providers.\n\nUntil the required changes are available, we may not need the create child provider capability.\n\nHence, we are keeping it simple at this point to simply express if a compute node supports P-state/not and leave it upto virt-driver or RMD understanding extra-specs to enable/disable.\n\n[1]\nhttp://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/virt-driver-numa-placement.html\n\n[2] https://review.opendev.org/#/c/649882/3/specs/train/approved/separate-vcpu-into-different-priority-pool.rst","accounts_in_message":[],"_revision_number":9},{"id":"a6af08396661615fa433efa04f040a155a03ed0c","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-17 08:29:43.000000000","message":"Patch Set 9:\n\nFacing server issues.\n\nExample here - until then\n\n.. code-block:: yaml\n\n  meta:\n    schema_version: 1.0\n\n  providers:\n    - identification:\t\n        uuid: $COMPUTE_HOST    \n      customization:\n          inventories:\n              ensure:\n                  $resource_class:\n                      # Describing LLC on this compute node\n\t\t      # max_unit indicates maximum size of single LLC\n\t\t      # total indicates sum of sizes of all LLC\n                      total: 22\n                      reserved: 2\n                      min_unit: 1\n                      max_unit: 11\n                      step_size: 1\n                      allocation_ratio: 1 \n          traits:\n              ensure:\n\t\t  # Describing that this compute node enables support for\n\t\t  # P-state control\n                  - CUSTOM_P_STATE_ENABLED","accounts_in_message":[],"_revision_number":9},{"id":"a8cab00051b69b4588fe555fdfae1e0ce6ef7da2","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-17 15:55:47.000000000","message":"Uploaded patch set 10.","accounts_in_message":[],"_revision_number":10},{"id":"73e3c5da0aada4fb8eb78bcedefbdc5e998a7062","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-17 15:57:47.000000000","message":"Patch Set 10:\n\nRequesting final review","accounts_in_message":[],"_revision_number":10},{"id":"ee1675001c108f4d77a4de7e06d696190b04d4f7","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-17 16:09:36.000000000","message":"Patch Set 10: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/10/check/openstack-tox-docs/70eee6f/html/ : SUCCESS in 6m 02s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/10/check/openstack-tox-pep8/dd5c955/ : SUCCESS in 3m 05s","accounts_in_message":[],"_revision_number":10},{"id":"6ee4df44517788fb58a93ebb6ce27f9260d15736","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-17 16:14:24.000000000","message":"Patch Set 9:\n\n(2 comments)\n\n\u003e @efried, if you help me with and example of the base structure \n\u003e \"-\u003ehost-\u003eNUMA\" as in supported by [1], I can extend it to represent the core p-states capability and contribute to Dakshina\u0027s examples. \n\nYou could, yes, *IF* nova were structuring NUMA topology in placement. But it\u0027s not, yet. Again, you could block/depend on that being done (and most likely not make Train) or you could accept the limitations and proceed as is.\n\n\u003e The current apporach as Eric suggested is to let the LLC be modeled in the root resource provider.\n\nYes\n\n\u003e Considering that we have multiple LLC, we can live with a max\u003dsize of single LLC, total\u003dsum of size of all LLC approach.\n\nAs I said earlier, I don\u0027t think this is a good idea. But that - as well as all the discussion below - is outside the scope of this spec.\n\n\u003e This is not clean but we can late fail the spawn for the following cases\n\nTo be clear, \"we\" can\u0027t late fail the spawn. NUMATopologyFilter can do so for\n\n\u003e A. CPU pinning information not available to choose the right NUMA\n\nbut RMD-wise you\u0027ll just have to live with\n\n\u003e B. Not enough cache on the desired NUMA (if cores are on different NUMA or insufficient LLC)\n\u003e C. Any other fragmentation that implies incorrect total\n\n\u003e In future, we could extend NUMATopologyFilter and virt-driver to support LLC as a NUMA bound resource as described in [1]\n\u003e \n\u003e Is this a direction for NUMA bound resources or is something better coming up?\n\nUm, yeah, that\u0027s a Juno spec. \"Something better\" is going to be centering around placement. But I still don\u0027t see a way for out-of-band efforts like RMD to extend NUMATopologyFilter and/or virt drivers.\n\n\u003e Hence, we are keeping it simple at this point to simply express if a compute node supports P-state/not and leave it upto virt-driver or RMD understanding extra-specs to enable/disable.\n\nThis.\n\nI will review PS10 by EOD.","accounts_in_message":[],"_revision_number":9},{"id":"2c92d9683e037a0715dfd55fa83fc1c60634de54","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-17 16:18:23.000000000","message":"Patch Set 10: Code-Review+1\n\n(2 comments)\n\nOne tweak inline, but I\u0027m basically good with this now.","accounts_in_message":[],"_revision_number":10},{"id":"e91498bd2faa88e21d1a7468812002942d0c8088","author":{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},"date":"2019-07-17 16:46:40.000000000","message":"Patch Set 10:\n\n\u003e \u003e @efried, if you help me with and example of the base structure\n \u003e \u003e \"-\u003ehost-\u003eNUMA\" as in supported by [1], I can extend it to\n \u003e represent the core p-states capability and contribute to Dakshina\u0027s\n \u003e examples.\n \u003e \n \u003e You could, yes, *IF* nova were structuring NUMA topology in\n \u003e placement. But it\u0027s not, yet. Again, you could block/depend on that\n \u003e being done (and most likely not make Train) or you could accept the\n \u003e limitations and proceed as is.\n \u003e \n\nYeap, no worries, we can revisit that after the NUMA topology is in place. By now we can use the root RP to add a node trait advertising the supported p-state control. Same with SST-BF.","accounts_in_message":[],"_revision_number":10},{"id":"644525e772632d48e2d606b8eefc16eab2012180","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2019-07-17 17:19:22.000000000","message":"Patch Set 10: Code-Review-1\n\n(13 comments)\n\nSome comments, some nits, and a few things I think need to be fixed, like the compute HOST-\u003eNOTE thing and maybe the overly hierarchical layout.","accounts_in_message":[],"_revision_number":10},{"id":"bf7b239289c9e034f549a77948b74b663ef638d2","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-17 17:26:06.000000000","message":"Patch Set 10:\n\n(2 comments)\n\n\u003e (2 comments)\n \u003e \n \u003e \u003e @efried, if you help me with and example of the base structure\n \u003e \u003e \"-\u003ehost-\u003eNUMA\" as in supported by [1], I can extend it to\n \u003e represent the core p-states capability and contribute to Dakshina\u0027s\n \u003e examples.\n \u003e \n \u003e You could, yes, *IF* nova were structuring NUMA topology in\n \u003e placement. But it\u0027s not, yet. Again, you could block/depend on that\n \u003e being done (and most likely not make Train) or you could accept the\n \u003e limitations and proceed as is.\n \u003e \n \u003e \u003e The current apporach as Eric suggested is to let the LLC be\n \u003e modeled in the root resource provider.\n \u003e \n \u003e Yes\n \u003e \n \u003e \u003e Considering that we have multiple LLC, we can live with a\n \u003e max\u003dsize of single LLC, total\u003dsum of size of all LLC approach.\n \u003e \n \u003e As I said earlier, I don\u0027t think this is a good idea. But that - as\n \u003e well as all the discussion below - is outside the scope of this\n \u003e spec.\n \u003e \n \u003e \u003e This is not clean but we can late fail the spawn for the\n \u003e following cases\n \u003e \n \u003e To be clear, \"we\" can\u0027t late fail the spawn. NUMATopologyFilter can\n \u003e do so for\n \u003e \n \u003e \u003e A. CPU pinning information not available to choose the right NUMA\n \u003e \n \u003e but RMD-wise you\u0027ll just have to live with\n \u003e \n \u003e \u003e B. Not enough cache on the desired NUMA (if cores are on\n \u003e different NUMA or insufficient LLC)\n \u003e \u003e C. Any other fragmentation that implies incorrect total\n \u003e \n \u003e \u003e In future, we could extend NUMATopologyFilter and virt-driver to\n \u003e support LLC as a NUMA bound resource as described in [1]\n \u003e \u003e\n \u003e \u003e Is this a direction for NUMA bound resources or is something\n \u003e better coming up?\n \u003e \n \u003e Um, yeah, that\u0027s a Juno spec. \"Something better\" is going to be\n \u003e centering around placement. But I still don\u0027t see a way for\n \u003e out-of-band efforts like RMD to extend NUMATopologyFilter and/or\n \u003e virt drivers.\n \u003e \n \u003e \u003e Hence, we are keeping it simple at this point to simply express\n \u003e if a compute node supports P-state/not and leave it upto\n \u003e virt-driver or RMD understanding extra-specs to enable/disable.\n \u003e \n \u003e This.\n \u003e \n \u003e I will review PS10 by EOD.\n\n@Eric, What\u0027s the Juno spec?\nUnless we want to support static provisioning in general for LLC/P-state resources and things like RMD can extend the flavor for other dynamic features.\n\nRegarding late fail, in situations A, B an C, where RMD can not satisfy the LLC allocation request, what is the best way to error the VM creation or else it would be inconsistent to have the VM running without the flavor requirements met (Max thing RMD would do is give the VM available cache ways from default pool - leftovers)","accounts_in_message":[],"_revision_number":10},{"id":"ef5d112e178e3aaae700f865388b24f08e5e14f0","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-17 17:29:52.000000000","message":"Uploaded patch set 11.","accounts_in_message":[],"_revision_number":11},{"id":"0e792a58e630a5ef232d7691912fc9ec37f29a9d","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-17 17:47:48.000000000","message":"Patch Set 11: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/11/check/openstack-tox-docs/071ae6c/html/ : SUCCESS in 6m 17s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/11/check/openstack-tox-pep8/e9a8967/ : SUCCESS in 5m 42s","accounts_in_message":[],"_revision_number":11},{"id":"5621ac05a7fbc4314d66bea8eb97c29b3f7d65b2","author":{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},"date":"2019-07-17 17:52:36.000000000","message":"Patch Set 9:\n\n(2 comments)","accounts_in_message":[],"_revision_number":9},{"id":"9a8d40f399b72f0b1d33dfb9febea79295396f15","author":{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},"date":"2019-07-17 18:06:51.000000000","message":"Patch Set 11:\n\n(1 comment)","accounts_in_message":[],"_revision_number":11},{"id":"a8cee0bb892aaf98cb17ecbb80e22bbaa0cf53f8","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-17 21:32:43.000000000","message":"Patch Set 11: Code-Review+1\n\n(13 comments)\n\nDan identified a couple of edits that need to be made, but IMO the intent \u0026 direction is clear and the edits could be done in a fup for the sake of getting this moving, so re+1ing.\n\n\u003e @Eric, What\u0027s the Juno spec?\n\nI was referring to this statement of yours:\n\n\u003e In future, we could extend NUMATopologyFilter and virt-driver to support LLC as a NUMA bound resource as described in [1]\n\u003csnip\u003e\n\u003e [1]\nhttp://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/virt-driver-numa-placement.html\n\n\u003e Unless we want to support static provisioning in general for LLC/P-state resources and things like RMD can extend the flavor for other dynamic features.\n\nI don\u0027t understand this sentence. The only thing this spec helps you do is static provisioning by extending the flavor. If you want RMD to read random new extra specs out of the flavor and use them to do dynamic things to the instance, that\u0027s fine, but it has nothing to do with this spec.\n\n\u003e Regarding late fail, in situations A, B an C, where RMD can not satisfy the LLC allocation request, what is the best way to error the VM creation or else it would be inconsistent to have the VM running without the flavor requirements met (Max thing RMD would do is give the VM available cache ways from default pool - leftovers)\n\nYes, leftovers, until we have more granular reporting/scheduling/allocation of NUMA nodes.\n\nThe only thing you could conceivably do (and some might consider this a hack) is implement a scheduler filter that talks to RMD on the compute to find out if the cache allocations can be satisfied correctly.","accounts_in_message":[],"_revision_number":11},{"id":"6645fa5db76676679a285eb3f3d9eeb6786b0e8b","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-17 23:03:41.000000000","message":"Patch Set 11:\n\n\u003e (1 comment)\n\nTo expose, if node is p-state enabled/disabled, this is sufficient. For, other usecases involving NUMA it is not probable now. Let us take the discussion later.","accounts_in_message":[],"_revision_number":11},{"id":"47b7f6b212d47fc53c716a8ded4351728cc19fe8","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-17 23:18:37.000000000","message":"Patch Set 11:\n\n\u003e (13 comments)\n \u003e \n \u003e Dan identified a couple of edits that need to be made, but IMO the\n \u003e intent \u0026 direction is clear and the edits could be done in a fup\n \u003e for the sake of getting this moving, so re+1ing.\n \u003e \n \u003e \u003e @Eric, What\u0027s the Juno spec?\n \u003e \n \u003e I was referring to this statement of yours:\n \u003e \n \u003e \u003e In future, we could extend NUMATopologyFilter and virt-driver to\n \u003e support LLC as a NUMA bound resource as described in [1]\n \u003e \u003csnip\u003e\n \u003e \u003e [1]\n \u003e http://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/virt-driver-numa-placement.html\n \u003e \n \u003e \u003e Unless we want to support static provisioning in general for\n \u003e LLC/P-state resources and things like RMD can extend the flavor for\n \u003e other dynamic features.\n \u003e \n \u003e I don\u0027t understand this sentence. The only thing this spec helps\n \u003e you do is static provisioning by extending the flavor. If you want\n \u003e RMD to read random new extra specs out of the flavor and use them\n \u003e to do dynamic things to the instance, that\u0027s fine, but it has\n \u003e nothing to do with this spec.\n \u003e \nCorrect, nothing to do with this spec. What I was saying is, for just static provisioning of new NUMA bound resources, if we can extend the NUMATopologyFilter, but that can be a new spec in itself.\n\nTo create a custom scheduler filter - especially for LLC (probably avoid communication to RMD), do we need a new spec? I believe not? We could probably minimize failures.\n\n \u003e \u003e Regarding late fail, in situations A, B an C, where RMD can not\n \u003e satisfy the LLC allocation request, what is the best way to error\n \u003e the VM creation or else it would be inconsistent to have the VM\n \u003e running without the flavor requirements met (Max thing RMD would do\n \u003e is give the VM available cache ways from default pool - leftovers)\n \u003e \n \u003e Yes, leftovers, until we have more granular reporting/scheduling/allocation\n \u003e of NUMA nodes.\n \u003e \n \u003e The only thing you could conceivably do (and some might consider\n \u003e this a hack) is implement a scheduler filter that talks to RMD on\n \u003e the compute to find out if the cache allocations can be satisfied\n \u003e correctly.","accounts_in_message":[],"_revision_number":11},{"id":"3e39db9a84b504042002f37dd807ae32c963e10b","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-18 00:49:50.000000000","message":"Patch Set 11:\n\n\u003e a new spec \n\nYou don\u0027t need a nova spec for whatever you\u0027re doing downstream. If you\u0027re talking about adding something like LLC awareness to the NumaTopologyFilter *upstream*, I don\u0027t see that having legs, because why wouldn\u0027t we go all the way and support that resource across the board? (Sean was proposing tracking LLC directly, but has since abandoned that spec.)","accounts_in_message":[],"_revision_number":11},{"id":"c72e880ec8642e8c3aa75a5c00c75e79f0031b78","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-07-18 01:03:38.000000000","message":"Patch Set 11: Code-Review-1\n\n(9 comments)\n\ngiven the limited usecase that will be supproted in this version i think the general direction is fine.\n\nwith the current restrtions however i dont see a justification for doing this at the virt driver level instead of doing it once in teh resocue tracker.","accounts_in_message":[],"_revision_number":11},{"id":"7191018677ee7e8c3aa831eb1314cf225de07732","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-18 02:17:52.000000000","message":"Patch Set 11:\n\n(15 comments)\n\nThank you Dan, Sean and Eric. I will be uploading few text tweaks.\n\nFew opens,\n\n1. For the simplified schema that looks at inventory/trait \"add\" for non-native resources, can we simply call out that changes in resource tracker suffice or be more generic and say its upto the virt_driver to call a common method for pre/post processing?\n\n2. Do we need to define a JSON schema?\n\n3. Are we convinced to just have a single file instead of a directory processed lexicographic-ally","accounts_in_message":[],"_revision_number":11},{"id":"f7388c7a5138998e3538bea1ee0092b92add9be3","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-18 02:22:38.000000000","message":"Patch Set 11:\n\n(4 comments)","accounts_in_message":[],"_revision_number":11},{"id":"63b13a6d728d7665be8091b466e40711ebdca094","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-18 02:36:19.000000000","message":"Patch Set 11:\n\n(2 comments)\n\n1. For the simplified schema that looks at inventory/trait \"add\" for non-native resources, can we simply call out that changes in resource tracker suffice or be more generic and say its upto the virt_driver to call a common method for pre/post processing?\n\nAnswered inline.\n\n2. Do we need to define a JSON schema?\n\nIt is my strong opinion that the pseudo schema here is adequate and the actual schema is for implementation time.\n\n3. Are we convinced to just have a single file instead of a directory processed lexicographic-ally\n\nDan wanted a directory. There\u0027s a good enough argument for that to be supported in the future (multiple players each dealing with their own provider) and it\u0027s not significantly harder than a single file, so let\u0027s do it.","accounts_in_message":[],"_revision_number":11},{"id":"e2dcb721f6df1769f5a5a3ad8712d2e61e0f1a9d","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-18 07:43:36.000000000","message":"Uploaded patch set 12.","accounts_in_message":[],"_revision_number":12},{"id":"5bcd1a0a8c12964ddf00736d7b987c594ed378e3","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-18 07:45:12.000000000","message":"Patch Set 12:\n\n(1 comment)","accounts_in_message":[],"_revision_number":12},{"id":"db21e8b18de4b8ad26b176b0cb4829a60c4b9fa4","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-18 07:54:22.000000000","message":"Patch Set 12: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/12/check/openstack-tox-docs/469d690/html/ : SUCCESS in 5m 47s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/12/check/openstack-tox-pep8/18c856f/ : SUCCESS in 3m 11s","accounts_in_message":[],"_revision_number":12},{"id":"277a800025ce3c9540d3ae393c7cd45db19d8632","author":{"_account_id":30001,"name":"Ivens Zambrano","email":"ivens.zambrano@intel.com","username":"IvensZambrano"},"date":"2019-07-18 07:59:04.000000000","message":"Patch Set 11:\n\n(1 comment)","accounts_in_message":[],"_revision_number":11},{"id":"2a01cf6771d8fc28347483b2d96ffbd97e78cf5d","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-07-18 09:31:02.000000000","message":"Patch Set 12: Code-Review-1\n\n(7 comments)\n\nOverall looks good. I have some questions inline. -1 mostly due to the special casing of the compute host name.","accounts_in_message":[],"_revision_number":12},{"id":"e21692d7c1919e785b4b65c789bbe8e3ddf43ced","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-18 10:13:18.000000000","message":"Patch Set 12:\n\n(8 comments)","accounts_in_message":[],"_revision_number":12},{"id":"f14b7c40dcf8fee0cf026cc67c454957042c49a1","author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"date":"2019-07-18 11:17:59.000000000","message":"Patch Set 12:\n\n(3 comments)\n\nSome questions within about how this is going to be used, but I think we\u0027re there on the format.","accounts_in_message":[],"_revision_number":12},{"id":"57198dc9a503b455fbea37641827d87325e6ec76","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-18 15:08:34.000000000","message":"Patch Set 12:\n\n(7 comments)","accounts_in_message":[],"_revision_number":12},{"id":"046c0f656deba3af92609389d4726b637da4f6be","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2019-07-18 15:32:04.000000000","message":"Patch Set 10:\n\n(4 comments)","accounts_in_message":[],"_revision_number":10},{"id":"69224985f6d8e4e8a024023ba3187fb965c5af9b","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-07-18 15:47:35.000000000","message":"Patch Set 12: -Code-Review\n\n(1 comment)","accounts_in_message":[],"_revision_number":12},{"id":"f8c948ee742dedb2e5ec662268d31aa190f95980","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-18 19:14:43.000000000","message":"Patch Set 12: Workflow-1\n\n(6 comments)\n\nThis round of comments brought to you by the ~2h of IRC starting at [1]. I\u0027ve conferred with Dakshina and we agreed that I will push the next patch set.\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-07-18.log.html#t2019-07-18T15:08:54","accounts_in_message":[],"_revision_number":12},{"id":"91f259fd49915d6a65889b2256e911b83d648399","author":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"date":"2019-07-18 19:35:10.000000000","message":"Patch Set 12:\n\n(2 comments)","accounts_in_message":[],"_revision_number":12},{"id":"9489abcb11aac082c18e3b892014c588afc69ad0","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-18 20:13:13.000000000","message":"Uploaded patch set 13.","accounts_in_message":[],"_revision_number":13},{"id":"29d0be2bc3d889a8e192a00d765720ce9afb27c1","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-18 20:14:57.000000000","message":"Patch Set 12:\n\n(11 comments)","accounts_in_message":[],"_revision_number":12},{"id":"11d07b0815328e72d747842cc70063eeaba59ebe","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-18 20:26:51.000000000","message":"Patch Set 13: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/13/check/openstack-tox-docs/4125b94/html/ : SUCCESS in 7m 16s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/13/check/openstack-tox-pep8/b840e31/ : SUCCESS in 5m 06s","accounts_in_message":[],"_revision_number":13},{"id":"ba5de56748697f88afd63e2d8800f7dcf5e5fe80","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-07-19 13:11:58.000000000","message":"Patch Set 13:\n\n(1 comment)","accounts_in_message":[],"_revision_number":13},{"id":"bc402e4495d7a6ec5b78bb5bd185e29e4328e51d","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-07-19 14:19:24.000000000","message":"Patch Set 13: Code-Review+2\n\nLet\u0027s add a ..note:  about using the yaml for node specific config in case of ironic as in ironic case a compute node might move between compute host, having different yaml configs.\n\nBesides the it looks good to me.","accounts_in_message":[],"_revision_number":13},{"id":"3669d01898a871bfee8ace5148343523ebe98b16","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-19 14:44:52.000000000","message":"Patch Set 13:\n\n\u003e Let\u0027s add a ..note:  about using the yaml for node specific config in case of ironic as in ironic case a compute node might move between compute host, having different yaml configs.\n\nDone in a fup: https://review.opendev.org/#/c/671749/","accounts_in_message":[],"_revision_number":13},{"id":"026782ddb47352586a97abcda8f5600d59279dfe","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2019-07-19 17:50:57.000000000","message":"Patch Set 13:\n\n(3 comments)","accounts_in_message":[],"_revision_number":13},{"id":"ddf3b7e2236e3c39538ab37ec5c2048fff59dc5a","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-19 18:04:51.000000000","message":"Uploaded patch set 14.","accounts_in_message":[],"_revision_number":14},{"id":"2ce673a5fbf5dcf11981061e43767d3b152ad34b","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-07-19 18:05:39.000000000","message":"Patch Set 14:\n\n(3 comments)\n\nAnd squashed in the fup [1], since gibi was +2 there.\n\n[1] https://review.opendev.org/#/c/671749/","accounts_in_message":[],"_revision_number":14},{"id":"c74c7982fe2d42a15f9c7a25d1334a0bd933e9ac","author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"date":"2019-07-19 18:06:00.000000000","message":"Patch Set 14: Code-Review+2 Workflow+1\n\nGibi was +2 on this before, Eric just tightened one definition for the first rev to make me happy, so I think it\u0027s okay for me to just +W this.","accounts_in_message":[],"_revision_number":14},{"id":"3f090ff6043dd191b6960253b41348e54c7c8f7e","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-19 18:22:38.000000000","message":"Patch Set 14: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/14/check/openstack-tox-docs/78ba9d8/html/ : SUCCESS in 6m 17s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/14/check/openstack-tox-pep8/11ad212/ : SUCCESS in 3m 46s","accounts_in_message":[],"_revision_number":14},{"id":"1b64bb7ea14e291f74180ede398924412ba70f56","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-19 18:22:51.000000000","message":"Patch Set 14: -Verified\n\nStarting gate jobs.","accounts_in_message":[],"_revision_number":14},{"id":"732a052151a2c44afa8f0e32e53ff3a254c2fb00","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-19 18:34:34.000000000","message":"Patch Set 14: Verified+2\n\nBuild succeeded (gate pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/97/612497/14/gate/openstack-tox-docs/7e49437/html/ : SUCCESS in 6m 31s\n- openstack-tox-pep8 http://logs.openstack.org/97/612497/14/gate/openstack-tox-pep8/7ea3e1c/ : SUCCESS in 4m 41s","accounts_in_message":[],"_revision_number":14},{"id":"5370fd8554d7aa8b589bef7c5b72c68a20afe00b","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-07-19 18:34:34.000000000","message":"Change has been successfully merged by Zuul","accounts_in_message":[],"_revision_number":14}],"current_revision_number":14,"current_revision":"c50c3e6412e4d6c0bea02737ad6dfc131b58907f","revisions":{"23f4d90e34f81a997173a2cb7f08a4e220a3ca67":{"kind":"REWORK","_number":1,"created":"2018-10-22 20:16:31.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/97/612497/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/1"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file\nformat.\n\nNote: This work is derived from Jay’s Rocky provider-config-file\nproposal [1] and Konstantinos’s device-placement-model spec [2] (which\nis derived from Eric’s device-passthrough spec [3]), but differs in\nseveral substantive ways.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/23f4d90e34f81a997173a2cb7f08a4e220a3ca67"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/23f4d90e34f81a997173a2cb7f08a4e220a3ca67"}]},"branch":"refs/heads/master"},"e074c84cd9c7e93a1b8cdd8e9160a0345f2513b2":{"kind":"REWORK","_number":2,"created":"2018-12-04 18:33:37.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/97/612497/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/2"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-12-04 18:33:36.000000000","tz":-360},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file\nformat.\n\nNote: This work is derived from Jay’s Rocky provider-config-file\nproposal [1] and Konstantinos’s device-placement-model spec [2] (which\nis derived from Eric’s device-passthrough spec [3]), but differs in\nseveral substantive ways.\n\nNote: This is intended to define a *framework*. Subsequent features can\ndefine the semantics by which the framework can be used to satisfy\nparticular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/e074c84cd9c7e93a1b8cdd8e9160a0345f2513b2"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/e074c84cd9c7e93a1b8cdd8e9160a0345f2513b2"}]},"branch":"refs/heads/master"},"b94a93be05967343364932726897e62b96272410":{"kind":"REWORK","_number":3,"created":"2019-05-31 08:48:49.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/3"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-05-31 08:44:55.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file\nformat.\n\nNote: This work is derived from Jay’s Rocky provider-config-file\nproposal [1] and Konstantinos’s device-placement-model spec [2] (which\nis derived from Eric’s device-passthrough spec [3]), but differs in\nseveral substantive ways.\n\nNote: This is intended to define a *framework*. Subsequent features can\ndefine the semantics by which the framework can be used to satisfy\nparticular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/b94a93be05967343364932726897e62b96272410"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/b94a93be05967343364932726897e62b96272410"}]},"branch":"refs/heads/master"},"bdecd6774cb9c7834b6afde7eebad5baea515bbb":{"kind":"REWORK","_number":4,"created":"2019-06-28 10:45:26.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/4","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/4","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/4"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-06-28 10:40:19.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file\nformat.\n\nNote: This work is derived from Jay’s Rocky provider-config-file\nproposal [1] and Konstantinos’s device-placement-model spec [2] (which\nis derived from Eric’s device-passthrough spec [3]), but differs in\nseveral substantive ways.\n\nNote: This is intended to define a *framework*. Subsequent features can\ndefine the semantics by which the framework can be used to satisfy\nparticular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/bdecd6774cb9c7834b6afde7eebad5baea515bbb"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/bdecd6774cb9c7834b6afde7eebad5baea515bbb"}]},"branch":"refs/heads/master"},"0936ef75b9fbc5be053eb5951b9314c06232e381":{"kind":"REWORK","_number":5,"created":"2019-07-03 14:00:39.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/5","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/5","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/5"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-07-03 13:56:27.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n\t\t  Daemon for finer grain control. PTG discussion notes available at\n\t\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n\t\t  usecases. Subsequent features can define the semantics by which the\n\t\t  framework can be used by consumers(besides Nova) or enhanced to\n\t\t  satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/0936ef75b9fbc5be053eb5951b9314c06232e381"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/0936ef75b9fbc5be053eb5951b9314c06232e381"}]},"branch":"refs/heads/master"},"33cceee453da4c8e5f957dc0bde418cd82e1d34b":{"kind":"REWORK","_number":6,"created":"2019-07-03 14:36:05.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/6","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/6","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/6"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-07-03 14:33:53.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n\t\t  Daemon for finer grain control. PTG discussion notes available at\n\t\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n\t\t  usecases. Subsequent features can define the semantics by which the\n\t\t  framework can be used by consumers(besides Nova) or enhanced to\n\t\t  satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/33cceee453da4c8e5f957dc0bde418cd82e1d34b"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/33cceee453da4c8e5f957dc0bde418cd82e1d34b"}]},"branch":"refs/heads/master"},"c8b4735d4ec19784100f97913f4431da2ec9ed25":{"kind":"REWORK","_number":7,"created":"2019-07-10 14:52:06.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/7","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/7","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/7"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-07-10 14:49:18.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n\t\t  Daemon for finer grain control. PTG discussion notes available at\n\t\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n\t\t  usecases. Subsequent features can define the semantics by which the\n\t\t  framework can be used by consumers(besides Nova) or enhanced to\n\t\t  satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/c8b4735d4ec19784100f97913f4431da2ec9ed25"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/c8b4735d4ec19784100f97913f4431da2ec9ed25"}]},"branch":"refs/heads/master"},"8d7596dea8406ea81b5e50a56e2fd0f06e393137":{"kind":"REWORK","_number":8,"created":"2019-07-10 17:50:33.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/8","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/8","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/8"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-07-10 17:46:10.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n          Daemon for finer grain control. PTG discussion notes available at\n\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n          usecases. Subsequent features can define the semantics by which the\n\t  framework can be used by consumers(besides Nova) or enhanced to\n          satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/8d7596dea8406ea81b5e50a56e2fd0f06e393137"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/8d7596dea8406ea81b5e50a56e2fd0f06e393137"}]},"branch":"refs/heads/master"},"fa8143d5c672291605de47a7ec0c0b118dba6014":{"kind":"REWORK","_number":9,"created":"2019-07-10 18:00:11.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/9","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/9","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/9"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-07-10 17:57:20.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n          Daemon for finer grain control. PTG discussion notes available at\n\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n          usecases. Subsequent features can define the semantics by which the\n\t  framework can be used by consumers(besides Nova) or enhanced to\n          satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/fa8143d5c672291605de47a7ec0c0b118dba6014"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/fa8143d5c672291605de47a7ec0c0b118dba6014"}]},"branch":"refs/heads/master"},"082ad365ad5fb1318851963ae55a0d0caefe9955":{"kind":"REWORK","_number":10,"created":"2019-07-17 15:55:47.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/10","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/10","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/10"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-07-17 15:53:39.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n          Daemon for finer grain control. PTG discussion notes available at\n\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n          usecases. Subsequent features can define the semantics by which the\n\t  framework can be used by consumers(besides Nova) or enhanced to\n          satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/082ad365ad5fb1318851963ae55a0d0caefe9955"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/082ad365ad5fb1318851963ae55a0d0caefe9955"}]},"branch":"refs/heads/master"},"1f45515e205467ff53e3422854096f1351c4633a":{"kind":"REWORK","_number":11,"created":"2019-07-17 17:29:52.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/11","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/11","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/11"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-07-17 17:27:58.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n          Daemon for finer grain control. PTG discussion notes available at\n\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n          usecases. Subsequent features can define the semantics by which the\n\t  framework can be used by consumers(besides Nova) or enhanced to\n          satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/1f45515e205467ff53e3422854096f1351c4633a"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/1f45515e205467ff53e3422854096f1351c4633a"}]},"branch":"refs/heads/master"},"6ad4f286cdd590dc2bf16a590c7451a5941c573e":{"kind":"REWORK","_number":12,"created":"2019-07-18 07:43:36.000000000","uploader":{"_account_id":29334,"name":"Dakshina Ilangovan","email":"dakshina.ilangovan@intel.com","username":"dakshinai"},"ref":"refs/changes/97/612497/12","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/12","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/12 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/12 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/12 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/12"}}},"commit":{"parents":[{"commit":"859c4f3e8897211cfce67090c9bbe4a12babbb33","subject":"Merge \"Update pypi url to new url\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/859c4f3e8897211cfce67090c9bbe4a12babbb33"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"dakshinai","email":"dakshina.ilangovan@intel.com","date":"2019-07-18 07:41:04.000000000","tz":-420},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n          Daemon for finer grain control. PTG discussion notes available at\n\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n          usecases. Subsequent features can define the semantics by which the\n\t  framework can be used by consumers(besides Nova) or enhanced to\n          satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/6ad4f286cdd590dc2bf16a590c7451a5941c573e"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/6ad4f286cdd590dc2bf16a590c7451a5941c573e"}]},"branch":"refs/heads/master"},"2af0e2a64d41e5a5f951aea3b62c5376fda807f9":{"kind":"REWORK","_number":13,"created":"2019-07-18 20:13:13.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/97/612497/13","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/13","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/13 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/13 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/13 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/13"}}},"commit":{"parents":[{"commit":"42ba77612edefafa5c366a759f003e70ee8090c5","subject":"Merge \"Fix the cross_az_attach value in AZ-unshelved spec\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/42ba77612edefafa5c366a759f003e70ee8090c5"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"Eric Fried","email":"openstack@fried.cc","date":"2019-07-18 20:13:06.000000000","tz":-300},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n          Daemon for finer grain control. PTG discussion notes available at\n\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n          usecases. Subsequent features can define the semantics by which the\n\t  framework can be used by consumers(besides Nova) or enhanced to\n          satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/2af0e2a64d41e5a5f951aea3b62c5376fda807f9"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/2af0e2a64d41e5a5f951aea3b62c5376fda807f9"}]},"branch":"refs/heads/master"},"c50c3e6412e4d6c0bea02737ad6dfc131b58907f":{"kind":"REWORK","_number":14,"created":"2019-07-19 18:04:51.000000000","uploader":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"ref":"refs/changes/97/612497/14","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/97/612497/14","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/14 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/14 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/14 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/97/612497/14"}}},"commit":{"parents":[{"commit":"42ba77612edefafa5c366a759f003e70ee8090c5","subject":"Merge \"Fix the cross_az_attach value in AZ-unshelved spec\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/42ba77612edefafa5c366a759f003e70ee8090c5"}]}],"author":{"name":"Eric Fried","email":"efried@us.ibm.com","date":"2018-10-22 20:14:46.000000000","tz":-300},"committer":{"name":"Eric Fried","email":"openstack@fried.cc","date":"2019-07-19 18:04:46.000000000","tz":-300},"subject":"Spec: Provider config YAML file","message":"Spec: Provider config YAML file\n\nThis is a proposal to configure resource provider visibility, ownership,\ninventory, trait, and aggregate settings using a standardized YAML file format.\n\n.. note:: This work is derived from `Jay\u0027s Rocky provider-config-file\n          proposal`_ and `Konstantinos\u0027s device-placement-model spec`_ (which\n          is derived from `Eric\u0027s device-passthrough spec`_), but differs in\n          several substantive ways.\n\n.. note:: This work is influenced by requirements to Nova to support non\n          native compute resources that are managed by Resource Management\n          Daemon for finer grain control. PTG discussion notes available at\n\t  `Resource Management Daemon_PTG Summary`_\n\n.. note:: We currently limit the ownership and consumption of the provider\n          config YAML as described by the file format to Nova only.\n\n.. note:: The provider config will currently only accept placement overrides\n          to create and manage inventories and traits for resources not\n\t  natively managed by the Nova virt driver.\n\n.. note:: This is intended to define a *framework* for currently active\n          usecases. Subsequent features can define the semantics by which the\n\t  framework can be used by consumers(besides Nova) or enhanced to\n          satisfy particular use cases.\n\n[1] https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst\n[2] https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst\n[3] https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst\n[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005809.html\n\nChange-Id: I3b3f3227bc8c0c6a1057122a3014131b1baf72a6\nblueprint: provider-config-file\nSigned-off-by: dakshinai \u003cdakshina.ilangovan@intel.com\u003e\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/c50c3e6412e4d6c0bea02737ad6dfc131b58907f"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/c50c3e6412e4d6c0bea02737ad6dfc131b58907f"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}