)]}'
{"specs/stein/approved/alloc-candidates-in-tree.rst":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2b6552fb9b577b80bc526a14c3e243d9fcb32afa","unresolved":false,"context_lines":[{"line_number":88,"context_line":"      | +------------+ +-----------+ |   | +-----------+ +-----------+ |"},{"line_number":89,"context_line":"      +------------------------------+   +-----------------------------+"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"for example::"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"    GET /allocation_candidates?resources\u003dVCPU:1,DISK_GB:50\u0026in_tree\u003d{cn1_uuid}"},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_9c4d8873","line":91,"updated":"2019-02-28 21:29:14.000000000","message":"This use case could be called, \"force host, local disk\".","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2b6552fb9b577b80bc526a14c3e243d9fcb32afa","unresolved":false,"context_lines":[{"line_number":101,"context_line":""},{"line_number":102,"context_line":"The specified tree can be a non-root provider::"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"    GET /allocation_candidates?resources\u003dVCPU:1,DISK_GB:50\u0026in_tree\u003d{numa1_1_uuid}"},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"will return the same result."},{"line_number":107,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_bc796c93","line":104,"updated":"2019-02-28 21:29:14.000000000","message":"\"resize my instance that has local disk (but note that this will *not* restrict my VCPU to numa1_1 - see Alternative 2)\"","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6a368ba6aa0685e36c25143001760f08b2aea466","unresolved":false,"context_lines":[{"line_number":108,"context_line":"result B::"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"    1. numa1_1 (VCPU) + cn1 (DISK_GB)"},{"line_number":111,"context_line":"    2. numa1_2 (VCPU) + cn1 (DISK_GB)"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"When you want to have ``VCPU`` from ``cn1`` and ``DISK_GB`` from wherever,"},{"line_number":114,"context_line":"the request may look like::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_fc25b4bf","line":111,"updated":"2019-02-28 22:13:55.000000000","message":"This seems unexpected. Why would I get back a sibling if I said \u0027in_tree\u003d{numa1_1_uuid}\u0027? I guess it must mean \"in the same tree that I\u0027m in\" and not a subtree.","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"245a42c12ffb5139089b54dc877c8cc4ead49fbd","unresolved":false,"context_lines":[{"line_number":108,"context_line":"result B::"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"    1. numa1_1 (VCPU) + cn1 (DISK_GB)"},{"line_number":111,"context_line":"    2. numa1_2 (VCPU) + cn1 (DISK_GB)"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"When you want to have ``VCPU`` from ``cn1`` and ``DISK_GB`` from wherever,"},{"line_number":114,"context_line":"the request may look like::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_107390ea","line":111,"in_reply_to":"9fdfeff1_350eef31","updated":"2019-03-04 10:09:04.000000000","message":"Yes, at least in ``GET /resource_providers`` \"in_tree\" is \"in the same tree that I\u0027m in\" and not a subtree, and I think it should symmetrically be reflected to ``GET /allocation_candidates``.\n\nGibi has proposed the subtree feature in ``GET /resource_providers``  in https://review.openstack.org/#/c/595236/. The spec has not addressed ``GET /allocation_candidates`` API so far, but technically we can add the same ``subtree`` queryparam in ``GET /allocation_candidates``. (just started PoC in https://review.openstack.org/#/c/636092/)\n\nI don\u0027t want ``in_tree`` in ``GET /allocation_candidates`` to behave like ``sub_tree`` in ``GET /resource_providers``, which is being proposed and not implemented yet.\n\nUsing different terminology makes this complex feature more complex :(","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9968c7519146271e490a4a01b429139a57e8b48a","unresolved":false,"context_lines":[{"line_number":108,"context_line":"result B::"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"    1. numa1_1 (VCPU) + cn1 (DISK_GB)"},{"line_number":111,"context_line":"    2. numa1_2 (VCPU) + cn1 (DISK_GB)"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"When you want to have ``VCPU`` from ``cn1`` and ``DISK_GB`` from wherever,"},{"line_number":114,"context_line":"the request may look like::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_350eef31","line":111,"in_reply_to":"9fdfeff1_fc25b4bf","updated":"2019-03-01 00:11:03.000000000","message":"Right, see explanation in Alternative 2. Agree this is counterintuitive at a glance, but aligns with the meaning of \"in_tree\" as designed, and as already implemented on GET /resource_providers.","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2b6552fb9b577b80bc526a14c3e243d9fcb32afa","unresolved":false,"context_lines":[{"line_number":110,"context_line":"    1. numa1_1 (VCPU) + cn1 (DISK_GB)"},{"line_number":111,"context_line":"    2. numa1_2 (VCPU) + cn1 (DISK_GB)"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"When you want to have ``VCPU`` from ``cn1`` and ``DISK_GB`` from wherever,"},{"line_number":114,"context_line":"the request may look like::"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    GET /allocation_candidates?resources\u003dVCPU:1\u0026in_tree\u003d{cn1_uuid}"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_fc5a941b","line":113,"updated":"2019-02-28 21:29:14.000000000","message":"\"force host, don\u0027t care where my disk comes from\"","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2b6552fb9b577b80bc526a14c3e243d9fcb32afa","unresolved":false,"context_lines":[{"line_number":128,"context_line":"    6. numa1_2 (VCPU) + ss2 (DISK_GB)"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"When you want to have ``VCPU`` from wherever and ``DISK_GB`` from ``ss1``,"},{"line_number":131,"context_line":"the request may look like::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"    GET: /allocation_candidates?resources\u003dVCPU:1"},{"line_number":134,"context_line":"                               \u0026resources1\u003dDISK_GB:10\u0026in_tree1\u003d{ss1_uuid}"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_7ca46407","line":131,"updated":"2019-02-28 21:29:14.000000000","message":"\"migrate/evacuate/etc. my instance to another compute node where I can keep the same shared disk (but note that a subset of the old resize-to-same-host-doubling-snafu applies)\"","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"f380acf3d2378f3cea46eaedf6038683e62882ff","unresolved":false,"context_lines":[{"line_number":131,"context_line":"the request may look like::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"    GET: /allocation_candidates?resources\u003dVCPU:1"},{"line_number":134,"context_line":"                               \u0026resources1\u003dDISK_GB:10\u0026in_tree1\u003d{ss1_uuid}"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"which will stick to the first sharing provider for DISK_GB."},{"line_number":137,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_fed61b27","line":134,"updated":"2019-02-28 11:20:54.000000000","message":"While I agree that we need to define how this behavior needs to work when these requests happen, I think we need to be very careful about something.\n\nIn a usual cloud situation, what is the use case where:\n\n* we know we want to choose a specific disk\n* we know the uuid of that provider\n\n?\n\nThe entire concept of in_tree assumes we have access to uuids which much of the time is not something anybody should know, for two reasons:\n\n* It\u0027s a pain in the ass keeping track of that info\n* It\u0027s not very cloudy\n\nSo in addition to describing how things work, we need to make sure that we document the _why_ people might like to that, why they maybe shouldn\u0027t, most of the time, and the assumptions their tooling needs to make in order to be able to take advantage of it.\n\nGenerally speaking, I think that any /allocation_candidates or /resource_providers list request that includes an identifier in it (that is the uuid of a resource provider or an aggregate) we need to think really hard about where that information is coming from and the burden it imposes upon the tooling.\n\nThere are very definitely situations where those sorts of things need to happen, but they should always be thought of as a bit weird and deserving of special care and feeding.","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"9919af15c677bde2b1a6044e8dd81f78c9922974","unresolved":false,"context_lines":[{"line_number":131,"context_line":"the request may look like::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"    GET: /allocation_candidates?resources\u003dVCPU:1"},{"line_number":134,"context_line":"                               \u0026resources1\u003dDISK_GB:10\u0026in_tree1\u003d{ss1_uuid}"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"which will stick to the first sharing provider for DISK_GB."},{"line_number":137,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_92a3439e","line":134,"in_reply_to":"9fdfeff1_1285135a","updated":"2019-02-28 12:01:24.000000000","message":"I wasn\u0027t being rhetorical, so thanks for answering, those are the sorts of things that ought to go into the grand \"how do I use the complicated stuff properly\" docs that ought to evolve, someday.\n\nBut, to keep pushing my point a bit:\n\n* migrations and resizes in a _cloud_ ought to be exceptional (even thought they are not), so those uses map to my \"a bit weird\" and \"special care\" (especially given how much pain and suffering so many nova devs have gone through over the years to try and make the various resize/migration actions work across all the many edges)\n* While the operator doesn\u0027t need to know about the uuids, the fact that nova does need to track them (despite it being not a problem in the nova case, I agree) is an obligation that should be made very clear to any potential client (whatever that might be) that wants to use these features.\n\nI\u0027m by no means trying to suggest that we don\u0027t have these kinds of features, just trying to emphasize that they are a considerable challenge to comprehend and make use of properly and we need to be conscious of that.","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2b6552fb9b577b80bc526a14c3e243d9fcb32afa","unresolved":false,"context_lines":[{"line_number":131,"context_line":"the request may look like::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"    GET: /allocation_candidates?resources\u003dVCPU:1"},{"line_number":134,"context_line":"                               \u0026resources1\u003dDISK_GB:10\u0026in_tree1\u003d{ss1_uuid}"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"which will stick to the first sharing provider for DISK_GB."},{"line_number":137,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_9ce9081b","line":134,"in_reply_to":"9fdfeff1_92a3439e","updated":"2019-02-28 21:29:14.000000000","message":"I can dig it. I\u0027ve thrown some one-line suggestions with which we can tag the examples, here and/or in a contributor doc we generate out of this.","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6a368ba6aa0685e36c25143001760f08b2aea466","unresolved":false,"context_lines":[{"line_number":131,"context_line":"the request may look like::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"    GET: /allocation_candidates?resources\u003dVCPU:1"},{"line_number":134,"context_line":"                               \u0026resources1\u003dDISK_GB:10\u0026in_tree1\u003d{ss1_uuid}"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"which will stick to the first sharing provider for DISK_GB."},{"line_number":137,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_bc4f2c90","line":134,"in_reply_to":"9fdfeff1_9ce9081b","updated":"2019-02-28 22:13:55.000000000","message":"I\u0027m afraid I don\u0027t understand the role of the \u0027in_tree1\u0027 query param in this example. I see that because of the \u0027{ss1_uuid}\u0027 parameter, we only get back candidates from ss1, but what did \u0027in_tree1\u0027 do? It looks like it included \u0027numa2_1\u0027 and \u0027numa2_2\u0027. What would \u0027in_tree\u003d{ss1_uuid}\u0027 have returned, without the \u003cN\u003e specified?","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9968c7519146271e490a4a01b429139a57e8b48a","unresolved":false,"context_lines":[{"line_number":131,"context_line":"the request may look like::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"    GET: /allocation_candidates?resources\u003dVCPU:1"},{"line_number":134,"context_line":"                               \u0026resources1\u003dDISK_GB:10\u0026in_tree1\u003d{ss1_uuid}"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"which will stick to the first sharing provider for DISK_GB."},{"line_number":137,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_d55f630c","line":134,"in_reply_to":"9fdfeff1_bc4f2c90","updated":"2019-03-01 00:11:03.000000000","message":"\u003e I\u0027m afraid I don\u0027t understand the role of the \u0027in_tree1\u0027 query\n \u003e param in this example.\n\nIt locks in the DISK_GB resource, requested in the granular group numbered \u00271\u0027, to coming from the tree of the provider specified by the in_tree parameter from the same granular group.\n\n \u003e I see that because of the \u0027{ss1_uuid}\u0027\n \u003e parameter, we only get back candidates from ss1,\n\nOnly because in_tree*1* matches up with resources*1*\n\n \u003e but what did\n \u003e \u0027in_tree1\u0027 do? It looks like it included \u0027numa2_1\u0027 and \u0027numa2_2\u0027.\n\nNo, those came at the behest of \u0027resources\u003dVCPU:1\u0027 - the unnumbered request group, which had no in_tree specified, meaning \"I don\u0027t care where these come from\".\n\n \u003e What would \u0027in_tree\u003d{ss1_uuid}\u0027 have returned, without the \u003cN\u003e\n \u003e specified?\n\nEmpty list, because there are no VCPU resources in the tree of ss1.","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a12a9b67a3171a7f7d3ec6e5f27d5b7588bdb645","unresolved":false,"context_lines":[{"line_number":131,"context_line":"the request may look like::"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"    GET: /allocation_candidates?resources\u003dVCPU:1"},{"line_number":134,"context_line":"                               \u0026resources1\u003dDISK_GB:10\u0026in_tree1\u003d{ss1_uuid}"},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"which will stick to the first sharing provider for DISK_GB."},{"line_number":137,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_1285135a","line":134,"in_reply_to":"9fdfeff1_fed61b27","updated":"2019-02-28 11:49:04.000000000","message":"\u003e In a usual cloud situation, what is the use case where:\n \u003e \n \u003e * we know we want to choose a specific disk\n \u003e * we know the uuid of that provider\n\nPossibly you were being rhetorical here, but I\u0027ll answer anyway. Two nova-centric examples that come to mind are:\n\n- Resize (give me more CPU, but don\u0027t move my pci devices; increase the size of my shared disk without changing where it comes from, so I don\u0027t need to migrate the data; etc)\n- Migrate (live, cold, evacuate...) but don\u0027t move my shared disk.\n\nThe *operator* doesn\u0027t need to know about the uuids, and they\u0027re not a problem for nova to track.","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2b6552fb9b577b80bc526a14c3e243d9fcb32afa","unresolved":false,"context_lines":[{"line_number":143,"context_line":"    4. numa2_2 (VCPU) + ss1 (DISK_GB)"},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"When you want to have ``VCPU`` from ``cn1`` and ``DISK_GB`` from ``ss1``,"},{"line_number":146,"context_line":"the request may look like::"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"    GET: /allocation_candidates?resources1\u003dVCPU:1\u0026in_tree1\u003d{cn1_uuid}"},{"line_number":149,"context_line":"                               \u0026resources2\u003dDISK_GB:10\u0026in_tree2\u003d{ss1_uuid}"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_5c7ac076","line":146,"updated":"2019-02-28 21:29:14.000000000","message":"\"resize to same host (snafu)\"","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2b6552fb9b577b80bc526a14c3e243d9fcb32afa","unresolved":false,"context_lines":[{"line_number":184,"context_line":"In result B, we could exclude ``numa1_2`` resource provider (the second"},{"line_number":185,"context_line":"candidate), but we don\u0027t take this way for the following reason:"},{"line_number":186,"context_line":"It is not consistent with the existing ``in_tree`` behavior in"},{"line_number":187,"context_line":"``GET /resource_providers``. The inconsistency despite of the same queryparam"},{"line_number":188,"context_line":"name could confuse users. If we need this behaivor, that would be something"},{"line_number":189,"context_line":"like ``subtree`` queryparam which should be symmetrically implemented to"},{"line_number":190,"context_line":"``GET /resource_providers`` as well. This is already proposed in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_5c05e00e","line":187,"range":{"start_line":187,"start_character":55,"end_line":187,"end_character":57},"updated":"2019-02-28 21:29:14.000000000","message":"x","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2b6552fb9b577b80bc526a14c3e243d9fcb32afa","unresolved":false,"context_lines":[{"line_number":186,"context_line":"It is not consistent with the existing ``in_tree`` behavior in"},{"line_number":187,"context_line":"``GET /resource_providers``. The inconsistency despite of the same queryparam"},{"line_number":188,"context_line":"name could confuse users. If we need this behaivor, that would be something"},{"line_number":189,"context_line":"like ``subtree`` queryparam which should be symmetrically implemented to"},{"line_number":190,"context_line":"``GET /resource_providers`` as well. This is already proposed in"},{"line_number":191,"context_line":"`Support subtree filter for GET /resource_providers`_ spec."},{"line_number":192,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fdfeff1_7c08e425","line":189,"range":{"start_line":189,"start_character":70,"end_line":189,"end_character":72},"updated":"2019-02-28 21:29:14.000000000","message":"in","commit_id":"9e665ac6b34692c256b37e7e96eabf883bf91b3f"}]}