ansible / ansible/eda-server-operator
eda-api deployment healthchecks fail on v6-primary cluster
- Dominant language
- Jinja
- Stars
- 45
- Forks
- 41
- Avg merge
- 2d
- Merged PRs (30d)
- 1
Description
On a dual-stack-v6-primary k8s (one that has v6 cluster/service subnets specified first to kubelet), healthchecks for eda-api fail, leading to the pod never being listed as a service backend and eventually being killed.
Our case is RKE2 with this configuration for cluster/service cidrs:
```yaml
cluster-cidr: "fd10:ceff:1067::/56,172.20.0.0/16"
service-cidr: "fd12:ceff:1067::/112,172.22.0.0/16"
```
I *believe* this could be fixed by changing `0.0.0.0` to `[::]` in this template for the gunicorn and daphne listeners:
https://github.com/ansible/eda-server-operator/blob/main/roles/eda/templates/eda-api.deployment.yaml.j2
This would also increase v6 support for EDA overall.
However, there may need to be some logic applied to select v4 or v6 in this template - if a k8s is v4 or v6 only for example, or if it's dual stack v4 primary, etc.
The failing healthchecks can be seen to be attempting the v6 address of the pod.

Contributor guide
Research direction
Inspect roles/eda/templates/eda-api.deployment.yaml.j2, focusing on the gunicorn and daphne listeners and the healthcheck addresses. Reproduce the failure with the provided RKE2 dual-stack-v6-primary configuration, then verify healthchecks work without killing the pod across the relevant IPv4 and IPv6 modes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ansible, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100