)]}'
{"releasenotes/notes/max_pending_resizes-conf-70b11db3f8a3513e.yaml":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6cece42f372da732f56f0835c71b04d014814296","unresolved":false,"context_lines":[{"line_number":7,"context_line":"    resizes that have not yet been confirmed or reverted. When a user reverts"},{"line_number":8,"context_line":"    a resize to a smaller flavor, there is a possibility of exceeding cores and"},{"line_number":9,"context_line":"    ram quota because quota is not checked during a revert, so as not to block"},{"line_number":10,"context_line":"    reverts."}],"source_content_type":"text/x-yaml","patch_set":1,"id":"1f1a1f67_0100db66","line":10,"updated":"2017-07-13 15:39:05.000000000","message":"This (and the commit message) don\u0027t read very clearly to me. On changes with a reno, I\u0027ve been trying to go read the reno before the code to see if it makes sense without knowing the internals.\n\nThe existing behavior is what exactly? We don\u0027t check quota on revert? Was it that way before the counting quotas change or is that new behavior?\n\nWith this set, they won\u0027t be able to put more than N instances into a resize-related state, right? So they will have to confirm or revert something in order to do another one, right?\n\nWhat behavior do they see from the outside if they bump up against this limit?","commit_id":"2fd1a54c553bf64ec752a379e1e23288d7654eff"}]}