Couldn't parse CURLOPT_RESOLVE entry in setup lib.sh of tls branch

[ssimmons806]

Problem description

The setup container is unable to connect with the elasticsearch container. The wait for elastic search function always fails with curl error 49 "Couldn't parse CURLOPT_RESOLVE entry".

Extra information

This is in the tls branch.

The resolve argument for the wait function in setup/lib.sh evaluates to elasticsearch:9200:elasticsearch when ELASTICSEARCH_HOST is not set (it is not set by default). But this format will always be invalid as the last part of the resolve arg should be an IP address HOST:PORT:ADDRESS.

function wait_for_elasticsearch {
  local elasticsearch_host="${ELASTICSEARCH_HOST:-elasticsearch}"

  local -a args=( '-s' '-D-' '-m15' '-w' '%{http_code}' 'https://elasticsearch:9200/'
    '--resolve' "elasticsearch:9200:${elasticsearch_host}" '--cacert' "$es_ca_cert" )

Stack configuration

Keeping data in a local directory instead of docker volume.

• /opt/elk copy of configurations
• /mnt/elk data

diff --git a/docker-compose.yml b/docker-compose.yml
index 98e4be0..b919f3c 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -12,16 +12,14 @@ services:
   tls:
     profiles:
       - setup
-    build:
-      context: tls/
-      args:
-        ELASTIC_VERSION: ${ELASTIC_VERSION}
-    user: root  # ensures we can write to the local tls/ directory.
+    image: $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/elk/elasticsearch:8.19.7
+    entrypoint: /entrypoint.sh
+    user: root
     init: true
     volumes:
-      - ./tls/entrypoint.sh:/entrypoint.sh:ro,Z
-      - ./tls/instances.yml:/usr/share/elasticsearch/tls/instances.yml:ro,Z
-      - ./tls/certs:/usr/share/elasticsearch/tls/certs:z
+      - /opt/elk/tls/entrypoint.sh:/entrypoint.sh:ro,Z
+      - /opt/elk/tls/instances.yml:/usr/share/elasticsearch/tls/instances.yml:ro,Z
+      - /mnt/elk/tls/certs:/usr/share/elasticsearch/tls/certs:z
 
   # The 'setup' service runs a one-off script which initializes users inside
   # Elasticsearch — such as 'logstash_internal' and 'kibana_system' — with the
@@ -40,17 +38,14 @@ services:
   setup:
     profiles:
       - setup
-    build:
-      context: setup/
-      args:
-        ELASTIC_VERSION: ${ELASTIC_VERSION}
+    image: $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/elk/elasticsearch:8.19.7
+    entrypoint: /entrypoint.sh
     init: true
     volumes:
-      - ./setup/entrypoint.sh:/entrypoint.sh:ro,Z
-      - ./setup/lib.sh:/lib.sh:ro,Z
-      - ./setup/roles:/roles:ro,Z
-      # (!) CA certificate. Generate using the 'tls' service.
-      - ./tls/certs/ca/ca.crt:/ca.crt:ro,z
+      - /opt/elk/setup/entrypoint.sh:/entrypoint.sh:ro,Z
+      - /opt/elk/setup/lib.sh:/lib.sh:ro,Z
+      - /opt/elk/setup/roles:/roles:ro,Z
+      - /mnt/elk/tls/certs/ca/ca.crt:/ca.crt:ro,z
     environment:
       ELASTIC_PASSWORD: ${ELASTIC_PASSWORD:-}
       LOGSTASH_INTERNAL_PASSWORD: ${LOGSTASH_INTERNAL_PASSWORD:-}
@@ -74,54 +69,45 @@ services:
   kibana-genkeys:
     profiles:
       - setup
-    build:
-      context: kibana/
-      args:
-        ELASTIC_VERSION: ${ELASTIC_VERSION}
+    image: $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/elk/kibana:8.19.7
     command:
       - bin/kibana-encryption-keys
       - generate
     network_mode: none
 
   elasticsearch:
-    build:
-      context: elasticsearch/
-      args:
-        ELASTIC_VERSION: ${ELASTIC_VERSION}
+    image: $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/elk/elasticsearch:8.19.7
     volumes:
-      - ./elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml:ro,Z
-      - elasticsearch:/usr/share/elasticsearch/data:Z
-      # (!) TLS certificates. Generate using the 'tls' service.
-      - ./tls/certs/ca/ca.crt:/usr/share/elasticsearch/config/ca.crt:ro,z
-      - ./tls/certs/elasticsearch/elasticsearch.crt:/usr/share/elasticsearch/config/elasticsearch.crt:ro,z
-      - ./tls/certs/elasticsearch/elasticsearch.key:/usr/share/elasticsearch/config/elasticsearch.key:ro,z
+      - /opt/elk/elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml:ro,Z
+      - /mnt/elk/elasticsearch:/usr/share/elasticsearch/data:Z
+      - /mnt/elk/tls/certs/ca/ca.crt:/usr/share/elasticsearch/config/ca.crt:ro,z
+      - /mnt/elk/tls/certs/elasticsearch/elasticsearch.crt:/usr/share/elasticsearch/config/elasticsearch.crt:ro,z
+      - /mnt/elk/tls/certs/elasticsearch/elasticsearch.key:/usr/share/elasticsearch/config/elasticsearch.key:ro,z
     ports:
       - 9200:9200
       - 9300:9300
     environment:
-      node.name: elasticsearch
-      ES_JAVA_OPTS: -Xms512m -Xmx512m
+      ES_SETTING_NODE_NAME: elasticsearch
+      ES_SETTING_DISCOVERY_TYPE: single-node
+      ES_JAVA_OPTS: >-
+        -Des.enforce.bootstrap.checks=true
+        -Xms512m
+        -Xmx512m
       # Bootstrap password.
       # Used to initialize the keystore during the initial startup of
       # Elasticsearch. Ignored on subsequent runs.
       ELASTIC_PASSWORD: ${ELASTIC_PASSWORD:-}
-      # Use single node discovery in order to disable production mode and avoid bootstrap checks.
-      # see: https://www.elastic.co/docs/deploy-manage/deploy/self-managed/bootstrap-checks
-      discovery.type: single-node
     networks:
       - elk
     restart: unless-stopped
 
   logstash:
-    build:
-      context: logstash/
-      args:
-        ELASTIC_VERSION: ${ELASTIC_VERSION}
+    image: $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/elk/logstash:8.19.7
     volumes:
-      - ./logstash/config/logstash.yml:/usr/share/logstash/config/logstash.yml:ro,Z
-      - ./logstash/pipeline:/usr/share/logstash/pipeline:ro,Z
-      # (!) CA certificate. Generate using the 'tls' service.
-      - ./tls/certs/ca/ca.crt:/usr/share/logstash/config/ca.crt:ro,z
+      - /opt/elk/logstash/config/logstash.yml:/usr/share/logstash/config/logstash.yml:ro,Z
+      - /opt/elk/logstash/pipeline:/usr/share/logstash/pipeline:ro,Z
+      - /mnt/elk/logstash:/usr/share/logstash/data:Z
+      - /mnt/elk/tls/certs/ca/ca.crt:/usr/share/logstash/config/ca.crt:ro,z
     ports:
       - 5044:5044
       - 50000:50000/tcp
@@ -137,29 +123,30 @@ services:
     restart: unless-stopped
 
   kibana:
-    build:
-      context: kibana/
-      args:
-        ELASTIC_VERSION: ${ELASTIC_VERSION}
+    image: $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/elk/kibana:8.19.7
     volumes:
-      - ./kibana/config/kibana.yml:/usr/share/kibana/config/kibana.yml:ro,Z
-      # (!) TLS certificates. Generate using the 'tls' service.
-      - ./tls/certs/ca/ca.crt:/usr/share/kibana/config/ca.crt:ro,z
-      - ./tls/certs/kibana/kibana.crt:/usr/share/kibana/config/kibana.crt:ro,Z
-      - ./tls/certs/kibana/kibana.key:/usr/share/kibana/config/kibana.key:ro,Z
+      - /opt/elk/kibana/config/kibana.yml:/usr/share/kibana/config/kibana.yml:ro,Z
+      - /mnt/elk/kibana:/usr/share/kibana/data:Z
+      - /mnt/elk/tls/certs/ca/ca.crt:/usr/share/kibana/config/ca.crt:ro,z
+      - /mnt/elk/tls/certs/kibana/kibana.crt:/usr/share/kibana/config/kibana.crt:ro,Z
+      - /mnt/elk/tls/certs/kibana/kibana.key:/usr/share/kibana/config/kibana.key:ro,Z
     ports:
       - 5601:5601
     environment:
+      SERVER_NAME: ***********
+      SERVER_PUBLICBASEURL: ***********
       KIBANA_SYSTEM_PASSWORD: ${KIBANA_SYSTEM_PASSWORD:-}
     networks:
       - elk
     depends_on:
       - elasticsearch
     restart: unless-stopped
+    healthcheck:
+      test: [
+        "CMD-SHELL",
+        "curl --silent --fail --output /dev/null --insecure https://localhost:5601/api/status"]
+      start_period: 30s
 
 networks:
   elk:
     driver: bridge
-
-volumes:
-  elasticsearch:
diff --git a/elasticsearch/config/elasticsearch.yml b/elasticsearch/config/elasticsearch.yml
index d3e32fe..fd672e9 100644
--- a/elasticsearch/config/elasticsearch.yml
+++ b/elasticsearch/config/elasticsearch.yml
@@ -5,7 +5,6 @@
 cluster.name: docker-cluster
 network.host: 0.0.0.0
 
-xpack.license.self_generated.type: trial
 xpack.security.enabled: true
 
 ##
diff --git a/kibana/config/kibana.yml b/kibana/config/kibana.yml
index 1f3c5fa..09a6b15 100644
--- a/kibana/config/kibana.yml
+++ b/kibana/config/kibana.yml
@@ -27,7 +27,7 @@ elasticsearch.ssl.certificateAuthorities: [ config/ca.crt ]
 ## Communications between web browsers and Kibana
 ## see https://www.elastic.co/guide/en/kibana/current/configuring-tls.html#configuring-tls-browser-kib
 #
-server.ssl.enabled: false
+server.ssl.enabled: true
 server.ssl.certificate: config/kibana.crt
 server.ssl.key: config/kibana.key

Docker setup

$ docker version

Client:
 Version:           25.0.13
 API version:       1.44
 Go version:        go1.24.9
 Git commit:        0bab007
 Built:             Mon Nov  3 00:00:00 2025
 OS/Arch:           linux/amd64
 Context:           default

Server:
 Engine:
  Version:          25.0.13
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.24.9
  Git commit:       165516e
  Built:            Mon Nov  3 00:00:00 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          2.1.5
  GitCommit:        fcd43222d6b07379a4be9786bda52438f0dd16a1
 runc:
  Version:          1.3.3
  GitCommit:        d842d7719497cc3b774fd71620278ac9e17710e0
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

$ docker compose version

Docker Compose version v5.0.0

Container logs

$ docker compose logs

setup-1  | [+] Waiting for availability of Elasticsearch. This can take several minutes.
setup-1  |    ⠍ Connection to Elasticsearch failed. Exit code: 49

[ssimmons806]

Is --resolve even needed? It works without it but I am assuming I'm missing something related to SSL when --resolve is not provided.

[antoineco]

Thanks for the detailed report 🙌

Do you happen to know what version of curl is installed inside your image? docker-elk is only tested against upstream images so it could be that this specific curl version is causing issues.

--resolve is only relevant for TLS, because the certificate SAN is generated for the name elasticsearch (the internal name resolved by Docker when containers are created by Compose) and the Server Name Indication (SNI) extension needs to match.
(For plain HTTP the Host: header is sufficient. We use the flag on the main branch simply to keep it as close to the tls branch as possible.)

[ssimmons806]

Oh ya good question! We copy the images from docker hub into our private repo.

$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/elk/elasticsearch:8.19.7 == https://hub.docker.com/layers/library/elasticsearch/8.19.7

I had assumed that was the same image as docker.elastic.co/elasticsearch/elasticsearch:8.19.7.

The curl version is

elasticsearch@a2fff8afc040:~$ curl --version
curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 (+libidn2/2.3.7) libssh/0.10.6/openssl/zlib nghttp2/1.59.0 librtmp/2.3 OpenLDAP/2.6.7
Release-Date: 2023-12-06, security patched: 8.5.0-2ubuntu10.6
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

And OS is

elasticsearch@a2fff8afc040:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.3 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

I get the same thing running above in docker run -it --rm docker.elastic.co/elasticsearch/elasticsearch:8.19.7 bash so I am confident it's all the same image.

I see we're behind a major version 9.2.2. I can see how it behaves when we upgrade.

Otherwise, were we supposed to set ELASTICSEARCH_HOST to an IP address somewhere?

[ssimmons806]

Yikes. Running docker run -it --rm docker.elastic.co/elasticsearch/elasticsearch:9.2.2 bash to see the difference. They changed a ton in 9.

That's likely the issue.

[elasticsearch@67fef17ae327 ~]$ curl --version
curl 7.76.1 (x86_64-redhat-linux-gnu) libcurl/7.76.1 OpenSSL/3.5.1 zlib/1.2.11 nghttp2/1.43.0
Release-Date: 2021-04-14
Protocols: file ftp ftps http https 
Features: alt-svc AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz NTLM SPNEGO SSL UnixSockets

[elasticsearch@67fef17ae327 ~]$ cat /etc/os-release 
NAME="Red Hat Enterprise Linux"
VERSION="9.7 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.7"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.7 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
BUG_REPORT_URL="https://issues.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.7
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.7"

[antoineco]

Ok so my assumption is that curl 7.x still supported resolving names in the ADDR part of --resolve, whereas curl 8.x no longer does.

ELASTICSEARCH_HOST does not need to be set. I introduced support for this environment variable to be able to easily test the script outside of a container, but the name alasticsearch is expected to resolve just fine with the upstream image, including on the release-8.x branch.

I'll look into a more portable alternative which doesn't rely on that name resolution. --connect-to looks promising.

[ssimmons806]

I bet you're right. I am going to try upgrading to 9 soon to confirm.

Feel free to close this.

[antoineco]

No need to update, but it would be great if you could try using the exact same image as we use on the release-8.x branch. I'm positive that images on all our branches have the same curl version because they are all based on the same base image.

docker run --rm docker.elastic.co/elasticsearch/elasticsearch:8.19.7 curl --version should show curl 7....

edit: I was wrong

[ssimmons806]

Welp, I don't know what is going on anymore.

Maybe they snuck in a change to their image? And you've got a previous image cached? Shifty.

$ docker image rm docker.elastic.co/elasticsearch/elasticsearch:8.19.7 
Untagged: docker.elastic.co/elasticsearch/elasticsearch:8.19.7
Untagged: docker.elastic.co/elasticsearch/elasticsearch@sha256:655d2801fa29bdb75c7d7862f32897f74b51ce5c7e0c1fa9ef3f5f40b07a8c88
Deleted: sha256:936afbde0cee0e7f552ae3653e3b98ad7e86478995baf1b6eb3e329d159a75bf
Deleted: sha256:9d26968707cd933d6e764ae03a290d987c3cc7d618fe7399d828d6c56cc2e6bb
Deleted: sha256:1f1096e91b257169325ceb8d0691bfa81bab08d8e0aa91231eac82784adda1b1
Deleted: sha256:f6685f94544a5e99e6bfa31590491d08bc00b59935721b0efdb6c4d3de3b8112
Deleted: sha256:8e523d849193a55fa631d10d7067c4b908a8e67aa9296e614f4e05722568f33a
Deleted: sha256:6e22c0f767ba39193ecf8d10e460bbe4859853cca7b385d300699f7e532b56e6
Deleted: sha256:a4093703e4076bfcb2ffc89f6d756d040ef24dc784a0f002cbd4b0fe3cad8d91
Deleted: sha256:315eabb133676090e14388c1a555cf4316f3dd4cd023d0b49edf32001bd304d9
Deleted: sha256:8a678fd63d72f0fdb0854130b2eae47f1bc37da1daae814364d94191e250f4e7
Deleted: sha256:7a3fa941ebb36fb4716d93e162c90b596772bd3da3377817e90bb821f4e88afc
Deleted: sha256:073ec47a8c22dcaa4d6e5758799ccefe2f9bde943685830b1bf6fd2395f5eabc

$ docker run -it --rm docker.elastic.co/elasticsearch/elasticsearch:8.19.7 curl --version
Unable to find image 'docker.elastic.co/elasticsearch/elasticsearch:8.19.7' locally
8.19.7: Pulling from elasticsearch/elasticsearch
ac355c58fb30: Pull complete 
ba7656a1bff7: Pull complete 
75c27d17be76: Pull complete 
4ca545ee6d5d: Pull complete 
6f44195fd4ae: Pull complete 
a74ac527ce37: Pull complete 
641c86503bb7: Pull complete 
11df6394b68b: Pull complete 
c0fa80cb96ef: Pull complete 
3713f5ca661e: Pull complete 
Digest: sha256:655d2801fa29bdb75c7d7862f32897f74b51ce5c7e0c1fa9ef3f5f40b07a8c88
Status: Downloaded newer image for docker.elastic.co/elasticsearch/elasticsearch:8.19.7
curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 (+libidn2/2.3.7) libssh/0.10.6/openssl/zlib nghttp2/1.59.0 librtmp/2.3 OpenLDAP/2.6.7
Release-Date: 2023-12-06, security patched: 8.5.0-2ubuntu10.6
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

[antoineco]

I was only assuming. Thank you for checking 👍

If both curl 7.x and 8.x are working in CI tests, I wonder what could be interfering.

I tried locally and saw the same message pop on my screen, but it turned out to be just a warning, and the IP was resolved nonetheless:

setup-1  | * Resolve address 'elasticsearch' found illegal!
setup-1  | * Couldn't parse CURLOPT_RESOLVE entry 'elasticsearch:9200:elasticsearch'!
setup-1  | *   Trying 172.18.0.2:9200...

Are you certain that your elasticsearch service is running, and not constantly restarting? As soon as mine becomes reachable, the warnings stop.

[ssimmons806]

It looks like curl 8.x never falls back to the IP directly. This is as is in the tls branch with silent -s argument removed

function wait_for_elasticsearch {
	local elasticsearch_host="${ELASTICSEARCH_HOST:-elasticsearch}"

	local -a args=( '-D-' '-m15' '-w' '%{http_code}' 'https://elasticsearch:9200/'
		'--resolve' "elasticsearch:9200:${elasticsearch_host}" '--cacert' "$es_ca_cert"
		)

setup-1  | [+] Waiting for availability of Elasticsearch. This can take several minutes.
setup-1  | curl: (49) Couldn't parse CURLOPT_RESOLVE entry 'elasticsearch:9200:elasticsearch'
setup-1  | curl: (49) Couldn't parse CURLOPT_RESOLVE entry 'elasticsearch:9200:elasticsearch'
setup-1  | curl: (49) Couldn't parse CURLOPT_RESOLVE entry 'elasticsearch:9200:elasticsearch'

...

setup-1  | curl: (49) Couldn't parse CURLOPT_RESOLVE entry 'elasticsearch:9200:elasticsearch'
setup-1  | curl: (49) Couldn't parse CURLOPT_RESOLVE entry 'elasticsearch:9200:elasticsearch'
setup-1  | curl: (49) Couldn't parse CURLOPT_RESOLVE entry 'elasticsearch:9200:elasticsearch'
setup-1  |    ⠍ Connection to Elasticsearch failed. Exit code: 49
setup-1 exited with code 49

Works if I remove --resolve from all the curls in setup/lib.sh. But I've got the default elasticsearch host from docker compose service.

This is silent -s without --resolve

function wait_for_elasticsearch {
	local -a args=( '-s' '-D-' '-m15' '-w' '%{http_code}' 'https://elasticsearch:9200/'
		'--cacert' "$es_ca_cert"
		)

setup-1  | [+] Waiting for availability of Elasticsearch. This can take several minutes.
setup-1  |    ⠿ Elasticsearch is running
setup-1  | [+] Waiting for initialization of built-in users
setup-1  |    ⠿ Built-in users were initialized
setup-1  | [+] Role 'filebeat_writer'
setup-1  |    ⠿ Creating/updating
setup-1  | [+] Role 'heartbeat_writer'
setup-1  |    ⠿ Creating/updating
setup-1  | [+] Role 'logstash_writer'
setup-1  |    ⠿ Creating/updating
setup-1  | [+] Role 'metricbeat_writer'
setup-1  |    ⠿ Creating/updating
setup-1  | [+] User 'metricbeat_internal'
setup-1  |    ⠿ No password defined, skipping
setup-1  | [+] User 'logstash_internal'
setup-1  |    ⠿ User exists, setting password
setup-1  | [+] User 'filebeat_internal'
setup-1  |    ⠿ No password defined, skipping
setup-1  | [+] User 'kibana_system'
setup-1  |    ⠿ User exists, setting password
setup-1  | [+] User 'heartbeat_internal'
setup-1  |    ⠿ No password defined, skipping
setup-1  | [+] User 'monitoring_internal'
setup-1  |    ⠿ No password defined, skipping
setup-1  | [+] User 'beats_system'
setup-1  |    ⠿ No password defined, skipping
setup-1 exited with code 0

[ssimmons806]

I think the reason CI isn't failing is tls branch is the only place with this --resolve arg and it's on 9.2.2. Other branches don't have the --resolve arg.

[antoineco]

Good point. tls is the only branch that uses --resolve in the setup script. Other branches only use it in CI scripts 🤦

I'm surprised that nobody stumbled upon this until now. Possibly very few people have tried the tls branch with Elastic v8 recently.

The fix should be trivial: we should only pass --resolve conditionally, if ELASTICSEARCH_ADDR is set (I'll rename from _HOST).
I'll push a fix later. Meanwhile feel free to remove the flag locally.

[ssimmons806]

All good ideas. Good call on the rename.

Yup I went ahead and just removed it for now. But I will appreciate being able to stay up-to-date with tls branch with the conditional approach.

Close this issue? I don't know the etiquette here.