)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"4b8f4965226c56b64ff6958985743e39bae24666","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"a446833c_c98ef758","updated":"2026-07-22 07:01:49.000000000","message":"Giving it further thought I\u0027m now bit hesitant to implement these public interfaces now because at this moment we expect this feature is quite specific to consul, while I agree we could implement that specific capability key used within \"some\" drivers (at this moment, only consul) for internal health check\n\nIs there any critical use case which heavily depends on these interfaces to externally discover presence of internal healtcheck ? IMHO consumers can pass healthcheck_endppint_url regardless of the driver used and can hit the required API regardless of the probe status (so that the implementation works not only for consul).","commit_id":"a22dbde51d6a3586f7bc3a0b7ab8db3cad265b9d"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"8e0bba29d0fb25fa37b5a07d5eef569fd01f890f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ee9bb35c_f0ba4c2a","in_reply_to":"a446833c_c98ef758","updated":"2026-07-23 05:47:26.000000000","message":"Yes, I understand this well. I will see if there is any way we can keep the functionality without doing a specific interface.","commit_id":"a22dbde51d6a3586f7bc3a0b7ab8db3cad265b9d"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"2ba56dcabd075fec5becec0a3bc9a14fd1ad47ff","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"fb6115c2_d8394226","in_reply_to":"ee9bb35c_f0ba4c2a","updated":"2026-07-23 06:14:26.000000000","message":"Just to make my stance clear, I\u0027m ok with treating health_url as an internal capability key for the capability but am not too sure about the other public interfaces. Can we just implement the capability key and omit the other parts.","commit_id":"a22dbde51d6a3586f7bc3a0b7ab8db3cad265b9d"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"85d698923c0a6756c9c3ce8a3ba21b60b93cea35","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"74e8c69b_1c67c167","in_reply_to":"ee9bb35c_f0ba4c2a","updated":"2026-07-23 06:16:04.000000000","message":"So, here\u0027s the other option: we can drop this CR entirely, and the consul driver just continues to set `provides_endpoint_health \u003d True` on itself, and the oslo.messaging code that uses tooz checks for it. That works entirely fine, but it\u0027s a bit dirty since it\u0027s essentially removing the formal contract and making oslo.messaging rely on an informal convention that nothing in tooz actually declares or enforces -- any future backend author (or even a refactor of the consul driver) would have no signal that the attribute is meaningful, and oslo.messaging is left duck-typing an attribute name by string with a getattr(..., False) fallback. So that keeps tooz\u0027s public surface minimal at the cost of the discoverability and type-safety the base-class attribute gives us.\n\nI\u0027m honestly fine either way — if you\u0027d rather not carry an interface that only Consul implements today, I\u0027ll happily drop the CR (for the sake of getting the rest of the chain accepted) and make things work with a few tweaks elsewhere. I can move provides_endpoint_health onto the Consul driver, fold the tiny healthcheck_endpoint_url helper into the driver as a plain capabilities.get(\u0027health_url\u0027) read, and keep health_url as a Consul-specific capability string. I\u0027m just concerned about how dirty that feels...","commit_id":"a22dbde51d6a3586f7bc3a0b7ab8db3cad265b9d"}]}