)]}'
{"specs/rocky/approved/reshape-provider-tree.rst":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/reshape-provider-tree"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Virt drivers need to be able to change the structure of the provider trees they"},{"line_number":14,"context_line":"expose. When moving existing resources, existing allocations need to be moved"},{"line_number":15,"context_line":"along with the inventories. And this must be done in such a way as to avoid"},{"line_number":16,"context_line":"races where a second entity can create or remove allocations against the moving"},{"line_number":17,"context_line":"inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_f091e29b","line":14,"range":{"start_line":14,"start_character":20,"end_line":14,"end_character":38},"updated":"2018-06-07 14:16:16.000000000","message":"nit: existing resource classes to a different resource provider in the tree ?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/reshape-provider-tree"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Virt drivers need to be able to change the structure of the provider trees they"},{"line_number":14,"context_line":"expose. When moving existing resources, existing allocations need to be moved"},{"line_number":15,"context_line":"along with the inventories. And this must be done in such a way as to avoid"},{"line_number":16,"context_line":"races where a second entity can create or remove allocations against the moving"},{"line_number":17,"context_line":"inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_d9072a1d","line":14,"range":{"start_line":14,"start_character":20,"end_line":14,"end_character":38},"in_reply_to":"5f7c97a3_f091e29b","updated":"2018-06-08 14:37:21.000000000","message":"No, I think this is fine...","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/reshape-provider-tree"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Virt drivers need to be able to change the structure of the provider trees they"},{"line_number":14,"context_line":"expose. When moving existing resources, existing allocations need to be moved"},{"line_number":15,"context_line":"along with the inventories. And this must be done in such a way as to avoid"},{"line_number":16,"context_line":"races where a second entity can create or remove allocations against the moving"},{"line_number":17,"context_line":"inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_72286c96","line":14,"range":{"start_line":14,"start_character":20,"end_line":14,"end_character":38},"in_reply_to":"5f7c97a3_f091e29b","updated":"2018-06-07 22:45:23.000000000","message":"Not just that, see below.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"e9d3d91658c0e45b7dd123872ff3d53d7489b16d","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Virt drivers need to be able to change the structure of the provider trees they"},{"line_number":14,"context_line":"expose. When moving existing resources, existing allocations need to be moved"},{"line_number":15,"context_line":"along with the inventories. And this must be done in such a way as to avoid"},{"line_number":16,"context_line":"races where a second entity can create or remove allocations against the moving"},{"line_number":17,"context_line":"inventories."},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_d5a13897","line":15,"range":{"start_line":15,"start_character":32,"end_line":15,"end_character":49},"updated":"2018-06-07 13:36:28.000000000","message":"It isn\u0027t \u0027must\u0027 since we have a choice to let the admin disable service first. Maybe we should clear the reason, like we want to simple the upgrade process for the admin, the admin only need to restart the service after package upgrade. Or the reason like Jay said, it is more about avoid to implement a transcation.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Virt drivers need to be able to change the structure of the provider trees they"},{"line_number":14,"context_line":"expose. When moving existing resources, existing allocations need to be moved"},{"line_number":15,"context_line":"along with the inventories. And this must be done in such a way as to avoid"},{"line_number":16,"context_line":"races where a second entity can create or remove allocations against the moving"},{"line_number":17,"context_line":"inventories."},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_d212a062","line":15,"range":{"start_line":15,"start_character":32,"end_line":15,"end_character":49},"in_reply_to":"5f7c97a3_503696b6","updated":"2018-06-07 22:45:23.000000000","message":"Yes, we must avoid races.  Disabling the service would qualify as \"such a way as to avoid races\" :)\n\nBut we are also trying to provide a way to do this online, which is why the placement API is necessary.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Virt drivers need to be able to change the structure of the provider trees they"},{"line_number":14,"context_line":"expose. When moving existing resources, existing allocations need to be moved"},{"line_number":15,"context_line":"along with the inventories. And this must be done in such a way as to avoid"},{"line_number":16,"context_line":"races where a second entity can create or remove allocations against the moving"},{"line_number":17,"context_line":"inventories."},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_503696b6","line":15,"range":{"start_line":15,"start_character":32,"end_line":15,"end_character":49},"in_reply_to":"5f7c97a3_d5a13897","updated":"2018-06-07 14:16:16.000000000","message":"It\u0027s \"must\" because even if disabling the compute service, the operator would still need to ask nova (or Placement) to move the inventories and allocations before restarting the compute.\nThe only difference between disabling or not the service is just about possible race conditions.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":23,"context_line":"---------"},{"line_number":24,"context_line":"* The libvirt driver currently inventories VGPU resources on the compute node"},{"line_number":25,"context_line":"  provider. In order to exploit provider trees, libvirt needs to create one"},{"line_number":26,"context_line":"  child provider per physical GPU and move the VGPU inventory from the compute"},{"line_number":27,"context_line":"  node provider to these GPU child providers. In a live deployment where VGPU"},{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_f06d6299","line":26,"range":{"start_line":26,"start_character":17,"end_line":26,"end_character":33},"updated":"2018-06-07 14:16:16.000000000","message":"no, per vGPU type (or pGPU group for Xen, but that\u0027s the same)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d4084f15c2daf148817a5642cc377046b56da79e","unresolved":false,"context_lines":[{"line_number":23,"context_line":"---------"},{"line_number":24,"context_line":"* The libvirt driver currently inventories VGPU resources on the compute node"},{"line_number":25,"context_line":"  provider. In order to exploit provider trees, libvirt needs to create one"},{"line_number":26,"context_line":"  child provider per physical GPU and move the VGPU inventory from the compute"},{"line_number":27,"context_line":"  node provider to these GPU child providers. In a live deployment where VGPU"},{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_87fa52b7","line":26,"range":{"start_line":26,"start_character":17,"end_line":26,"end_character":33},"in_reply_to":"5f7c97a3_0bec1fb9","updated":"2018-06-12 15:30:37.000000000","message":"If I have one pGPU that provides four small and two large vGPU types, then the libvirt driver would _have_ to create two providers for the two types, and then decorate each with the appropriate traits and expose the correct inventory. I don\u0027t see how else it could work unless you want to restrict to one vGPU type per physical device, which, wouldn\u0027t be very flexible.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c0ecedfc54b51c241a7c40c3a022e7d1c015fbaf","unresolved":false,"context_lines":[{"line_number":23,"context_line":"---------"},{"line_number":24,"context_line":"* The libvirt driver currently inventories VGPU resources on the compute node"},{"line_number":25,"context_line":"  provider. In order to exploit provider trees, libvirt needs to create one"},{"line_number":26,"context_line":"  child provider per physical GPU and move the VGPU inventory from the compute"},{"line_number":27,"context_line":"  node provider to these GPU child providers. In a live deployment where VGPU"},{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_d254a956","line":26,"range":{"start_line":26,"start_character":17,"end_line":26,"end_character":33},"in_reply_to":"5f7c97a3_128546ad","updated":"2018-06-11 15:29:08.000000000","message":"Right, agree it could be either per pGPU or type or anything else the virt driver and hardware provider agree on.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c6efc946a7d17dceb213866d93777a2714982676","unresolved":false,"context_lines":[{"line_number":23,"context_line":"---------"},{"line_number":24,"context_line":"* The libvirt driver currently inventories VGPU resources on the compute node"},{"line_number":25,"context_line":"  provider. In order to exploit provider trees, libvirt needs to create one"},{"line_number":26,"context_line":"  child provider per physical GPU and move the VGPU inventory from the compute"},{"line_number":27,"context_line":"  node provider to these GPU child providers. In a live deployment where VGPU"},{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_128546ad","line":26,"range":{"start_line":26,"start_character":17,"end_line":26,"end_character":33},"in_reply_to":"5f7c97a3_5af9b17d","updated":"2018-06-11 12:48:11.000000000","message":"No, libvirt will create child RPs per vGPU type. See https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/vgpu-rocky.html\n\nThe fact that nvidia only supports one type per pGPU is a different concern.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"694b6f9fbeb1e3fbe82f709cb6a5d0d972d5d041","unresolved":false,"context_lines":[{"line_number":23,"context_line":"---------"},{"line_number":24,"context_line":"* The libvirt driver currently inventories VGPU resources on the compute node"},{"line_number":25,"context_line":"  provider. In order to exploit provider trees, libvirt needs to create one"},{"line_number":26,"context_line":"  child provider per physical GPU and move the VGPU inventory from the compute"},{"line_number":27,"context_line":"  node provider to these GPU child providers. In a live deployment where VGPU"},{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_8726d2ca","line":26,"range":{"start_line":26,"start_character":17,"end_line":26,"end_character":33},"in_reply_to":"5f7c97a3_87fa52b7","updated":"2018-06-12 15:51:43.000000000","message":"Ah, I see what you\u0027re saying. Yes, true. The fact that NVIDIA pGPUs only support a single vGPU type at any given time is, as bauzas argued, a different concern.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b60631faa9851f536bbb163dd51f90b2507a0c66","unresolved":false,"context_lines":[{"line_number":23,"context_line":"---------"},{"line_number":24,"context_line":"* The libvirt driver currently inventories VGPU resources on the compute node"},{"line_number":25,"context_line":"  provider. In order to exploit provider trees, libvirt needs to create one"},{"line_number":26,"context_line":"  child provider per physical GPU and move the VGPU inventory from the compute"},{"line_number":27,"context_line":"  node provider to these GPU child providers. In a live deployment where VGPU"},{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5af9b17d","line":26,"range":{"start_line":26,"start_character":17,"end_line":26,"end_character":33},"in_reply_to":"5f7c97a3_945df916","updated":"2018-06-08 21:05:45.000000000","message":"It really could be any of those things.  This use case is an example.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9938d084217e677df339bade00700425ee6bbddc","unresolved":false,"context_lines":[{"line_number":23,"context_line":"---------"},{"line_number":24,"context_line":"* The libvirt driver currently inventories VGPU resources on the compute node"},{"line_number":25,"context_line":"  provider. In order to exploit provider trees, libvirt needs to create one"},{"line_number":26,"context_line":"  child provider per physical GPU and move the VGPU inventory from the compute"},{"line_number":27,"context_line":"  node provider to these GPU child providers. In a live deployment where VGPU"},{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_0bec1fb9","line":26,"range":{"start_line":26,"start_character":17,"end_line":26,"end_character":33},"in_reply_to":"5f7c97a3_d254a956","updated":"2018-06-12 00:51:15.000000000","message":"No, I\u0027m sorry, but the *provider* is a pGPU. Whether libvirt or Xen associates particular traits to that provider based on a vGPU type doesn\u0027t make the provider \u003d\u003d\u003d vGPU type.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":23,"context_line":"---------"},{"line_number":24,"context_line":"* The libvirt driver currently inventories VGPU resources on the compute node"},{"line_number":25,"context_line":"  provider. In order to exploit provider trees, libvirt needs to create one"},{"line_number":26,"context_line":"  child provider per physical GPU and move the VGPU inventory from the compute"},{"line_number":27,"context_line":"  node provider to these GPU child providers. In a live deployment where VGPU"},{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_945df916","line":26,"range":{"start_line":26,"start_character":17,"end_line":26,"end_character":33},"in_reply_to":"5f7c97a3_f06d6299","updated":"2018-06-08 14:37:21.000000000","message":"No, the provider represents the pGPU (or pGPU group in the case of Xen). libvirt won\u0027t create a resource provider per vGPU type.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_500456c6","line":31,"range":{"start_line":31,"start_character":47,"end_line":31,"end_character":65},"updated":"2018-06-07 14:16:16.000000000","message":"VCPU, MEMORY_MB to be clear.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_920c2843","line":31,"range":{"start_line":31,"start_character":47,"end_line":31,"end_character":65},"in_reply_to":"5f7c97a3_500456c6","updated":"2018-06-07 22:45:23.000000000","message":"or PCPU, or some crazy future MEMORY_SNOWFLAKE - I\u0027m being deliberately generic here.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"41e14d9989b4eb382b6f5eec73f8555352728e32","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_19c5b03d","line":32,"range":{"start_line":31,"start_character":67,"end_line":32,"end_character":19},"updated":"2018-06-07 11:35:19.000000000","message":"nit: that is not yet a thing","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b60631faa9851f536bbb163dd51f90b2507a0c66","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_1aa7b952","line":32,"range":{"start_line":31,"start_character":67,"end_line":32,"end_character":19},"in_reply_to":"5f7c97a3_14cec9b3","updated":"2018-06-08 21:05:45.000000000","message":"In summary, these are really just random examples.  As long as they capture the spirit of the kinds of things we need to handle, IMO it\u0027s not important that they reflect precisely what\u0027s going to be done in the real world.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_7030729f","line":32,"range":{"start_line":31,"start_character":67,"end_line":32,"end_character":19},"in_reply_to":"5f7c97a3_19c5b03d","updated":"2018-06-07 14:16:16.000000000","message":"Right, I think it\u0027s not a problem for new resource classes that are not in the root RP (like PCPU)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c0ecedfc54b51c241a7c40c3a022e7d1c015fbaf","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_52ef3986","line":32,"range":{"start_line":31,"start_character":67,"end_line":32,"end_character":19},"in_reply_to":"5f7c97a3_1aa7b952","updated":"2018-06-11 15:29:08.000000000","message":"These are just example cases that may exist now or in the future. We\u0027re describing a generic pivot system here. The use cases don\u0027t all need to be things we need to actively do right now.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_9d35d947","line":32,"range":{"start_line":31,"start_character":67,"end_line":32,"end_character":19},"in_reply_to":"5f7c97a3_52ef3986","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_925e6843","line":32,"range":{"start_line":31,"start_character":67,"end_line":32,"end_character":19},"in_reply_to":"5f7c97a3_7030729f","updated":"2018-06-07 22:45:23.000000000","message":"Right, but this thing has to work in the future too.  I can remove this if it\u0027s contentious.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_14cec9b3","line":32,"range":{"start_line":31,"start_character":67,"end_line":32,"end_character":19},"in_reply_to":"5f7c97a3_7030729f","updated":"2018-06-08 14:37:21.000000000","message":"Well, for things like PCPU, we are going to need to actually *split* current allocations of VCPU into allocations of VCPU and PCPU against one or more child providers representing the physical CPU socket/package.\n\nThis is going to get interesting considering the virt driver is going to need to look at all the coupled NUMATopology and InstanceNUMATopology junk in order to figure out which dedicated CPU (PCPU) amounts are allocated against each NUMA socket. In addition to that mess, we\u0027re also going to need to provide operators with instructions on how to change the *flavors* that currently just have some amount of VCPU when in fact all the vCPU guest resources are dedicated (pinned).","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"5238827f7812ab2f66cdd1d3df6aa05de7a75ed2","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  resources are already allocated to instances, the allocations need to be"},{"line_number":29,"context_line":"  moved along with the inventories."},{"line_number":30,"context_line":"* Drivers wishing to model NUMA must similarly create child providers and move"},{"line_number":31,"context_line":"  inventory and allocations of several classes (processor, memory, VFs on"},{"line_number":32,"context_line":"  NUMA-affined NICs, etc.) to those providers."},{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_8cd400bd","line":32,"range":{"start_line":31,"start_character":67,"end_line":32,"end_character":19},"in_reply_to":"5f7c97a3_925e6843","updated":"2018-06-08 10:35:58.000000000","message":"I just don\u0027t want to make somebody reading this believe that VF is already a resource.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"},{"line_number":36,"context_line":"  name to the new."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_90ef4ee8","line":36,"updated":"2018-06-07 14:16:16.000000000","message":"I wasn\u0027t thinking of this use-case. Well, it would only be a problem if custom RCs are moving from the root RP to a child one, right?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c0ecedfc54b51c241a7c40c3a022e7d1c015fbaf","unresolved":false,"context_lines":[{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"},{"line_number":36,"context_line":"  name to the new."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_d202693e","line":36,"in_reply_to":"5f7c97a3_5439a1a0","updated":"2018-06-11 15:29:08.000000000","message":"Right, any time we need to migrate inventory and allocations atomically, this will apply.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"},{"line_number":36,"context_line":"  name to the new."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b244c41a","line":36,"in_reply_to":"5f7c97a3_90ef4ee8","updated":"2018-06-07 22:14:16.000000000","message":"If it\u0027s a rename of a resource class on an existing provider with existing allocations, you could:\n\n1. add the new resource class and inventory with the new name\n2. copy the allocations on that provider from old to new\n3. drop old\n\nBut that\u0027s not really atomic...which is maybe why it\u0027s called out as part of this spec.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"},{"line_number":36,"context_line":"  name to the new."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5439a1a0","line":36,"in_reply_to":"5f7c97a3_90ef4ee8","updated":"2018-06-08 14:37:21.000000000","message":"No, it\u0027s a problem even if the provider structure doesn\u0027t change and we just need to change the resource class ID for a resource class that was originally added as a custom resource class and later was standardized (and thus changed resource class identifiers....)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":33,"context_line":"* A driver is using a custom resource class. That resource class is added to"},{"line_number":34,"context_line":"  the standard set (under a new, non-``CUSTOM_`` name). In order to use the"},{"line_number":35,"context_line":"  standard name, the driver must move inventory and allocations from the old"},{"line_number":36,"context_line":"  name to the new."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b21e0472","line":36,"in_reply_to":"5f7c97a3_b244c41a","updated":"2018-06-07 22:45:23.000000000","message":"Correct.  We don\u0027t want the scheduler allocating against either the old or the new resource class while this is happening.  It\u0027s the same race we\u0027re avoiding when moving same-RC to different-RP.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"41e14d9989b4eb382b6f5eec73f8555352728e32","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":"The overall flow is as follows:"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. seqdiag::"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"    seqdiag {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5901e869","line":41,"updated":"2018-06-07 11:35:19.000000000","message":"Add a note about when this sequence will be executed.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c0ecedfc54b51c241a7c40c3a022e7d1c015fbaf","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":"The overall flow is as follows:"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. seqdiag::"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"    seqdiag {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_928dd1d5","line":41,"in_reply_to":"5f7c97a3_3a7955c4","updated":"2018-06-11 15:29:08.000000000","message":"\u003e It happens on every periodic task hit in the resource tracker - or\n \u003e relabel the \u0027Resource Tracker\u0027 lane to \u0027Migration Script\u0027 and it\n \u003e represents that.\n\nThis needs to change to \"only on startup\" now right?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":"The overall flow is as follows:"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. seqdiag::"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"    seqdiag {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5d7ae123","line":41,"in_reply_to":"5f7c97a3_3a7955c4","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b60631faa9851f536bbb163dd51f90b2507a0c66","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":"The overall flow is as follows:"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. seqdiag::"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"    seqdiag {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_3a7955c4","line":41,"in_reply_to":"5f7c97a3_5061b638","updated":"2018-06-08 21:05:45.000000000","message":"It happens on every periodic task hit in the resource tracker - or relabel the \u0027Resource Tracker\u0027 lane to \u0027Migration Script\u0027 and it represents that.\n\nI will add words.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":"The overall flow is as follows:"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. seqdiag::"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"    seqdiag {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5061b638","line":41,"in_reply_to":"5f7c97a3_5901e869","updated":"2018-06-07 14:16:16.000000000","message":"What gibi said. We discussed a lot about when and how to call this, I think it\u0027s important to provide this in the spec.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":"The overall flow is as follows:"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":".. seqdiag::"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"    seqdiag {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_3d7da51b","line":41,"in_reply_to":"5f7c97a3_928dd1d5","updated":"2018-06-11 23:19:46.000000000","message":"\u003e This needs to change to \"only on startup\" now right?\n\nNo, it still gets hit on every periodic task interval.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":64,"context_line":"        \u0027Report Client\u0027 -\u003e  Placement [label \u003d \"POST /resource_providers"},{"line_number":65,"context_line":"                                                (create new providers)\"];"},{"line_number":66,"context_line":"        \u0027Report Client\u0027 \u003c-- Placement [label \u003d \"HTTP 200\"];"},{"line_number":67,"context_line":"        \u0027Report Client\u0027 -\u003e  Placement [label \u003d \"POST /migrator {transformation payload}\"];"},{"line_number":68,"context_line":"        Placement --\u003e Placement [label \u003d \"create/modify/"},{"line_number":69,"context_line":"                                          delete"},{"line_number":70,"context_line":"                                          inventories\"];"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_50621618","line":67,"updated":"2018-06-07 14:16:16.000000000","message":"IMHO, this is the most important thing that needs a spec detail, plus how and when we\u0027re about to call it.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":64,"context_line":"        \u0027Report Client\u0027 -\u003e  Placement [label \u003d \"POST /resource_providers"},{"line_number":65,"context_line":"                                                (create new providers)\"];"},{"line_number":66,"context_line":"        \u0027Report Client\u0027 \u003c-- Placement [label \u003d \"HTTP 200\"];"},{"line_number":67,"context_line":"        \u0027Report Client\u0027 -\u003e  Placement [label \u003d \"POST /migrator {transformation payload}\"];"},{"line_number":68,"context_line":"        Placement --\u003e Placement [label \u003d \"create/modify/"},{"line_number":69,"context_line":"                                          delete"},{"line_number":70,"context_line":"                                          inventories\"];"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_52069022","line":67,"in_reply_to":"5f7c97a3_50621618","updated":"2018-06-07 22:45:23.000000000","message":"Yup, all called out below.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":73,"context_line":"                                          allocations\"];"},{"line_number":74,"context_line":"        \u0027Report Client\u0027 \u003c-- Placement [label \u003d \"HTTP 204\"];"},{"line_number":75,"context_line":"        \u0027Resource Tracker\u0027 \u003c-- \u0027Report Client\u0027"},{"line_number":76,"context_line":"    }"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_10d01ec9","line":76,"updated":"2018-06-07 14:16:16.000000000","message":"Looks to me the above diagram is quite an implementation detail, but meh. At least, we should just explain what should be called and when but I don\u0027t think we need to have a diagram.\n\nAlso it misses the crucial point that we need a specific API endpoint for it, given you provide a lot of other points.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":73,"context_line":"                                          allocations\"];"},{"line_number":74,"context_line":"        \u0027Report Client\u0027 \u003c-- Placement [label \u003d \"HTTP 204\"];"},{"line_number":75,"context_line":"        \u0027Resource Tracker\u0027 \u003c-- \u0027Report Client\u0027"},{"line_number":76,"context_line":"    }"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_3230b49e","line":76,"in_reply_to":"5f7c97a3_10d01ec9","updated":"2018-06-07 22:14:16.000000000","message":"\u003e Also it misses the crucial point that we need a specific API endpoint for it, given you provide a lot of other points.\n\nThat\u0027s called out below.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"41e14d9989b4eb382b6f5eec73f8555352728e32","unresolved":false,"context_lines":[{"line_number":88,"context_line":"      :returns: A dict, keyed by consumer UUID, of allocation records."},{"line_number":89,"context_line":"      \"\"\""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"A consumer isn\u0027t always an instance, so we can\u0027t just use the instance list as"},{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b91fdcb5","line":91,"range":{"start_line":91,"start_character":2,"end_line":91,"end_character":35},"updated":"2018-06-07 11:35:19.000000000","message":"Mention that what else it can be. As far as I understood it can be instance.uuid and migration.uuid for now BUT theoretically we can get back allocations that are not made by nova. What we will do with those allocations?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":88,"context_line":"      :returns: A dict, keyed by consumer UUID, of allocation records."},{"line_number":89,"context_line":"      \"\"\""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"A consumer isn\u0027t always an instance, so we can\u0027t just use the instance list as"},{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5dcc2188","line":91,"range":{"start_line":91,"start_character":2,"end_line":91,"end_character":35},"in_reply_to":"5f7c97a3_352ade7d","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":88,"context_line":"      :returns: A dict, keyed by consumer UUID, of allocation records."},{"line_number":89,"context_line":"      \"\"\""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"A consumer isn\u0027t always an instance, so we can\u0027t just use the instance list as"},{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_72eaacd8","line":91,"range":{"start_line":91,"start_character":2,"end_line":91,"end_character":35},"in_reply_to":"5f7c97a3_5019b685","updated":"2018-06-07 22:14:16.000000000","message":"I assume the point of this sentence is just noting that the new method returns a dict keyed by consumer uuid since there can be different consumers, and you could have migration records as consumers holding VGPU allocations on a source node while we\u0027re migrating the instance to another dest node, and that migration consumer needs to continue holding those allocations on the VGPU resources when the VGPU resources are moved to a child provider in the source node tree.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":88,"context_line":"      :returns: A dict, keyed by consumer UUID, of allocation records."},{"line_number":89,"context_line":"      \"\"\""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"A consumer isn\u0027t always an instance, so we can\u0027t just use the instance list as"},{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_352ade7d","line":91,"range":{"start_line":91,"start_character":2,"end_line":91,"end_character":35},"in_reply_to":"5f7c97a3_72eaacd8","updated":"2018-06-07 22:45:23.000000000","message":"Yes, exactly that (but making no assumptions about specific resource classes).  Will enhance.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":88,"context_line":"      :returns: A dict, keyed by consumer UUID, of allocation records."},{"line_number":89,"context_line":"      \"\"\""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"A consumer isn\u0027t always an instance, so we can\u0027t just use the instance list as"},{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5019b685","line":91,"range":{"start_line":91,"start_character":2,"end_line":91,"end_character":35},"in_reply_to":"5f7c97a3_b91fdcb5","updated":"2018-06-07 14:16:16.000000000","message":"Well, are we sure that we need to move allocations that are not for instances ? I mean, the problem is about existing resource classes, right? Either VCPU, MEMORY_MB or VGPU, right? If so, all of them are about either a *migration* or *an instance*. Could we maybe simplify that ?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"},{"line_number":95,"context_line":"those will belong to consumers on other hosts."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"So we have to discover all the consumers associated with the providers in the"},{"line_number":98,"context_line":"local tree::"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5bfeb705","line":95,"updated":"2018-06-07 14:16:16.000000000","message":"Again, I don\u0027t think it\u0027s a problem, given DISK_GB doesn\u0027t need to be moved and other resource classes that aren\u0027t yet there would directly be using child RPs, nope ?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"},{"line_number":95,"context_line":"those will belong to consumers on other hosts."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"So we have to discover all the consumers associated with the providers in the"},{"line_number":98,"context_line":"local tree::"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_92ce6881","line":95,"in_reply_to":"5f7c97a3_5bfeb705","updated":"2018-06-07 22:14:16.000000000","message":"Assuming efried is being generic for sharing providers where DISK_GB might not be what\u0027s being shared, but it\u0027s the canonical example.\n\nHaving said that, I\u0027m not sure I\u0027m following here, but will assume efried has the context (I know I don\u0027t).","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"},{"line_number":95,"context_line":"those will belong to consumers on other hosts."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"So we have to discover all the consumers associated with the providers in the"},{"line_number":98,"context_line":"local tree::"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_727aacba","line":95,"in_reply_to":"5f7c97a3_92ce6881","updated":"2018-06-07 22:45:23.000000000","message":"Certainly being generic.  This has to work for unknown future cases, not just the ones we know about today.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":92,"context_line":"the consumer list."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"We can\u0027t get *all* allocations for associated sharing providers because some of"},{"line_number":95,"context_line":"those will belong to consumers on other hosts."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"So we have to discover all the consumers associated with the providers in the"},{"line_number":98,"context_line":"local tree::"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_bddec83b","line":95,"in_reply_to":"5f7c97a3_92ce6881","updated":"2018-06-08 14:37:21.000000000","message":"Yes, @efried is just being generic here and thorough.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":100,"context_line":"  for each \"local\" provider:"},{"line_number":101,"context_line":"      GET /resource_providers/{provider.uuid}/allocations"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We can\u0027t use *just* those allocations because we would miss allocations for"},{"line_number":104,"context_line":"sharing providers. So we have to get all the allocations for just the consumers"},{"line_number":105,"context_line":"discovered above::"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  for each consumer in ^:"},{"line_number":108,"context_line":"      GET /allocations/{consumer.uuid}"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":".. note:: We will still miss data if **all** of a consumer\u0027s allocations live"},{"line_number":111,"context_line":"          on sharing providers. I don\u0027t have a good way to close that hole."},{"line_number":112,"context_line":"          But that scenario won\u0027t happen in the near future, so it\u0027ll be noted"},{"line_number":113,"context_line":"          as a limitation via a code comment."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Return a dict, keyed by the ``{consumer.uuid}``, of the resulting allocation"},{"line_number":116,"context_line":"records. This is the form of the new `Allocations Parameter`_ expected by"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_1dc81c72","line":113,"range":{"start_line":103,"start_character":0,"end_line":113,"end_character":45},"updated":"2018-06-08 14:37:21.000000000","message":"Note to other reviewers: so, the reason this is necessary is because we are taking the \"replace the world\" approach as opposed to the \"apply this set of change operations\" approach. It\u0027s probably worth pointing out in the Alternatives section that none of the above would be necessary if we were just having the compute node (or other client) sending a set of \"move X to Y\" instructions.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b60631faa9851f536bbb163dd51f90b2507a0c66","unresolved":false,"context_lines":[{"line_number":100,"context_line":"  for each \"local\" provider:"},{"line_number":101,"context_line":"      GET /resource_providers/{provider.uuid}/allocations"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We can\u0027t use *just* those allocations because we would miss allocations for"},{"line_number":104,"context_line":"sharing providers. So we have to get all the allocations for just the consumers"},{"line_number":105,"context_line":"discovered above::"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  for each consumer in ^:"},{"line_number":108,"context_line":"      GET /allocations/{consumer.uuid}"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":".. note:: We will still miss data if **all** of a consumer\u0027s allocations live"},{"line_number":111,"context_line":"          on sharing providers. I don\u0027t have a good way to close that hole."},{"line_number":112,"context_line":"          But that scenario won\u0027t happen in the near future, so it\u0027ll be noted"},{"line_number":113,"context_line":"          as a limitation via a code comment."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Return a dict, keyed by the ``{consumer.uuid}``, of the resulting allocation"},{"line_number":116,"context_line":"records. This is the form of the new `Allocations Parameter`_ expected by"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_3a007502","line":113,"range":{"start_line":103,"start_character":0,"end_line":113,"end_character":45},"in_reply_to":"5f7c97a3_1dc81c72","updated":"2018-06-08 21:05:45.000000000","message":"It would still be necessary.  This section talks about how we\u0027re going to gather information on allocations, which we still need to do even if the /migrator was a series of \u0027move\u0027 instructions.  Because we can\u0027t know which allocations of provider X need to move to Y and which to Z - the virt driver has to tell us.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9938d084217e677df339bade00700425ee6bbddc","unresolved":false,"context_lines":[{"line_number":100,"context_line":"  for each \"local\" provider:"},{"line_number":101,"context_line":"      GET /resource_providers/{provider.uuid}/allocations"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We can\u0027t use *just* those allocations because we would miss allocations for"},{"line_number":104,"context_line":"sharing providers. So we have to get all the allocations for just the consumers"},{"line_number":105,"context_line":"discovered above::"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  for each consumer in ^:"},{"line_number":108,"context_line":"      GET /allocations/{consumer.uuid}"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":".. note:: We will still miss data if **all** of a consumer\u0027s allocations live"},{"line_number":111,"context_line":"          on sharing providers. I don\u0027t have a good way to close that hole."},{"line_number":112,"context_line":"          But that scenario won\u0027t happen in the near future, so it\u0027ll be noted"},{"line_number":113,"context_line":"          as a limitation via a code comment."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Return a dict, keyed by the ``{consumer.uuid}``, of the resulting allocation"},{"line_number":116,"context_line":"records. This is the form of the new `Allocations Parameter`_ expected by"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_cb7dc7e7","line":113,"range":{"start_line":103,"start_character":0,"end_line":113,"end_character":45},"in_reply_to":"5f7c97a3_3a007502","updated":"2018-06-12 00:51:15.000000000","message":"I\u0027m sorry, but if the virt driver were only sending \"move this inventory from X to Y and this allocation from X to Y\" then we absolutely would not need to grab all allocations and all inventories for all local and first-level sharing providers. You\u0027d only need to pull the inventory records and/or allocation records for the specific things you\u0027re moving. However, because we\u0027ve chosen the \"replace the world\" strategy, we do not have any other option that \"grab all inventory records for all resources and all allocation records for all resources on all consumers for all providers in the tree\". And that\u0027s all I was trying to say here.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"13d637c97f6fb23b98b757a48fd4f6d3ebc813df","unresolved":false,"context_lines":[{"line_number":100,"context_line":"  for each \"local\" provider:"},{"line_number":101,"context_line":"      GET /resource_providers/{provider.uuid}/allocations"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We can\u0027t use *just* those allocations because we would miss allocations for"},{"line_number":104,"context_line":"sharing providers. So we have to get all the allocations for just the consumers"},{"line_number":105,"context_line":"discovered above::"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  for each consumer in ^:"},{"line_number":108,"context_line":"      GET /allocations/{consumer.uuid}"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":".. note:: We will still miss data if **all** of a consumer\u0027s allocations live"},{"line_number":111,"context_line":"          on sharing providers. I don\u0027t have a good way to close that hole."},{"line_number":112,"context_line":"          But that scenario won\u0027t happen in the near future, so it\u0027ll be noted"},{"line_number":113,"context_line":"          as a limitation via a code comment."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Return a dict, keyed by the ``{consumer.uuid}``, of the resulting allocation"},{"line_number":116,"context_line":"records. This is the form of the new `Allocations Parameter`_ expected by"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_7696ce4b","line":113,"range":{"start_line":103,"start_character":0,"end_line":113,"end_character":45},"in_reply_to":"5f7c97a3_cb7dc7e7","updated":"2018-06-12 14:19:46.000000000","message":"Yes, fair point.  However, the devil is in the details.  We would still have to have a way for the virt driver to tell us which allocations need to move from where to where.  If the virt driver isn\u0027t talking directly to placement, it either has to return enough information for the resource tracker to figure that out, or it has to pick through the full set of allocations, which the RT has to give it.  The former may be possible, sort of, if the virt driver isn\u0027t working with allocations per se, but returns [instance UUID + RC + amount].  Not sure how that works with migration UUIDs, though...","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"d5d42100991e27873230a6689544b07e131ecffc","unresolved":false,"context_lines":[{"line_number":127,"context_line":""},{"line_number":128,"context_line":"  def update_provider_tree(self, provider_tree, allocations, nodename):"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"The ``allocations`` argument is a dict, keyed by consumer UUID, of allocation"},{"line_number":131,"context_line":"records of the form::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"  { $CONSUMER_UUID: {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_0eab311e","line":130,"updated":"2018-06-06 20:52:31.000000000","message":"I would note here that allocations must always be passed (i.e. it\u0027s not ok to just pass None and assume nothing will change) because the caller can never know whether these shenanigans are going on.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b60631faa9851f536bbb163dd51f90b2507a0c66","unresolved":false,"context_lines":[{"line_number":127,"context_line":""},{"line_number":128,"context_line":"  def update_provider_tree(self, provider_tree, allocations, nodename):"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"The ``allocations`` argument is a dict, keyed by consumer UUID, of allocation"},{"line_number":131,"context_line":"records of the form::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"  { $CONSUMER_UUID: {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_6e12ae5a","line":130,"in_reply_to":"5f7c97a3_0eab311e","updated":"2018-06-08 21:05:45.000000000","message":"For performance reasons, we\u0027re probably going to switch that up and use \u0027None\u0027 to signal that migration shouldn\u0027t be done.  In any case, yes, will describe.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":127,"context_line":""},{"line_number":128,"context_line":"  def update_provider_tree(self, provider_tree, allocations, nodename):"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"The ``allocations`` argument is a dict, keyed by consumer UUID, of allocation"},{"line_number":131,"context_line":"records of the form::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"  { $CONSUMER_UUID: {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_9dddd942","line":130,"in_reply_to":"5f7c97a3_6e12ae5a","updated":"2018-06-11 23:19:46.000000000","message":"Done according to discussions on the etherpad, noted below.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":131,"context_line":"records of the form::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"  { $CONSUMER_UUID: {"},{"line_number":134,"context_line":"        # NOTE: The shape  of each \"allocations\" dict below is identical to the"},{"line_number":135,"context_line":"        # return from GET /allocations/{consumer_uuid}..."},{"line_number":136,"context_line":"        \"allocations\": {"},{"line_number":137,"context_line":"            $RP_UUID: {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_72986c74","line":134,"range":{"start_line":134,"start_character":25,"end_line":134,"end_character":27},"updated":"2018-06-07 22:14:16.000000000","message":"nit: ETOOMANYSPACES","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":131,"context_line":"records of the form::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"  { $CONSUMER_UUID: {"},{"line_number":134,"context_line":"        # NOTE: The shape  of each \"allocations\" dict below is identical to the"},{"line_number":135,"context_line":"        # return from GET /allocations/{consumer_uuid}..."},{"line_number":136,"context_line":"        \"allocations\": {"},{"line_number":137,"context_line":"            $RP_UUID: {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_ddd7d122","line":134,"range":{"start_line":134,"start_character":25,"end_line":134,"end_character":27},"in_reply_to":"5f7c97a3_3dc39859","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":131,"context_line":"records of the form::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"  { $CONSUMER_UUID: {"},{"line_number":134,"context_line":"        # NOTE: The shape  of each \"allocations\" dict below is identical to the"},{"line_number":135,"context_line":"        # return from GET /allocations/{consumer_uuid}..."},{"line_number":136,"context_line":"        \"allocations\": {"},{"line_number":137,"context_line":"            $RP_UUID: {"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_3dc39859","line":134,"range":{"start_line":134,"start_character":25,"end_line":134,"end_character":27},"in_reply_to":"5f7c97a3_72986c74","updated":"2018-06-08 14:37:21.000000000","message":"the horror. the horror. :)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6cc5874c6e0fa96a2cb00050444204284616a5ae","unresolved":false,"context_lines":[{"line_number":156,"context_line":""},{"line_number":157,"context_line":".. note:: I don\u0027t love the idea of the method editing the dict in place rather"},{"line_number":158,"context_line":"          than returning a copy, but it\u0027s consistent with how we\u0027re handling"},{"line_number":159,"context_line":"          the ``provider_tree`` arg."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"Return Value"},{"line_number":162,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_8e0aaa23","line":159,"updated":"2018-06-08 22:26:37.000000000","message":"metoo@aol.com\n\nhowever, given that we are changing the reponse value when the rest of change is happening, and this is special case stuff, we can be different here?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"13d637c97f6fb23b98b757a48fd4f6d3ebc813df","unresolved":false,"context_lines":[{"line_number":156,"context_line":""},{"line_number":157,"context_line":".. note:: I don\u0027t love the idea of the method editing the dict in place rather"},{"line_number":158,"context_line":"          than returning a copy, but it\u0027s consistent with how we\u0027re handling"},{"line_number":159,"context_line":"          the ``provider_tree`` arg."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"Return Value"},{"line_number":162,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b6d6a6c2","line":159,"in_reply_to":"5f7c97a3_2b88fbc3","updated":"2018-06-12 14:19:46.000000000","message":"That information would overlap significantly with what\u0027s in the provider tree and the allocations dict, which would all be pretty confusing to untangle.  IMO the simplest thing is to make just the provider tree and the allocations dict the outputs; and the only question is whether the latter should be returned or edited in place.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":156,"context_line":""},{"line_number":157,"context_line":".. note:: I don\u0027t love the idea of the method editing the dict in place rather"},{"line_number":158,"context_line":"          than returning a copy, but it\u0027s consistent with how we\u0027re handling"},{"line_number":159,"context_line":"          the ``provider_tree`` arg."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"Return Value"},{"line_number":162,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_fd164df2","line":159,"in_reply_to":"5f7c97a3_8e0aaa23","updated":"2018-06-11 23:19:46.000000000","message":"I\u0027m going to leave it this way for now, unless you feel really strongly about this.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f5955f2d64871d480319c6a666409dd6101a4f8c","unresolved":false,"context_lines":[{"line_number":156,"context_line":""},{"line_number":157,"context_line":".. note:: I don\u0027t love the idea of the method editing the dict in place rather"},{"line_number":158,"context_line":"          than returning a copy, but it\u0027s consistent with how we\u0027re handling"},{"line_number":159,"context_line":"          the ``provider_tree`` arg."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"Return Value"},{"line_number":162,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_2b88fbc3","line":159,"in_reply_to":"5f7c97a3_fd164df2","updated":"2018-06-12 01:03:31.000000000","message":"The other option would be to have some returned struct that contained the move operation instructions and have update_from_provider_tree() do the needful with regards to constructing the payload for POST /migrator, yeah?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":163,"context_line":"When enacting a change that will entail moving inventories and/or allocations,"},{"line_number":164,"context_line":"``update_provider_tree()`` must return a list of UUIDs of the providers whose"},{"line_number":165,"context_line":"inventories and/or allocations are being moved. This includes both the"},{"line_number":166,"context_line":"**source** and **target** providers."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"Virt Drivers"},{"line_number":169,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_3b809b46","line":166,"updated":"2018-06-07 14:16:16.000000000","message":"I\u0027m not getting why this method needs to return both source and target provider UUIDs, or at least how the virt driver tells which UUID is a source and which other is a target.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6cc5874c6e0fa96a2cb00050444204284616a5ae","unresolved":false,"context_lines":[{"line_number":163,"context_line":"When enacting a change that will entail moving inventories and/or allocations,"},{"line_number":164,"context_line":"``update_provider_tree()`` must return a list of UUIDs of the providers whose"},{"line_number":165,"context_line":"inventories and/or allocations are being moved. This includes both the"},{"line_number":166,"context_line":"**source** and **target** providers."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"Virt Drivers"},{"line_number":169,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b16b4bb7","line":166,"in_reply_to":"5f7c97a3_0bb45135","updated":"2018-06-08 22:26:37.000000000","message":"Is it crazy to say \"if allocations are returned, then use /migrator\"?\n\nI assume we still want migrator to be a special case, not an always?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":163,"context_line":"When enacting a change that will entail moving inventories and/or allocations,"},{"line_number":164,"context_line":"``update_provider_tree()`` must return a list of UUIDs of the providers whose"},{"line_number":165,"context_line":"inventories and/or allocations are being moved. This includes both the"},{"line_number":166,"context_line":"**source** and **target** providers."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"Virt Drivers"},{"line_number":169,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b53a6ec1","line":166,"in_reply_to":"5f7c97a3_3b809b46","updated":"2018-06-07 22:45:23.000000000","message":"\u003e I\u0027m not getting why this method needs to return both source and\n \u003e target provider UUIDs,\n\nI need to think this through some more, but when I wrote it there was definitely a reason I wanted both.  (If either is unnecessary, then I think neither is necessary in fact.)\n\n \u003e or at least how the virt driver tells which\n \u003e UUID is a source and which other is a target.\n\nWe actually don\u0027t care, because the /migrator is replacing everything.  (Which is why we either need all or none.)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":163,"context_line":"When enacting a change that will entail moving inventories and/or allocations,"},{"line_number":164,"context_line":"``update_provider_tree()`` must return a list of UUIDs of the providers whose"},{"line_number":165,"context_line":"inventories and/or allocations are being moved. This includes both the"},{"line_number":166,"context_line":"**source** and **target** providers."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"Virt Drivers"},{"line_number":169,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_3d21254e","line":166,"in_reply_to":"5f7c97a3_b16b4bb7","updated":"2018-06-11 23:19:46.000000000","message":"I reworded `Performance Impact`_.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":163,"context_line":"When enacting a change that will entail moving inventories and/or allocations,"},{"line_number":164,"context_line":"``update_provider_tree()`` must return a list of UUIDs of the providers whose"},{"line_number":165,"context_line":"inventories and/or allocations are being moved. This includes both the"},{"line_number":166,"context_line":"**source** and **target** providers."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"Virt Drivers"},{"line_number":169,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_bd5d687a","line":166,"in_reply_to":"5f7c97a3_b53a6ec1","updated":"2018-06-08 14:37:21.000000000","message":"I\u0027m with Sylvain on this. My understanding was that update_provider_tree() would be returning what amounted to a \"desired state\" for the inventories and allocations?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8b515ff17861cc10dc082d6199877bff8b48a1a7","unresolved":false,"context_lines":[{"line_number":163,"context_line":"When enacting a change that will entail moving inventories and/or allocations,"},{"line_number":164,"context_line":"``update_provider_tree()`` must return a list of UUIDs of the providers whose"},{"line_number":165,"context_line":"inventories and/or allocations are being moved. This includes both the"},{"line_number":166,"context_line":"**source** and **target** providers."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"Virt Drivers"},{"line_number":169,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_0bb45135","line":166,"in_reply_to":"5f7c97a3_bd5d687a","updated":"2018-06-08 14:57:45.000000000","message":"Right; the question is how update_from_provider_tree knows whether to use the /migrator or not.  If we\u0027re okay with update_from_provider_tree *always* using the /migrator, then you\u0027re right, we don\u0027t need a return value at all.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":196,"context_line":"              allocations for each consumer therein. Ignored if"},{"line_number":197,"context_line":"              migrated_providers is empty."},{"line_number":198,"context_line":"      :param migrated_providers: A list of UUIDs of resource providers whose"},{"line_number":199,"context_line":"              inventories and/or allocations are being migrated. The list must"},{"line_number":200,"context_line":"              include both the source and target providers of the moves. When"},{"line_number":201,"context_line":"              this is nonempty, the allocations parameter and any changes to"},{"line_number":202,"context_line":"              provider inventories (discovered by comparing new_tree to the"},{"line_number":203,"context_line":"              cache) are flushed back to placement in a single POST /migrator"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_52769040","line":200,"range":{"start_line":199,"start_character":65,"end_line":200,"end_character":72},"updated":"2018-06-07 22:14:16.000000000","message":"As Sylvain mentioned above, how do we determine which is the source and which is the target? Is it via what is said next: \"discovered by comparing new_tree to the cache\"?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"13d637c97f6fb23b98b757a48fd4f6d3ebc813df","unresolved":false,"context_lines":[{"line_number":196,"context_line":"              allocations for each consumer therein. Ignored if"},{"line_number":197,"context_line":"              migrated_providers is empty."},{"line_number":198,"context_line":"      :param migrated_providers: A list of UUIDs of resource providers whose"},{"line_number":199,"context_line":"              inventories and/or allocations are being migrated. The list must"},{"line_number":200,"context_line":"              include both the source and target providers of the moves. When"},{"line_number":201,"context_line":"              this is nonempty, the allocations parameter and any changes to"},{"line_number":202,"context_line":"              provider inventories (discovered by comparing new_tree to the"},{"line_number":203,"context_line":"              cache) are flushed back to placement in a single POST /migrator"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_36f4d65a","line":200,"range":{"start_line":199,"start_character":65,"end_line":200,"end_character":72},"in_reply_to":"5f7c97a3_4bae972e","updated":"2018-06-12 14:19:46.000000000","message":"And consequently this text is gone now.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":196,"context_line":"              allocations for each consumer therein. Ignored if"},{"line_number":197,"context_line":"              migrated_providers is empty."},{"line_number":198,"context_line":"      :param migrated_providers: A list of UUIDs of resource providers whose"},{"line_number":199,"context_line":"              inventories and/or allocations are being migrated. The list must"},{"line_number":200,"context_line":"              include both the source and target providers of the moves. When"},{"line_number":201,"context_line":"              this is nonempty, the allocations parameter and any changes to"},{"line_number":202,"context_line":"              provider inventories (discovered by comparing new_tree to the"},{"line_number":203,"context_line":"              cache) are flushed back to placement in a single POST /migrator"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_55499a5d","line":200,"range":{"start_line":199,"start_character":65,"end_line":200,"end_character":72},"in_reply_to":"5f7c97a3_52769040","updated":"2018-06-07 22:45:23.000000000","message":"Doesn\u0027t matter which is which - see above.\n\n(In the general case, a provider could theoretically be both a source and a target.)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f5955f2d64871d480319c6a666409dd6101a4f8c","unresolved":false,"context_lines":[{"line_number":196,"context_line":"              allocations for each consumer therein. Ignored if"},{"line_number":197,"context_line":"              migrated_providers is empty."},{"line_number":198,"context_line":"      :param migrated_providers: A list of UUIDs of resource providers whose"},{"line_number":199,"context_line":"              inventories and/or allocations are being migrated. The list must"},{"line_number":200,"context_line":"              include both the source and target providers of the moves. When"},{"line_number":201,"context_line":"              this is nonempty, the allocations parameter and any changes to"},{"line_number":202,"context_line":"              provider inventories (discovered by comparing new_tree to the"},{"line_number":203,"context_line":"              cache) are flushed back to placement in a single POST /migrator"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_4bae972e","line":200,"range":{"start_line":199,"start_character":65,"end_line":200,"end_character":72},"in_reply_to":"5f7c97a3_55499a5d","updated":"2018-06-12 01:03:31.000000000","message":"Right. Since this is a replace operation, it doesn\u0027t matter what is the source and what is the destination. We\u0027re just overwriting the whole set of allocation records...","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":230,"context_line":"      $RP_UUID: {"},{"line_number":231,"context_line":"        # This is the exact payload format for"},{"line_number":232,"context_line":"        # PUT /resource_provider/$RP_UUID/inventories."},{"line_number":233,"context_line":"        # It should represent the final state of the entire set of resources"},{"line_number":234,"context_line":"        # for this provider. In particular, omitting a $RC dict will cause the"},{"line_number":235,"context_line":"        # inventory for that resource class to be deleted if previously present."},{"line_number":236,"context_line":"        \"inventories\": { $RC: { \u003ctotal, reserved, etc.\u003e } }"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_9b6c4f9d","line":233,"range":{"start_line":233,"start_character":10,"end_line":233,"end_character":45},"updated":"2018-06-07 14:16:16.000000000","message":"I still don\u0027t understand why we need to return the source UUIDs from update_provider_tree() as those are included in the allocations, and see here, you only want to use the target ones.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b4614f850645daebb26ef7ee25b6f68727ccd9b0","unresolved":false,"context_lines":[{"line_number":230,"context_line":"      $RP_UUID: {"},{"line_number":231,"context_line":"        # This is the exact payload format for"},{"line_number":232,"context_line":"        # PUT /resource_provider/$RP_UUID/inventories."},{"line_number":233,"context_line":"        # It should represent the final state of the entire set of resources"},{"line_number":234,"context_line":"        # for this provider. In particular, omitting a $RC dict will cause the"},{"line_number":235,"context_line":"        # inventory for that resource class to be deleted if previously present."},{"line_number":236,"context_line":"        \"inventories\": { $RC: { \u003ctotal, reserved, etc.\u003e } }"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_f47d36e7","line":233,"range":{"start_line":233,"start_character":10,"end_line":233,"end_character":45},"in_reply_to":"5f7c97a3_0ec53f5c","updated":"2018-06-08 18:45:46.000000000","message":"I don\u0027t know how you could possibly have gotten confused.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":230,"context_line":"      $RP_UUID: {"},{"line_number":231,"context_line":"        # This is the exact payload format for"},{"line_number":232,"context_line":"        # PUT /resource_provider/$RP_UUID/inventories."},{"line_number":233,"context_line":"        # It should represent the final state of the entire set of resources"},{"line_number":234,"context_line":"        # for this provider. In particular, omitting a $RC dict will cause the"},{"line_number":235,"context_line":"        # inventory for that resource class to be deleted if previously present."},{"line_number":236,"context_line":"        \"inventories\": { $RC: { \u003ctotal, reserved, etc.\u003e } }"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_7dfd9039","line":233,"range":{"start_line":233,"start_character":10,"end_line":233,"end_character":45},"in_reply_to":"5f7c97a3_55b75a3b","updated":"2018-06-08 14:37:21.000000000","message":"\u003e Yes, that would work if we used /migrator every time for all\n \u003e inventory changes (whether there are allocation changes or not).  I\n \u003e think Jay had objections to using this API for anything other than\n \u003e an actual upgrade scenario.  (Though I\u0027m not convinced it\u0027s better\n \u003e to do the operations one at a time in the general case.)\n\nIt wasn\u0027t that I was supportive of doing the operations one at a time. It was that I could see the potential for abusing this call which definitely will have a performance/blocking behaviour that is different from the \"normal\" flow. :)\n\n \u003e Knowing the affected providers allows us to restrict the /migrator\n \u003e call to just those providers.  It\u0027s an optimization.\n \u003e \n \u003e However, I think you may be correct (here and above) that we could\n \u003e figure out the list of affected providers by diffing the\n \u003e allocations dict from what we started with.  If so, we wouldn\u0027t\n \u003e need *any* return from update_provider_tree - we can just do all\n \u003e the figuring in update_from_provider_tree.\n\nFor inventory records, yes. For allocations, no.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8b515ff17861cc10dc082d6199877bff8b48a1a7","unresolved":false,"context_lines":[{"line_number":230,"context_line":"      $RP_UUID: {"},{"line_number":231,"context_line":"        # This is the exact payload format for"},{"line_number":232,"context_line":"        # PUT /resource_provider/$RP_UUID/inventories."},{"line_number":233,"context_line":"        # It should represent the final state of the entire set of resources"},{"line_number":234,"context_line":"        # for this provider. In particular, omitting a $RC dict will cause the"},{"line_number":235,"context_line":"        # inventory for that resource class to be deleted if previously present."},{"line_number":236,"context_line":"        \"inventories\": { $RC: { \u003ctotal, reserved, etc.\u003e } }"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_ab7e7d67","line":233,"range":{"start_line":233,"start_character":10,"end_line":233,"end_character":45},"in_reply_to":"5f7c97a3_7dfd9039","updated":"2018-06-08 14:57:45.000000000","message":"\u003e For inventory records, yes. For allocations, no.\n\nSorry, could you elaborate please?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":230,"context_line":"      $RP_UUID: {"},{"line_number":231,"context_line":"        # This is the exact payload format for"},{"line_number":232,"context_line":"        # PUT /resource_provider/$RP_UUID/inventories."},{"line_number":233,"context_line":"        # It should represent the final state of the entire set of resources"},{"line_number":234,"context_line":"        # for this provider. In particular, omitting a $RC dict will cause the"},{"line_number":235,"context_line":"        # inventory for that resource class to be deleted if previously present."},{"line_number":236,"context_line":"        \"inventories\": { $RC: { \u003ctotal, reserved, etc.\u003e } }"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_55b75a3b","line":233,"range":{"start_line":233,"start_character":10,"end_line":233,"end_character":45},"in_reply_to":"5f7c97a3_9b6c4f9d","updated":"2018-06-07 22:45:23.000000000","message":"Yes, that would work if we used /migrator every time for all inventory changes (whether there are allocation changes or not).  I think Jay had objections to using this API for anything other than an actual upgrade scenario.  (Though I\u0027m not convinced it\u0027s better to do the operations one at a time in the general case.)\n\nKnowing the affected providers allows us to restrict the /migrator call to just those providers.  It\u0027s an optimization.\n\nHowever, I think you may be correct (here and above) that we could figure out the list of affected providers by diffing the allocations dict from what we started with.  If so, we wouldn\u0027t need *any* return from update_provider_tree - we can just do all the figuring in update_from_provider_tree.\n\nI need to think that all the way through.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"ba69c78b95db73523c65a48850e834a15539f950","unresolved":false,"context_lines":[{"line_number":230,"context_line":"      $RP_UUID: {"},{"line_number":231,"context_line":"        # This is the exact payload format for"},{"line_number":232,"context_line":"        # PUT /resource_provider/$RP_UUID/inventories."},{"line_number":233,"context_line":"        # It should represent the final state of the entire set of resources"},{"line_number":234,"context_line":"        # for this provider. In particular, omitting a $RC dict will cause the"},{"line_number":235,"context_line":"        # inventory for that resource class to be deleted if previously present."},{"line_number":236,"context_line":"        \"inventories\": { $RC: { \u003ctotal, reserved, etc.\u003e } }"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_0ec53f5c","line":233,"range":{"start_line":233,"start_character":10,"end_line":233,"end_character":45},"in_reply_to":"5f7c97a3_ab7e7d67","updated":"2018-06-08 16:02:15.000000000","message":"Sorry, I misread your statement above as \"we can just do all the figuring in update_provider_tree()\" instead of \"update_from_provider_tree()\". And since the provider_tree passed to update_provider_tree() doesn\u0027t have allocation information, I was pointing out that update_provider_tree() wouldn\u0027t be able to figure that diff.\n\nBut you said update_*from*_provider_tree(), not update_provider_tree(). So, in shot, just ignore me :)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":230,"context_line":"      $RP_UUID: {"},{"line_number":231,"context_line":"        # This is the exact payload format for"},{"line_number":232,"context_line":"        # PUT /resource_provider/$RP_UUID/inventories."},{"line_number":233,"context_line":"        # It should represent the final state of the entire set of resources"},{"line_number":234,"context_line":"        # for this provider. In particular, omitting a $RC dict will cause the"},{"line_number":235,"context_line":"        # inventory for that resource class to be deleted if previously present."},{"line_number":236,"context_line":"        \"inventories\": { $RC: { \u003ctotal, reserved, etc.\u003e } }"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_1d66a9bc","line":233,"range":{"start_line":233,"start_character":10,"end_line":233,"end_character":45},"in_reply_to":"5f7c97a3_f47d36e7","updated":"2018-06-11 23:19:46.000000000","message":"I killed the return value. We know whether to perform a migration based on the None-ness of the allocations param to update_from_provider_tree.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":241,"context_line":"    \"allocations\": ["},{"line_number":242,"context_line":"      # This is the exact payload format for POST /allocations"},{"line_number":243,"context_line":"      $CONSUMER_UUID: {"},{"line_number":244,"context_line":"        # project_id and user_id could have been optional for this API, but we"},{"line_number":245,"context_line":"        # keep them for consistency. It\u0027s *probably* not supported to change"},{"line_number":246,"context_line":"        # them via this call; but not sure we should explicitly check for that."},{"line_number":247,"context_line":"        \"project_id\": $PROJ_ID,"},{"line_number":248,"context_line":"        \"user_id\": $USER_ID,"},{"line_number":249,"context_line":"        # This field is part of the consumer generation series under review,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_92cae84c","line":246,"range":{"start_line":244,"start_character":8,"end_line":246,"end_character":79},"updated":"2018-06-07 22:14:16.000000000","message":"If you\u0027re creating new allocations on new providers (VGPU child providers in the compute node tree), then we need to provider the project and user to avoid the whole \"pre-1.8 consumer generation\" mess, right?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":241,"context_line":"    \"allocations\": ["},{"line_number":242,"context_line":"      # This is the exact payload format for POST /allocations"},{"line_number":243,"context_line":"      $CONSUMER_UUID: {"},{"line_number":244,"context_line":"        # project_id and user_id could have been optional for this API, but we"},{"line_number":245,"context_line":"        # keep them for consistency. It\u0027s *probably* not supported to change"},{"line_number":246,"context_line":"        # them via this call; but not sure we should explicitly check for that."},{"line_number":247,"context_line":"        \"project_id\": $PROJ_ID,"},{"line_number":248,"context_line":"        \"user_id\": $USER_ID,"},{"line_number":249,"context_line":"        # This field is part of the consumer generation series under review,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_dd9384ff","line":246,"range":{"start_line":244,"start_character":8,"end_line":246,"end_character":79},"in_reply_to":"5f7c97a3_92cae84c","updated":"2018-06-08 14:37:21.000000000","message":"++","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":241,"context_line":"    \"allocations\": ["},{"line_number":242,"context_line":"      # This is the exact payload format for POST /allocations"},{"line_number":243,"context_line":"      $CONSUMER_UUID: {"},{"line_number":244,"context_line":"        # project_id and user_id could have been optional for this API, but we"},{"line_number":245,"context_line":"        # keep them for consistency. It\u0027s *probably* not supported to change"},{"line_number":246,"context_line":"        # them via this call; but not sure we should explicitly check for that."},{"line_number":247,"context_line":"        \"project_id\": $PROJ_ID,"},{"line_number":248,"context_line":"        \"user_id\": $USER_ID,"},{"line_number":249,"context_line":"        # This field is part of the consumer generation series under review,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b5910e9d","line":246,"range":{"start_line":244,"start_character":8,"end_line":246,"end_character":79},"in_reply_to":"5f7c97a3_92cae84c","updated":"2018-06-07 22:45:23.000000000","message":"Yes, good point; I was thinking I could just copy them from the source, but in this iteration of the payload design we don\u0027t actually know the source.  So yes, proj \u0026 user IDs are required.  I\u0027ll remove this comment.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"41e14d9989b4eb382b6f5eec73f8555352728e32","unresolved":false,"context_lines":[{"line_number":263,"context_line":"In a single atomic transaction, placement replaces the inventories for each"},{"line_number":264,"context_line":"``$RP_UUID`` in the ``inventories`` dict; and replaces the allocations for each"},{"line_number":265,"context_line":"``$CONSUMER_UUID`` in the ``allocations`` dict."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"Return values:"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"* ``204 No Content`` on success."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_445fbce4","line":266,"updated":"2018-06-07 11:35:19.000000000","message":"Does traits and aggregate membership are OK to be migrated outside of this atomic transaction? I guess it can be done when the new RPs are created as without inventory these new RPs will not be selected even if they have traits and are members of a needed aggregate.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"5238827f7812ab2f66cdd1d3df6aa05de7a75ed2","unresolved":false,"context_lines":[{"line_number":263,"context_line":"In a single atomic transaction, placement replaces the inventories for each"},{"line_number":264,"context_line":"``$RP_UUID`` in the ``inventories`` dict; and replaces the allocations for each"},{"line_number":265,"context_line":"``$CONSUMER_UUID`` in the ``allocations`` dict."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"Return values:"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"* ``204 No Content`` on success."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_ac9d3c0b","line":266,"in_reply_to":"5f7c97a3_35ebbe12","updated":"2018-06-08 10:35:58.000000000","message":"@Eric: thanks for confirming my gut feeling. :)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":263,"context_line":"In a single atomic transaction, placement replaces the inventories for each"},{"line_number":264,"context_line":"``$RP_UUID`` in the ``inventories`` dict; and replaces the allocations for each"},{"line_number":265,"context_line":"``$CONSUMER_UUID`` in the ``allocations`` dict."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"Return values:"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"* ``204 No Content`` on success."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5b36b7b6","line":266,"in_reply_to":"5f7c97a3_445fbce4","updated":"2018-06-07 14:16:16.000000000","message":"Moving traits is a good question. Moving aggregates is IHMO not needed because the topology isn\u0027t changing, just the usage of this topology.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":263,"context_line":"In a single atomic transaction, placement replaces the inventories for each"},{"line_number":264,"context_line":"``$RP_UUID`` in the ``inventories`` dict; and replaces the allocations for each"},{"line_number":265,"context_line":"``$CONSUMER_UUID`` in the ``allocations`` dict."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"Return values:"},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"* ``204 No Content`` on success."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_35ebbe12","line":266,"in_reply_to":"5f7c97a3_5b36b7b6","updated":"2018-06-07 22:45:23.000000000","message":"The only thing we\u0027re trying to avoid is races allocating to moving inventories.  Traits and aggregate changes can be done outside of /migrator in the normal sequence that update_from_provider_tree takes.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":269,"context_line":"* ``204 No Content`` on success."},{"line_number":270,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":271,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":272,"context_line":"  for at least the former so the caller can tell whether fresh a ``GET`` is"},{"line_number":273,"context_line":"  necessary before redriving the operation."},{"line_number":274,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":275,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_f2e8fcb3","line":272,"range":{"start_line":272,"start_character":57,"end_line":272,"end_character":64},"updated":"2018-06-07 22:14:16.000000000","message":"a fresh","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":269,"context_line":"* ``204 No Content`` on success."},{"line_number":270,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":271,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":272,"context_line":"  for at least the former so the caller can tell whether fresh a ``GET`` is"},{"line_number":273,"context_line":"  necessary before redriving the operation."},{"line_number":274,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":275,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_1d4d493a","line":272,"range":{"start_line":272,"start_character":57,"end_line":272,"end_character":64},"in_reply_to":"5f7c97a3_f2e8fcb3","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":270,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":271,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":272,"context_line":"  for at least the former so the caller can tell whether fresh a ``GET`` is"},{"line_number":273,"context_line":"  necessary before redriving the operation."},{"line_number":274,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"Direct Interface to Placement"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_72d4ece9","line":273,"range":{"start_line":273,"start_character":19,"end_line":273,"end_character":28},"updated":"2018-06-07 22:14:16.000000000","message":"retrying, redriving must be texas speak","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":270,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":271,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":272,"context_line":"  for at least the former so the caller can tell whether fresh a ``GET`` is"},{"line_number":273,"context_line":"  necessary before redriving the operation."},{"line_number":274,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"Direct Interface to Placement"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_95dbb27b","line":273,"range":{"start_line":273,"start_character":19,"end_line":273,"end_character":28},"in_reply_to":"5f7c97a3_72d4ece9","updated":"2018-06-07 22:45:23.000000000","message":"I use \"redriving\" to mean \"make the same changes to the data again, then reissue the request\".  I think of \"retrying\" as just reissuing the exact same request unchanged.\n\nY\u0027all.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"5238827f7812ab2f66cdd1d3df6aa05de7a75ed2","unresolved":false,"context_lines":[{"line_number":270,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":271,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":272,"context_line":"  for at least the former so the caller can tell whether fresh a ``GET`` is"},{"line_number":273,"context_line":"  necessary before redriving the operation."},{"line_number":274,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"Direct Interface to Placement"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_ccb99879","line":273,"range":{"start_line":273,"start_character":19,"end_line":273,"end_character":28},"in_reply_to":"5f7c97a3_95dbb27b","updated":"2018-06-08 10:35:58.000000000","message":"maybe: \"is necessary before re-calculating the necessary migrations and then retrying the operation\"","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":270,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":271,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":272,"context_line":"  for at least the former so the caller can tell whether fresh a ``GET`` is"},{"line_number":273,"context_line":"  necessary before redriving the operation."},{"line_number":274,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"Direct Interface to Placement"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_fd4f2d32","line":273,"range":{"start_line":273,"start_character":19,"end_line":273,"end_character":28},"in_reply_to":"5f7c97a3_ccb99879","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":281,"context_line":"without going over the network. This allows client code to invoke the placement"},{"line_number":282,"context_line":"API exactly as if it were a standalone service."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"Words from cdent, including stuff about CONF."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Offline Upgrade Script"},{"line_number":287,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_52f2109c","line":284,"updated":"2018-06-07 22:14:16.000000000","message":"That would be linking to https://review.openstack.org/#/c/572576/ plus aforementioned words.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6cc5874c6e0fa96a2cb00050444204284616a5ae","unresolved":false,"context_lines":[{"line_number":281,"context_line":"without going over the network. This allows client code to invoke the placement"},{"line_number":282,"context_line":"API exactly as if it were a standalone service."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"Words from cdent, including stuff about CONF."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Offline Upgrade Script"},{"line_number":287,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_f15f83e2","line":284,"in_reply_to":"5f7c97a3_52f2109c","updated":"2018-06-08 22:26:37.000000000","message":"Coming soon","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"3378c2f6c75dc9a67e6120d93131fd78c56c5bab","unresolved":false,"context_lines":[{"line_number":281,"context_line":"without going over the network. This allows client code to invoke the placement"},{"line_number":282,"context_line":"API exactly as if it were a standalone service."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"Words from cdent, including stuff about CONF."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Offline Upgrade Script"},{"line_number":287,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_d3ccc635","line":284,"in_reply_to":"5f7c97a3_93f64f8f","updated":"2018-06-09 14:59:55.000000000","message":"Nice, thanks Chris.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":281,"context_line":"without going over the network. This allows client code to invoke the placement"},{"line_number":282,"context_line":"API exactly as if it were a standalone service."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"Words from cdent, including stuff about CONF."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Offline Upgrade Script"},{"line_number":287,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_7d3c7d91","line":284,"in_reply_to":"5f7c97a3_d3ccc635","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"27ca5cbe17ba13fcb43fadfbb56a1e6d865e92a7","unresolved":false,"context_lines":[{"line_number":281,"context_line":"without going over the network. This allows client code to invoke the placement"},{"line_number":282,"context_line":"API exactly as if it were a standalone service."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"Words from cdent, including stuff about CONF."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"Offline Upgrade Script"},{"line_number":287,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_93f64f8f","line":284,"in_reply_to":"5f7c97a3_f15f83e2","updated":"2018-06-09 12:40:50.000000000","message":"How about:\n\nTo make the `Offline Upgrade Script`_ possible, we need to make placement       \naccessible by importing Python code rather than as a standalone service. The     \nquickest path forward is to use `wsgi-intercept`_ to allow HTTP interactions,   \nusing the `requests`_ library, to work with only database traffic going over    \nthe network. This allows client code to make changes to the placement data      \nstore using the same API, but without running a placement service.              \n                                                                                \nAn implementation of this, as a context manager called `PlacementDirect`_, is   \nin progress. The context manager accepts an `oslo config`_, populated by the    \ncaller. This allows the calling code to control how it wishes to discover       \nconfiguration settings, most importantly the database being used by placement.  \n                                                                                \nThis implementation provides a quick solution to the immediate needs of offline \nuse of ``/migrator`` while allowing options for prettier solutions in the       \nfuture.                                                                         \n                                                                                \n.. _wsgi-intercept: https://pypi.org/project/wsgi_intercept/                    \n.. _requests: http://docs.python-requests.org/                                  \n.. _PlacementDirect: https://review.openstack.org/#/c/572576/                   \n.. _oslo config: https://docs.openstack.org/oslo.config/latest/","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6cc5874c6e0fa96a2cb00050444204284616a5ae","unresolved":false,"context_lines":[{"line_number":286,"context_line":"Offline Upgrade Script"},{"line_number":287,"context_line":"----------------------"},{"line_number":288,"context_line":"To facilitate Fast Forward Upgrades, we must provide a script that can perform"},{"line_number":289,"context_line":"this reshaping while all services are offline. It will operate as follows, for"},{"line_number":290,"context_line":"each nodename (one, except for ironic) on the host:"},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"* Spin up a SchedulerReportClient with a `Direct Interface to Placement`_."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_f136a3b4","line":289,"range":{"start_line":289,"start_character":21,"end_line":289,"end_character":33},"updated":"2018-06-08 22:26:37.000000000","message":"all services except databases","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":286,"context_line":"Offline Upgrade Script"},{"line_number":287,"context_line":"----------------------"},{"line_number":288,"context_line":"To facilitate Fast Forward Upgrades, we must provide a script that can perform"},{"line_number":289,"context_line":"this reshaping while all services are offline. It will operate as follows, for"},{"line_number":290,"context_line":"each nodename (one, except for ironic) on the host:"},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"* Spin up a SchedulerReportClient with a `Direct Interface to Placement`_."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_bde8d515","line":289,"range":{"start_line":289,"start_character":21,"end_line":289,"end_character":33},"in_reply_to":"5f7c97a3_f136a3b4","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":289,"context_line":"this reshaping while all services are offline. It will operate as follows, for"},{"line_number":290,"context_line":"each nodename (one, except for ironic) on the host:"},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"* Spin up a SchedulerReportClient with a `Direct Interface to Placement`_."},{"line_number":293,"context_line":"* Retrieve a ProviderTree via"},{"line_number":294,"context_line":"  ``SchedulerReportClient.get_provider_tree_and_ensure_root()``."},{"line_number":295,"context_line":"* Retrieve allocations via `get_allocations_for_provider_tree()`_."},{"line_number":296,"context_line":"* Instantiate the appropriate virt driver."},{"line_number":297,"context_line":"* Invoke that virt driver\u0027s `update_provider_tree()`_ method."},{"line_number":298,"context_line":"* If the `Return Value`_ is nonempty, invoke `update_from_provider_tree()`_."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_d2338061","line":295,"range":{"start_line":292,"start_character":2,"end_line":295,"end_character":66},"updated":"2018-06-07 22:14:16.000000000","message":"So this is essentially copying what the ResourceTracker is doing during _update() right?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":289,"context_line":"this reshaping while all services are offline. It will operate as follows, for"},{"line_number":290,"context_line":"each nodename (one, except for ironic) on the host:"},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"* Spin up a SchedulerReportClient with a `Direct Interface to Placement`_."},{"line_number":293,"context_line":"* Retrieve a ProviderTree via"},{"line_number":294,"context_line":"  ``SchedulerReportClient.get_provider_tree_and_ensure_root()``."},{"line_number":295,"context_line":"* Retrieve allocations via `get_allocations_for_provider_tree()`_."},{"line_number":296,"context_line":"* Instantiate the appropriate virt driver."},{"line_number":297,"context_line":"* Invoke that virt driver\u0027s `update_provider_tree()`_ method."},{"line_number":298,"context_line":"* If the `Return Value`_ is nonempty, invoke `update_from_provider_tree()`_."}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_55e51a37","line":295,"range":{"start_line":292,"start_character":2,"end_line":295,"end_character":66},"in_reply_to":"5f7c97a3_d2338061","updated":"2018-06-07 22:45:23.000000000","message":"YES","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c0ecedfc54b51c241a7c40c3a022e7d1c015fbaf","unresolved":false,"context_lines":[{"line_number":297,"context_line":"* Invoke that virt driver\u0027s `update_provider_tree()`_ method."},{"line_number":298,"context_line":"* If the `Return Value`_ is nonempty, invoke `update_from_provider_tree()`_."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Words from dansmith, like what the script will be called, what its args look"},{"line_number":301,"context_line":"like, who\u0027s supposed to invoke it and how and when."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_15520b13","line":300,"range":{"start_line":300,"start_character":0,"end_line":300,"end_character":19},"updated":"2018-06-11 15:29:08.000000000","message":"It\u0027ll be in nova-manage, and I guess it\u0027ll be under db, unless people want it under placement? I guess it\u0027s technically like heal_allocations, so maybe we do that.\n\n $ nova-manage placement update_compute_inventory\n\nThat\u0027d be okay right?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":297,"context_line":"* Invoke that virt driver\u0027s `update_provider_tree()`_ method."},{"line_number":298,"context_line":"* If the `Return Value`_ is nonempty, invoke `update_from_provider_tree()`_."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Words from dansmith, like what the script will be called, what its args look"},{"line_number":301,"context_line":"like, who\u0027s supposed to invoke it and how and when."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_127818f6","line":300,"updated":"2018-06-07 22:14:16.000000000","message":"We can also refer to https://review.openstack.org/#/c/501025/ as a kind of model for how this type offline upgrade which requires virt driver interaction would work.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":297,"context_line":"* Invoke that virt driver\u0027s `update_provider_tree()`_ method."},{"line_number":298,"context_line":"* If the `Return Value`_ is nonempty, invoke `update_from_provider_tree()`_."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Words from dansmith, like what the script will be called, what its args look"},{"line_number":301,"context_line":"like, who\u0027s supposed to invoke it and how and when."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_bdd1b559","line":300,"in_reply_to":"5f7c97a3_127818f6","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":297,"context_line":"* Invoke that virt driver\u0027s `update_provider_tree()`_ method."},{"line_number":298,"context_line":"* If the `Return Value`_ is nonempty, invoke `update_from_provider_tree()`_."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Words from dansmith, like what the script will be called, what its args look"},{"line_number":301,"context_line":"like, who\u0027s supposed to invoke it and how and when."},{"line_number":302,"context_line":""},{"line_number":303,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5dd98180","line":300,"range":{"start_line":300,"start_character":0,"end_line":300,"end_character":19},"in_reply_to":"5f7c97a3_15520b13","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6cc5874c6e0fa96a2cb00050444204284616a5ae","unresolved":false,"context_lines":[{"line_number":343,"context_line":"* Use ``wsgi-intercept`` but create the pythonic wrappers outside of the REST"},{"line_number":344,"context_line":"  layer. This is also a long-term option."},{"line_number":345,"context_line":""},{"line_number":346,"context_line":"Words from cdent, cause I\u0027m sure I made a hash of this too."},{"line_number":347,"context_line":""},{"line_number":348,"context_line":"Data model impact"},{"line_number":349,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_31509bd5","line":346,"updated":"2018-06-08 22:26:37.000000000","message":"Seems complete enough to me.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"d5d42100991e27873230a6689544b07e131ecffc","unresolved":false,"context_lines":[{"line_number":365,"context_line":"---------------------"},{"line_number":366,"context_line":"See `Upgrade Impact`_."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Performance Impact"},{"line_number":369,"context_line":"------------------"},{"line_number":370,"context_line":"The new `Placement POST /migrator`_ operation has the potential to be slow, and"},{"line_number":371,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_0e59f159","line":368,"updated":"2018-06-06 20:52:31.000000000","message":"I think there\u0027s also an impact that the update_provider_tree caller needs to go query allocations now.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b60631faa9851f536bbb163dd51f90b2507a0c66","unresolved":false,"context_lines":[{"line_number":365,"context_line":"---------------------"},{"line_number":366,"context_line":"See `Upgrade Impact`_."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Performance Impact"},{"line_number":369,"context_line":"------------------"},{"line_number":370,"context_line":"The new `Placement POST /migrator`_ operation has the potential to be slow, and"},{"line_number":371,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_9afbc979","line":368,"in_reply_to":"5f7c97a3_0e59f159","updated":"2018-06-08 21:05:45.000000000","message":"Agreed, thanks for bringing this up.  We\u0027re talking about it [1] and will update accordingly.\n\n[1] https://etherpad.openstack.org/p/reshape-provider-tree-performance","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":365,"context_line":"---------------------"},{"line_number":366,"context_line":"See `Upgrade Impact`_."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Performance Impact"},{"line_number":369,"context_line":"------------------"},{"line_number":370,"context_line":"The new `Placement POST /migrator`_ operation has the potential to be slow, and"},{"line_number":371,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_5d94218b","line":368,"in_reply_to":"5f7c97a3_9afbc979","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":379,"context_line":"----------------"},{"line_number":380,"context_line":"See `Virt Drivers`_."},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"Upgrade impact"},{"line_number":383,"context_line":"--------------"},{"line_number":384,"context_line":"Words from dansmith about FFU."},{"line_number":385,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_f2a0fc44","line":382,"updated":"2018-06-07 22:14:16.000000000","message":"I/we need to put some thought into how nova-status upgrade check could be leveraged here; I think the easy thing would be iterate root providers that have VGPU allocations and note that they need to get migrated (either offline or restarting nova-compute services with queens code). The hard part would be how do we tell the operators about this - would we just make it informational, like \"FYI you\u0027ve got these things in use so you\u0027re gonna have some work to do\" as a WARNING. If no VGPU resources used, then it\u0027s a SUCCESS? I\u0027m not sure in what case it could be a FAILURE, unless we did a compute service version check at the same time and noticed \"oh you\u0027ve got stein computes with VGPU resources on the root provider so you\u0027re upgrade isn\u0027t done\" - but knowing the stein version of the compute would be hard before rocky GA (we could always backport something later).","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":379,"context_line":"----------------"},{"line_number":380,"context_line":"See `Virt Drivers`_."},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"Upgrade impact"},{"line_number":383,"context_line":"--------------"},{"line_number":384,"context_line":"Words from dansmith about FFU."},{"line_number":385,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b5bfcefa","line":382,"in_reply_to":"5f7c97a3_f2a0fc44","updated":"2018-06-07 22:45:23.000000000","message":"I\u0027m concerned that you\u0027re thinking too specifically here.  The determination as to whether a migration is happening comes out of the virt driver as a result of logic we can\u0027t anticipate (or we wouldn\u0027t be implementing it this way).\n\nThe only safe thing is to always run the script.  I was under the impression that FFUers ran scripts anyway.  When no upgrade is happening, the script is a no-op - but it\u0027s also totally harmless.\n\nIs my perspective totally whack, yo?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"fc4c16fb2924186c81a3ca26cc08c09f9d2ba4f3","unresolved":false,"context_lines":[{"line_number":381,"context_line":""},{"line_number":382,"context_line":"Upgrade impact"},{"line_number":383,"context_line":"--------------"},{"line_number":384,"context_line":"Words from dansmith about FFU."},{"line_number":385,"context_line":""},{"line_number":386,"context_line":"Implementation"},{"line_number":387,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_cb4d2b3c","line":384,"range":{"start_line":384,"start_character":11,"end_line":384,"end_character":19},"updated":"2018-06-06 19:51:18.000000000","message":"/mriedem","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":381,"context_line":""},{"line_number":382,"context_line":"Upgrade impact"},{"line_number":383,"context_line":"--------------"},{"line_number":384,"context_line":"Words from dansmith about FFU."},{"line_number":385,"context_line":""},{"line_number":386,"context_line":"Implementation"},{"line_number":387,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_3a55ab50","line":384,"range":{"start_line":384,"start_character":11,"end_line":384,"end_character":19},"in_reply_to":"5f7c97a3_cb4d2b3c","updated":"2018-06-11 23:19:46.000000000","message":"I added words.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"fc4c16fb2924186c81a3ca26cc08c09f9d2ba4f3","unresolved":false,"context_lines":[{"line_number":389,"context_line":"Assignee(s)"},{"line_number":390,"context_line":"-----------"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"* `Placement POST /migrator`_: jaypipes"},{"line_number":393,"context_line":"* `Direct Interface to Placement`_: cdent"},{"line_number":394,"context_line":"* Report client, resource tracker, virt driver parity: efried"},{"line_number":395,"context_line":"* `Offline Upgrade Script`_: dansmith"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_ab522fdd","line":392,"range":{"start_line":392,"start_character":31,"end_line":392,"end_character":39},"updated":"2018-06-06 19:51:18.000000000","message":"and cdent?  https://etherpad.openstack.org/p/placement-making-the-(up)grade L145, not sure what \"REST API\" entails.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9cc4a8c374b6b770971dbe60edb7195227c2165f","unresolved":false,"context_lines":[{"line_number":389,"context_line":"Assignee(s)"},{"line_number":390,"context_line":"-----------"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"* `Placement POST /migrator`_: jaypipes"},{"line_number":393,"context_line":"* `Direct Interface to Placement`_: cdent"},{"line_number":394,"context_line":"* Report client, resource tracker, virt driver parity: efried"},{"line_number":395,"context_line":"* `Offline Upgrade Script`_: dansmith"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_c82adfe5","line":392,"range":{"start_line":392,"start_character":31,"end_line":392,"end_character":39},"in_reply_to":"5f7c97a3_ab522fdd","updated":"2018-06-08 14:37:21.000000000","message":"ack, I think I\u0027ll be focusing on the single DB transaction wrangling and cdent will be focusing on the API plumbing. At least, I think that\u0027s what we agreed to. Chris, does that meet your recollection?","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":389,"context_line":"Assignee(s)"},{"line_number":390,"context_line":"-----------"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"* `Placement POST /migrator`_: jaypipes"},{"line_number":393,"context_line":"* `Direct Interface to Placement`_: cdent"},{"line_number":394,"context_line":"* Report client, resource tracker, virt driver parity: efried"},{"line_number":395,"context_line":"* `Offline Upgrade Script`_: dansmith"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_7a09e381","line":392,"range":{"start_line":392,"start_character":31,"end_line":392,"end_character":39},"in_reply_to":"5f7c97a3_b10a6bce","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6cc5874c6e0fa96a2cb00050444204284616a5ae","unresolved":false,"context_lines":[{"line_number":389,"context_line":"Assignee(s)"},{"line_number":390,"context_line":"-----------"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"* `Placement POST /migrator`_: jaypipes"},{"line_number":393,"context_line":"* `Direct Interface to Placement`_: cdent"},{"line_number":394,"context_line":"* Report client, resource tracker, virt driver parity: efried"},{"line_number":395,"context_line":"* `Offline Upgrade Script`_: dansmith"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_b10a6bce","line":392,"range":{"start_line":392,"start_character":31,"end_line":392,"end_character":39},"in_reply_to":"5f7c97a3_c82adfe5","updated":"2018-06-08 22:26:37.000000000","message":"yup, that meets my recollection","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b5fedeb046611d06ea0b842de70a6100e492ca9c","unresolved":false,"context_lines":[{"line_number":393,"context_line":"* `Direct Interface to Placement`_: cdent"},{"line_number":394,"context_line":"* Report client, resource tracker, virt driver parity: efried"},{"line_number":395,"context_line":"* `Offline Upgrade Script`_: dansmith"},{"line_number":396,"context_line":"* Reviews and general heckling: mriedem, bauzas, gibi, edleafe"},{"line_number":397,"context_line":""},{"line_number":398,"context_line":"Work Items"},{"line_number":399,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_fbf223e3","line":396,"range":{"start_line":396,"start_character":0,"end_line":396,"end_character":62},"updated":"2018-06-07 14:16:16.000000000","message":"do we really need to write this ? :)","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"1990dc1c93b3925734a1fc249ae15bd04f3f91cb","unresolved":false,"context_lines":[{"line_number":393,"context_line":"* `Direct Interface to Placement`_: cdent"},{"line_number":394,"context_line":"* Report client, resource tracker, virt driver parity: efried"},{"line_number":395,"context_line":"* `Offline Upgrade Script`_: dansmith"},{"line_number":396,"context_line":"* Reviews and general heckling: mriedem, bauzas, gibi, edleafe"},{"line_number":397,"context_line":""},{"line_number":398,"context_line":"Work Items"},{"line_number":399,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_75b93613","line":396,"range":{"start_line":396,"start_character":0,"end_line":396,"end_character":62},"in_reply_to":"5f7c97a3_fbf223e3","updated":"2018-06-07 22:45:23.000000000","message":"Sorry, I was getting kinda punchy by this point.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"fc4c16fb2924186c81a3ca26cc08c09f9d2ba4f3","unresolved":false,"context_lines":[{"line_number":408,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":409,"context_line":"Functional test enhancements for everyone, including gabbi tests for `Placement"},{"line_number":410,"context_line":"POST /migrator`_."},{"line_number":411,"context_line":""},{"line_number":412,"context_line":"Documentation Impact"},{"line_number":413,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":414,"context_line":"* `Placement POST /migrator`_ (placement API reference)"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_eb710779","line":411,"updated":"2018-06-06 19:51:18.000000000","message":"Live test by xen (naichuans) and bauzas for their VGPU stuff.","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":408,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":409,"context_line":"Functional test enhancements for everyone, including gabbi tests for `Placement"},{"line_number":410,"context_line":"POST /migrator`_."},{"line_number":411,"context_line":""},{"line_number":412,"context_line":"Documentation Impact"},{"line_number":413,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":414,"context_line":"* `Placement POST /migrator`_ (placement API reference)"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_fa43b3ae","line":411,"in_reply_to":"5f7c97a3_eb710779","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e90e8ffc5c77d2b861407a991fb4179f923fe35e","unresolved":false,"context_lines":[{"line_number":412,"context_line":"Documentation Impact"},{"line_number":413,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":414,"context_line":"* `Placement POST /migrator`_ (placement API reference)"},{"line_number":415,"context_line":"* `Offline Upgrade Script`_ (dansmith?)"},{"line_number":416,"context_line":""},{"line_number":417,"context_line":"References"},{"line_number":418,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_12c6d817","line":415,"range":{"start_line":415,"start_character":29,"end_line":415,"end_character":37},"updated":"2018-06-07 22:14:16.000000000","message":"Yeah would get doc\u0027ed like here https://docs.openstack.org/nova/latest/cli/nova-manage.html#nova-database - see \"ironic_flavor_migration\"","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e7871bc30cd96cc872f737768a10ec5c977e9dcc","unresolved":false,"context_lines":[{"line_number":412,"context_line":"Documentation Impact"},{"line_number":413,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":414,"context_line":"* `Placement POST /migrator`_ (placement API reference)"},{"line_number":415,"context_line":"* `Offline Upgrade Script`_ (dansmith?)"},{"line_number":416,"context_line":""},{"line_number":417,"context_line":"References"},{"line_number":418,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f7c97a3_7a300356","line":415,"range":{"start_line":415,"start_character":29,"end_line":415,"end_character":37},"in_reply_to":"5f7c97a3_12c6d817","updated":"2018-06-11 23:19:46.000000000","message":"Done","commit_id":"99fa9f5d5f16314aaaca5bdeb63b90d1558d11be"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f5955f2d64871d480319c6a666409dd6101a4f8c","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the `Offline Upgrade Script`_."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Otherwise, the above flow is executed in the `Resource Tracker _update()`_"},{"line_number":89,"context_line":"method at every periodic task interval."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_6bccb333","line":89,"updated":"2018-06-12 01:03:31.000000000","message":"I predict this will be problematic for people with lots of compute hosts (CERN, etc). They will likely want to disable this behaviour and rely on an out-of-band execution of the \"migrator\" stuff only when needed.","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9b325ed2c166c31db2fc14618d78be6e2a136c72","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the `Offline Upgrade Script`_."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Otherwise, the above flow is executed in the `Resource Tracker _update()`_"},{"line_number":89,"context_line":"method at every periodic task interval."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_b12415b4","line":89,"in_reply_to":"5f7c97a3_0fabb487","updated":"2018-06-15 18:41:10.000000000","message":"I totally don\u0027t understand what you guys are talking about. Using /migrator to do dynamic resizing and hotplug? Why would we do that? Didn\u0027t we agree that /migrator is only to be used for pivot operations like going from flat to nested?\n\nA /migrator pivot must happen between leaving a version that didn\u0027t have NUMA nodes nested under the compute, and arriving at normal operation. The compute node must reshape the inventory and allocations all at once at that point, atomically, and that\u0027s the point of /migrator. You can collect all the data you want before you decide what your post to /migrator is going to be, but the migrator call either succeeds or it fails, and there shouldn\u0027t be any transformative operations before or after that related to the pivot. So, yeah, if POST /migrator fails, we have to abort startup I think, or go into a loop and keep retrying (if it\u0027s a retry-able failure).\n\nAssuming that is done, and we start running normally (doing our periodic sync, getting new instances, deleting instances as requested), at what point while running does it make sense that the compute node would need another large atomic pivot?","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b8aee7e2b8d5a9c85f5e335453fb7540f9a86ff7","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the `Offline Upgrade Script`_."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Otherwise, the above flow is executed in the `Resource Tracker _update()`_"},{"line_number":89,"context_line":"method at every periodic task interval."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_47bc3aba","line":89,"in_reply_to":"5f7c97a3_36c296ea","updated":"2018-06-12 15:36:59.000000000","message":"The former is what I take from this, and what I commented on the previous version about. Especially given your FFU exclusion above, this sounds like we\u0027ll consider the migration on every update. IMHO, L74 can *never* run in the periodic. If we do it at startup, then it shouldn\u0027t need to, but it needs to not be something that can happen in the periodic, IMHO. Even if that means we have to stop updating and start throwing errors.","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"36fd4c6768cec8d81d4c3dddc6d467a48b3d277d","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the `Offline Upgrade Script`_."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Otherwise, the above flow is executed in the `Resource Tracker _update()`_"},{"line_number":89,"context_line":"method at every periodic task interval."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_0fabb487","line":89,"in_reply_to":"5f7c97a3_471e7a70","updated":"2018-06-12 18:54:19.000000000","message":"If we\u0027re saying reshapes are only possible on startup, we need to figure out how we would handle (partial) failures.\n\nAs currently written, update_from_provider_tree (the method that flushes the changes back to placement) makes multiple API calls.  If one fails, it invalidates that RP\u0027s cache entry and continues trying to flush the rest of the changes.  At the end, if anything failed along the way, it raises ResourceProviderSyncFailed.  At the next periodic interval, the resource tracker repopulates the invalidated cache entries, reinvokes update_provider_tree, and tries the whole thing again.  The idea is that eventually, enough refreshes and retries will get things to the state they\u0027re supposed to be in.\n\nNow keep in mind that, even if we\u0027re using POST /migrator, the update_from_provider_tree flow is still not a single atomic transaction.  Outside of POST /migrator, we still have to perform separate calls for:\n\n- provider creations and deletions;\n- trait and aggregate changes;\n- depending how strict we are being about the use of POST /migrator, inventory changes that aren\u0027t related to the reshape.\n\nThe advantage of the current flow is that it\u0027s self-healing.  If we plumb things to only attempt reshapes on initial startup, and some piece fails, how do we recover from that?  I see a few options:\n\n- Blow up the compute service.\n- Retry some number of times (this will be trickier than just adding a @retrying) and then blow up the compute service.\n- Only consider it a hard failure if the POST /migrator call fails (whereupon we blow up the compute service).  Because the other pieces could still conceivably run as part of the normal periodic flow, and heal themselves that way.  (Note that this forces us to limit POST /migrator to only reshapes, which makes update_from_provider_tree harder to code, because we have to pick out which inventory changes are which.)\n\nMe, I\u0027m still advocating for leaving the existing (self-healing) flow in place.  Reshapes should be very rare anyway.  If we artificially limit them to occurring only on release boundaries and/or compute restarts, we can never use them for things like dynamic resizing, hot plugging, etc.\n\nIt\u0027s also easier/simpler to code :)","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"791b236a9f4648b45624786de3789ebcfe8c9692","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the `Offline Upgrade Script`_."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Otherwise, the above flow is executed in the `Resource Tracker _update()`_"},{"line_number":89,"context_line":"method at every periodic task interval."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_471e7a70","line":89,"in_reply_to":"5f7c97a3_47bc3aba","updated":"2018-06-12 15:52:04.000000000","message":"Responding to Dan: Does that mean that those environments (presumably like the ones that Eric and I might sometimes have in our vicinity) where hardware is separate from the host that nova-compute is running on, and may do dynamic management of the topology of parts of that hardware from structure A to structure B, must restart nova-compute to migrate allocations it?\n\nOr is that a thing that should never happen?","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"13d637c97f6fb23b98b757a48fd4f6d3ebc813df","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the `Offline Upgrade Script`_."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Otherwise, the above flow is executed in the `Resource Tracker _update()`_"},{"line_number":89,"context_line":"method at every periodic task interval."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_36c296ea","line":89,"in_reply_to":"5f7c97a3_6bccb333","updated":"2018-06-12 14:19:46.000000000","message":"\u003e I predict this will be problematic\n\nWhat \"this\", doing migrations live at all, or running the non-migration version of the flow on every interval?  The latter is the same as what we\u0027re doing today.","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"09607d8183f4c653fcf42f692f17f3819b17ad34","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the `Offline Upgrade Script`_."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Otherwise, the above flow is executed in the `Resource Tracker _update()`_"},{"line_number":89,"context_line":"method at every periodic task interval."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_d082d3a5","line":89,"in_reply_to":"5f7c97a3_b12415b4","updated":"2018-06-18 13:02:04.000000000","message":"I agree with Dan, we should be doing the atomic modification once when upgrading (by running it when restarting the compute service).\n\nI don\u0027t see why we should call it every 60 seconds once the compute is upgraded ?","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"fdb68f27d7703d09a2031ae28cc03bd33fd0920c","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the `Offline Upgrade Script`_."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Otherwise, the above flow is executed in the `Resource Tracker _update()`_"},{"line_number":89,"context_line":"method at every periodic task interval."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":".. _`get_allocations_for_provider_tree()`:"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_3d90b796","line":89,"in_reply_to":"5f7c97a3_d082d3a5","updated":"2018-06-18 17:26:53.000000000","message":"#agreed in the sched meeting [1] and #openstack-placement afterward [2]:\n\n- Resource tracker should only attempt/allow reshapes (via the try/except-and-gather-allocations-and-retry algorithm) on startup.\n- On startup, if we are attempting a migration and POST /migrator fails, blow up the compute service.\n- During periodic, if we get MigrationNeeded, log lots of red and carry on.  Don\u0027t blow up compute; and for now, don\u0027t disable it either.\n- Otherwise during periodic, carry on as we do today: if something goes wrong, invalidate cache, log, and let the next periodic heal things.\n- Thus, update_provider_tree doesn\u0027t need an extra flag to indicate startup; it can behave as noted here.  If it determines a reshape is needed, it raises MigrationNeeded, period.  It doesn\u0027t try to figure out whether or not to run that check - it just always runs it.  It\u0027s a cheap check.  The expensive parts (populating the provider tree and discovering the topology of the system) are already done regardless.  This is just comparing python objects.\n\n[1] http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-06-18-14.00.log.html#l-20\n[2] http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2018-06-18.log.html#t2018-06-18T15:02:39","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f5955f2d64871d480319c6a666409dd6101a4f8c","unresolved":false,"context_lines":[{"line_number":101,"context_line":"      :returns: A dict, keyed by consumer UUID, of allocation records."},{"line_number":102,"context_line":"      \"\"\""},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"A consumer isn\u0027t always an instance (it may be a \"migration\" - or other things"},{"line_number":105,"context_line":"not created by Nova, in the future), so we can\u0027t just use the instance list as"},{"line_number":106,"context_line":"the consumer list."},{"line_number":107,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_abef2b85","line":104,"range":{"start_line":104,"start_character":0,"end_line":104,"end_character":35},"updated":"2018-06-12 01:03:31.000000000","message":"An instance may not always consume everything, but when it does, it prefers Dos Equis.","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f5955f2d64871d480319c6a666409dd6101a4f8c","unresolved":false,"context_lines":[{"line_number":130,"context_line":"records. This is the form of the new `Allocations Parameter`_ expected by"},{"line_number":131,"context_line":"`update_provider_tree()`_ and `update_from_provider_tree()`_), and return it."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"MigrationNeeded exception"},{"line_number":134,"context_line":"-------------------------"},{"line_number":135,"context_line":"A new exception, ``MigrationNeeded`` will be introduced. It is used as a signal"},{"line_number":136,"context_line":"from `update_provider_tree()`_ to indicate that a migration must be performed."},{"line_number":137,"context_line":"This is for performance reasons so that we do not have to"},{"line_number":138,"context_line":"`get_allocations_for_provider_tree()`_ on every periodic task interval."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":".. _`update_provider_tree()`:"},{"line_number":141,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_8bea6f71","line":138,"range":{"start_line":133,"start_character":0,"end_line":138,"end_character":71},"updated":"2018-06-12 01:03:31.000000000","message":"ooh, I like this idea better than the previous proposed return value. ++","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"09607d8183f4c653fcf42f692f17f3819b17ad34","unresolved":false,"context_lines":[{"line_number":130,"context_line":"records. This is the form of the new `Allocations Parameter`_ expected by"},{"line_number":131,"context_line":"`update_provider_tree()`_ and `update_from_provider_tree()`_), and return it."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"MigrationNeeded exception"},{"line_number":134,"context_line":"-------------------------"},{"line_number":135,"context_line":"A new exception, ``MigrationNeeded`` will be introduced. It is used as a signal"},{"line_number":136,"context_line":"from `update_provider_tree()`_ to indicate that a migration must be performed."},{"line_number":137,"context_line":"This is for performance reasons so that we do not have to"},{"line_number":138,"context_line":"`get_allocations_for_provider_tree()`_ on every periodic task interval."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":".. _`update_provider_tree()`:"},{"line_number":141,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_f0b4af84","line":138,"range":{"start_line":133,"start_character":0,"end_line":138,"end_character":71},"in_reply_to":"5f7c97a3_8bea6f71","updated":"2018-06-18 13:02:04.000000000","message":"Yup, this. But then, we should be only have a exception once given the atomic call would migrate the allocations","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f5955f2d64871d480319c6a666409dd6101a4f8c","unresolved":false,"context_lines":[{"line_number":193,"context_line":"As virt drivers begin to model resources in nested providers, their"},{"line_number":194,"context_line":"implementations will need to:"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* determine whether a migration is necessary and raise ``MigrationNeeded`` as"},{"line_number":197,"context_line":"  appropriate;"},{"line_number":198,"context_line":"* perform the migration by processing provider inventories and the specified"},{"line_number":199,"context_line":"  allocations."},{"line_number":200,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_eb8d23d4","line":197,"range":{"start_line":196,"start_character":49,"end_line":197,"end_character":14},"updated":"2018-06-12 01:03:31.000000000","message":"the virt driver will need to raise MigrationNeeded only after in-place editing the allocations dict, right? Might be worth making that explicit, but not a blocker.","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"13d637c97f6fb23b98b757a48fd4f6d3ebc813df","unresolved":false,"context_lines":[{"line_number":193,"context_line":"As virt drivers begin to model resources in nested providers, their"},{"line_number":194,"context_line":"implementations will need to:"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* determine whether a migration is necessary and raise ``MigrationNeeded`` as"},{"line_number":197,"context_line":"  appropriate;"},{"line_number":198,"context_line":"* perform the migration by processing provider inventories and the specified"},{"line_number":199,"context_line":"  allocations."},{"line_number":200,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_164d1a99","line":197,"range":{"start_line":196,"start_character":49,"end_line":197,"end_character":14},"in_reply_to":"5f7c97a3_eb8d23d4","updated":"2018-06-12 14:19:46.000000000","message":"No, it raises MigrationNeeded if it detects a migration is needed but it received allocations\u003dNone.  See the RT flow (L234-241).","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f5955f2d64871d480319c6a666409dd6101a4f8c","unresolved":false,"context_lines":[{"line_number":307,"context_line":""},{"line_number":308,"context_line":"This implementation provides a quick solution to the immediate needs of offline"},{"line_number":309,"context_line":"use of `Placement POST /migrator`_ while allowing options for prettier"},{"line_number":310,"context_line":"solutions in the future."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Offline Upgrade Script"},{"line_number":313,"context_line":"----------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f7c97a3_0ba41f4a","line":310,"updated":"2018-06-12 01:03:31.000000000","message":"++ good addition from cdent.","commit_id":"e9d24a1a1c600dfe22d9996918a84bc0f1b17b5a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"81e643054d8deb41ddbc4d89df29622fe9a62ae6","unresolved":false,"context_lines":[{"line_number":258,"context_line":"      if startup:"},{"line_number":259,"context_line":"          # Kill the compute service."},{"line_number":260,"context_line":"          raise"},{"line_number":261,"context_line":"      # Else do the normal logging thing and carry on"},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"The purpose of this is to make exceptions in `update_from_provider_tree()`_"},{"line_number":264,"context_line":"fatal on startup only."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_266744ed","line":261,"range":{"start_line":261,"start_character":6,"end_line":261,"end_character":53},"updated":"2018-06-18 19:49:16.000000000","message":"We had also talked about handling ReshapeNeeded in _update_available_resource_for_node so that rather than trace, we\u0027d log an error but something relatively useful to the operator to explain what it means.\n\nFor example, let\u0027s say an operator was trying to fix something in the provider tree using the placement OSC CLIs and they goofed up something and the virt driver detects it and reports ReshapeNeeded during the update_available_resource periodic - the error in the compute logs could tell the operator to restart the compute service to get the tree back into the expected model. Having said this, we would lose that ability for all \u0027reshape\u0027 scenarios over time if we drop them each release, e.g. dropping the VGPU on root provider check in Stein. Maybe I shouldn\u0027t have said anything.","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"eacb0c7f5c54548fd217116e347b3b21478f6aaa","unresolved":false,"context_lines":[{"line_number":258,"context_line":"      if startup:"},{"line_number":259,"context_line":"          # Kill the compute service."},{"line_number":260,"context_line":"          raise"},{"line_number":261,"context_line":"      # Else do the normal logging thing and carry on"},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"The purpose of this is to make exceptions in `update_from_provider_tree()`_"},{"line_number":264,"context_line":"fatal on startup only."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_8c5af7ef","line":261,"range":{"start_line":261,"start_character":6,"end_line":261,"end_character":53},"in_reply_to":"5f7c97a3_266744ed","updated":"2018-06-18 21:08:36.000000000","message":"I\u0027ll add vague wording about logging something useful and relevant, but leave it at that.\n\nBut your \"out-of-band OSC snafu\" example is a great use case for the self-healing approach from PS7.  Basically the job of update_provider_tree is to check for any discrepancies between the provider_tree it\u0027s given and what it thinks it should look like.  If any of those discrepancies involve moving inventories, and allocations is None, raise ReshapeNeeded.  If we don\u0027t have to get specific about what those discrepancies can and can\u0027t look like, then we don\u0027t need to deprecate or remove anything in Stein or whatever, and we can just heal up.\n\nRealistically, though, I can see how it\u0027s going to be more difficult to implement such a general check versus specific ones like \"are my vgpus on the compute node RP?\"","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6f919eaf15cb0257eeaffba18ee54f70e82d50b9","unresolved":false,"context_lines":[{"line_number":258,"context_line":"      if startup:"},{"line_number":259,"context_line":"          # Kill the compute service."},{"line_number":260,"context_line":"          raise"},{"line_number":261,"context_line":"      # Else do the normal logging thing and carry on"},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"The purpose of this is to make exceptions in `update_from_provider_tree()`_"},{"line_number":264,"context_line":"fatal on startup only."}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_bf1112b2","line":261,"range":{"start_line":261,"start_character":6,"end_line":261,"end_character":53},"in_reply_to":"5f7c97a3_8c5af7ef","updated":"2018-06-19 03:10:29.000000000","message":"My point was more about handling ReshapeNeeded specifically in the compute manager code rather than the generic Exception with stacktrace. But that\u0027s an implementation detail we can iron out during code review.","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"81e643054d8deb41ddbc4d89df29622fe9a62ae6","unresolved":false,"context_lines":[{"line_number":338,"context_line":"this reshaping while all services (except databases) are offline. It will look"},{"line_number":339,"context_line":"like::"},{"line_number":340,"context_line":""},{"line_number":341,"context_line":"  nova-manage placement update_compute_inventory"},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"...and operate as follows, for each nodename (one, except for ironic) on the"},{"line_number":344,"context_line":"host:"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_a6e6f449","line":341,"range":{"start_line":341,"start_character":24,"end_line":341,"end_character":30},"updated":"2018-06-18 19:49:16.000000000","message":"nit: reshape might be more appropriate? or migrate_compute_inventory?","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"eacb0c7f5c54548fd217116e347b3b21478f6aaa","unresolved":false,"context_lines":[{"line_number":338,"context_line":"this reshaping while all services (except databases) are offline. It will look"},{"line_number":339,"context_line":"like::"},{"line_number":340,"context_line":""},{"line_number":341,"context_line":"  nova-manage placement update_compute_inventory"},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"...and operate as follows, for each nodename (one, except for ironic) on the"},{"line_number":344,"context_line":"host:"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_4cf13fde","line":341,"range":{"start_line":341,"start_character":24,"end_line":341,"end_character":30},"in_reply_to":"5f7c97a3_a6e6f449","updated":"2018-06-18 21:08:36.000000000","message":"Yuh, migrate_compute_inventory is probably the closest to accurate.","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"81e643054d8deb41ddbc4d89df29622fe9a62ae6","unresolved":false,"context_lines":[{"line_number":430,"context_line":"------------------"},{"line_number":431,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":432,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":433,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":434,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":435,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":436,"context_line":"very rare."},{"line_number":437,"context_line":""},{"line_number":438,"context_line":"Gathering allocations, particularly in large deployments, has the potential to"},{"line_number":439,"context_line":"be heavy and slow, so we only do this if `update_provider_tree()`_ indicates"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_860f38df","line":436,"range":{"start_line":433,"start_character":7,"end_line":436,"end_character":10},"updated":"2018-06-18 19:49:16.000000000","message":"Does this need to get updated? We should only be hitting POST /reshaper on compute service startup.","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"eacb0c7f5c54548fd217116e347b3b21478f6aaa","unresolved":false,"context_lines":[{"line_number":430,"context_line":"------------------"},{"line_number":431,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":432,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":433,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":434,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":435,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":436,"context_line":"very rare."},{"line_number":437,"context_line":""},{"line_number":438,"context_line":"Gathering allocations, particularly in large deployments, has the potential to"},{"line_number":439,"context_line":"be heavy and slow, so we only do this if `update_provider_tree()`_ indicates"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_ec184b1f","line":436,"range":{"start_line":433,"start_character":7,"end_line":436,"end_character":10},"in_reply_to":"5f7c97a3_860f38df","updated":"2018-06-18 21:08:36.000000000","message":"No, this is still appropriate.  POST /reshaper will be a convenient way to do the inventory shuffling step of update_from_provider_tree even when we\u0027re not migrating.  Otherwise we\u0027re duplicating the same logic but in multiple separate calls.  So I would rather see us use the single code path at least to start, and only do that duplication if the reshaper causes us actual problems.","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"81e643054d8deb41ddbc4d89df29622fe9a62ae6","unresolved":false,"context_lines":[{"line_number":436,"context_line":"very rare."},{"line_number":437,"context_line":""},{"line_number":438,"context_line":"Gathering allocations, particularly in large deployments, has the potential to"},{"line_number":439,"context_line":"be heavy and slow, so we only do this if `update_provider_tree()`_ indicates"},{"line_number":440,"context_line":"that a reshape is necessary."},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Other deployer impact"},{"line_number":443,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_26f664da","line":440,"range":{"start_line":439,"start_character":19,"end_line":440,"end_character":28},"updated":"2018-06-18 19:49:16.000000000","message":"and only on startup of the compute service.","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"eacb0c7f5c54548fd217116e347b3b21478f6aaa","unresolved":false,"context_lines":[{"line_number":436,"context_line":"very rare."},{"line_number":437,"context_line":""},{"line_number":438,"context_line":"Gathering allocations, particularly in large deployments, has the potential to"},{"line_number":439,"context_line":"be heavy and slow, so we only do this if `update_provider_tree()`_ indicates"},{"line_number":440,"context_line":"that a reshape is necessary."},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Other deployer impact"},{"line_number":443,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5f7c97a3_0c14a7e8","line":440,"range":{"start_line":439,"start_character":19,"end_line":440,"end_character":28},"in_reply_to":"5f7c97a3_26f664da","updated":"2018-06-18 21:08:36.000000000","message":"ack","commit_id":"0570320670a817da9fee618f8dc6df2beb4a39e3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fbcb8ae6f3f639996d8928bf5e8e0c1b7e56b69","unresolved":false,"context_lines":[{"line_number":129,"context_line":""},{"line_number":130,"context_line":"ReshapeNeeded exception"},{"line_number":131,"context_line":"-----------------------"},{"line_number":132,"context_line":"A new exception, ``ReshapeNeeded``, will be introduced. It is used as a signal"},{"line_number":133,"context_line":"from `update_provider_tree()`_ to indicate that a reshape must be performed."},{"line_number":134,"context_line":"This is for performance reasons so that we don\u0027t"},{"line_number":135,"context_line":"`get_allocations_for_provider_tree()`_ unless it\u0027s necessary."}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_74edd88c","line":132,"range":{"start_line":132,"start_character":19,"end_line":132,"end_character":32},"updated":"2018-06-19 09:43:32.000000000","message":"nit : reshape what ? I thought ReshapeInventoriesNeeded was a better exception name, but that\u0027s an implementation detail.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":129,"context_line":""},{"line_number":130,"context_line":"ReshapeNeeded exception"},{"line_number":131,"context_line":"-----------------------"},{"line_number":132,"context_line":"A new exception, ``ReshapeNeeded``, will be introduced. It is used as a signal"},{"line_number":133,"context_line":"from `update_provider_tree()`_ to indicate that a reshape must be performed."},{"line_number":134,"context_line":"This is for performance reasons so that we don\u0027t"},{"line_number":135,"context_line":"`get_allocations_for_provider_tree()`_ unless it\u0027s necessary."}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_6511a0af","line":132,"range":{"start_line":132,"start_character":19,"end_line":132,"end_character":32},"in_reply_to":"5f7c97a3_74edd88c","updated":"2018-06-19 12:45:30.000000000","message":"Reshape of the provider tree.  The inventories (and allocations) are being *moved*, or possibly \"migrated\".  We can spend some time bikeshedding the perfect name for this in the implementation, I suppose.  But in the end it\u0027s just a signal from virt to compute, so not worth losing sleep over.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"a073ac27d6f3436e7032678e2e5bdb6c8fa06891","unresolved":false,"context_lines":[{"line_number":150,"context_line":"If it decides a reshape is necessary, it must raise the new ``ReshapeNeeded``"},{"line_number":151,"context_line":"exception."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"When not ``None``, the ``allocations`` argument is a dict, keyed by consumer"},{"line_number":154,"context_line":"UUID, of allocation records of the form::"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"  { $CONSUMER_UUID: {"},{"line_number":157,"context_line":"        # NOTE: The shape of each \"allocations\" dict below is identical to the"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_9f0f76df","line":154,"range":{"start_line":153,"start_character":0,"end_line":154,"end_character":41},"updated":"2018-06-19 04:29:35.000000000","message":"Just to make sure... This can be an empty dict if there is no consumers/allocations on that host, so virt driver should be careful to distinguish None and empty dict not to raise the ReshapeNeeded exception if it gets empty dict for allocation dict, right?","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":150,"context_line":"If it decides a reshape is necessary, it must raise the new ``ReshapeNeeded``"},{"line_number":151,"context_line":"exception."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"When not ``None``, the ``allocations`` argument is a dict, keyed by consumer"},{"line_number":154,"context_line":"UUID, of allocation records of the form::"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"  { $CONSUMER_UUID: {"},{"line_number":157,"context_line":"        # NOTE: The shape of each \"allocations\" dict below is identical to the"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_852b9ce8","line":154,"range":{"start_line":153,"start_character":0,"end_line":154,"end_character":41},"in_reply_to":"5f7c97a3_9f0f76df","updated":"2018-06-19 12:45:30.000000000","message":"Yes, definitely.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"a073ac27d6f3436e7032678e2e5bdb6c8fa06891","unresolved":false,"context_lines":[{"line_number":218,"context_line":"      ..."},{"line_number":219,"context_line":"      \"\"\""},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"When ``allocations`` is ``None``, the behavior of"},{"line_number":222,"context_line":"``update_from_provider_tree()`` is as it was previously (in Queens)."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":".. _`Resource Tracker _update()`:"},{"line_number":225,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_95f0b7ff","line":222,"range":{"start_line":221,"start_character":34,"end_line":222,"end_character":68},"updated":"2018-06-19 04:29:35.000000000","message":"But it will be changed to POST /reshaper, so this can lead misreading, right?\n\nIt would be nice to add something like:\n\"using POST /reshaper with a body whose \"allocations\" filed has empty list. See Placement `POST /reshaper` for details\"","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":218,"context_line":"      ..."},{"line_number":219,"context_line":"      \"\"\""},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"When ``allocations`` is ``None``, the behavior of"},{"line_number":222,"context_line":"``update_from_provider_tree()`` is as it was previously (in Queens)."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":".. _`Resource Tracker _update()`:"},{"line_number":225,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_458344cc","line":222,"range":{"start_line":221,"start_character":34,"end_line":222,"end_character":68},"in_reply_to":"5f7c97a3_95f0b7ff","updated":"2018-06-19 12:45:30.000000000","message":"You are correct: we will change to POST /reshaper for at least the inventory bits (subject to the caveat in the Performance Impact section) - but the *behavior* (effect, end result) will be unchanged.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6f919eaf15cb0257eeaffba18ee54f70e82d50b9","unresolved":false,"context_lines":[{"line_number":258,"context_line":"      if startup:"},{"line_number":259,"context_line":"          # Kill the compute service."},{"line_number":260,"context_line":"          raise"},{"line_number":261,"context_line":"      # Else log a useful exception reporting what happened and maybe even how"},{"line_number":262,"context_line":"      # to fix it; and then carry on."},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"The purpose of this is to make exceptions in `update_from_provider_tree()`_"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_bf76f20b","line":261,"updated":"2018-06-19 03:10:29.000000000","message":"For others: from SP9 I think we want to also handle ReshapeNeeded specifically in the compute manager code that\u0027s calling the RT.update_available_resource and provide a useful error rather than the generic Exception handling and stacktrace that we have today, but it\u0027s an implementation detail.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":258,"context_line":"      if startup:"},{"line_number":259,"context_line":"          # Kill the compute service."},{"line_number":260,"context_line":"          raise"},{"line_number":261,"context_line":"      # Else log a useful exception reporting what happened and maybe even how"},{"line_number":262,"context_line":"      # to fix it; and then carry on."},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"The purpose of this is to make exceptions in `update_from_provider_tree()`_"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_802e2a40","line":261,"in_reply_to":"5f7c97a3_349c400d","updated":"2018-06-19 12:45:30.000000000","message":"I put up a WIP for this part of the flow yesterday [1].  I just added comments at [2] and [3] to refine according to this.\n\n[1] https://review.openstack.org/#/c/576236/\n[2] https://review.openstack.org/#/c/576236/1/nova/compute/resource_tracker.py@894\n[3] https://review.openstack.org/#/c/576236/1/nova/compute/manager.py@7362","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a18bca90ebd59a17cfa3c87efc193afd67207606","unresolved":false,"context_lines":[{"line_number":258,"context_line":"      if startup:"},{"line_number":259,"context_line":"          # Kill the compute service."},{"line_number":260,"context_line":"          raise"},{"line_number":261,"context_line":"      # Else log a useful exception reporting what happened and maybe even how"},{"line_number":262,"context_line":"      # to fix it; and then carry on."},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"The purpose of this is to make exceptions in `update_from_provider_tree()`_"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_f30ef93b","line":261,"in_reply_to":"5f7c97a3_802e2a40","updated":"2018-07-12 19:34:53.000000000","message":"Spec fup is here: https://review.openstack.org/#/c/582350/","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fbcb8ae6f3f639996d8928bf5e8e0c1b7e56b69","unresolved":false,"context_lines":[{"line_number":258,"context_line":"      if startup:"},{"line_number":259,"context_line":"          # Kill the compute service."},{"line_number":260,"context_line":"          raise"},{"line_number":261,"context_line":"      # Else log a useful exception reporting what happened and maybe even how"},{"line_number":262,"context_line":"      # to fix it; and then carry on."},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"The purpose of this is to make exceptions in `update_from_provider_tree()`_"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_349c400d","line":261,"in_reply_to":"5f7c97a3_bf76f20b","updated":"2018-06-19 09:43:32.000000000","message":"Agreed. Please provide a spec follow-up for it if needed.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"2bcf7ccbdb121e414814f3b1ac1843e1861e1dd2","unresolved":false,"context_lines":[{"line_number":308,"context_line":"Return values:"},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"* ``204 No Content`` on success."},{"line_number":311,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":312,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":313,"context_line":"  for at least the former so the caller can tell whether a fresh ``GET`` is"},{"line_number":314,"context_line":"  necessary before recalculating the necessary reshapes and retrying the"},{"line_number":315,"context_line":"  operation."},{"line_number":316,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"Direct Interface to Placement"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_6e4ae55b","line":315,"range":{"start_line":311,"start_character":0,"end_line":315,"end_character":12},"updated":"2018-06-19 08:17:28.000000000","message":"Assume we are in a n-cpu startup and reshap is needed. The virt driver calculates the new tree and the RT post it to placement, but placement returns a 409. Will we treat this as an error in the startup case and kill n-cpu and let pacemaker restart n-cpu to resolve the conflict?","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fd7f6f71156a21827dc6e91586516effe507aeb5","unresolved":false,"context_lines":[{"line_number":308,"context_line":"Return values:"},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"* ``204 No Content`` on success."},{"line_number":311,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":312,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":313,"context_line":"  for at least the former so the caller can tell whether a fresh ``GET`` is"},{"line_number":314,"context_line":"  necessary before recalculating the necessary reshapes and retrying the"},{"line_number":315,"context_line":"  operation."},{"line_number":316,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"Direct Interface to Placement"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_844fa2bc","line":315,"range":{"start_line":311,"start_character":0,"end_line":315,"end_character":12},"in_reply_to":"5f7c97a3_4099f26a","updated":"2018-07-09 08:59:43.000000000","message":"\u003e Yup, good question.  We shouldn\u0027t have to worry about this on FFU\n \u003e because everything is quiescent.  But on compute startup, we\u0027re\n \u003e probably cranking up any number of services at once, some of which\n \u003e could be mucking with placement at the same time.  I think we\u0027re\n \u003e *usually* safe because this compute should \"own\" the providers and\n \u003e consumers it\u0027s messing with.  But we should think through things\n \u003e like a) sharing providers (potentially \"co-owned\" by multiple\n \u003e computes); b) cyborg, which owns some of the resources (does it own\n \u003e the whole provider associated with those resources? how does that\n \u003e reshape flow work?); c) cases where some allocations for an\n \u003e instance are owned by entities outside of the compute host (can\n \u003e this happen? like can neutron own the IP/BW resource allocation for\n \u003e an instance?)\n \u003e \n \u003e I don\u0027t know what pacemaker is; but is the remedy to basically keep\n \u003e trying to start n-cpu until we win the race and everything smoothes\n \u003e out?\n\na) is a possible source of conflict if allocations on the shared RP needs to be changed during a reshape.\n\nI have not enough insight about cyborg to answer b)\n\nc) at least in case of BW the allocation is still owned by (created/deleted by) Nova according to the current plans. The RPs providing BW resources are owned by Neutron. So if that RP subtree needs to be reshaped in the future then we will have a situation when the change in RP structure is initiated by Neutron but the resulting change could potentially affect allocations that are owned by Nova. I\u0027m sure it will be fun to do this in the future... ;) ... but I would ignore this problem for now.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":308,"context_line":"Return values:"},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"* ``204 No Content`` on success."},{"line_number":311,"context_line":"* ``409 Conflict`` on any provider or consumer generation conflict; or if a"},{"line_number":312,"context_line":"  concurrent transaction is detected. Appropriate error codes should be used"},{"line_number":313,"context_line":"  for at least the former so the caller can tell whether a fresh ``GET`` is"},{"line_number":314,"context_line":"  necessary before recalculating the necessary reshapes and retrying the"},{"line_number":315,"context_line":"  operation."},{"line_number":316,"context_line":"* ``400 Bad Request`` on any other failure."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"Direct Interface to Placement"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_4099f26a","line":315,"range":{"start_line":311,"start_character":0,"end_line":315,"end_character":12},"in_reply_to":"5f7c97a3_6e4ae55b","updated":"2018-06-19 12:45:30.000000000","message":"Yup, good question.  We shouldn\u0027t have to worry about this on FFU because everything is quiescent.  But on compute startup, we\u0027re probably cranking up any number of services at once, some of which could be mucking with placement at the same time.  I think we\u0027re *usually* safe because this compute should \"own\" the providers and consumers it\u0027s messing with.  But we should think through things like a) sharing providers (potentially \"co-owned\" by multiple computes); b) cyborg, which owns some of the resources (does it own the whole provider associated with those resources? how does that reshape flow work?); c) cases where some allocations for an instance are owned by entities outside of the compute host (can this happen? like can neutron own the IP/BW resource allocation for an instance?)\n\nI don\u0027t know what pacemaker is; but is the remedy to basically keep trying to start n-cpu until we win the race and everything smoothes out?","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"2bcf7ccbdb121e414814f3b1ac1843e1861e1dd2","unresolved":false,"context_lines":[{"line_number":335,"context_line":""},{"line_number":336,"context_line":"Offline Upgrade Script"},{"line_number":337,"context_line":"----------------------"},{"line_number":338,"context_line":"To facilitate Fast Forward Upgrades, we will provide a script that can perform"},{"line_number":339,"context_line":"this reshaping while all services (except databases) are offline. It will look"},{"line_number":340,"context_line":"like::"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"  nova-manage placement migrate_compute_inventory"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_4e7e096b","line":339,"range":{"start_line":338,"start_character":67,"end_line":339,"end_character":65},"updated":"2018-06-19 08:17:28.000000000","message":"As we need to spin up the virt driver so we need whatever services the virt driver needs. Like in case of libvirt driver we need a running libvirt service to make this work.\n\nI think you need to be specific what services (I guess OpenStack services) can be offline and what needs to be online, e.g. db and hypervisor services.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":335,"context_line":""},{"line_number":336,"context_line":"Offline Upgrade Script"},{"line_number":337,"context_line":"----------------------"},{"line_number":338,"context_line":"To facilitate Fast Forward Upgrades, we will provide a script that can perform"},{"line_number":339,"context_line":"this reshaping while all services (except databases) are offline. It will look"},{"line_number":340,"context_line":"like::"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"  nova-manage placement migrate_compute_inventory"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_c040a2a5","line":339,"range":{"start_line":338,"start_character":67,"end_line":339,"end_character":65},"in_reply_to":"5f7c97a3_4e7e096b","updated":"2018-06-19 12:45:30.000000000","message":"Yeah, good point.  I know the PowerVM driver is going to need to be able to talk to the NovaLink REST service in order to figure out topology and allocations.  Is that allowable in a FFU scenario?\n\nAnd of course if we\u0027re FFUing OpenStack, we\u0027re probably also upgrading the helper services, so there would have to be some kind of documented lockstep of [upgrade helper, upgrade openstack, start helper, run upgrade script, stop helper]...","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fd7f6f71156a21827dc6e91586516effe507aeb5","unresolved":false,"context_lines":[{"line_number":335,"context_line":""},{"line_number":336,"context_line":"Offline Upgrade Script"},{"line_number":337,"context_line":"----------------------"},{"line_number":338,"context_line":"To facilitate Fast Forward Upgrades, we will provide a script that can perform"},{"line_number":339,"context_line":"this reshaping while all services (except databases) are offline. It will look"},{"line_number":340,"context_line":"like::"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"  nova-manage placement migrate_compute_inventory"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_84d482bc","line":339,"range":{"start_line":338,"start_character":67,"end_line":339,"end_character":65},"in_reply_to":"5f7c97a3_c040a2a5","updated":"2018-07-09 08:59:43.000000000","message":"Your lockstep procedure seems to me the way forward here.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"2bcf7ccbdb121e414814f3b1ac1843e1861e1dd2","unresolved":false,"context_lines":[{"line_number":429,"context_line":""},{"line_number":430,"context_line":"Performance Impact"},{"line_number":431,"context_line":"------------------"},{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_0ef1f1de","line":433,"range":{"start_line":432,"start_character":70,"end_line":433,"end_character":22},"updated":"2018-06-19 08:17:28.000000000","message":"Does it mean that running the reshaping (offline, or by simply starting the new n-cpu service) in parallel on multiple compute nodes could potentially lead to rejected db transactions in placement causing failed data migrations (e.g. fail n-cpu service startups) that needs to be retried later? If there is such a potential scaling problem then we have to tell this in the upgrade instructions to the deployers so they can do the n-cpu restart is small enough batches or even in sequence.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":429,"context_line":""},{"line_number":430,"context_line":"Performance Impact"},{"line_number":431,"context_line":"------------------"},{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_c0dc22e3","line":433,"range":{"start_line":432,"start_character":70,"end_line":433,"end_character":22},"in_reply_to":"5f7c97a3_0ef1f1de","updated":"2018-06-19 12:45:30.000000000","message":"That *shouldn\u0027t* be the case, because each compute\u0027s process ought to be restricted to its own set of providers, so the transactions shouldn\u0027t overlap.\n\nHowever, we need to consider and be careful as noted above about scenarios where there *is* overlap.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"e28c2caa5120bc86c2de81e7ae218aafd0cfd228","unresolved":false,"context_lines":[{"line_number":429,"context_line":""},{"line_number":430,"context_line":"Performance Impact"},{"line_number":431,"context_line":"------------------"},{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_c6fd8c08","line":433,"range":{"start_line":432,"start_character":70,"end_line":433,"end_character":22},"in_reply_to":"5f7c97a3_84ab221c","updated":"2018-07-10 00:32:03.000000000","message":"\u003e lock rows in several tables,\n\nThis ^\n\n \u003e those rows will never overlap?\n\nNot necessarily this ^\n\nConsider needing to reshape sharing providers...","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fd7f6f71156a21827dc6e91586516effe507aeb5","unresolved":false,"context_lines":[{"line_number":429,"context_line":""},{"line_number":430,"context_line":"Performance Impact"},{"line_number":431,"context_line":"------------------"},{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_84ab221c","line":433,"range":{"start_line":432,"start_character":70,"end_line":433,"end_character":22},"in_reply_to":"5f7c97a3_c0dc22e3","updated":"2018-07-09 08:59:43.000000000","message":"So when you say \u0027lock several tables\u0027 do you only mean lock rows in several tables, but those rows will never overlap?","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"7baba9318b773e33cd44b94914ee7a8232ee4aaa","unresolved":false,"context_lines":[{"line_number":431,"context_line":"------------------"},{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":437,"context_line":"very rare."},{"line_number":438,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_05df8c38","line":435,"range":{"start_line":434,"start_character":7,"end_line":435,"end_character":37},"updated":"2018-06-19 11:29:05.000000000","message":"a) why?\nb) let\u0027s not?\n\n/reshaper is weird in many ways, in terms of what it means as a \"resource\" on the API. Normal stuff should do normal things.\n\nWe like to imagine that making single requests is more performant, but (as I\u0027ve said before) on the server-side, having multiple smaller requests is better for a system that is designed (and expected) to be used in a horizontally scalable way. It makes interleaving requests from many services easier and less blocking.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":431,"context_line":"------------------"},{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":437,"context_line":"very rare."},{"line_number":438,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_20b5d67e","line":435,"range":{"start_line":434,"start_character":7,"end_line":435,"end_character":37},"in_reply_to":"5f7c97a3_05df8c38","updated":"2018-06-19 12:45:30.000000000","message":"See my reasoning at [1].  There\u0027s also just generally something to be said for doing all inventory updates in a single transaction (which is what this would entail in a non-reshape scenario).  Otherwise partial failures (or even races) could lead to some weird inventories, which could lead to some weird/invalid allocations getting scheduled.\n\nWhat do others think?\n\n[1] https://review.openstack.org/#/c/572583/9/specs/rocky/approved/reshape-provider-tree.rst@436","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f2dcb8e161533816d06ee97e680fa10bf376bff1","unresolved":false,"context_lines":[{"line_number":431,"context_line":"------------------"},{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":437,"context_line":"very rare."},{"line_number":438,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_d4bce707","line":435,"range":{"start_line":434,"start_character":7,"end_line":435,"end_character":37},"in_reply_to":"5f7c97a3_20b5d67e","updated":"2018-06-19 13:00:18.000000000","message":"As I said below, I think in general that big locks are a bad idea and am thinking along the same lines as Chris here.\n\n\u003e Otherwise partial failures (or even races) could lead to some weird inventories, which could lead to some weird/invalid allocations getting scheduled.\n\nHow is that possible when we have generations?","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ab389d62312dac823c3914110a6ef7f342794e0a","unresolved":false,"context_lines":[{"line_number":431,"context_line":"------------------"},{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":437,"context_line":"very rare."},{"line_number":438,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_aa630019","line":435,"range":{"start_line":434,"start_character":7,"end_line":435,"end_character":37},"in_reply_to":"5f7c97a3_d4bce707","updated":"2018-06-19 14:37:27.000000000","message":"\u003e How is that possible when we have generations?\n\nGenerations don\u0027t really have anything to do with it, other than providing one of the ways to get a partial failure.\n\nufpt: twiddle inventory on rp1 \u003d\u003e ok\nufpt: twiddle inventory on rp2 \u003d\u003e fail (e.g. gen conflict)\n...\nsched: GET /a_c \u003d\u003e weirdness\nsched: allocate \u003d\u003e weirdness\n\nOh, by races I meant between update_from_provider_tree and the scheduler.\n\nufpt: twiddle inventory on rp1\nsched: GET /a_c\nsched: allocate\nufpt: twiddle inventory on rp2","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6f919eaf15cb0257eeaffba18ee54f70e82d50b9","unresolved":false,"context_lines":[{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":437,"context_line":"very rare."},{"line_number":438,"context_line":""},{"line_number":439,"context_line":"Gathering allocations, particularly in large deployments, has the potential to"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_3f53c26e","line":436,"range":{"start_line":435,"start_character":39,"end_line":436,"end_character":15},"updated":"2018-06-19 03:10:29.000000000","message":"My guess is we won\u0027t likely do any performance testing at scale with this to know the difference, it will likely come down to CERN having to tell us once they hit this code and have issues (if there would be issues). I generally wouldn\u0027t like anything with a big lock on a bunch of tables (I think about the DB quota driver with the reservations table lock that the Huawei public cloud ops team always complained about to me). Or the COMPUTE_RESOURCE_SEMAPHORE lock in the ResourceTracker for that matter.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fbcb8ae6f3f639996d8928bf5e8e0c1b7e56b69","unresolved":false,"context_lines":[{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":437,"context_line":"very rare."},{"line_number":438,"context_line":""},{"line_number":439,"context_line":"Gathering allocations, particularly in large deployments, has the potential to"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_f4aec82d","line":436,"range":{"start_line":435,"start_character":39,"end_line":436,"end_character":15},"in_reply_to":"5f7c97a3_3f53c26e","updated":"2018-06-19 09:43:32.000000000","message":"We will see when implementing the changes.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"f6e6d732eb48b238b1ac4887c219ce2cdba95bb8","unresolved":false,"context_lines":[{"line_number":432,"context_line":"The new `Placement POST /reshaper`_ operation has the potential to be slow, and"},{"line_number":433,"context_line":"to lock several tables. Its use should be restricted to reshaping provider"},{"line_number":434,"context_line":"trees. Initially we may use the reshaper from `update_from_provider_tree()`_"},{"line_number":435,"context_line":"even if no reshape is being performed; but if this is found to be problematic"},{"line_number":436,"context_line":"for performance, we can restrict it to only reshape scenarios, which will be"},{"line_number":437,"context_line":"very rare."},{"line_number":438,"context_line":""},{"line_number":439,"context_line":"Gathering allocations, particularly in large deployments, has the potential to"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5f7c97a3_e0211eb7","line":436,"range":{"start_line":435,"start_character":39,"end_line":436,"end_character":15},"in_reply_to":"5f7c97a3_f4aec82d","updated":"2018-06-19 12:45:30.000000000","message":"We\u0027re probably overanticipating the performance difference between POST /reshaper and piecemeal updates for any reasonable real-world flow.  Non-reshape inventory changes should happen rarely, and when they do, they\u0027re likely to involve one or two resources on one or two providers.","commit_id":"c45fd3c7b7e63fabb58d3ec861aed35c27519542"}],"test-requirements.txt":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"859ea0dbf0d5c3946a8da8602ac3e5dd8118e778","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":"hacking\u003e\u003d0.12.0,!\u003d0.13.0,\u003c0.14  # Apache-2.0"},{"line_number":6,"context_line":"oslo.utils\u003e\u003d3.33.0 # Apache-2.0"},{"line_number":7,"context_line":"sphinxcontrib-seqdiag\u003e\u003d0.8.4 # BSD"},{"line_number":8,"context_line":"testrepository\u003e\u003d0.0.18 # Apache-2.0/BSD"},{"line_number":9,"context_line":"testtools\u003e\u003d1.4.0 # MIT"}],"source_content_type":"text/plain","patch_set":4,"id":"5f7c97a3_8b441476","line":7,"updated":"2018-06-06 19:32:51.000000000","message":"Shouldn\u0027t this be in doc/requirements.txt now?","commit_id":"ba19de528073962ae85a9db04fe0a876386656ab"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"65734f523ad1d17dfda5402c0f6a91369005830f","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":"hacking\u003e\u003d0.12.0,!\u003d0.13.0,\u003c0.14  # Apache-2.0"},{"line_number":6,"context_line":"oslo.utils\u003e\u003d3.33.0 # Apache-2.0"},{"line_number":7,"context_line":"sphinxcontrib-seqdiag\u003e\u003d0.8.4 # BSD"},{"line_number":8,"context_line":"testrepository\u003e\u003d0.0.18 # Apache-2.0/BSD"},{"line_number":9,"context_line":"testtools\u003e\u003d1.4.0 # MIT"}],"source_content_type":"text/plain","patch_set":4,"id":"5f7c97a3_4b235cbf","line":7,"in_reply_to":"5f7c97a3_8b441476","updated":"2018-06-06 19:34:15.000000000","message":"I didn\u0027t know that was a thing.  That\u0027s probably why the sphinx job was failing (I can never decipher those job-output thingies).  Will move, thanks.","commit_id":"ba19de528073962ae85a9db04fe0a876386656ab"}]}