)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":38863,"name":"Kubilay Kaptanoglu","display_name":"kkaptanoglu","email":"kkaptanoglu@vmind.com.tr","username":"kkaptanoglu"},"change_message_id":"7d6cc66841f58c981f1f9ca52df197e979471496","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"5861a0a7_ab13ce26","updated":"2026-09-02 13:19:10.000000000","message":"recheck","commit_id":"7f604b350e2c296f7b939b0bfb63ce2ed9bbdfa3"},{"author":{"_account_id":37306,"name":"Piotr Milewski","display_name":"Piotr Milewski","email":"vurmil@gmail.com","username":"vurmil"},"change_message_id":"374893eab94455ed0714d360594fb00b68bcd0fa","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"2a37b0c4_bb3daf2d","updated":"2026-09-04 10:52:48.000000000","message":"Few comments:\n\n* `kolla_internal_fqdn` doesn\u0027t really work here since there is no LB behind it.\n* Could we support multiple `opensearch_address` values? Not everyone has an LB in front of OpenSearch/Elasticsearch, so pointing directly to a few nodes would be useful.\n* I\u0027d also add this option to the docs with an example.","commit_id":"2043b457dbe99fdfbbbfdf68bf8db54231b52b23"},{"author":{"_account_id":37313,"name":"Alma MAILLET-CONTOZ","display_name":"Alma MAILLET-CONTOZ","email":"alma.maillet-contoz@infomaniak.com","username":"nicolasmc","status":"Intern SRE at Infomaniak"},"change_message_id":"57611304f97cd4beb8b3332b44b03c3f591f1440","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"a357f8b7_247c073a","updated":"2026-09-04 09:27:44.000000000","message":"LGTM","commit_id":"2043b457dbe99fdfbbbfdf68bf8db54231b52b23"},{"author":{"_account_id":37306,"name":"Piotr Milewski","display_name":"Piotr Milewski","email":"vurmil@gmail.com","username":"vurmil"},"change_message_id":"7a5bb0f40f023a0000bf283ba713b4af42de164a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"c3370e11_2a85fbcb","in_reply_to":"2a37b0c4_bb3daf2d","updated":"2026-09-04 10:54:07.000000000","message":"https://review.opendev.org/c/openstack/kolla-ansible/+/953458","commit_id":"2043b457dbe99fdfbbbfdf68bf8db54231b52b23"},{"author":{"_account_id":38863,"name":"Kubilay Kaptanoglu","display_name":"kkaptanoglu","email":"kkaptanoglu@vmind.com.tr","username":"kkaptanoglu"},"change_message_id":"ed2a140d42eb192a3b282094728aaf60c9cb0158","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"f9cdb411_4314f794","in_reply_to":"8cb491df_0134fc2f","updated":"2026-09-04 14:02:02.000000000","message":"Making opensearch_address support multiple addresses has a broader impact than just Fluentd.\n\nIt directly affects several existing variables and integrations that currently expect a single OpenSearch endpoint:\n\n`opensearch_connection_string`: affects deployments using osprofiler and would break when opensearch_address becomes a list.\n`opensearch_internal_endpoint`: used by Grafana datasource configuration, post-config.yml, blackbox_exporter, and similar components.\n`cloudkitty_elasticsearch_url`: CloudKitty can use OpenSearch/Elasticsearch as its storage backend, and this would also break if multiple addresses are passed.\n\nAlso, in the current  implementation, Fluentd does not use opensearch_address at all and reads the OpenSearch hosts directly from the inventory. Other components, however, still expect opensearch_address to be a single endpoint.\n\nConsidering the scope of the required changes, one possible approach would be to keep opensearch_address as a single endpoint and introduce a Fluentd-specific list variable such as fluentd_opensearch_addresses. However, this would effectively introduce a duplicate OpenSearch endpoint variable, since opensearch_address would still be required by the other integrations mentioned above.\n\nThe components mentioned above still require a single OpenSearch endpoint. From my perspective, if an external OpenSearch cluster with multiple nodes is used, placing an L4 load balancer in front of the cluster would be a simpler and less intrusive solution than either changing the semantics of `opensearch_address` across Kolla-Ansible or introducing a new Fluentd-specific variable such as `fluentd_opensearch_address`.","commit_id":"2043b457dbe99fdfbbbfdf68bf8db54231b52b23"},{"author":{"_account_id":34034,"name":"Franciszek Przewoźny","display_name":"Franciszek Przewozny","email":"przewozny.franciszek@gmail.com","username":"fprzewozn","status":"OpenStack Engineer / SRE @ Opera Software"},"change_message_id":"a249069f1d16d9c73bd4d6b3e6642539c4991a0a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"e468e807_1af099df","in_reply_to":"8fee680f_ff787138","updated":"2026-09-29 19:44:43.000000000","message":"As agreed on IRC, we\u0027re revoking multi-OpenSearch idea.","commit_id":"2043b457dbe99fdfbbbfdf68bf8db54231b52b23"},{"author":{"_account_id":38863,"name":"Kubilay Kaptanoglu","display_name":"kkaptanoglu","email":"kkaptanoglu@vmind.com.tr","username":"kkaptanoglu"},"change_message_id":"ab921fbc59e4e439df0fb584db5c0054e2b7e934","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"8cb491df_0134fc2f","in_reply_to":"c3370e11_2a85fbcb","updated":"2026-09-04 12:52:16.000000000","message":"The ability to support multiple OpenSearch addresses makes sense. I\u0027ll work on it.","commit_id":"2043b457dbe99fdfbbbfdf68bf8db54231b52b23"},{"author":{"_account_id":34034,"name":"Franciszek Przewoźny","display_name":"Franciszek Przewozny","email":"przewozny.franciszek@gmail.com","username":"fprzewozn","status":"OpenStack Engineer / SRE @ Opera Software"},"change_message_id":"d33e04672942e1f111b5a9c14b034d97c7bd0630","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"564fac0b_531f8e5c","in_reply_to":"c3370e11_2a85fbcb","updated":"2026-09-04 12:34:27.000000000","message":"Yes please! if multiple `opensearch_address` values support were added, I could drop custom override in my environments for the output.","commit_id":"2043b457dbe99fdfbbbfdf68bf8db54231b52b23"},{"author":{"_account_id":38863,"name":"Kubilay Kaptanoglu","display_name":"kkaptanoglu","email":"kkaptanoglu@vmind.com.tr","username":"kkaptanoglu"},"change_message_id":"e5e2e50d4c0b09f8406754b88e2f1c0f89494c66","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"8fee680f_ff787138","in_reply_to":"f9cdb411_4314f794","updated":"2026-09-07 06:20:43.000000000","message":"An additional suggestion:\n\nI think we can keep backward compatibility by allowing `opensearch_address` to accept either a string or a list, and normalize it internally.\n\nFor example, we could introduce an internal list representation:\n\n```yaml\nopensearch_addresses: \"{{ [opensearch_address] if opensearch_address is string else opensearch_address }}\"\n```\n\nThis way, existing deployments using:\n\n```yaml\nopensearch_address: \"10.0.0.10\"\n```\n\nwould continue to work, while also allowing:\n\n```yaml\nopensearch_address:\n  - \"10.0.0.10\"\n  - \"10.0.0.11\"\n```\n\nComponents that support multiple OpenSearch endpoints could use the normalized list directly.\n\nFor components that still require a single endpoint, we could use the first item from the normalized list.\n\nFor example:\n\n```yaml\nopensearch_addresses: \u003e-\n  {{\n    [opensearch_address]\n    if opensearch_address is string\n    else opensearch_address\n  }}\n\nopensearch_primary_address: \"{{ opensearch_addresses | first }}\"\n```\n\nThen consumers could simply use the appropriate normalized variable:\n\n```jinja2\n# Components supporting multiple endpoints, such as Fluentd\nhosts {{ opensearch_addresses | join(\u0027,\u0027) }}\n\n# Components requiring a single endpoint\nhost {{ opensearch_primary_address }}\n```\n\nThis would allow us to extend `opensearch_address` to support multiple endpoints without breaking existing string-based configurations, while keeping the compatibility logic in one place instead of adding type checks throughout the templates.","commit_id":"2043b457dbe99fdfbbbfdf68bf8db54231b52b23"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"9edd16bc93b93c29d0dec9fbf99d2a497a8c4008","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"8a94c6c0_8875a2df","updated":"2026-10-13 17:47:43.000000000","message":"trivial","commit_id":"a68e99bbaead4a0415668103fa18a8169101528b"}]}