Bug
Installing Ascender on OCP (k8s_platform: ocp) fails at the "Wait until Ascender API is Up" task with:
Status code was -1 and not [200]: Request failed: <urlopen error [Errno 111] Connection refused>
The installer's uri check hits 127.0.0.1 instead of the actual OCP ingress VIP because /etc/hosts was modified by the installer itself.
Root Cause
Two issues combine to cause this:
1. config_vars.sh never prompts for use_etc_hosts on OCP
The prompt is gated to k3s/dkp/rke2 only:
if [[ ( $k8s_platform == "k3s" || $k8s_platform == "dkp" || $k8s_platform == "rke2") ]]; then
OCP is not included, so use_etc_hosts is never written to custom.config.yml.
2. default.config.yml defaults use_etc_hosts: true
Since the variable is absent from custom.config.yml, it falls through to the default:
3. k8s_setup_ocp.yml honors use_etc_hosts and writes localhost entries
The OCP setup task file has the same /etc/hosts tasks as the k3s setup, writing entries like:
127.0.0.1 ascender.example.com
127.0.0.1 ledger.example.com
This maps the Ascender hostname to localhost on the installer host. The final health check then curls localhost on port 443, gets connection refused, retries 200 times, and fails.
Impact
Every OCP install using the default config will hit this. The app deploys fine (pods running, route admitted, migration complete), but the installer reports failure. Users will waste time debugging networking and firewall issues when the real problem is a bad /etc/hosts entry the installer wrote.
Suggested Fix
Option A (preferred): Remove the /etc/hosts tasks from k8s_setup_ocp.yml entirely. OCP uses Routes with external DNS, so local host file entries are never appropriate.
Option B: Add ocp to the platform guard in config_vars.sh so the user is at least prompted, and default it to false for OCP.
Option C (minimal): Add a when: k8s_platform not in ["ocp", "aks", "gke", "eks"] condition to the /etc/hosts tasks so they only run on platforms where local resolution makes sense (k3s, rke2, dkp).
Environment
- Ascender 25.3.5
- AWX Operator 2.19.4
- OKD 4.17.0-okd-scos.0
- Installer host: RHEL 9
Workaround
Add use_etc_hosts: false to custom.config.yml before running setup.sh
Bug
Installing Ascender on OCP (
k8s_platform: ocp) fails at the "Wait until Ascender API is Up" task with:The installer's
uricheck hits127.0.0.1instead of the actual OCP ingress VIP because/etc/hostswas modified by the installer itself.Root Cause
Two issues combine to cause this:
1.
config_vars.shnever prompts foruse_etc_hostson OCPThe prompt is gated to k3s/dkp/rke2 only:
OCP is not included, so
use_etc_hostsis never written tocustom.config.yml.2.
default.config.ymldefaultsuse_etc_hosts: trueSince the variable is absent from
custom.config.yml, it falls through to the default:3.
k8s_setup_ocp.ymlhonorsuse_etc_hostsand writes localhost entriesThe OCP setup task file has the same
/etc/hoststasks as the k3s setup, writing entries like:This maps the Ascender hostname to localhost on the installer host. The final health check then curls localhost on port 443, gets connection refused, retries 200 times, and fails.
Impact
Every OCP install using the default config will hit this. The app deploys fine (pods running, route admitted, migration complete), but the installer reports failure. Users will waste time debugging networking and firewall issues when the real problem is a bad
/etc/hostsentry the installer wrote.Suggested Fix
Option A (preferred): Remove the
/etc/hoststasks fromk8s_setup_ocp.ymlentirely. OCP uses Routes with external DNS, so local host file entries are never appropriate.Option B: Add
ocpto the platform guard inconfig_vars.shso the user is at least prompted, and default it tofalsefor OCP.Option C (minimal): Add a
when: k8s_platform not in ["ocp", "aks", "gke", "eks"]condition to the/etc/hoststasks so they only run on platforms where local resolution makes sense (k3s, rke2, dkp).Environment
Workaround
Add
use_etc_hosts: falsetocustom.config.ymlbefore runningsetup.sh