)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":36080,"name":"Erkin Mussurmankulov","display_name":"Eric","email":"mangust404@gmail.com","username":"mongoose404","status":"PS Cloud services employee"},"change_message_id":"3173102fea61dd6ebd3fabe4bd0c6aecd509d41d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"7203a43e_88681edf","updated":"2026-07-12 11:00:58.000000000","message":"@wchy1001@gmail.com\nHello, Wu. Please also take a look at this small patch.\n\nI found a bug that when the guest agent gets an existing data volume in the unclean state, for example, during the REBUILD process, it will format it. Wipe out all user data. I will consider this a high-priority bug.\n\nI faced it while running the rebuild tests for KeyDB/Valkey, and yesterday with PostgreSQL also.\n\nThis patch ensures that the guest agent will not perform volume formatting if it\u0027s unclean.\nAnd another related fix [here](https://review.opendev.org/c/openstack/trove/+/996931). It will ensure that the data volume is cleanly unmounted during the rebuild process.\n\nI think this is also a blocker for the SSL feature.","commit_id":"d12dd7cc04810cb2bbb37fef589b79e0421d11b0"},{"author":{"_account_id":26285,"name":"wu.chunyang","email":"wchy1001@gmail.com","username":"wu.chunyang"},"change_message_id":"8d15fa7a7e544c5572397c54918e3a0f20551cb6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"af478739_7d9aab33","updated":"2026-07-19 06:49:06.000000000","message":"LGTM now","commit_id":"2c30e6be77ef2d7814862a9133d4a88368c28f10"},{"author":{"_account_id":36080,"name":"Erkin Mussurmankulov","display_name":"Eric","email":"mangust404@gmail.com","username":"mongoose404","status":"PS Cloud services employee"},"change_message_id":"e6cf6ff7028d92738e22c3cc3f11c05aabf49a2d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"06eaa7f3_5761ab47","in_reply_to":"af478739_7d9aab33","updated":"2026-07-19 07:15:29.000000000","message":"Great, thanks!","commit_id":"2c30e6be77ef2d7814862a9133d4a88368c28f10"}],"trove/guestagent/volume.py":[{"author":{"_account_id":26285,"name":"wu.chunyang","email":"wchy1001@gmail.com","username":"wu.chunyang"},"change_message_id":"1c5c3d56a6c7e4785f09796e5a0a1efdab484472","unresolved":true,"context_lines":[{"line_number":107,"context_line":"                msg \u003d _(\"Volume \u0027%s\u0027 does not appear to be formatted.\") % ("},{"line_number":108,"context_line":"                    device_path)"},{"line_number":109,"context_line":"                raise exception.GuestError(original_message\u003dmsg)"},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"            log_fmt \u003d ("},{"line_number":112,"context_line":"                \"Failed to check filesystem on \u0027%(dev)s\u0027: %(err)s\""},{"line_number":113,"context_line":"            )"},{"line_number":114,"context_line":"            exc_fmt \u003d _("},{"line_number":115,"context_line":"                \"Failed to check filesystem on \u0027%(dev)s\u0027.\""},{"line_number":116,"context_line":"            )"},{"line_number":117,"context_line":"            log_and_raise("},{"line_number":118,"context_line":"                log_fmt, exc_fmt, {"},{"line_number":119,"context_line":"                    \u0027dev\u0027: device_path,"},{"line_number":120,"context_line":"                    \u0027err\u0027: pe.stderr,"},{"line_number":121,"context_line":"                })"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"        # Attempt automatic repair of recoverable filesystem issues."},{"line_number":124,"context_line":"        try:"}],"source_content_type":"text/x-python","patch_set":3,"id":"19973126_c7206420","line":121,"range":{"start_line":110,"start_character":0,"end_line":121,"end_character":18},"updated":"2026-07-17 01:55:46.000000000","message":"This logic may be problematic. When exit_code !\u003d 2 (i.e. an unexpected error rather than \"no filesystem found\"), log_and_raise raises a GuestError, which format() catches and then proceeds to mkfs. In that case we\u0027d wipe an existing volume even though the check merely failed. I think on an unexpected error we should let it propagate as a ProcessExecutionError instead of raising GuestError,so we don\u0027t force a format that could destroy database data.","commit_id":"d12dd7cc04810cb2bbb37fef589b79e0421d11b0"},{"author":{"_account_id":36080,"name":"Erkin Mussurmankulov","display_name":"Eric","email":"mangust404@gmail.com","username":"mongoose404","status":"PS Cloud services employee"},"change_message_id":"490ea39001234ea8371c036637324998adfab564","unresolved":true,"context_lines":[{"line_number":107,"context_line":"                msg \u003d _(\"Volume \u0027%s\u0027 does not appear to be formatted.\") % ("},{"line_number":108,"context_line":"                    device_path)"},{"line_number":109,"context_line":"                raise exception.GuestError(original_message\u003dmsg)"},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"            log_fmt \u003d ("},{"line_number":112,"context_line":"                \"Failed to check filesystem on \u0027%(dev)s\u0027: %(err)s\""},{"line_number":113,"context_line":"            )"},{"line_number":114,"context_line":"            exc_fmt \u003d _("},{"line_number":115,"context_line":"                \"Failed to check filesystem on \u0027%(dev)s\u0027.\""},{"line_number":116,"context_line":"            )"},{"line_number":117,"context_line":"            log_and_raise("},{"line_number":118,"context_line":"                log_fmt, exc_fmt, {"},{"line_number":119,"context_line":"                    \u0027dev\u0027: device_path,"},{"line_number":120,"context_line":"                    \u0027err\u0027: pe.stderr,"},{"line_number":121,"context_line":"                })"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"        # Attempt automatic repair of recoverable filesystem issues."},{"line_number":124,"context_line":"        try:"}],"source_content_type":"text/x-python","patch_set":3,"id":"97b38168_2ccf048f","line":121,"range":{"start_line":110,"start_character":0,"end_line":121,"end_character":18},"in_reply_to":"19973126_c7206420","updated":"2026-07-18 07:55:09.000000000","message":"Hm, yes, you\u0027re right. I do see what `log_and_raise` does now, and the previous implementation looks much worse for me.\nAlso, we do need better tests here, as this part is highly crucial. Check it out now, please.","commit_id":"d12dd7cc04810cb2bbb37fef589b79e0421d11b0"}]}