)]}'
{"openstackclient/volume/v3/volume.py":[{"author":{"_account_id":4523,"name":"Eric Harney","email":"eharney@redhat.com","username":"eharney"},"change_message_id":"5c7127bc7f7c8ec1a1e7e97e19f56e93f3c9cf7a","unresolved":true,"context_lines":[{"line_number":768,"context_line":"                        _(\"New size must be greater than %s GB\") % volume.size"},{"line_number":769,"context_line":"                    )"},{"line_number":770,"context_line":"                    raise exceptions.CommandError(msg)"},{"line_number":771,"context_line":"                if volume.status not in (\u0027available\u0027, \u0027in-use\u0027):"},{"line_number":772,"context_line":"                    msg \u003d ("},{"line_number":773,"context_line":"                        _("},{"line_number":774,"context_line":"                            \"Volume is in %s state, it must be available \""}],"source_content_type":"text/x-python","patch_set":1,"id":"1b8c0f99_24f5a46b","line":771,"updated":"2024-12-09 16:08:29.000000000","message":"I have to wonder if checking this status before attempting the extend operation (which is already done here) is really the best way to do this.\n\nIt basically means that the client will reject operations that may succeed when multiple operations are happening - i.e. if the status is moving into \u0027available\u0027 on the Cinder service between line 771 and line 789.\n\nChecking the status to generate a useful error message after the extend() call fails is the other option -- or maybe the failure of the operation gives a good enough message that we can use from Cinder API?  Something to think about...","commit_id":"03933e9a736daa3531e46d851fc7ecdc817a3944"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"7650853b254c4a2821bfc5c981823bb0bdc8985a","unresolved":true,"context_lines":[{"line_number":768,"context_line":"                        _(\"New size must be greater than %s GB\") % volume.size"},{"line_number":769,"context_line":"                    )"},{"line_number":770,"context_line":"                    raise exceptions.CommandError(msg)"},{"line_number":771,"context_line":"                if volume.status not in (\u0027available\u0027, \u0027in-use\u0027):"},{"line_number":772,"context_line":"                    msg \u003d ("},{"line_number":773,"context_line":"                        _("},{"line_number":774,"context_line":"                            \"Volume is in %s state, it must be available \""}],"source_content_type":"text/x-python","patch_set":1,"id":"00e07a10_cffa9354","line":771,"in_reply_to":"1b8c0f99_24f5a46b","updated":"2025-03-24 16:31:59.000000000","message":"Just so I understand correctly, you\u0027re suggesting there could be a TOCTOU issue here, right? It\u0027s a fair point but I guess the question is are Cinder\u0027s API error messages detailed enough for the user to figure this out without doing so client side? In my experience, they\u0027re not (same applies for most services) hence the client-side checks.\n\nAssuming not, then IMO the benefit of this detailed error message outweighs the small risk of such a TOCTOU issue arising. However, if the error messages _are_ detailed enough, I\u0027d okay with removing this logic entirely. I would not be okay with doing the check _after_ the call though, since we don\u0027t that anywhere else and it would be very surprising behavior.","commit_id":"03933e9a736daa3531e46d851fc7ecdc817a3944"}]}