)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"fde873f51725149cf6501beea34345b6cf03b8bb","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d4d74608_9a67b3f6","updated":"2026-07-17 04:53:33.000000000","message":"I wonder if we could use the retrying library, which is already widely used, to handle that retry logic instead of implementing our own version ?","commit_id":"f29448a52173186a948748652f22ce65eaf059ac"},{"author":{"_account_id":38176,"name":"Sei Sano","display_name":"say3no","email":"sei.sano@ntt.com","username":"say3no"},"change_message_id":"79d3d47fb8771aae9cbef0c0d314a21a46ad8539","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f10ca3dc_44c81939","updated":"2026-10-09 05:54:09.000000000","message":"Thanks for the detailed analysis, and sorry this has been waiting. I\u0027d like to help settle the direction so you can\nmove forward.\n\nI think the scope of this change is right: retry only the service lookup and enable/disable. These calls are idempotent, so retrying them on a 5xx is safe.\n\nThat is also why I\u0027d avoid the keystoneauth1 Adapter approach here. Passing status_code_retries / retriable_status_codes through nova_client.Client() should be easy (the kwargs reach SessionClient as is), but it would apply to every Nova call, including non-idempotent ones like evacuate. A 502 from a load balancer does not guarantee that nova-api never received the request, so retrying those could send the same action twice.\n\nFor the retry logic itself, I\u0027d prefer tenacity:\n\n* It is in global-requirements, and masakari already pulls it in through taskflow and tooz, so it adds no new\ndependency in practice.\n* cinder, neutron, ironic and manila use it, so the pattern will look familiar.\n\nSomething like this should keep the current behavior:\n\n  _retry_on_transient \u003d tenacity.retry(\n      retry\u003dtenacity.retry_if_exception(_is_transient_nova_error),\n      stop\u003dtenacity.stop_after_attempt(3),\n      wait\u003dtenacity.wait_incrementing(start\u003d2, increment\u003d2),\n      before_sleep\u003dtenacity.before_sleep_log(LOG, logging.WARNING),\n      reraise\u003dTrue,\n  )\n\nreraise\u003dTrue matters here, so that translate_nova_exception still sees the original novaclient exception instead of tenacity.RetryError.\n\nCould you update the change along these lines? The tests can stay mostly the same, just mock the sleep differently.","commit_id":"f29448a52173186a948748652f22ce65eaf059ac"},{"author":{"_account_id":290,"name":"Antony Messerli","email":"antony@mes.ser.li","username":"antonym"},"change_message_id":"f9723194a41f08300030954b24770a0359c6cc5e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e08728ce_dee051d3","in_reply_to":"d4d74608_9a67b3f6","updated":"2026-09-01 21:41:29.000000000","message":"Happy to use a library rather than rolling our own. One thing though: retrying appears to be unmaintained upstream, and it\u0027s only listed in the testing section of global-requirements, masakari doesn\u0027t currently depend on it. Would tenacity make more sense (cinder/neutron/ironic/manila all use it), or could we leverage keystoneauth1.adapter.Adapter instead? novaclient\u0027s SessionClient subclasses it, and it already supports connect_retries / status_code_retries / retriable_status_codes with exponential backoff and Retry-After handling.","commit_id":"f29448a52173186a948748652f22ce65eaf059ac"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"1eced5b3138bbd15a8435676d898fc4596cd2dc7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9546b8db_1b6e6a64","in_reply_to":"e08728ce_dee051d3","updated":"2026-09-22 03:40:48.000000000","message":"retrying is not very active but I regard it as a stable lib rather than an abandoned one. It\u0027s used in nova for example. However I don\u0027t have strong preference of it over tenacity so either is fine.\n\nRegarding usage of keystoneauth1.adapter I think that\u0027s preferred though we need update how we load credentials from conf, I guess.","commit_id":"f29448a52173186a948748652f22ce65eaf059ac"}]}