)]}'
{"specs/rocky/approved/update-provider-tree.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"03a3484f7d7b7cdc08baeb6cfa95b08ec888d013","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This is fully owned by the"},{"line_number":50,"context_line":"  update_provider_tree method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f93b717_7cac4c9e","line":48,"updated":"2018-02-02 13:06:26.000000000","message":"A simple read of this makes it sounds like the ProviderTree has one root, but that\u0027s not the case.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"6631bd05b8eb4c15d23797db7717948293cb1b28","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This is fully owned by the"},{"line_number":50,"context_line":"  update_provider_tree method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_c961f43b","line":48,"in_reply_to":"3fa0c359_f8359cf8","updated":"2018-02-05 19:38:58.000000000","message":"Done","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"309e9760ab437e194aee87eb075473079b31868f","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This is fully owned by the"},{"line_number":50,"context_line":"  update_provider_tree method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_f8359cf8","line":48,"in_reply_to":"5f93b717_7cac4c9e","updated":"2018-02-05 19:04:50.000000000","message":"\u003e A simple read of this makes it sounds like the ProviderTree has one\n \u003e root\n\nHow so?  Because it\u0027s named \"tree\"?\n\nYou\u0027re right, though - it\u0027s worth mentioning explicitly (somewhere) how multiple roots can come into play.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"48318306fd456a2c4d58a8b6bd92c46a94a0de4a","unresolved":false,"context_lines":[{"line_number":130,"context_line":""},{"line_number":131,"context_line":"  def update_provider_tree(self, provider_tree, nodename):"},{"line_number":132,"context_line":"      traits \u003d [\u0027HW_CPU_X86_AVX\u0027, \u0027HW_CPU_X86_AVX2\u0027, \u0027CUSTOM_GOLD\u0027]"},{"line_number":133,"context_line":"      provider_tree.update_traits(nodename, traits)"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"SchedulerReportClient.update_from_provider_tree()"},{"line_number":136,"context_line":"-------------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_b813940d","line":133,"updated":"2018-02-05 17:33:36.000000000","message":"++ on both the above porting suggestions. nice.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"abcaaadb5c9598f880574753b84d65ce1bb64ba7","unresolved":false,"context_lines":[{"line_number":139,"context_line":"the necessary placement API calls to ensure that the representation in the"},{"line_number":140,"context_line":"placement service matches it.  In particular:"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"* Providers removed by ``update_provider_tree`` are removed from placement."},{"line_number":143,"context_line":"* Providers added by ``update_provider_tree`` are created in placement."},{"line_number":144,"context_line":"* If inventories, traits, or aggregates were changed for any providers by"},{"line_number":145,"context_line":"  ``update_provider_tree``, those changes are flushed back to placement."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_4bd07cf8","line":142,"updated":"2018-02-05 18:19:05.000000000","message":"How do providers that no longer exist get removed?","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"309e9760ab437e194aee87eb075473079b31868f","unresolved":false,"context_lines":[{"line_number":139,"context_line":"the necessary placement API calls to ensure that the representation in the"},{"line_number":140,"context_line":"placement service matches it.  In particular:"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"* Providers removed by ``update_provider_tree`` are removed from placement."},{"line_number":143,"context_line":"* Providers added by ``update_provider_tree`` are created in placement."},{"line_number":144,"context_line":"* If inventories, traits, or aggregates were changed for any providers by"},{"line_number":145,"context_line":"  ``update_provider_tree``, those changes are flushed back to placement."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_a95b482c","line":142,"in_reply_to":"3fa0c359_4bd07cf8","updated":"2018-02-05 19:04:50.000000000","message":"By update_provider_tree, or by report client?\n\nThe former via the `ProviderTree.remove` method (see L78).\n\nThe latter via DELETE /resource_providers/{u} [1][2].  I\u0027m not going into that kind of detail here or elsewhere in this spec, kind of assuming it\u0027s obvious; do you think it\u0027s necessary?\n\n[1] https://review.openstack.org/#/c/533821/18/nova/scheduler/client/report.py@1536\n[2] https://review.openstack.org/#/c/533821/18/nova/scheduler/client/report.py@673","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"abcaaadb5c9598f880574753b84d65ce1bb64ba7","unresolved":false,"context_lines":[{"line_number":177,"context_line":"      except NotImplementedError:"},{"line_number":178,"context_line":"          SchedulerReportClient.update_compute_node()"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"  try:"},{"line_number":181,"context_line":"      ComputeDriver.get_traits()"},{"line_number":182,"context_line":"  except NotImplementedError:"},{"line_number":183,"context_line":"      pass"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Alternatives"},{"line_number":186,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_8b0d2492","line":183,"range":{"start_line":180,"start_character":0,"end_line":183,"end_character":10},"updated":"2018-02-05 18:19:05.000000000","message":"Shouldn\u0027t this be inside the NotImplementedError block above? IOW, if update_provider_tree() is implemented, we shouldn\u0027t need to call get_traits() anymore.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"309e9760ab437e194aee87eb075473079b31868f","unresolved":false,"context_lines":[{"line_number":177,"context_line":"      except NotImplementedError:"},{"line_number":178,"context_line":"          SchedulerReportClient.update_compute_node()"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"  try:"},{"line_number":181,"context_line":"      ComputeDriver.get_traits()"},{"line_number":182,"context_line":"  except NotImplementedError:"},{"line_number":183,"context_line":"      pass"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Alternatives"},{"line_number":186,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_4e3e4a2a","line":183,"range":{"start_line":180,"start_character":0,"end_line":183,"end_character":10},"in_reply_to":"3fa0c359_0e1b621b","updated":"2018-02-05 19:04:50.000000000","message":"@edleafe Yes, I think you\u0027re right - it should go in the *outer* NotImplementedError block, because we\u0027d like it to work for both the get_inventory() and update_compute_node() paths.  The way it\u0027s described here is how it\u0027s currently implemented, but I think that\u0027s just because of how the get_traits patch happened to land during Q FF.  Will fix.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"6631bd05b8eb4c15d23797db7717948293cb1b28","unresolved":false,"context_lines":[{"line_number":177,"context_line":"      except NotImplementedError:"},{"line_number":178,"context_line":"          SchedulerReportClient.update_compute_node()"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"  try:"},{"line_number":181,"context_line":"      ComputeDriver.get_traits()"},{"line_number":182,"context_line":"  except NotImplementedError:"},{"line_number":183,"context_line":"      pass"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Alternatives"},{"line_number":186,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_298f38cd","line":183,"range":{"start_line":180,"start_character":0,"end_line":183,"end_character":10},"in_reply_to":"3fa0c359_4e3e4a2a","updated":"2018-02-05 19:38:58.000000000","message":"Done","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d2fe955c96b41b2479c1acdd285ae55cfbec65a6","unresolved":false,"context_lines":[{"line_number":177,"context_line":"      except NotImplementedError:"},{"line_number":178,"context_line":"          SchedulerReportClient.update_compute_node()"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"  try:"},{"line_number":181,"context_line":"      ComputeDriver.get_traits()"},{"line_number":182,"context_line":"  except NotImplementedError:"},{"line_number":183,"context_line":"      pass"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Alternatives"},{"line_number":186,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_0e1b621b","line":183,"range":{"start_line":180,"start_character":0,"end_line":183,"end_character":10},"in_reply_to":"3fa0c359_8b0d2492","updated":"2018-02-05 18:41:25.000000000","message":"From Eric, above:\n\n \"This method supersedes ``get_inventory()``: if this method is implemented,\n``get_inventory()`` is not used.\n\n``get_traits()`` is not ignored, but it is preferable to use\n``update_provider_tree`` for updating trait information.\"","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"03a3484f7d7b7cdc08baeb6cfa95b08ec888d013","unresolved":false,"context_lines":[{"line_number":220,"context_line":"------------------"},{"line_number":221,"context_line":"This change increases the amount of traffic to the placement service, which has"},{"line_number":222,"context_line":"the potential to affect performance.  However, the SchedulerReportClient makes"},{"line_number":223,"context_line":"use of extensive caching of the ProviderTree to minimize the number of"},{"line_number":224,"context_line":"placement API calls made."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f93b717_1ca508a2","line":223,"updated":"2018-02-02 13:06:26.000000000","message":"as this caching has been the source of much of the debate and disagreement on ProviderTree behavior, it might make sense to explain it more in this document.\n\nHad we started from a spec in the first place, I probably would have suggested that we first make a cache-free version and then add caching later as that\u0027s a fairly time-tested mode for finding bugs.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"abcaaadb5c9598f880574753b84d65ce1bb64ba7","unresolved":false,"context_lines":[{"line_number":220,"context_line":"------------------"},{"line_number":221,"context_line":"This change increases the amount of traffic to the placement service, which has"},{"line_number":222,"context_line":"the potential to affect performance.  However, the SchedulerReportClient makes"},{"line_number":223,"context_line":"use of extensive caching of the ProviderTree to minimize the number of"},{"line_number":224,"context_line":"placement API calls made."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_4bb15c8f","line":223,"in_reply_to":"3fa0c359_0b0274b5","updated":"2018-02-05 18:19:05.000000000","message":"The problem is that the code that is \"thrown up\" (good choice of words!) tends to become the default, and all other approaches are ignored. What we\u0027ve called \"strawman\" code in the past hasn\u0027t been done for clarity; it\u0027s been done to do an end-around the spec process when there isn\u0027t agreement. And when the inevitable shortcomings arise, commenting on those issues are derided as \"I told you so\" instead of treating them as having substance.\n\nThe spec process isn\u0027t perfect, but the vast majority of specs do complete. Those that don\u0027t say more about the personalities involved than the code itself.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d2fe955c96b41b2479c1acdd285ae55cfbec65a6","unresolved":false,"context_lines":[{"line_number":220,"context_line":"------------------"},{"line_number":221,"context_line":"This change increases the amount of traffic to the placement service, which has"},{"line_number":222,"context_line":"the potential to affect performance.  However, the SchedulerReportClient makes"},{"line_number":223,"context_line":"use of extensive caching of the ProviderTree to minimize the number of"},{"line_number":224,"context_line":"placement API calls made."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_6ecc6689","line":223,"in_reply_to":"3fa0c359_4bb15c8f","updated":"2018-02-05 18:41:25.000000000","message":"I don\u0027t have anything against specs. I have something against going on endlessly in specs instead of just getting on with a code proposal. And yes, I consider such comments as \"I told you so\" comments in the absence of alternative *code*.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"1179e8f27ace1f3e27bdf07306bdebf5949462c1","unresolved":false,"context_lines":[{"line_number":220,"context_line":"------------------"},{"line_number":221,"context_line":"This change increases the amount of traffic to the placement service, which has"},{"line_number":222,"context_line":"the potential to affect performance.  However, the SchedulerReportClient makes"},{"line_number":223,"context_line":"use of extensive caching of the ProviderTree to minimize the number of"},{"line_number":224,"context_line":"placement API calls made."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_0b0274b5","line":223,"in_reply_to":"3fa0c359_78ae6c2f","updated":"2018-02-05 17:59:13.000000000","message":"And I can\u0027t count the number of times that we\u0027ve spun endlessly in spec reviews instead of just throwing some code up to look at and use as a basis for ongoing work.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"309e9760ab437e194aee87eb075473079b31868f","unresolved":false,"context_lines":[{"line_number":220,"context_line":"------------------"},{"line_number":221,"context_line":"This change increases the amount of traffic to the placement service, which has"},{"line_number":222,"context_line":"the potential to affect performance.  However, the SchedulerReportClient makes"},{"line_number":223,"context_line":"use of extensive caching of the ProviderTree to minimize the number of"},{"line_number":224,"context_line":"placement API calls made."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_0bfd9439","line":223,"in_reply_to":"3fa0c359_f8d7dc22","updated":"2018-02-05 19:04:50.000000000","message":"I feel like this spec stands on its own without going into the details of caching.\n\nBut I wholeheartedly agree that it would be worth writing up (somewhere else) how report client uses (or should be using) ProviderTree for caching, conflict detection/resolution, retries, etc.  At the moment we\u0027re all over the map on that stuff, and a spec would be a nice way to codify it so we can work towards consistency.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"79269295005513b0250fceded56934d7be25b3cc","unresolved":false,"context_lines":[{"line_number":220,"context_line":"------------------"},{"line_number":221,"context_line":"This change increases the amount of traffic to the placement service, which has"},{"line_number":222,"context_line":"the potential to affect performance.  However, the SchedulerReportClient makes"},{"line_number":223,"context_line":"use of extensive caching of the ProviderTree to minimize the number of"},{"line_number":224,"context_line":"placement API calls made."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_78ae6c2f","line":223,"in_reply_to":"3fa0c359_f8d7dc22","updated":"2018-02-05 17:46:06.000000000","message":"I think that that\u0027s silly. We do specs because we all want to participate in the design, and resolve conceptual differences before anyone has sunk a significant chunk of time into coding. I can\u0027t begin to count the number of times that my understanding of an issue was clarified by participating in the spec process.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"48318306fd456a2c4d58a8b6bd92c46a94a0de4a","unresolved":false,"context_lines":[{"line_number":220,"context_line":"------------------"},{"line_number":221,"context_line":"This change increases the amount of traffic to the placement service, which has"},{"line_number":222,"context_line":"the potential to affect performance.  However, the SchedulerReportClient makes"},{"line_number":223,"context_line":"use of extensive caching of the ProviderTree to minimize the number of"},{"line_number":224,"context_line":"placement API calls made."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Other deployer impact"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3fa0c359_f8d7dc22","line":223,"in_reply_to":"5f93b717_1ca508a2","updated":"2018-02-05 17:33:36.000000000","message":"Had we started from a spec, likely we would still be arguing over the spec.","commit_id":"533c6355f54f0323cb474f723ef0b44b0629a7d4"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"51c6ceefa8f6fc8e22dc6b1d030b32c4b8c96b69","unresolved":false,"context_lines":[{"line_number":61,"context_line":"providers associated with this compute node, as well as the inventory,"},{"line_number":62,"context_line":"aggregates, and traits associated with those resource providers."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":".. note:: A ProviderTree instance may in fact contain more than one \"tree\""},{"line_number":65,"context_line":"          (where a \"tree\" may comprise just a root node).  For example, the"},{"line_number":66,"context_line":"          compute host may be represented by one tree, and each of several"},{"line_number":67,"context_line":"          shared storage or network providers associated via aggregate may be"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_c4b799d8","line":64,"range":{"start_line":64,"start_character":10,"end_line":64,"end_character":74},"updated":"2018-02-05 19:51:16.000000000","message":"\"ProviderForest\"?  :-P","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"e08cf21f43e6740295fe5773791ab53b1b8299f0","unresolved":false,"context_lines":[{"line_number":67,"context_line":"          shared storage or network providers associated via aggregate may be"},{"line_number":68,"context_line":"          represented as separate trees (or single roots)."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"This method supersedes ``get_inventory()`` and ``get_traits``: if this"},{"line_number":71,"context_line":"method is implemented, neither ``get_inventory()`` nor ``get_traits`` is"},{"line_number":72,"context_line":"used."},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_0a8ae3bd","line":70,"range":{"start_line":70,"start_character":38,"end_line":70,"end_character":40},"updated":"2018-02-10 08:22:23.000000000","message":"nit: nix (prefer using the same terminology throughout the document)","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ce0612114ac8fa9f656a347380a5943e80b4f6f5","unresolved":false,"context_lines":[{"line_number":67,"context_line":"          shared storage or network providers associated via aggregate may be"},{"line_number":68,"context_line":"          represented as separate trees (or single roots)."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"This method supersedes ``get_inventory()`` and ``get_traits``: if this"},{"line_number":71,"context_line":"method is implemented, neither ``get_inventory()`` nor ``get_traits`` is"},{"line_number":72,"context_line":"used."},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_de1f96b4","line":70,"range":{"start_line":70,"start_character":38,"end_line":70,"end_character":40},"in_reply_to":"3fa0c359_0a8ae3bd","updated":"2018-02-13 22:03:57.000000000","message":"Done (throughout)","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"51c6ceefa8f6fc8e22dc6b1d030b32c4b8c96b69","unresolved":false,"context_lines":[{"line_number":68,"context_line":"          represented as separate trees (or single roots)."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"This method supersedes ``get_inventory()`` and ``get_traits``: if this"},{"line_number":71,"context_line":"method is implemented, neither ``get_inventory()`` nor ``get_traits`` is"},{"line_number":72,"context_line":"used."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Driver implementations of ``update_provider_tree`` are expected to use public"},{"line_number":75,"context_line":"``ProviderTree`` methods to effect changes to the provider tree passed in."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_e40ad588","line":72,"range":{"start_line":71,"start_character":23,"end_line":72,"end_character":4},"updated":"2018-02-05 19:51:16.000000000","message":"Much clearer - thanks.","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"2280d176b60784a725dcfb0aeab025c1ac1ba8e1","unresolved":false,"context_lines":[{"line_number":85,"context_line":"* ``update_aggregates``: Set the aggregates for a provider."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":".. note:: There is no supported mechanism for ``update_provider_tree`` to"},{"line_number":88,"context_line":"          effect changes to allocations.  This is intentional."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Porting from get_inventory()"},{"line_number":91,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_c659dafe","line":88,"range":{"start_line":88,"start_character":42,"end_line":88,"end_character":62},"updated":"2018-02-05 23:00:45.000000000","message":"because we\u0027ll tackle that (handling the case that allocations get out of synch) with a separate spec? Could clarify that this is out of scope vs. the current text which kind of implies we just don\u0027t wanna allow that.","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ce0612114ac8fa9f656a347380a5943e80b4f6f5","unresolved":false,"context_lines":[{"line_number":85,"context_line":"* ``update_aggregates``: Set the aggregates for a provider."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":".. note:: There is no supported mechanism for ``update_provider_tree`` to"},{"line_number":88,"context_line":"          effect changes to allocations.  This is intentional."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Porting from get_inventory()"},{"line_number":91,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_2586adba","line":88,"range":{"start_line":88,"start_character":42,"end_line":88,"end_character":62},"in_reply_to":"3fa0c359_c659dafe","updated":"2018-02-13 22:03:57.000000000","message":"It actually *is* because we don\u0027t wanna allow that.  I\u0027ll add words explaining why.","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"2280d176b60784a725dcfb0aeab025c1ac1ba8e1","unresolved":false,"context_lines":[{"line_number":139,"context_line":"SchedulerReportClient.update_from_provider_tree()"},{"line_number":140,"context_line":"-------------------------------------------------"},{"line_number":141,"context_line":"This is the report client method responsible for accepting the ProviderTree"},{"line_number":142,"context_line":"as modified by the virt driver via ``update_provider_tree`` and making any"},{"line_number":143,"context_line":"the necessary placement API calls to ensure that the representation in the"},{"line_number":144,"context_line":"placement service matches it.  In particular:"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* Providers removed by ``update_provider_tree`` are removed from placement."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_66ed66ee","line":143,"range":{"start_line":142,"start_character":71,"end_line":143,"end_character":3},"updated":"2018-02-05 23:00:45.000000000","message":"either \"any\" or \"the\" but not both.","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ce0612114ac8fa9f656a347380a5943e80b4f6f5","unresolved":false,"context_lines":[{"line_number":139,"context_line":"SchedulerReportClient.update_from_provider_tree()"},{"line_number":140,"context_line":"-------------------------------------------------"},{"line_number":141,"context_line":"This is the report client method responsible for accepting the ProviderTree"},{"line_number":142,"context_line":"as modified by the virt driver via ``update_provider_tree`` and making any"},{"line_number":143,"context_line":"the necessary placement API calls to ensure that the representation in the"},{"line_number":144,"context_line":"placement service matches it.  In particular:"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* Providers removed by ``update_provider_tree`` are removed from placement."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_e32c3dad","line":143,"range":{"start_line":142,"start_character":71,"end_line":143,"end_character":3},"in_reply_to":"3fa0c359_66ed66ee","updated":"2018-02-13 22:03:57.000000000","message":"Done","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"e08cf21f43e6740295fe5773791ab53b1b8299f0","unresolved":false,"context_lines":[{"line_number":143,"context_line":"the necessary placement API calls to ensure that the representation in the"},{"line_number":144,"context_line":"placement service matches it.  In particular:"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* Providers removed by ``update_provider_tree`` are removed from placement."},{"line_number":147,"context_line":"* Providers added by ``update_provider_tree`` are created in placement."},{"line_number":148,"context_line":"* If inventories, traits, or aggregates were changed for any providers by"},{"line_number":149,"context_line":"  ``update_provider_tree``, those changes are flushed back to placement."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_eaa53748","line":146,"range":{"start_line":146,"start_character":0,"end_line":146,"end_character":75},"updated":"2018-02-10 08:22:23.000000000","message":"Doesn\u0027t this make the placement tightly coupled with the nova and prevent the placement from being independent after all? \n\n\nIf one from another project wants to create a child RP of a compute host (let\u0027s say bandwidth RP from neutron), he can use placement API to creating one. However, because the virt driver doesn\u0027t know about it, it can be removed in the next periodic update. Doesn\u0027t that result in a strong restriction for placement users?\n\nOr developers of virt drivers should consider not to remove those unknown child RPs? Or the report client operates it in update_from_provider_tree? ( I\u0027m not sure that operation is in the patch now being proposed.[1] ) Anyway, it is worth stating that explicitly in the spec, IMO.\n\n[1] https://review.openstack.org/#/c/533821/21\n\n\nNote that at least libvirt driver today removes CUSTOM_RCs which users set manually via placement API for a compute host when the periodic updating task happens. This is because report client passes inv_data without modifying it from the one received from the virt driver in _update_inventory[2]. Is this a bug, or by design?\n\n[2] https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L821-L826\n\n\nI agree that arguing over the spec takes time, but I think it is good to make clear here to which extent virt drivers and the report client are responsible for compute host\u0027s inventories and child RPs.","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ce0612114ac8fa9f656a347380a5943e80b4f6f5","unresolved":false,"context_lines":[{"line_number":143,"context_line":"the necessary placement API calls to ensure that the representation in the"},{"line_number":144,"context_line":"placement service matches it.  In particular:"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* Providers removed by ``update_provider_tree`` are removed from placement."},{"line_number":147,"context_line":"* Providers added by ``update_provider_tree`` are created in placement."},{"line_number":148,"context_line":"* If inventories, traits, or aggregates were changed for any providers by"},{"line_number":149,"context_line":"  ``update_provider_tree``, those changes are flushed back to placement."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_bed88a52","line":146,"range":{"start_line":146,"start_character":0,"end_line":146,"end_character":75},"in_reply_to":"3fa0c359_eaa53748","updated":"2018-02-13 22:03:57.000000000","message":"Thanks for bringing this up, Tetsuro-san.  It\u0027s definitely something that warrants clarification, both in the spec and in the docstring of the method.\n\nBased on various discussions, we are likely to need to support multiple points of control/ownership for a single tree.  For example, there may be NFV code \"out there\" controlling a bandwidth provider which is a child of the compute node RP.  We can\u0027t know/enforce ahead of time which pieces of the tree aren\u0027t \"owned\" by the compute host; except that the compute host is always the source of truth for at least the root provider.\n\nIn scenarios of multiple ownership, the virt driver at least needs to be aware, and be careful not to delete/modify providers it doesn\u0027t own.\n\nSo we\u0027re fine as long as the particular implementation of update_provider_tree doesn\u0027t .remove() providers it doesn\u0027t own (or, importantly, ancestors thereof).\n\nI\u0027ll add some more explanation of this.\n\nSee IRC [1] for more discussion.\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-02-13.log.html#t2018-02-13T19:56:31","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"e58cd62d2e8bff8debe6d94c0a08c663347f7bbd","unresolved":false,"context_lines":[{"line_number":230,"context_line":""},{"line_number":231,"context_line":"One mitigation strategy, already largely implemented, is caching the placement"},{"line_number":232,"context_line":"representation locally via a separate ProviderTree instance maintained in the"},{"line_number":233,"context_line":"SchedulerReportClient.  The specifics are outside the scope of this document."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"Other deployer impact"},{"line_number":236,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_e6f868c5","line":233,"range":{"start_line":233,"start_character":24,"end_line":233,"end_character":77},"updated":"2018-02-07 12:29:10.000000000","message":"Just to make me feel better, if you could repeat what you said above about \n\n \u003e But I wholeheartedly agree that it would be worth writing up\n \u003e (somewhere else) how report client uses (or should be using)\n \u003e ProviderTree for caching, conflict detection/resolution, retries,\n \u003e etc.  At the moment we\u0027re all over the map on that stuff, and a\n \u003e spec would be a nice way to codify it so we can work towards\n \u003e consistency.\n\nbecause I agree with all that and putting it in the doc here is sort of like a commitment to actually doing it.","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ce0612114ac8fa9f656a347380a5943e80b4f6f5","unresolved":false,"context_lines":[{"line_number":230,"context_line":""},{"line_number":231,"context_line":"One mitigation strategy, already largely implemented, is caching the placement"},{"line_number":232,"context_line":"representation locally via a separate ProviderTree instance maintained in the"},{"line_number":233,"context_line":"SchedulerReportClient.  The specifics are outside the scope of this document."},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"Other deployer impact"},{"line_number":236,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa0c359_1e2aded9","line":233,"range":{"start_line":233,"start_character":24,"end_line":233,"end_character":77},"in_reply_to":"3fa0c359_e6f868c5","updated":"2018-02-13 22:03:57.000000000","message":"Done","commit_id":"98223c168653e85b3f6b94984b803bbb420d1e39"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"61e9cf6537f5f87737d698267f7c409425a79f57","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This object is fully owned by the"},{"line_number":50,"context_line":"  ``update_provider_tree`` method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations.  Note, however, that it may contain"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_1ae5fcdb","line":48,"range":{"start_line":48,"start_character":59,"end_line":48,"end_character":72},"updated":"2018-02-14 13:19:09.000000000","message":"I remain moderately confused about the representation of aggregate members in a ProviderTree. If a shared disk, 1999 compute node, and _this_ compute node are in aggregate X, what\u0027s in the ProviderTree. Presumably not 2001 resource providers? If so, why/how?\n\nThe critical word here is \"in\". In placement an rp is in one or more aggregates. We list them in the api as is they \"have\" them. But it is more of an \"in\".\n\nMaybe you don\u0027t want to mention aggregates here or maybe it is only those members of aggregate which have the MISC_SHARES trait?","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"75fbdec0d4801462bd51dd2de727bd63ebe6f7c2","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This object is fully owned by the"},{"line_number":50,"context_line":"  ``update_provider_tree`` method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations.  Note, however, that it may contain"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_a68b91bd","line":48,"range":{"start_line":48,"start_character":59,"end_line":48,"end_character":72},"in_reply_to":"3fa0c359_0b3930f0","updated":"2018-02-14 15:37:24.000000000","message":"Thanks Jay, but yes, I know all that, and that doesn\u0027t answer my actual  questions at all. Eric\u0027s statement makes it sound like in my scenario described above there would be 2001 providers in the ProviderTree.\n\nThat doesn\u0027t seem like what we want (nor does it seem aligned with what your describing in your more broad response of \"what\u0027s an aggregate\") thus the request for clarification.","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"491787735b9b517cfe0cec991b6357d5404e61ad","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This object is fully owned by the"},{"line_number":50,"context_line":"  ``update_provider_tree`` method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations.  Note, however, that it may contain"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_0b3930f0","line":48,"range":{"start_line":48,"start_character":59,"end_line":48,"end_character":72},"in_reply_to":"3fa0c359_1ae5fcdb","updated":"2018-02-14 15:13:20.000000000","message":"@cdent: I can answer your questions here. Aggregates are non-hierarchical relationships between providers. Provider trees are hierarchical relationships between providers. That\u0027s really it.\n\nYou can think of it this way...\n\nYou and I are Nova contributors. We also belong to a family of people.\n\nThe group of Nova contributors is related to each other by way of association. There isn\u0027t any implicit or explicit dependency between us. We all just happen to work on Nova.\n\nThe group of people in our *families*, however, are different. They *do* have dependencies between them. You and I are dependent on our parents for our existence -- without them, we wouldn\u0027t be here. Put another way... without them, we would have no traits nor inventory. Likewise, without you and your wife, your son would not be. The dependent nature of the relationship is important.\n\nAggregates and provider trees are nothing more than ways of expressing groups of resource providers that either *do* or *do not* have a dependent relationship between them.","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"12d214274aa318f535b36db77da8ad87552a3f61","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This object is fully owned by the"},{"line_number":50,"context_line":"  ``update_provider_tree`` method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations.  Note, however, that it may contain"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_46ab8a74","line":48,"range":{"start_line":48,"start_character":59,"end_line":48,"end_character":72},"in_reply_to":"3fa0c359_46494a5e","updated":"2018-02-15 15:29:39.000000000","message":"Agree with limiting to just the sharing provdiers.","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"219016246d0dad2529a6b613a0ab0720eeee40e0","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This object is fully owned by the"},{"line_number":50,"context_line":"  ``update_provider_tree`` method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations.  Note, however, that it may contain"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_46494a5e","line":48,"range":{"start_line":48,"start_character":59,"end_line":48,"end_character":72},"in_reply_to":"3fa0c359_9f4d77c6","updated":"2018-02-15 15:18:49.000000000","message":"Yeah, sorry Chris, I didn\u0027t understand your question. I agree with you and Eric that the \"get me related providers\" operation that the ProviderTree does should be limited to the sharing providers (i.e. MISC_SHARES_VIA_AGGREGATE trait).","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"057d2fac25cf4194ed105f28522761998e6f7d7d","unresolved":false,"context_lines":[{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers associated with the compute node\u0027s nested tree or aggregates, as"},{"line_number":49,"context_line":"  currently known by placement.  This object is fully owned by the"},{"line_number":50,"context_line":"  ``update_provider_tree`` method, and can therefore be modified without"},{"line_number":51,"context_line":"  locking/concurrency considerations.  Note, however, that it may contain"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_9f4d77c6","line":48,"range":{"start_line":48,"start_character":59,"end_line":48,"end_character":72},"in_reply_to":"3fa0c359_a68b91bd","updated":"2018-02-14 16:05:56.000000000","message":"Chris, you raise a good point that needs some more thought and investigation.\n\nThe way the code is written [1], you would indeed get all 2001 providers in your ProviderTree.  (We don\u0027t, however, go and get *their* aggregate-associated providers [2].)\n\nIn the scenario you describe, I definitely want the shared disk in the ProviderTree.  (This gives me the flexibility for my computes to co-own/manage shared providers, which is how we plan to do it for PowerVM SSP).  But I don\u0027t need the other 1999 compute RPs. \nHaving them there is at best inefficient and at worst bloody dangerous.\n\nSo we definitely need to do something so we don\u0027t get those 1999 other computes.  Restricting to agg-associated providers with the MISC_SHARES_VIA_AGGREGATE trait would work, but it doesn\u0027t _feel_ right.  My gut tells me there\u0027s going to be some use case where we\u0027re using aggregates that *aren\u0027t* sharing providers.  But maybe my discomfort is unfounded, or not worth indulging until/unless we actually see such a use case.\n\n[1] https://github.com/openstack/nova/blob/87036b4b27945b6ae34b57e6ee15dd76eb7f726a/nova/scheduler/client/report.py#L784-L791\n[2] https://github.com/openstack/nova/blob/87036b4b27945b6ae34b57e6ee15dd76eb7f726a/nova/scheduler/client/report.py#L792-L799","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0108919c8439a5b3ff73e85c7760711d58b792fd","unresolved":false,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":".. note:: There is no supported mechanism for ``update_provider_tree`` to"},{"line_number":90,"context_line":"          effect changes to allocations.  This is intentional: in Nova,"},{"line_number":91,"context_line":"          allocations are managed exclusively outside of virt. (Usually by the"},{"line_number":92,"context_line":"          scheduler; sometimes - e.g. for migrations - by the conductor.)"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Porting from get_inventory"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_193e78c0","line":91,"range":{"start_line":91,"start_character":10,"end_line":91,"end_character":61},"updated":"2018-02-13 22:40:15.000000000","message":"Sure, but there will need to be interaction with virt to correct out-of-synch allocations, since virt is what will know what reality is. I assume that\u0027s a separate method in a separate spec, though.","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"19885e19b5a0ff19316a94d4ae221cf13be42f72","unresolved":false,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":".. note:: There is no supported mechanism for ``update_provider_tree`` to"},{"line_number":90,"context_line":"          effect changes to allocations.  This is intentional: in Nova,"},{"line_number":91,"context_line":"          allocations are managed exclusively outside of virt. (Usually by the"},{"line_number":92,"context_line":"          scheduler; sometimes - e.g. for migrations - by the conductor.)"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Porting from get_inventory"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_949d6dbd","line":91,"range":{"start_line":91,"start_character":10,"end_line":91,"end_character":61},"in_reply_to":"3fa0c359_193e78c0","updated":"2018-02-13 23:30:11.000000000","message":"Yeah, totally unrelated possible nebulous future thoughts on \"healing\" placement.  Chris has been bouncing around ideas in this neighborhood.","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0108919c8439a5b3ff73e85c7760711d58b792fd","unresolved":false,"context_lines":[{"line_number":239,"context_line":"representation locally via a separate ProviderTree instance maintained in the"},{"line_number":240,"context_line":"SchedulerReportClient.  The specifics are outside the scope of this document."},{"line_number":241,"context_line":"However, the existing code in this area is inconsistent and needs to be"},{"line_number":242,"context_line":"codified in a separate specification so we can work towards consistency."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Other deployer impact"},{"line_number":245,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_1e62de0a","line":242,"range":{"start_line":242,"start_character":0,"end_line":242,"end_character":8},"updated":"2018-02-13 22:40:15.000000000","message":"code needs to be codified? ;)","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"19885e19b5a0ff19316a94d4ae221cf13be42f72","unresolved":false,"context_lines":[{"line_number":239,"context_line":"representation locally via a separate ProviderTree instance maintained in the"},{"line_number":240,"context_line":"SchedulerReportClient.  The specifics are outside the scope of this document."},{"line_number":241,"context_line":"However, the existing code in this area is inconsistent and needs to be"},{"line_number":242,"context_line":"codified in a separate specification so we can work towards consistency."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Other deployer impact"},{"line_number":245,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3fa0c359_14439d43","line":242,"range":{"start_line":242,"start_character":0,"end_line":242,"end_character":8},"in_reply_to":"3fa0c359_1e62de0a","updated":"2018-02-13 23:30:11.000000000","message":"phththpht","commit_id":"77fc9ffbfe60eb7b5929142b6f1b25094d76cc2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"18111b789857bdcbbb4455e3ec30c38df10e9f90","unresolved":false,"context_lines":[{"line_number":33,"context_line":"Use Cases"},{"line_number":34,"context_line":"---------"},{"line_number":35,"context_line":"As a virt driver developer, I wish to be able to model my compute node and"},{"line_number":36,"context_line":"associated entities as any combination of provider trees and sharing providers,"},{"line_number":37,"context_line":"along with inventories, traits, and aggregate associations for those providers."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_b2870fb7","line":36,"range":{"start_line":36,"start_character":61,"end_line":36,"end_character":78},"updated":"2018-02-16 16:35:52.000000000","message":"Does a virt driver ever provides resources that are shared? Or is it mostly about virt driver joining a placement aggregate that already contains a sharing provider?","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e115e6d8d37ad4b8ec8f14664cace3f9775fc439","unresolved":false,"context_lines":[{"line_number":33,"context_line":"Use Cases"},{"line_number":34,"context_line":"---------"},{"line_number":35,"context_line":"As a virt driver developer, I wish to be able to model my compute node and"},{"line_number":36,"context_line":"associated entities as any combination of provider trees and sharing providers,"},{"line_number":37,"context_line":"along with inventories, traits, and aggregate associations for those providers."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_68b193e1","line":36,"range":{"start_line":36,"start_character":61,"end_line":36,"end_character":78},"in_reply_to":"3fa0c359_b2870fb7","updated":"2018-02-16 22:24:08.000000000","message":"Yeah, this wording is specifically allowing for virt to manage the sharing provider itself.  This is how we plan to do it for PowerVM Shared Storage Pools, so that we don\u0027t need an outside agent/admin/orchestrator to do it.","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"18111b789857bdcbbb4455e3ec30c38df10e9f90","unresolved":false,"context_lines":[{"line_number":44,"context_line":"``ComputeDriver.update_provider_tree`` is introduced.  It accepts two"},{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers in the tree associated with the compute node, and any sharing"},{"line_number":49,"context_line":"  providers (those with the ``MISC_SHARES_VIA_AGGREGATE`` trait) associated via"},{"line_number":50,"context_line":"  aggregate with any of those providers (but not *their* tree- or"},{"line_number":51,"context_line":"  aggregate-associated providers), as currently known by placement.  This"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_3230df07","line":48,"range":{"start_line":47,"start_character":55,"end_line":48,"end_character":56},"updated":"2018-02-16 16:35:52.000000000","message":"Does it also mean that after neutron will start nesting RPs under an existing compute RP to model SRIOV or bandwidth then the virt driver will get these RPs as well in the ProviderTree?","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e115e6d8d37ad4b8ec8f14664cace3f9775fc439","unresolved":false,"context_lines":[{"line_number":44,"context_line":"``ComputeDriver.update_provider_tree`` is introduced.  It accepts two"},{"line_number":45,"context_line":"parameters:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"* A ``nova.compute.provider_tree.ProviderTree`` object representing all the"},{"line_number":48,"context_line":"  providers in the tree associated with the compute node, and any sharing"},{"line_number":49,"context_line":"  providers (those with the ``MISC_SHARES_VIA_AGGREGATE`` trait) associated via"},{"line_number":50,"context_line":"  aggregate with any of those providers (but not *their* tree- or"},{"line_number":51,"context_line":"  aggregate-associated providers), as currently known by placement.  This"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_48c6174c","line":48,"range":{"start_line":47,"start_character":55,"end_line":48,"end_character":56},"in_reply_to":"3fa0c359_3230df07","updated":"2018-02-16 22:24:08.000000000","message":"Yes, that\u0027s exactly what it means (I assume your next comment is on the same subject).","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"18111b789857bdcbbb4455e3ec30c38df10e9f90","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  aggregate with any of those providers (but not *their* tree- or"},{"line_number":51,"context_line":"  aggregate-associated providers), as currently known by placement.  This"},{"line_number":52,"context_line":"  object is fully owned by the ``update_provider_tree`` method, and can"},{"line_number":53,"context_line":"  therefore be modified without locking/concurrency considerations.  Note,"},{"line_number":54,"context_line":"  however, that it may contain providers not directly owned/controlled by the"},{"line_number":55,"context_line":"  compute host.  Care must be taken not to remove or modify such providers"},{"line_number":56,"context_line":"  inadvertently."},{"line_number":57,"context_line":"* String name of the compute node for which the caller is updating providers"},{"line_number":58,"context_line":"  and inventory.  Drivers managing more than one node may use this in an"},{"line_number":59,"context_line":"  advisory capacity to restrict changes to only the providers associated with"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_f2127762","line":56,"range":{"start_line":53,"start_character":69,"end_line":56,"end_character":15},"updated":"2018-02-16 16:35:52.000000000","message":"Ahh I see. +1","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"064ca3487c4543a0b52f3c203a7f522382da68c9","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  however, that it may contain providers not directly owned/controlled by the"},{"line_number":55,"context_line":"  compute host.  Care must be taken not to remove or modify such providers"},{"line_number":56,"context_line":"  inadvertently."},{"line_number":57,"context_line":"* String name of the compute node for which the caller is updating providers"},{"line_number":58,"context_line":"  and inventory.  Drivers managing more than one node may use this in an"},{"line_number":59,"context_line":"  advisory capacity to restrict changes to only the providers associated with"},{"line_number":60,"context_line":"  that one node, but this is not a requirement: the caller always subsumes all"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_decba147","line":57,"range":{"start_line":57,"start_character":2,"end_line":57,"end_character":33},"updated":"2018-02-19 15:21:30.000000000","message":"So compute_nodes.hypervisor_hostname.","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2cae2d716c39a5b8456f7c82d143eeab7aa4aaa5","unresolved":false,"context_lines":[{"line_number":54,"context_line":"  however, that it may contain providers not directly owned/controlled by the"},{"line_number":55,"context_line":"  compute host.  Care must be taken not to remove or modify such providers"},{"line_number":56,"context_line":"  inadvertently."},{"line_number":57,"context_line":"* String name of the compute node for which the caller is updating providers"},{"line_number":58,"context_line":"  and inventory.  Drivers managing more than one node may use this in an"},{"line_number":59,"context_line":"  advisory capacity to restrict changes to only the providers associated with"},{"line_number":60,"context_line":"  that one node, but this is not a requirement: the caller always subsumes all"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_611d1072","line":57,"range":{"start_line":57,"start_character":2,"end_line":57,"end_character":33},"in_reply_to":"3fa0c359_decba147","updated":"2018-02-19 16:21:49.000000000","message":"Yes.  Should I call that out explicitly?","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"064ca3487c4543a0b52f3c203a7f522382da68c9","unresolved":false,"context_lines":[{"line_number":55,"context_line":"  compute host.  Care must be taken not to remove or modify such providers"},{"line_number":56,"context_line":"  inadvertently."},{"line_number":57,"context_line":"* String name of the compute node for which the caller is updating providers"},{"line_number":58,"context_line":"  and inventory.  Drivers managing more than one node may use this in an"},{"line_number":59,"context_line":"  advisory capacity to restrict changes to only the providers associated with"},{"line_number":60,"context_line":"  that one node, but this is not a requirement: the caller always subsumes all"},{"line_number":61,"context_line":"  changes regardless."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_9ed519e8","line":58,"range":{"start_line":58,"start_character":18,"end_line":58,"end_character":25},"updated":"2018-02-19 15:21:30.000000000","message":"Drivers like ironic, yes?","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2cae2d716c39a5b8456f7c82d143eeab7aa4aaa5","unresolved":false,"context_lines":[{"line_number":55,"context_line":"  compute host.  Care must be taken not to remove or modify such providers"},{"line_number":56,"context_line":"  inadvertently."},{"line_number":57,"context_line":"* String name of the compute node for which the caller is updating providers"},{"line_number":58,"context_line":"  and inventory.  Drivers managing more than one node may use this in an"},{"line_number":59,"context_line":"  advisory capacity to restrict changes to only the providers associated with"},{"line_number":60,"context_line":"  that one node, but this is not a requirement: the caller always subsumes all"},{"line_number":61,"context_line":"  changes regardless."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_a129d89b","line":58,"range":{"start_line":58,"start_character":18,"end_line":58,"end_character":25},"in_reply_to":"3fa0c359_9ed519e8","updated":"2018-02-19 16:21:49.000000000","message":"Yeah, just like ironic :)  Should I call that out explicitly?","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"064ca3487c4543a0b52f3c203a7f522382da68c9","unresolved":false,"context_lines":[{"line_number":66,"context_line":"providers associated with this compute node, as well as the inventory,"},{"line_number":67,"context_line":"aggregates, and traits associated with those resource providers."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. note:: A ProviderTree instance may in fact contain more than one \"tree\""},{"line_number":70,"context_line":"          (where a \"tree\" may comprise just a root node).  For example, the"},{"line_number":71,"context_line":"          compute host may be represented by one tree, and each of several"},{"line_number":72,"context_line":"          shared storage or network providers associated via aggregate may be"},{"line_number":73,"context_line":"          represented as separate trees (or single roots)."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"This method supersedes ``get_inventory`` and ``get_traits``: if this method is"},{"line_number":76,"context_line":"implemented, neither ``get_inventory`` nor ``get_traits`` is used."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_7ee4cdac","line":73,"range":{"start_line":69,"start_character":0,"end_line":73,"end_character":58},"updated":"2018-02-19 15:21:30.000000000","message":"On L50 it says, \"but not *their* tree- or aggregate-associated providers\" so now I\u0027m confused. Maybe an example of each case with a simple tree diagram could help here?","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2cae2d716c39a5b8456f7c82d143eeab7aa4aaa5","unresolved":false,"context_lines":[{"line_number":66,"context_line":"providers associated with this compute node, as well as the inventory,"},{"line_number":67,"context_line":"aggregates, and traits associated with those resource providers."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. note:: A ProviderTree instance may in fact contain more than one \"tree\""},{"line_number":70,"context_line":"          (where a \"tree\" may comprise just a root node).  For example, the"},{"line_number":71,"context_line":"          compute host may be represented by one tree, and each of several"},{"line_number":72,"context_line":"          shared storage or network providers associated via aggregate may be"},{"line_number":73,"context_line":"          represented as separate trees (or single roots)."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"This method supersedes ``get_inventory`` and ``get_traits``: if this method is"},{"line_number":76,"context_line":"implemented, neither ``get_inventory`` nor ``get_traits`` is used."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_ec64b7e7","line":73,"range":{"start_line":69,"start_character":0,"end_line":73,"end_character":58},"in_reply_to":"3fa0c359_7ee4cdac","updated":"2018-02-19 16:21:49.000000000","message":"Right; the point is that a sharing provider will show up in the ProviderTree as a root; but the ProviderTree will *not* include:\n- The other non-sharing providers (e.g. compute hosts) aggregated with that sharing provider (whether in the same aggregate as this compute host, or a different aggregate that the sharing provider is also a member of); or\n- The rest of the sharing provider\u0027s tree, in the (maybe weird, but theoretically possible) case where the sharing provider happens to be part of a tree in its own right.\n\nOh.  Now I see the discrepancy.\n\nYeah, we should figure out which way we want that latter case to go.","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"78d1398038f5ae6f56083c22dc0b93594d23a8d3","unresolved":false,"context_lines":[{"line_number":66,"context_line":"providers associated with this compute node, as well as the inventory,"},{"line_number":67,"context_line":"aggregates, and traits associated with those resource providers."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. note:: A ProviderTree instance may in fact contain more than one \"tree\""},{"line_number":70,"context_line":"          (where a \"tree\" may comprise just a root node).  For example, the"},{"line_number":71,"context_line":"          compute host may be represented by one tree, and each of several"},{"line_number":72,"context_line":"          shared storage or network providers associated via aggregate may be"},{"line_number":73,"context_line":"          represented as separate trees (or single roots)."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"This method supersedes ``get_inventory`` and ``get_traits``: if this method is"},{"line_number":76,"context_line":"implemented, neither ``get_inventory`` nor ``get_traits`` is used."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_2c5fff72","line":73,"range":{"start_line":69,"start_character":0,"end_line":73,"end_character":58},"in_reply_to":"3fa0c359_ec64b7e7","updated":"2018-02-19 16:54:37.000000000","message":"Per IRC [1], it\u0027s the latter bullet as written: i.e. *don\u0027t* include the rest of the sharing provider\u0027s tree.\n\nWill reword the above paragraph accordingly.\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-02-19.log.html#t2018-02-19T16:23:10","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"18111b789857bdcbbb4455e3ec30c38df10e9f90","unresolved":false,"context_lines":[{"line_number":157,"context_line":""},{"line_number":158,"context_line":".. note:: In multiple-ownership scenarios, virt drivers should be careful not"},{"line_number":159,"context_line":"          to remove or modify providers not owned by the compute host."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"ResourceTracker._update"},{"line_number":162,"context_line":"-----------------------"},{"line_number":163,"context_line":"This is where the virt driver is asked to report on compute resources.  It is"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_ad72547b","line":160,"updated":"2018-02-16 16:35:52.000000000","message":"In case of mismatch in RP generations due to parallel updates (e.g. changes in the aggregate list of the RP) placement will return 409 conflict. Will nova do the retry by flushing the ProviderTree cache and the calling update_provider_tree() on the virt driver again with the new tree?","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e115e6d8d37ad4b8ec8f14664cace3f9775fc439","unresolved":false,"context_lines":[{"line_number":157,"context_line":""},{"line_number":158,"context_line":".. note:: In multiple-ownership scenarios, virt drivers should be careful not"},{"line_number":159,"context_line":"          to remove or modify providers not owned by the compute host."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"ResourceTracker._update"},{"line_number":162,"context_line":"-----------------------"},{"line_number":163,"context_line":"This is where the virt driver is asked to report on compute resources.  It is"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_c82d47fe","line":160,"in_reply_to":"3fa0c359_ad72547b","updated":"2018-02-16 22:24:08.000000000","message":"As written, we just bail and retry by letting the next iteration of the periodic task hit naturally.\n\nAs for how the cache is invalidated... we\u0027ve got some work to do on that front, which is what the text around L241-5 is about.","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"18111b789857bdcbbb4455e3ec30c38df10e9f90","unresolved":false,"context_lines":[{"line_number":243,"context_line":"SchedulerReportClient.  The specifics are outside the scope of this document."},{"line_number":244,"context_line":"However, the existing code in this area is inconsistent and needs to be"},{"line_number":245,"context_line":"codified in a separate specification so we can work towards consistency."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"Other deployer impact"},{"line_number":248,"context_line":"---------------------"},{"line_number":249,"context_line":"None"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_cd79e02f","line":246,"updated":"2018-02-16 16:35:52.000000000","message":"Will the new update_provider_tree() method implementation in the virt driver have similar performance characteristics than the legacy implementations? \nIt feels that walking through the ProviderTree might me more costly as it will contain more (even unnecessary) data (e.g. providers owned by other modules like neutron).","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e115e6d8d37ad4b8ec8f14664cace3f9775fc439","unresolved":false,"context_lines":[{"line_number":243,"context_line":"SchedulerReportClient.  The specifics are outside the scope of this document."},{"line_number":244,"context_line":"However, the existing code in this area is inconsistent and needs to be"},{"line_number":245,"context_line":"codified in a separate specification so we can work towards consistency."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"Other deployer impact"},{"line_number":248,"context_line":"---------------------"},{"line_number":249,"context_line":"None"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3fa0c359_c87b07f2","line":246,"in_reply_to":"3fa0c359_cd79e02f","updated":"2018-02-16 22:24:08.000000000","message":"At the level of ComputeDriver/ResourceTracker, we have no visibility or control over what the driver\u0027s implementation will do.\n\nIt\u0027s operating over objects rather than raw dicts, and is capable of a much wider scope of influence.  But even so, the local data structure traversal/management will be negligible compared to the \"real work\" of getting the information from the hypervisor.  If that wider scope of influence results in getting more data from the hypervisor... well then yeah, it could be more costly.  But that\u0027d be because it\u0027s doing more stuff.\n\nIOW, if we\u0027re talking an apples:apples port of existing functionality from get_available_resource/get_inventory/get_traits to update_provider_tree, the difference should be nil.","commit_id":"baca4d55b72187a639b9883231ca14d1778dfaae"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"cce8db0557765e3dc0790f270bd929633d390738","unresolved":false,"context_lines":[{"line_number":69,"context_line":".. note:: Despite the name, a ProviderTree instance may in fact contain more"},{"line_number":70,"context_line":"          than one tree.  For purposes of this specification, the ProviderTree"},{"line_number":71,"context_line":"          passed to ``update_provider_tree`` will contain a) the entire tree"},{"line_number":72,"context_line":"          associated with the compute host; and b) any sharing providers (those"},{"line_number":73,"context_line":"          with the ``MISC_SHARES_VIA_AGGREGATE`` trait) which are associated"},{"line_number":74,"context_line":"          via aggregate with any of the providers in the compute host\u0027s tree."},{"line_number":75,"context_line":"          The sharing providers will be presented as lone roots in the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3fa0c359_279cf85b","line":72,"range":{"start_line":72,"start_character":38,"end_line":72,"end_character":42},"updated":"2018-02-19 17:31:45.000000000","message":"node? we don\u0027t have resource providers for the compute host, we do for the nodes.","commit_id":"fa1a06e2c8e86da315e648138dcc07644870ed5d"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"63ec61a42faf0ce7f7630136fe3f01df9cd1a686","unresolved":false,"context_lines":[{"line_number":69,"context_line":".. note:: Despite the name, a ProviderTree instance may in fact contain more"},{"line_number":70,"context_line":"          than one tree.  For purposes of this specification, the ProviderTree"},{"line_number":71,"context_line":"          passed to ``update_provider_tree`` will contain a) the entire tree"},{"line_number":72,"context_line":"          associated with the compute host; and b) any sharing providers (those"},{"line_number":73,"context_line":"          with the ``MISC_SHARES_VIA_AGGREGATE`` trait) which are associated"},{"line_number":74,"context_line":"          via aggregate with any of the providers in the compute host\u0027s tree."},{"line_number":75,"context_line":"          The sharing providers will be presented as lone roots in the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3fa0c359_a729e89b","line":72,"range":{"start_line":72,"start_character":38,"end_line":72,"end_character":42},"in_reply_to":"3fa0c359_279cf85b","updated":"2018-02-19 18:00:15.000000000","message":"Whoah, then I totally don\u0027t understand how the RT flow goes, and L57-61 is likely wrong.","commit_id":"fa1a06e2c8e86da315e648138dcc07644870ed5d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"21f8318fd2069713d7f1fc8f27fb8ed6dceb5813","unresolved":false,"context_lines":[{"line_number":69,"context_line":".. note:: Despite the name, a ProviderTree instance may in fact contain more"},{"line_number":70,"context_line":"          than one tree.  For purposes of this specification, the ProviderTree"},{"line_number":71,"context_line":"          passed to ``update_provider_tree`` will contain a) the entire tree"},{"line_number":72,"context_line":"          associated with the compute host; and b) any sharing providers (those"},{"line_number":73,"context_line":"          with the ``MISC_SHARES_VIA_AGGREGATE`` trait) which are associated"},{"line_number":74,"context_line":"          via aggregate with any of the providers in the compute host\u0027s tree."},{"line_number":75,"context_line":"          The sharing providers will be presented as lone roots in the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3fa0c359_022be72f","line":72,"range":{"start_line":72,"start_character":38,"end_line":72,"end_character":42},"in_reply_to":"3fa0c359_a729e89b","updated":"2018-02-19 20:23:44.000000000","message":"\u003e Whoah, then I totally don\u0027t understand how the RT flow goes, and\n \u003e L57-61 is likely wrong.\n\nHeh, I guess my comments in that section earlier were useful then.","commit_id":"fa1a06e2c8e86da315e648138dcc07644870ed5d"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ca59b17786766f5fdbc47a4573542149e955cd49","unresolved":false,"context_lines":[{"line_number":69,"context_line":".. note:: Despite the name, a ProviderTree instance may in fact contain more"},{"line_number":70,"context_line":"          than one tree.  For purposes of this specification, the ProviderTree"},{"line_number":71,"context_line":"          passed to ``update_provider_tree`` will contain a) the entire tree"},{"line_number":72,"context_line":"          associated with the compute host; and b) any sharing providers (those"},{"line_number":73,"context_line":"          with the ``MISC_SHARES_VIA_AGGREGATE`` trait) which are associated"},{"line_number":74,"context_line":"          via aggregate with any of the providers in the compute host\u0027s tree."},{"line_number":75,"context_line":"          The sharing providers will be presented as lone roots in the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3fa0c359_ad29c99b","line":72,"range":{"start_line":72,"start_character":38,"end_line":72,"end_character":42},"in_reply_to":"3fa0c359_a729e89b","updated":"2018-02-19 19:16:10.000000000","message":"Educated self, fixed both, added art.  Enjoy.","commit_id":"fa1a06e2c8e86da315e648138dcc07644870ed5d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"cce8db0557765e3dc0790f270bd929633d390738","unresolved":false,"context_lines":[{"line_number":71,"context_line":"          passed to ``update_provider_tree`` will contain a) the entire tree"},{"line_number":72,"context_line":"          associated with the compute host; and b) any sharing providers (those"},{"line_number":73,"context_line":"          with the ``MISC_SHARES_VIA_AGGREGATE`` trait) which are associated"},{"line_number":74,"context_line":"          via aggregate with any of the providers in the compute host\u0027s tree."},{"line_number":75,"context_line":"          The sharing providers will be presented as lone roots in the"},{"line_number":76,"context_line":"          ProviderTree, even if they happen to be part of a tree themselves."},{"line_number":77,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3fa0c359_c7a2f49a","line":74,"range":{"start_line":74,"start_character":65,"end_line":74,"end_character":69},"updated":"2018-02-19 17:31:45.000000000","message":"node\u0027s","commit_id":"fa1a06e2c8e86da315e648138dcc07644870ed5d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ed4985af744ba625f33e8b39706f8ee11aaedc19","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  aggregate with any of those providers (but not *their* tree- or"},{"line_number":51,"context_line":"  aggregate-associated providers), as currently known by placement.  This"},{"line_number":52,"context_line":"  object is fully owned by the ``update_provider_tree`` method, and can"},{"line_number":53,"context_line":"  therefore be modified without locking/concurrency considerations.  Note,"},{"line_number":54,"context_line":"  however, that it may contain providers not directly owned/controlled by the"},{"line_number":55,"context_line":"  compute host.  Care must be taken not to remove or modify such providers"},{"line_number":56,"context_line":"  inadvertently."}],"source_content_type":"text/x-rst","patch_set":7,"id":"3fa0c359_41839fcb","line":53,"range":{"start_line":53,"start_character":12,"end_line":53,"end_character":23},"updated":"2018-02-26 17:09:52.000000000","message":"a Python object is by default a mutable, so that\u0027s fine with me. Just an implementation detail tho.","commit_id":"ddcc1680274fa6fd01e1313205109417da9ebd73"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"89f323726a0fa25b31970dec3398185972d7b849","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  aggregate with any of those providers (but not *their* tree- or"},{"line_number":51,"context_line":"  aggregate-associated providers), as currently known by placement.  This"},{"line_number":52,"context_line":"  object is fully owned by the ``update_provider_tree`` method, and can"},{"line_number":53,"context_line":"  therefore be modified without locking/concurrency considerations.  Note,"},{"line_number":54,"context_line":"  however, that it may contain providers not directly owned/controlled by the"},{"line_number":55,"context_line":"  compute host.  Care must be taken not to remove or modify such providers"},{"line_number":56,"context_line":"  inadvertently."}],"source_content_type":"text/x-rst","patch_set":7,"id":"3fa0c359_82867e65","line":53,"range":{"start_line":53,"start_character":12,"end_line":53,"end_character":23},"in_reply_to":"3fa0c359_41839fcb","updated":"2018-02-27 09:22:09.000000000","message":"Right; the key part of the sentence is \"without locking/concurrency considerations\".","commit_id":"ddcc1680274fa6fd01e1313205109417da9ebd73"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c59d45ca6cd254c3536c8f12623aa6f6b74ba4cd","unresolved":false,"context_lines":[{"line_number":109,"context_line":"* ``new_child``: Add a new child under an existing provider."},{"line_number":110,"context_line":"* ``data``: Access information (name, UUID, parent, inventory, traits,"},{"line_number":111,"context_line":"  aggregates) about a provider in the tree."},{"line_number":112,"context_line":"* ``remove``: Remove a provider **and its descendants** from the tree.  Use"},{"line_number":113,"context_line":"  caution in multiple-ownership scenarios."},{"line_number":114,"context_line":"* ``update_inventory``: Set the inventory for a provider."},{"line_number":115,"context_line":"* ``update_traits``: Set the traits for a provider."},{"line_number":116,"context_line":"* ``update_aggregates``: Set the aggregates for a provider."}],"source_content_type":"text/x-rst","patch_set":7,"id":"3fa0c359_1b91fe99","line":113,"range":{"start_line":112,"start_character":0,"end_line":113,"end_character":42},"updated":"2018-02-20 15:38:31.000000000","message":"++","commit_id":"ddcc1680274fa6fd01e1313205109417da9ebd73"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"c59d45ca6cd254c3536c8f12623aa6f6b74ba4cd","unresolved":false,"context_lines":[{"line_number":115,"context_line":"* ``update_traits``: Set the traits for a provider."},{"line_number":116,"context_line":"* ``update_aggregates``: Set the aggregates for a provider."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":".. note:: There is no supported mechanism for ``update_provider_tree`` to"},{"line_number":119,"context_line":"          effect changes to allocations.  This is intentional: in Nova,"},{"line_number":120,"context_line":"          allocations are managed exclusively outside of virt. (Usually by the"},{"line_number":121,"context_line":"          scheduler; sometimes - e.g. for migrations - by the conductor.)"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Porting from get_inventory"},{"line_number":124,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3fa0c359_9bf2ee05","line":121,"range":{"start_line":118,"start_character":0,"end_line":121,"end_character":73},"updated":"2018-02-20 15:38:31.000000000","message":"also ++","commit_id":"ddcc1680274fa6fd01e1313205109417da9ebd73"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ed4985af744ba625f33e8b39706f8ee11aaedc19","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":".. code::"},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"  def update_provider_tree(self, provider_tree, nodename):"},{"line_number":145,"context_line":"      inv_data \u003d {"},{"line_number":146,"context_line":"          \u0027VCPU\u0027: { ... },"},{"line_number":147,"context_line":"          \u0027MEMORY_MB\u0027: { ... },"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3fa0c359_01527767","line":144,"range":{"start_line":144,"start_character":33,"end_line":144,"end_character":46},"updated":"2018-02-26 17:09:52.000000000","message":"it would be an empty ProviderTree object then I guess ?","commit_id":"ddcc1680274fa6fd01e1313205109417da9ebd73"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"89f323726a0fa25b31970dec3398185972d7b849","unresolved":false,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":".. code::"},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"  def update_provider_tree(self, provider_tree, nodename):"},{"line_number":145,"context_line":"      inv_data \u003d {"},{"line_number":146,"context_line":"          \u0027VCPU\u0027: { ... },"},{"line_number":147,"context_line":"          \u0027MEMORY_MB\u0027: { ... },"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3fa0c359_a2bcda06","line":144,"range":{"start_line":144,"start_character":33,"end_line":144,"end_character":46},"in_reply_to":"3fa0c359_01527767","updated":"2018-02-27 09:22:09.000000000","message":"Not at all.  The resource tracker always passes in a ProviderTree that represents placement\u0027s latest understanding of the compute node\u0027s RP tree, according to the report client.  Even the first time around, this has been prepopulated (via _ensure_resource_provider()).  After that, it *should* be whatever resulted from the previous update_provider_tree call, assuming no outside entity mucked with it; and this is the virt driver\u0027s opportunity to make changes.","commit_id":"ddcc1680274fa6fd01e1313205109417da9ebd73"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"ed4985af744ba625f33e8b39706f8ee11aaedc19","unresolved":false,"context_lines":[{"line_number":231,"context_line":"* Allow virt drivers direct control over placement.  While we can\u0027t stop"},{"line_number":232,"context_line":"  out-of-tree drivers from doing this, it has been discussed and decided that"},{"line_number":233,"context_line":"  in-tree drivers should be funneled through the choke point of the"},{"line_number":234,"context_line":"  SchedulerReportClient for actual placement API communication."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Data model impact"},{"line_number":237,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3fa0c359_01d7d7c0","line":234,"updated":"2018-02-26 17:09:52.000000000","message":"Yeah, would be terrible if the contrary. ++","commit_id":"ddcc1680274fa6fd01e1313205109417da9ebd73"}]}