)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5963119d64b1c99e25934a5f9b2d10ec0a1e8c31","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Remove force flag from live-migrate and evacuate"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Force live-migrate and evacuate operations cannot be meaningfully supported"},{"line_number":10,"context_line":"for servers having complex resource allocations. So this spec proposes to"},{"line_number":11,"context_line":"remove the ``force`` flag from these operations in a new REST API"},{"line_number":12,"context_line":"microversion."},{"line_number":13,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3f79a3b5_5b46a952","line":10,"range":{"start_line":9,"start_character":43,"end_line":10,"end_character":49},"updated":"2018-10-10 12:54:14.000000000","message":"one could reasonably say that the --force flag was never a good idea to begin with and should never have been added in the first place...even for non-complex resource allocation.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Remove force flag from live-migrate and evacuate"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Force live-migrate and evacuate operations cannot be meaningfully supported"},{"line_number":10,"context_line":"for servers having complex resource allocations. So this spec proposes to"},{"line_number":11,"context_line":"remove the ``force`` flag from these operations in a new REST API"},{"line_number":12,"context_line":"microversion."},{"line_number":13,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3f79a3b5_0697789e","line":10,"range":{"start_line":9,"start_character":43,"end_line":10,"end_character":49},"in_reply_to":"3f79a3b5_5b46a952","updated":"2018-10-10 13:45:30.000000000","message":"I guess I\u0027m behind on the ML thread but yeah I thought we talked about just deprecating the force flag altogether since it\u0027s just a bad idea and outdated given our reliance on placement now and doing claims in the control plane rather than the computes.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8441e7738cf0aea2c70009d6c4ea81eca86920ba","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Remove force flag from live-migrate and evacuate"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Force live-migrate and evacuate operations cannot be meaningfully supported"},{"line_number":10,"context_line":"for servers having complex resource allocations. So this spec proposes to"},{"line_number":11,"context_line":"remove the ``force`` flag from these operations in a new REST API"},{"line_number":12,"context_line":"microversion."},{"line_number":13,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3f79a3b5_a6632445","line":10,"range":{"start_line":9,"start_character":43,"end_line":10,"end_character":49},"in_reply_to":"3f79a3b5_5b46a952","updated":"2018-10-10 13:47:56.000000000","message":"Quit beating around the bush, Jay - how do you feel about the force flag, really?","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":10,"context_line":"for servers having complex resource allocations. So this spec proposes to"},{"line_number":11,"context_line":"remove the ``force`` flag from these operations in a new REST API"},{"line_number":12,"context_line":"microversion."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Change-Id: I1fad03e7fca734bec9a045df0d3d72d9012f6159"},{"line_number":15,"context_line":"Blueprint: remove-force-flag-from-live-migrate-and-evacuate"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3f79a3b5_c6d8a053","line":13,"updated":"2018-10-10 13:45:30.000000000","message":"Add the APIImpact tag.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":10,"context_line":"for servers having complex resource allocations. So this spec proposes to"},{"line_number":11,"context_line":"remove the ``force`` flag from these operations in a new REST API"},{"line_number":12,"context_line":"microversion."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Change-Id: I1fad03e7fca734bec9a045df0d3d72d9012f6159"},{"line_number":15,"context_line":"Blueprint: remove-force-flag-from-live-migrate-and-evacuate"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3f79a3b5_811efd71","line":13,"in_reply_to":"3f79a3b5_c6d8a053","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"}],"specs/stein/approved/remove-force-flag-from-live-migrate-and-evacuate.rst":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Remove force flag from live-migrate and evacuate"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/remove-force-flag-from-live-migrate-and-evacuate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e6db5c4b","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":6},"updated":"2018-10-10 13:45:30.000000000","message":"Deprecate?","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Remove force flag from live-migrate and evacuate"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/remove-force-flag-from-live-migrate-and-evacuate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_4b4fa68b","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":6},"in_reply_to":"3f79a3b5_418d5a7a","updated":"2018-10-11 09:17:14.000000000","message":"@Matt: This spec is deprecating the flag by removing it from a new microversion.\n\n@Eric: My intention is to implement the flag removal in the new microversion a way that basically sets the force\u003dFalse in the nova-api before calling the deeper nova layers. This means that force\u003dFalse in old microversion will behave the same as using the new microversion (and therefore not providing the flag at all).","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"caa80c6de33320afe790841395122f6c4ba29a6e","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Remove force flag from live-migrate and evacuate"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/remove-force-flag-from-live-migrate-and-evacuate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_81e29201","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":6},"in_reply_to":"3f79a3b5_c11dea62","updated":"2018-10-10 14:04:23.000000000","message":"I don\u0027t see the point of continuing to support buggy and unsafe behaviour.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"48e160cfcc48608545632925afbf6469bac6add3","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Remove force flag from live-migrate and evacuate"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/remove-force-flag-from-live-migrate-and-evacuate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_418d5a7a","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":6},"in_reply_to":"3f79a3b5_c11dea62","updated":"2018-10-10 14:09:18.000000000","message":"It\u0027s an interesting point: is there any difference in behavior between using the new microversion and using the old microversion without the force flag?\n\nNot to say we shouldn\u0027t still do the actual removal (forbid the flag via schema), but the new microversion isn\u0027t necessary for consumers wishing to get the \"new\" behavior.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c64840b44c9e613ca70b22e2f8732c38bf0d9996","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Remove force flag from live-migrate and evacuate"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/remove-force-flag-from-live-migrate-and-evacuate"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c11dea62","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":6},"in_reply_to":"3f79a3b5_e6db5c4b","updated":"2018-10-10 13:48:00.000000000","message":"Nevermind, I guess it is removed per the API impact, I was just thinking about how we deprecate things in the API by removing them, but still support them on older microversions, like personality files.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_66898cc5","line":20,"updated":"2018-10-10 13:45:30.000000000","message":"So you\u0027re missing something in this spec, which is that before 2.29 for evacuate and 2.30 for live migrate, if you specify a host then we bypass the scheduler (it\u0027s an assumed force). We can remove the force flag in a new microversion, but if you\u0027re using OSC, which defaults to microversion 2.1, it\u0027s going to pass 2.1 and if a host is specified it\u0027s essentially being forced. So in that case, if the server being force live migrated/evacuated has complex nested allocations, what do we do? Are we going to be able to fail gracefully?","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"69d0dc57ba97707b0f573b09ddc5aa3164d71ed6","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c1ce352b","line":20,"in_reply_to":"3f79a3b5_072a122e","updated":"2018-10-11 09:15:32.000000000","message":"@Jay, we volunteerly wrote 2.29 and 2.30 because it was the legacy behaviour and because operators wanted to keep it. I used the term \"force\" for exactly what it is : you\u0027re not asking, you\u0027re forcing the decision.\n\nAbout the idea of failing fast for nested allocations on the source host in case of a previous microversion, I\u0027m good with that. It\u0027s better to not do any try to move and just return an ERROR for live-migrate rather than trying to blindly create new allocations.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6ed95082","line":20,"in_reply_to":"3f79a3b5_072a122e","updated":"2018-10-11 09:17:14.000000000","message":"There are two cases:\n\n1) the server has complex allocation on the source host. Here my plan is to fail in the conductor when it detects the complex allocation.\n\n2) the server does not have complex allocation on the source host (e.g. the source is not reshaped yet) but it would require a complex allocation on the destination host. Here conductor cannot detect the problem, so conductor will try the legacy blind copy but that will fail in placement which will also result in raising NoValidHost.\n\nBut these behaviors are for the old microversions. With the new microversion nova conductor will always call the scheduler to validate the dest host and get proper complex allocation candidates for it.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"441c3a4b274a1378f2e57bc9466a3b09282d5600","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_072a122e","line":20,"in_reply_to":"3f79a3b5_21305e06","updated":"2018-10-10 14:55:51.000000000","message":"Precisely my point, Matt.\n\nEric, we don\u0027t *need* to know if the destination is going to break. It either will or it won\u0027t. If it does, the live migration fails and the source allocations aren\u0027t changed anyway. If it succeeds, by a miracle or fluke, then the allocations are correct, since doing a POST /allocations will always prevent over-capacity issues.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"680f590cc9a8eafbf7ec1e2fa2c21436b31f9edf","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_21305e06","line":20,"in_reply_to":"3f79a3b5_41447ab8","updated":"2018-10-10 14:23:41.000000000","message":"I think if we\u0027re being forced and the source has nested allocations, we fail fast and don\u0027t attempt the blind copy even if we might have gotten lucky by putting all of the resource allocations on the yet un-reshaped dest. That\u0027s a narrow window until the dest is upgraded and reshaped and getting lucky isn\u0027t something I think we need to care about.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_61ae4130","line":20,"in_reply_to":"3f79a3b5_66898cc5","updated":"2018-10-11 09:17:14.000000000","message":"Actually I don\u0027t see any problems special to \u003c2.29 microversions.\n\nLogic will be like:\n* os-live-migrate \u003c 2.30 and the host is specified: Conductor will fail on complex allocations. If the allocation is simple on both source and dest then blind copy will be done and will work.\n* os-live-migrate \u003e\u003d 2.30 \u003c new-version and host specified and force\u003dTrue: Conductor will fail on complex allocations. If the allocation is simple on both source and dest then blind copy will be done and will work.\n* os-live-migrate \u003d\u003d new-version and host specified: conductor will always call the scheduler.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"caa80c6de33320afe790841395122f6c4ba29a6e","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_81905251","line":20,"in_reply_to":"3f79a3b5_66898cc5","updated":"2018-10-10 14:04:23.000000000","message":"No, fail hard. Fail fast. And put in the release notes that 2.29 and 2.30 were bad ideas from the start and are no longer supported.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5936bc7f40b7775be71a63bad0b8406ed34c69e0","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_ab908443","line":20,"in_reply_to":"3f79a3b5_6ed95082","updated":"2018-10-13 16:40:02.000000000","message":"\u003e 2) the server does not have complex allocation on the source host (e.g. the source is not reshaped yet) but it would require a complex allocation on the destination host. Here conductor cannot detect the problem, so conductor will try the legacy blind copy but that will fail in placement which will also result in raising NoValidHost.\n\nI thought we talked about this already? I don\u0027t really see the point in trying to blind copy complex allocations to the dest. If it works, it is by sheer luck, but I wouldn\u0027t expect it to since the nested provider UUIDs will be different. Therefore it seems easiest from a code/usability/maintainability perspective to detect if force is True and source has complex allocations, fail fast.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"48e160cfcc48608545632925afbf6469bac6add3","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_41447ab8","line":20,"in_reply_to":"3f79a3b5_81905251","updated":"2018-10-10 14:09:18.000000000","message":"You mean fail hard and fast when allocations are on multiple providers on the source. We can\u0027t tell whether the destination is going to break (which is the whole point of this) so we have to try the blind copy in that case.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d34a2a48fd96ae4a28aea55244e38be6664ea15","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Today when ``force: True`` is specified nova tries to blindly copy the resource"},{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_be242f60","line":20,"in_reply_to":"3f79a3b5_ab908443","updated":"2018-10-15 13:20:59.000000000","message":"#2) talks about a server that _does not_ have a complex allocation on the source compute. :)","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8441e7738cf0aea2c70009d6c4ea81eca86920ba","unresolved":false,"context_lines":[{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"},{"line_number":24,"context_line":"become more complex (e.g. it allocates from more than one providers or"},{"line_number":25,"context_line":"allocates from a nested provider) the blind copy will fail."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a64c84c9","line":24,"range":{"start_line":24,"start_character":58,"end_line":24,"end_character":67},"updated":"2018-10-10 13:47:56.000000000","message":"provider","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":21,"context_line":"allocation from the source host to the target host. This only works if the"},{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"},{"line_number":24,"context_line":"become more complex (e.g. it allocates from more than one providers or"},{"line_number":25,"context_line":"allocates from a nested provider) the blind copy will fail."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_8e6dcc9a","line":24,"range":{"start_line":24,"start_character":58,"end_line":24,"end_character":67},"in_reply_to":"3f79a3b5_a64c84c9","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8441e7738cf0aea2c70009d6c4ea81eca86920ba","unresolved":false,"context_lines":[{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"},{"line_number":24,"context_line":"become more complex (e.g. it allocates from more than one providers or"},{"line_number":25,"context_line":"allocates from a nested provider) the blind copy will fail."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_06c3f807","line":25,"updated":"2018-10-10 13:47:56.000000000","message":"could mention sharing","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":22,"context_line":"the server\u0027s allocation is satisfied by the single root resource provider both"},{"line_number":23,"context_line":"on the source host and on the destination host. As soon as the allocation"},{"line_number":24,"context_line":"become more complex (e.g. it allocates from more than one providers or"},{"line_number":25,"context_line":"allocates from a nested provider) the blind copy will fail."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_0e621cae","line":25,"in_reply_to":"3f79a3b5_06c3f807","updated":"2018-10-11 09:17:14.000000000","message":"as far as I understand we cannot allocate from a sharing provider only. While we can allocate from a nested provider only. The first part of the OR contains the sharing provider case.\n\nClarified in the text.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"None"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Proposed change"},{"line_number":33,"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":1,"id":"3f79a3b5_86794831","line":30,"updated":"2018-10-10 13:45:30.000000000","message":"Really? Clearly we have use cases for bandwidth-based scheduling on nested resource providers, and I think this is also something for shared storage support (see bug 1784020).","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"None"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Proposed change"},{"line_number":33,"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":1,"id":"3f79a3b5_4e6334ac","line":30,"in_reply_to":"3f79a3b5_21893e24","updated":"2018-10-11 09:17:14.000000000","message":"Yeah, this change actually remove a use case from the system. I can describe what is removed.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"caa80c6de33320afe790841395122f6c4ba29a6e","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"None"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Proposed change"},{"line_number":33,"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":1,"id":"3f79a3b5_21893e24","line":30,"in_reply_to":"3f79a3b5_86794831","updated":"2018-10-10 14:04:23.000000000","message":"I think by \"None\" gibi is saying that there is no positive use case for this. it\u0027s just fixing a mistake that was made in the API.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Forcing the destination host in a complex allocation case cannot supported"},{"line_number":36,"context_line":"without calling Placement to get allocation candidates on the destination host"},{"line_number":37,"context_line":"as Nova does not know how to copy the complex allocation. The documentation"},{"line_number":38,"context_line":"of the force flag states that Nova will not call the scheduler to verify the"},{"line_number":39,"context_line":"destination host. This now leads to a contradiction. So the spec proposes to"},{"line_number":40,"context_line":"remove the ``force`` flag as it cannot be supported any more."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Note that fixing old microversions to fail cleanly without leaking allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e6e59cdc","line":39,"range":{"start_line":37,"start_character":58,"end_line":39,"end_character":52},"updated":"2018-10-10 13:45:30.000000000","message":"Well....as we\u0027ve discussed, we already basically broke this contract in Pike with I40b5af5e85b1266402a7e4bdeb3705e1b0bd6f3b and I6590f0eda4ec4996543ad40d8c2640b83fc3dd9d. You should probably reference those changes in the spec as further justification for why the force parameter is outdated and we can\u0027t really honor it very well anymore, and already aren\u0027t for vcpu, ram and disk.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Forcing the destination host in a complex allocation case cannot supported"},{"line_number":36,"context_line":"without calling Placement to get allocation candidates on the destination host"},{"line_number":37,"context_line":"as Nova does not know how to copy the complex allocation. The documentation"},{"line_number":38,"context_line":"of the force flag states that Nova will not call the scheduler to verify the"},{"line_number":39,"context_line":"destination host. This now leads to a contradiction. So the spec proposes to"},{"line_number":40,"context_line":"remove the ``force`` flag as it cannot be supported any more."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Note that fixing old microversions to fail cleanly without leaking allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_613881d3","line":39,"range":{"start_line":37,"start_character":58,"end_line":39,"end_character":52},"in_reply_to":"3f79a3b5_41a8fa76","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"caa80c6de33320afe790841395122f6c4ba29a6e","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Forcing the destination host in a complex allocation case cannot supported"},{"line_number":36,"context_line":"without calling Placement to get allocation candidates on the destination host"},{"line_number":37,"context_line":"as Nova does not know how to copy the complex allocation. The documentation"},{"line_number":38,"context_line":"of the force flag states that Nova will not call the scheduler to verify the"},{"line_number":39,"context_line":"destination host. This now leads to a contradiction. So the spec proposes to"},{"line_number":40,"context_line":"remove the ``force`` flag as it cannot be supported any more."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Note that fixing old microversions to fail cleanly without leaking allocation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_41a8fa76","line":39,"range":{"start_line":37,"start_character":58,"end_line":39,"end_character":52},"in_reply_to":"3f79a3b5_e6e59cdc","updated":"2018-10-10 14:04:23.000000000","message":"++\n\nGood to reference those.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3e3b648032b259533c271cdcf77977de08e141e6","unresolved":false,"context_lines":[{"line_number":42,"context_line":"Note that fixing old microversions to fail cleanly without leaking allocation"},{"line_number":43,"context_line":"in complex allocation scenarios is not part of this spec but handled as part of"},{"line_number":44,"context_line":"`use-nested-allocation-candidates`_"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"Alternatives"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_b804a31a","line":45,"updated":"2018-10-10 12:43:58.000000000","message":"Well, sure, but maybe you should provide the consensus we have for it here.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":42,"context_line":"Note that fixing old microversions to fail cleanly without leaking allocation"},{"line_number":43,"context_line":"in complex allocation scenarios is not part of this spec but handled as part of"},{"line_number":44,"context_line":"`use-nested-allocation-candidates`_"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"Alternatives"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6194018d","line":45,"in_reply_to":"3f79a3b5_b804a31a","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":46,"context_line":"Alternatives"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_261394b9","line":49,"updated":"2018-10-10 13:45:30.000000000","message":"So I\u0027m confused, is this spec deprecating the force flag in all cases, or only nested provider cases? Because the problem statements before this are just talked about how force doesn\u0027t work for nested.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"48e160cfcc48608545632925afbf6469bac6add3","unresolved":false,"context_lines":[{"line_number":46,"context_line":"Alternatives"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_41d6baf4","line":49,"in_reply_to":"3f79a3b5_261394b9","updated":"2018-10-10 14:09:18.000000000","message":"All cases, because we can\u0027t reliably determine the need for complex allocations on the destination beforehand.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":46,"context_line":"Alternatives"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e1ced1b5","line":49,"in_reply_to":"3f79a3b5_41d6baf4","updated":"2018-10-11 09:17:14.000000000","message":"@Matt: the name of the spec and the API section is pretty clearly states that we remove the force flag from the API in a new microversion.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"69d0dc57ba97707b0f573b09ddc5aa3164d71ed6","unresolved":false,"context_lines":[{"line_number":46,"context_line":"Alternatives"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_61008136","line":49,"in_reply_to":"3f79a3b5_41d6baf4","updated":"2018-10-11 09:15:32.000000000","message":"There are two cases :\n- we\u0027re removing force for new microversions, period.\n- we\u0027re allowing force because of older microversions, but in that case, we just return an ERROR if the allocation is nested on the source host.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5936bc7f40b7775be71a63bad0b8406ed34c69e0","unresolved":false,"context_lines":[{"line_number":46,"context_line":"Alternatives"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_cbbdc0b2","line":49,"in_reply_to":"3f79a3b5_e1ced1b5","updated":"2018-10-13 16:40:02.000000000","message":"Yeah I think I was just initially confused by the wording in the commit message or something made me think that we\u0027d only ignore the force flag in the case of complex allocations. I get that the spec proposes to remove the parameter in a microversion.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_66eaeca0","line":50,"updated":"2018-10-10 13:45:30.000000000","message":"formatting is wrong here - wrapped lines need to align with the text above","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."},{"line_number":53,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c1c955ab","line":50,"in_reply_to":"3f79a3b5_66eaeca0","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"See more details in the `ML thread`_"},{"line_number":55,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c67e60e2","line":52,"updated":"2018-10-10 13:45:30.000000000","message":"This isn\u0027t an alternative IMO - that would mean regressing the changes we made in pike linked above.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":49,"context_line":"* Try to guess when the server needs a complex allocation on the destination"},{"line_number":50,"context_line":"host and only ignore the force flag in these cases."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"See more details in the `ML thread`_"},{"line_number":55,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e13331c3","line":52,"in_reply_to":"3f79a3b5_c67e60e2","updated":"2018-10-11 09:17:14.000000000","message":"I can look at it from the perspective that the bugfix in Pike regressed the behavior documented in the API and this alternative would restore the original documented API behavior.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8441e7738cf0aea2c70009d6c4ea81eca86920ba","unresolved":false,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"* Do not manage resource allocations for forced move operations."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"See more details in the `ML thread`_"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"Data model impact"},{"line_number":57,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a6d1e4cc","line":54,"range":{"start_line":54,"start_character":24,"end_line":54,"end_character":36},"updated":"2018-10-10 13:47:56.000000000","message":"Yes, thanks for including this.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3e3b648032b259533c271cdcf77977de08e141e6","unresolved":false,"context_lines":[{"line_number":64,"context_line":"In a new microversion remove the ``force`` flag from both APIs:"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"* POST /servers/{server_id}/action (os-migrateLive Action)"},{"line_number":67,"context_line":"* POST /servers/{server_id}/action (evacuate Action)"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_f8121b61","line":67,"updated":"2018-10-10 12:43:58.000000000","message":"like I said below, I think we need two microversions.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"69d0dc57ba97707b0f573b09ddc5aa3164d71ed6","unresolved":false,"context_lines":[{"line_number":64,"context_line":"In a new microversion remove the ``force`` flag from both APIs:"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"* POST /servers/{server_id}/action (os-migrateLive Action)"},{"line_number":67,"context_line":"* POST /servers/{server_id}/action (evacuate Action)"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6185e1ad","line":67,"in_reply_to":"3f79a3b5_f8121b61","updated":"2018-10-11 09:15:32.000000000","message":"Given the IRC discussion, I\u0027m backing up, just do one microversion.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":64,"context_line":"In a new microversion remove the ``force`` flag from both APIs:"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"* POST /servers/{server_id}/action (os-migrateLive Action)"},{"line_number":67,"context_line":"* POST /servers/{server_id}/action (evacuate Action)"},{"line_number":68,"context_line":""},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_61472120","line":67,"in_reply_to":"3f79a3b5_f8121b61","updated":"2018-10-11 09:17:14.000000000","message":"We discussed this on IRC and agreed to keep this change in a single microversion.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":80,"context_line":"Other end user impact"},{"line_number":81,"context_line":"---------------------"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Update python-novaclient to support the new microversion."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Performance Impact"},{"line_number":86,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_666d0c2e","line":83,"updated":"2018-10-10 13:45:30.000000000","message":"And python-openstackclient.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":80,"context_line":"Other end user impact"},{"line_number":81,"context_line":"---------------------"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Update python-novaclient to support the new microversion."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Performance Impact"},{"line_number":86,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_214da93b","line":83,"in_reply_to":"3f79a3b5_666d0c2e","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8441e7738cf0aea2c70009d6c4ea81eca86920ba","unresolved":false,"context_lines":[{"line_number":81,"context_line":"---------------------"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Update python-novaclient to support the new microversion."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Performance Impact"},{"line_number":86,"context_line":"------------------"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_4655701d","line":84,"updated":"2018-10-10 13:47:56.000000000","message":"Not sure if this goes here, but:\n\nPossibility of a higher failure rate, since we\u0027ll no longer bypass the parts of the scheduling algorithm that restrict for traits and aggregates.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"caa80c6de33320afe790841395122f6c4ba29a6e","unresolved":false,"context_lines":[{"line_number":81,"context_line":"---------------------"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Update python-novaclient to support the new microversion."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Performance Impact"},{"line_number":86,"context_line":"------------------"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_61bc16b5","line":84,"in_reply_to":"3f79a3b5_4655701d","updated":"2018-10-10 14:04:23.000000000","message":"One could reasonably argue that the real failure was in letting someone bypass the resource accounting in the first place. :)","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":81,"context_line":"---------------------"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Update python-novaclient to support the new microversion."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Performance Impact"},{"line_number":86,"context_line":"------------------"},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a1a3f9af","line":84,"in_reply_to":"3f79a3b5_61bc16b5","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8441e7738cf0aea2c70009d6c4ea81eca86920ba","unresolved":false,"context_lines":[{"line_number":85,"context_line":"Performance Impact"},{"line_number":86,"context_line":"------------------"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"None"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e6b6fc89","line":88,"range":{"start_line":88,"start_character":0,"end_line":88,"end_character":4},"updated":"2018-10-10 13:47:56.000000000","message":"slight performance degradation due to running the scheduler code, including an extra GET /a_c call.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":85,"context_line":"Performance Impact"},{"line_number":86,"context_line":"------------------"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"None"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_61e3a107","line":88,"range":{"start_line":88,"start_character":0,"end_line":88,"end_character":4},"in_reply_to":"3f79a3b5_e6b6fc89","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"680f590cc9a8eafbf7ec1e2fa2c21436b31f9edf","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"None"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6c2c0d93","line":93,"updated":"2018-10-10 14:23:41.000000000","message":"Not sure if this should be mentioned or not, but the one use case I can see for the force parameter is I\u0027ve disabled a compute service because I don\u0027t want new VMs to go to it, and I want to rebalance my computes so I live migrate VMs off oversubscribed computes to the disabled compute. You would have to force in that case because otherwise the ComputeFilter would rejected the disabled compute. But...if your cloud is really that busy that another new VM is going to take that target host in the interim, you likely have a public cloud and have lots of computes and should have spare capacity for rebalancing. Would be good to get mnaser\u0027s thoughts on this since he does something like this at vexxhost.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"None"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_81383d3b","line":93,"in_reply_to":"3f79a3b5_07b8d2e5","updated":"2018-10-11 09:17:14.000000000","message":"Added a sentence about it. mnaser\u0027s left a comment that vexxhost doesn\u0027t in general use forced live-migration.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"69d0dc57ba97707b0f573b09ddc5aa3164d71ed6","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"None"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_4188e5c1","line":93,"in_reply_to":"3f79a3b5_07b8d2e5","updated":"2018-10-11 09:15:32.000000000","message":"That sounds a reasonable approach.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"8c0d24da145391331ccf2aede7e45cdfbf68e543","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"None"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_60be2dd5","line":93,"in_reply_to":"3f79a3b5_405d31ea","updated":"2018-10-11 19:07:30.000000000","message":"\u003e We actually do a bit of the opposite.  We disable the compute node\n \u003e that\u0027s being evacuated and then run the host evacuate (aka live\n \u003e migration for all instances in $host) and let the scheduler decide\n \u003e their new (ideal) location.\n \u003e \n \u003e The reason we don\u0027t want to do the server-to-server approach is\n \u003e that it serializes the process a little bit, where as with letting\n \u003e the scheduler decide everything it would eventually slowly shape\n \u003e things to the ideal state as live migrations occur.\n\n+100","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a4b0cf0acfa7aa1844d3288d0b90dd6516fded99","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"None"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e2d9d6f0","line":93,"in_reply_to":"3f79a3b5_60be2dd5","updated":"2018-10-12 09:26:59.000000000","message":"\u003e \u003e We actually do a bit of the opposite.  We disable the compute\n \u003e node\n \u003e \u003e that\u0027s being evacuated and then run the host evacuate (aka live\n \u003e \u003e migration for all instances in $host) and let the scheduler\n \u003e decide\n \u003e \u003e their new (ideal) location.\n \u003e \u003e\n \u003e \u003e The reason we don\u0027t want to do the server-to-server approach is\n \u003e \u003e that it serializes the process a little bit, where as with\n \u003e letting\n \u003e \u003e the scheduler decide everything it would eventually slowly shape\n \u003e \u003e things to the ideal state as live migrations occur.\n \u003e \n \u003e +100\n\n\nI love that too. @Mohammed, you\u0027re one of the best operators I know !","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8016ff7127dab1a0817b511083739679cde13301","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"None"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a7d31e63","line":93,"in_reply_to":"3f79a3b5_6c2c0d93","updated":"2018-10-10 14:50:31.000000000","message":"In talking about this with Dan, maybe we should always ignore the ComputeFilter if a host is specified, so if you force or not regardless of microversion, as long as you specify a host and we go through the scheduler we ignore the ComputeFilter.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"a99fad812346ff149858e9bc8088182bdf94c1e0","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"None"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_405d31ea","line":93,"in_reply_to":"3f79a3b5_6c2c0d93","updated":"2018-10-11 18:59:07.000000000","message":"We actually do a bit of the opposite.  We disable the compute node that\u0027s being evacuated and then run the host evacuate (aka live migration for all instances in $host) and let the scheduler decide their new (ideal) location.\n\nThe reason we don\u0027t want to do the server-to-server approach is that it serializes the process a little bit, where as with letting the scheduler decide everything it would eventually slowly shape things to the ideal state as live migrations occur.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"2da0db23f0f5f7af28dc6efdce0d36c3e1e5b76d","unresolved":false,"context_lines":[{"line_number":90,"context_line":"Other deployer impact"},{"line_number":91,"context_line":"---------------------"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"None"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_07b8d2e5","line":93,"in_reply_to":"3f79a3b5_a7d31e63","updated":"2018-10-10 14:57:18.000000000","message":"That sounds reasonable to me, Matt. ++","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"None"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Upgrade impact"},{"line_number":101,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_0648d887","line":98,"updated":"2018-10-10 13:45:30.000000000","message":"I would actually say supporting the force flag has been a detriment to maintaining nova since it\u0027s an edge case and requires workarounds like the ones made in pike to support it. Dropping support over time will be a benefit to maintaining the project and improve consistency/reliability/usability of the API.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"caa80c6de33320afe790841395122f6c4ba29a6e","unresolved":false,"context_lines":[{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"None"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Upgrade impact"},{"line_number":101,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_81ccd262","line":98,"in_reply_to":"3f79a3b5_0648d887","updated":"2018-10-10 14:04:23.000000000","message":"+100","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"None"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Upgrade impact"},{"line_number":101,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6124010f","line":98,"in_reply_to":"3f79a3b5_0648d887","updated":"2018-10-11 09:17:14.000000000","message":"Done","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3e3b648032b259533c271cdcf77977de08e141e6","unresolved":false,"context_lines":[{"line_number":119,"context_line":"* Add a new microversion to the API that removes the ``force`` flag from the"},{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_582a2f91","line":122,"updated":"2018-10-10 12:43:58.000000000","message":"We had two microversions, one per API, so I think we need two others here too.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"69d0dc57ba97707b0f573b09ddc5aa3164d71ed6","unresolved":false,"context_lines":[{"line_number":119,"context_line":"* Add a new microversion to the API that removes the ``force`` flag from the"},{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c1b5d57e","line":122,"in_reply_to":"3f79a3b5_46033011","updated":"2018-10-11 09:15:32.000000000","message":"Fair enough.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":119,"context_line":"* Add a new microversion to the API that removes the ``force`` flag from the"},{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_81211dff","line":122,"in_reply_to":"3f79a3b5_46033011","updated":"2018-10-11 09:17:14.000000000","message":"We agreed on IRC that this change will be done in a single microversion.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5963119d64b1c99e25934a5f9b2d10ec0a1e8c31","unresolved":false,"context_lines":[{"line_number":119,"context_line":"* Add a new microversion to the API that removes the ``force`` flag from the"},{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_dba079f6","line":122,"in_reply_to":"3f79a3b5_582a2f91","updated":"2018-10-10 12:54:14.000000000","message":"I see no reason to add 2 microversions.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"8441e7738cf0aea2c70009d6c4ea81eca86920ba","unresolved":false,"context_lines":[{"line_number":119,"context_line":"* Add a new microversion to the API that removes the ``force`` flag from the"},{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_46033011","line":122,"in_reply_to":"3f79a3b5_dba079f6","updated":"2018-10-10 13:47:56.000000000","message":"Agree one microversion is appropriate. We use a single microversion to implement a single \"feature\" even when it touches multiple routes/operations.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"76b49edecae16c2ff38704173c0398eee5014278","unresolved":false,"context_lines":[{"line_number":119,"context_line":"* Add a new microversion to the API that removes the ``force`` flag from the"},{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_464b30b0","line":122,"in_reply_to":"3f79a3b5_dba079f6","updated":"2018-10-10 13:45:30.000000000","message":"Me neither, just remove them all in one microversion. It\u0027s confusing enough when we have 1000 microversions to use our API.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3e3b648032b259533c271cdcf77977de08e141e6","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_38309306","line":123,"updated":"2018-10-10 12:43:58.000000000","message":"please note we already have a gap on OSC that doesn\u0027t support 2.29 and 2.30 microversions adding this field (and like said in https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc )\nLike I said in the thread, I think we should also make sure we can both support 2.29, 2.30 and the new microversions in OSC.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f398f7fb925403067af259a5a1b68280ecf96c4c","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_216fe929","line":123,"in_reply_to":"3f79a3b5_1b97d19e","updated":"2018-10-11 09:17:14.000000000","message":"I can commit to give support to the new microversion in both clients. I\u0027m not sure this spec should be the one that gives support the old 2.29 and 2.30 microversions in OSC.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"69d0dc57ba97707b0f573b09ddc5aa3164d71ed6","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_615c014c","line":123,"in_reply_to":"3f79a3b5_1b97d19e","updated":"2018-10-11 09:15:32.000000000","message":"See my comment on L20. During the spec review we had for 2.29 and 2.30, we discussed on whether we thought it would be good to have a force operation and we decided as a team to keep the old behaviour, but signal it better (hence the force flag).\n\nThat said, it was pre \u0027scheduler-claims\u0027. TBH, we never considered the force case when we implemented scheduler-claims so we basically left this weird situation happening for a while, until now we feel the pain to support it to be more important than to remove it.\n\nClaiming that it was a \u0027friggin bad idea from the beginning\u0027 doesn\u0027t really help.","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"5963119d64b1c99e25934a5f9b2d10ec0a1e8c31","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_1b97d19e","line":123,"in_reply_to":"3f79a3b5_38309306","updated":"2018-10-10 12:54:14.000000000","message":"Strongly disagree. After a certain point, we, as a team, need to be able to say \"OK, this API was just a friggin bad idea from the beginning and we\u0027re not going to support this bad idea any more\".","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"1066e070b242920ab6a8a3a0dcf3526e2c16e366","unresolved":false,"context_lines":[{"line_number":120,"context_line":"  payload. If the new microversion is used in the request then default"},{"line_number":121,"context_line":"  ``force`` to False when calling Nova internals."},{"line_number":122,"context_line":"* Document the new microversion"},{"line_number":123,"context_line":"* Add support for the new microversion in the python-novaclient"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_702125b5","line":123,"in_reply_to":"3f79a3b5_615c014c","updated":"2018-10-11 13:10:24.000000000","message":"\u003e See my comment on L20. During the spec review we had for 2.29 and\n \u003e 2.30, we discussed on whether we thought it would be good to have a\n \u003e force operation and we decided as a team to keep the old behaviour,\n \u003e but signal it better (hence the force flag).\n\nYeah, and I think that was a bad idea.\n\n \u003e That said, it was pre \u0027scheduler-claims\u0027. TBH, we never considered\n \u003e the force case when we implemented scheduler-claims so we basically\n \u003e left this weird situation happening for a while, until now we feel\n \u003e the pain to support it to be more important than to remove it.\n \u003e \n \u003e Claiming that it was a \u0027friggin bad idea from the beginning\u0027\n \u003e doesn\u0027t really help.\n\nSorry, it was a bad idea from the beginning to allow operators to purposefully subvert the resource accounting practices in nova.\n\nThis is a good example of a concept we should just say \"sorry, our bad\" and remove from the codebase.\n\nMy point is that we spend endless hours re-treading the same bug-introducing code and decisions instead of just sucking it up, admitting it was a mistake, and removing the mistake from the codebase, accepting the fact that an operator might come to us and complain.\n\n-jay","commit_id":"b7dc3ed3317cfb23ae2933a100ed84b2d39a301f"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5936bc7f40b7775be71a63bad0b8406ed34c69e0","unresolved":false,"context_lines":[{"line_number":38,"context_line":"This does not effect the use cases when the operator specifies the destination"},{"line_number":39,"context_line":"host and let Nova and Placement verify that host before the move."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Please note that this removes the possibility to force live-migrate servers to"},{"line_number":42,"context_line":"hosts where the nova-compute is disabled as the ComputeFilter in the filter"},{"line_number":43,"context_line":"scheduler will reject such hosts."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_8bd90829","line":41,"updated":"2018-10-13 16:40:02.000000000","message":"nit: could throw this in a .. note:: formatted block","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6405fb1612ddb08978bbcfb8e89c7cfa749da92c","unresolved":false,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Please note that this removes the possibility to force live-migrate servers to"},{"line_number":42,"context_line":"hosts where the nova-compute is disabled as the ComputeFilter in the filter"},{"line_number":43,"context_line":"scheduler will reject such hosts."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"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":2,"id":"3f79a3b5_42b0ca8d","line":43,"updated":"2018-10-12 09:35:38.000000000","message":"But operators can remove the ComputeFilter, right? They can also provide a specific custom filter that would accept disabled hosts...\nNot sure it\u0027s something we should really discuss here.","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"0d34a2a48fd96ae4a28aea55244e38be6664ea15","unresolved":false,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Please note that this removes the possibility to force live-migrate servers to"},{"line_number":42,"context_line":"hosts where the nova-compute is disabled as the ComputeFilter in the filter"},{"line_number":43,"context_line":"scheduler will reject such hosts."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"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":2,"id":"3f79a3b5_7efc573e","line":43,"in_reply_to":"3f79a3b5_2bca3445","updated":"2018-10-15 13:20:59.000000000","message":"I\u0027d like to keep it simple. Turning off ComputeFilter for targeted move can be handled in a separate spec.","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"505daf50f8b73927c24967fc5e407c80212f07c5","unresolved":false,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Please note that this removes the possibility to force live-migrate servers to"},{"line_number":42,"context_line":"hosts where the nova-compute is disabled as the ComputeFilter in the filter"},{"line_number":43,"context_line":"scheduler will reject such hosts."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"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":2,"id":"3f79a3b5_9d9c03c0","line":43,"in_reply_to":"3f79a3b5_42b0ca8d","updated":"2018-10-12 09:51:00.000000000","message":"This case was explicitly discussed in IRC [1] where you raised the issue of ComputeFilter. So I thought it is good to document it. Matt also raised it in PS1 [2]\n\n[1]http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-10-10.log.html#t2018-10-10T14:25:25\n[2] https://review.openstack.org/#/c/609330/1/specs/stein/approved/remove-force-flag-from-live-migrate-and-evacuate.rst@93","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5936bc7f40b7775be71a63bad0b8406ed34c69e0","unresolved":false,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Please note that this removes the possibility to force live-migrate servers to"},{"line_number":42,"context_line":"hosts where the nova-compute is disabled as the ComputeFilter in the filter"},{"line_number":43,"context_line":"scheduler will reject such hosts."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"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":2,"id":"3f79a3b5_2bca3445","line":43,"in_reply_to":"3f79a3b5_9d9c03c0","updated":"2018-10-13 16:40:02.000000000","message":"As mentioned in PS1, we could change the code irrespective of microversion such that if a host is specified and we go through the scheduler, we ignore the ComputeFilter. We could pass a flag through for that like we do for rebuilding with a new image. I\u0027m not even sure we should make that part of this change, it\u0027s just an option we can keep in our pocket in case someone says they really rely on the force flag to move instances to disabled hosts. As mnaser pointed out, there are alternatives for rebalancing the system (or for shuffling workloads during upgrade).","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"ef3c63d283d205f19180304957bcdc4bf29ab0bb","unresolved":false,"context_lines":[{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"Forcing the destination host in a complex allocation case cannot supported"},{"line_number":49,"context_line":"without calling Placement to get allocation candidates on the destination host"},{"line_number":50,"context_line":"as Nova does not know how to copy the complex allocation. The documentation"},{"line_number":51,"context_line":"of the force flag states that Nova will not call the scheduler to verify the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_f95441ff","line":48,"range":{"start_line":48,"start_character":58,"end_line":48,"end_character":74},"updated":"2018-10-11 13:45:01.000000000","message":"cannot be supported","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5936bc7f40b7775be71a63bad0b8406ed34c69e0","unresolved":false,"context_lines":[{"line_number":50,"context_line":"as Nova does not know how to copy the complex allocation. The documentation"},{"line_number":51,"context_line":"of the force flag states that Nova will not call the scheduler to verify the"},{"line_number":52,"context_line":"destination host. This rule has already been broken since Pike by two"},{"line_number":53,"context_line":"`bugfixes`_.  Also supporting complex allocations requires to get allocation"},{"line_number":54,"context_line":"candidates from Placement. So the spec proposes to remove the ``force`` flag as"},{"line_number":55,"context_line":"it cannot be supported any more."},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_ebcf5c51","line":53,"range":{"start_line":53,"start_character":1,"end_line":53,"end_character":9},"updated":"2018-10-13 16:40:02.000000000","message":"nit: bug fixes","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"e44ce65e1d1900141d74f32d9438c09b98987ff2","unresolved":false,"context_lines":[{"line_number":59,"context_line":"`use-nested-allocation-candidates`_ That change will make sure that the forced"},{"line_number":60,"context_line":"move operation on a server that either has complex allocation on the source"},{"line_number":61,"context_line":"host or would require complex allocation on the destination host will be"},{"line_number":62,"context_line":"rejected with a NoValidHost exception by the Nova conductor."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_71ba7671","line":62,"range":{"start_line":62,"start_character":16,"end_line":62,"end_character":27},"updated":"2018-10-12 07:10:21.000000000","message":"Hmm... This might be a nit, but this sounds weird to me, because I think the operation is not valid (we don\u0027t support it) rather than that the destination host is not valid. The destination host could be valid if you drop the force flag. Thoughts?","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"505daf50f8b73927c24967fc5e407c80212f07c5","unresolved":false,"context_lines":[{"line_number":59,"context_line":"`use-nested-allocation-candidates`_ That change will make sure that the forced"},{"line_number":60,"context_line":"move operation on a server that either has complex allocation on the source"},{"line_number":61,"context_line":"host or would require complex allocation on the destination host will be"},{"line_number":62,"context_line":"rejected with a NoValidHost exception by the Nova conductor."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_5d7bcb78","line":62,"range":{"start_line":62,"start_character":16,"end_line":62,"end_character":27},"in_reply_to":"3f79a3b5_42652a1b","updated":"2018-10-12 09:51:00.000000000","message":"We have to look at two different cases again:\n\n1) source host allocation is flat. Nova will try the blind copy but dest host would require nested allocation as some of the resources need to be allocated from a child RP on the dest. As the blind copy tries to allocate that resource from the root of the dest placement will reject it that there is not enough inventory on the root. This cannot be differentiated from the case when a flat dest node does not have enough resource for the request. So here nova can only raise NoValidHost.\n\n2) source host allocation is nested. Nova detect that and does not even try the blind copy. So nova could raise whatever exception BUT raising different exception to the end user here would be confusing due to the fact that in #1) nova can only raise NoValidHost.\n\nSo in both #1 and #2 there are cases when we should raise ComplexAllocationNotSupportedWithForce as a reason of tha failure BUT Nova can only do that in #2. So I don\u0027t like the idea of mixing the exceptions.\n\nBTW, the message in the exception will be a bit more specific in case of #2) See the implementation patch in https://review.openstack.org/#/c/605785/12/nova/scheduler/utils.py","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"c56cb25bf669842d194bd9846f7eb06fb66942ec","unresolved":false,"context_lines":[{"line_number":59,"context_line":"`use-nested-allocation-candidates`_ That change will make sure that the forced"},{"line_number":60,"context_line":"move operation on a server that either has complex allocation on the source"},{"line_number":61,"context_line":"host or would require complex allocation on the destination host will be"},{"line_number":62,"context_line":"rejected with a NoValidHost exception by the Nova conductor."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_b2c47042","line":62,"range":{"start_line":62,"start_character":16,"end_line":62,"end_character":27},"in_reply_to":"3f79a3b5_5d7bcb78","updated":"2018-10-14 09:40:32.000000000","message":"\u003e So in both #1 and #2 there are cases when we should raise\n \u003e ComplexAllocationNotSupportedWithForce as a reason of the failure\n \u003e BUT Nova can only do that in #2. So I don\u0027t like the idea of mixing\n \u003e the exceptions.\n\nI see. That makes sense to me. I still think NoValidHost makes non-sense to operators who wants to skip the scheduler by forcing, but, yes, having a different exception for the two cases is more confusing. Thank you for the clear explanation.","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5936bc7f40b7775be71a63bad0b8406ed34c69e0","unresolved":false,"context_lines":[{"line_number":59,"context_line":"`use-nested-allocation-candidates`_ That change will make sure that the forced"},{"line_number":60,"context_line":"move operation on a server that either has complex allocation on the source"},{"line_number":61,"context_line":"host or would require complex allocation on the destination host will be"},{"line_number":62,"context_line":"rejected with a NoValidHost exception by the Nova conductor."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_6bfd8c6b","line":62,"range":{"start_line":62,"start_character":16,"end_line":62,"end_character":27},"in_reply_to":"3f79a3b5_5d7bcb78","updated":"2018-10-13 16:40:02.000000000","message":"I agree with gibi\u0027s assessment here, and ultimately it\u0027s a NoValidHost. If you\u0027re live migrating with microversion \u003c 2.34 you get a 400 for that:\n\nhttps://github.com/openstack/nova/blob/12fcfc5e2b51b563529a5bc0b2990816bbbda80b/nova/api/openstack/compute/migrate_server.py#L111\n\nYou could maybe argue that ComplexAllocationNotSupportedWithForce could be a 409 case, but it\u0027s not really a clear distinction or benefit to me to try and separate the failures that the user gets if they are trying to force and we can\u0027t do it.","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6405fb1612ddb08978bbcfb8e89c7cfa749da92c","unresolved":false,"context_lines":[{"line_number":59,"context_line":"`use-nested-allocation-candidates`_ That change will make sure that the forced"},{"line_number":60,"context_line":"move operation on a server that either has complex allocation on the source"},{"line_number":61,"context_line":"host or would require complex allocation on the destination host will be"},{"line_number":62,"context_line":"rejected with a NoValidHost exception by the Nova conductor."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_42652a1b","line":62,"range":{"start_line":62,"start_character":16,"end_line":62,"end_character":27},"in_reply_to":"3f79a3b5_71ba7671","updated":"2018-10-12 09:35:38.000000000","message":"Yeah, good point. We should provide a separate exception, not this one.","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"413997e2d2053f26669ab88715dab235f9d1e588","unresolved":false,"context_lines":[{"line_number":59,"context_line":"`use-nested-allocation-candidates`_ That change will make sure that the forced"},{"line_number":60,"context_line":"move operation on a server that either has complex allocation on the source"},{"line_number":61,"context_line":"host or would require complex allocation on the destination host will be"},{"line_number":62,"context_line":"rejected with a NoValidHost exception by the Nova conductor."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7e39b7cc","line":62,"range":{"start_line":62,"start_character":16,"end_line":62,"end_character":27},"in_reply_to":"3f79a3b5_b2c47042","updated":"2018-10-15 12:51:49.000000000","message":"Ok, fair to say NoValidHosts is a reasonable exception. Thanks for replying quickly","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6405fb1612ddb08978bbcfb8e89c7cfa749da92c","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Please note that this spec removes the possibility to force live-migrate"},{"line_number":116,"context_line":"servers to hosts where the nova-compute is disabled as the ComputeFilter in"},{"line_number":117,"context_line":"the filter scheduler will reject such hosts."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Developer impact"},{"line_number":120,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_623866ec","line":117,"updated":"2018-10-12 09:35:38.000000000","message":"But like I said, if you\u0027re an operator and you really care about this, you can just write a custom filter that wouldn\u0027t accept disabled hosts and remove this ComputeFilter.","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"413997e2d2053f26669ab88715dab235f9d1e588","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Please note that this spec removes the possibility to force live-migrate"},{"line_number":116,"context_line":"servers to hosts where the nova-compute is disabled as the ComputeFilter in"},{"line_number":117,"context_line":"the filter scheduler will reject such hosts."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Developer impact"},{"line_number":120,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_be6c2fcf","line":117,"in_reply_to":"3f79a3b5_2bf314a1","updated":"2018-10-15 12:51:49.000000000","message":"Sure, I just wanted to make sure this is not really a problem about this spec so we could just remove the above. Anyway, just a nit given we all agree.","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"505daf50f8b73927c24967fc5e407c80212f07c5","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Please note that this spec removes the possibility to force live-migrate"},{"line_number":116,"context_line":"servers to hosts where the nova-compute is disabled as the ComputeFilter in"},{"line_number":117,"context_line":"the filter scheduler will reject such hosts."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Developer impact"},{"line_number":120,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_7de5673d","line":117,"in_reply_to":"3f79a3b5_623866ec","updated":"2018-10-12 09:51:00.000000000","message":"You and Matt seemed to care about this on IRC and in PS1 So I documented it (see my reply at L43 with the references)","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5936bc7f40b7775be71a63bad0b8406ed34c69e0","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Please note that this spec removes the possibility to force live-migrate"},{"line_number":116,"context_line":"servers to hosts where the nova-compute is disabled as the ComputeFilter in"},{"line_number":117,"context_line":"the filter scheduler will reject such hosts."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"Developer impact"},{"line_number":120,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_2bf314a1","line":117,"in_reply_to":"3f79a3b5_7de5673d","updated":"2018-10-13 16:40:02.000000000","message":"Yeah it\u0027s fine and good to point it out. We have ways to resolve this later if it\u0027s a problem for people (ignore ComputeFilter if live migrating to a disabled host). As I said above, I don\u0027t know that we should try and employ that until someone makes it necessary, and even then we might want it to be configurable.","commit_id":"23e91b7178dca7656db6b277a7967a76d5a36f2d"}]}