Use lib-common DownwardAPI to retrieve pod IP by bshephar · Pull Request #550 · openstack-k8s-operators/horizon-operator

bshephar · 2026-01-07T22:15:28Z

This change uses the lib-common env DownwardAPI [1] to write the pods IP to the env vars of the pod. We then retrieve this in local_settings.py to populate ALLOWED_HOSTS.

[1] https://github.com/openstack-k8s-operators/lib-common/blob/main/modules/common/env/env.go#L100-L114

Fixes #487
Jira: https://issues.redhat.com/browse/OSPRH-19216

openshift-ci · 2026-01-07T22:15:34Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: bshephar
Once this PR has been reviewed and has the lgtm label, please assign abays for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-ci · 2026-01-07T22:15:39Z

Hi @bshephar. Thanks for your PR.

I'm waiting for a openstack-k8s-operators member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

bshephar · 2026-01-07T22:20:00Z

@gibizer @fmount @stuggi Hey folks, happy New Year. Welcome to 2026.

Trying to solve a problem with IPV6 addresses raised by:
#478

I had initially proposed doing it this way:
#496

I know that @deshipu wasn't a huge fan of that implementation from the beginning. So, this is an attempt to find a compromise and still fix the problem of allowing Liveness/Readiness probes to healthcheck the individual pods.

What do y'all think of this alternative?

This change uses the `lib-common` env `DownwardAPI` [1] to write the pods IP to the env vars of the pod. We then retrieve this in `local_settings.py` to populate `ALLOWED_HOSTS`. [1] https://github.com/openstack-k8s-operators/lib-common/blob/main/modules/common/env/env.go#L100-L114 Fixes openstack-k8s-operators#487 Jira: https://issues.redhat.com/browse/OSPRH-19216 Signed-off-by: Brendan Shephard <bshephar@bne-home.net>

bshephar · 2026-01-07T22:48:42Z

Maybe we can avoid putting anything in local_settings.py using HTTPHeaders in the HTTPGetAction:
https://pkg.go.dev/k8s.io/api/core/v1#HTTPGetAction

That might be an even nicer approach actually - assuming that would actually work. Like, a request to the pod IP, but setting the Host HTTPHeader. Maybe Django would still block it, I'm not too sure. Just throwing theories and possible alternatives out there.

stuggi · 2026-01-08T09:52:15Z

Hi and Happy New Year!

If it works as intended, I'd prefer this implementation. its simple and easy.

fmount · 2026-01-12T07:54:45Z

+1 from me as well. It is clean enough and the complexity to achieve the goal is minimal.

I wanted to check some logs coming at least from the build-deploy job, but I don't see horizon enabled [1].

[1] https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openstack-k8s-operators_horizon-operator/550/pull-ci-openstack-k8s-operators-horizon-operator-main-horizon-operator-build-deploy-kuttl/2009200602453643264/artifacts/horizon-operator-build-deploy-kuttl/openstack-k8s-operators-gather/artifacts/must-gather/quay-io-openstack-k8s-operators-openstack-must-gather-sha256-6965f656a2712be18219bf47c45b31085032383eed3e09cbf2491ae5b2211ce0/namespaces/openstack/crs/openstackcontrolplanes.core.openstack.org/openstack-galera.yaml

gibizer

Happy New Year!

I only have clarification question but feel free to ignore me to merge this without me as I saw others are OK with this approach and I'm pretty unfamiliar with this.

I'm low on context here. Does simply adding "localhost" and "::1" to the ALLOWED_HOSTS not enough to allow the probes to access horizon?

gibizer · 2026-01-12T08:36:56Z

 	envVars["ENABLE_WATCHER"] = env.SetValue(enabledServices["watcher"])
 	envVars["CONFIG_HASH"] = env.SetValue(configHash)
 	envVars["UNPACK_THEME"] = env.SetValue("true")
+	envVars["POD_IP"] = env.DownwardAPI("status.podIP")


I'm not familiar with the IP handling of k8s. Is the IP pre-determined before a pod is created? Without that I don't see how this construct can inject the IP of the pod to the env of the process running within the pod as seems it seems circular (we need to create the pod to know the IP, but we need to add that IP to the pod ENV when it is started)jm

Yeah, I mean, we should be able to see if this is a problem in the CI env logs I guess. But the IP is allocated from the CNI prior to the pod starting iiuc.

I'll check the must-gather to see if we can confirm this though.

bshephar · 2026-01-12T08:48:48Z

Happy New Year!

I only have clarification question but feel free to ignore me to merge this without me as I saw others are OK with this approach and I'm pretty unfamiliar with this.

I'm low on context here. Does simply adding "localhost" and "::1" to the ALLOWED_HOSTS not enough to allow the probes to access horizon?

Hey!

Na, unfortunately not. But it is a fair question, so context for everyone else. ALLOWED_HOSTS is a list of sites Django is allowed to serve. So for example, horizon.example.net, 192.168.3.4, etc.

Ref:

https://docs.djangoproject.com/en/6.0/ref/settings/#allowed-hosts

So we need to add each pod IP to the list, otherwise the pod won't respond to the health check request.

gibizer · 2026-01-13T14:41:14Z

Happy New Year!
I only have clarification question but feel free to ignore me to merge this without me as I saw others are OK with this approach and I'm pretty unfamiliar with this.
I'm low on context here. Does simply adding "localhost" and "::1" to the ALLOWED_HOSTS not enough to allow the probes to access horizon?

Hey!

Na, unfortunately not. But it is a fair question, so context for everyone else. ALLOWED_HOSTS is a list of sites Django is allowed to serve. So for example, horizon.example.net, 192.168.3.4, etc.

Ref:

https://docs.djangoproject.com/en/6.0/ref/settings/#allowed-hosts

So we need to add each pod IP to the list, otherwise the pod won't respond to the health check request.

Ahh OK. Thanks. So we put the pod's IP to the allowed list and assume that the probe is using that IP when requesting some URL from the pod to check readyness/liveness. Make sense.
I'm a bit worried about the Pod IP in the env of the Pod logic as noted inline. But if that works then I'm totally fine with this PR.

openshift-ci Bot requested review from deshipu and mcgonago January 7, 2026 22:15

openshift-ci Bot added the needs-ok-to-test label Jan 7, 2026

bshephar mentioned this pull request Jan 7, 2026

Improve robustness of get_pod_ip() function #496

Open

bshephar force-pushed the dowward-api-pod-ip branch from e822a85 to 3b10d73 Compare January 7, 2026 22:35

stuggi added ok-to-test and removed needs-ok-to-test labels Jan 8, 2026

gibizer reviewed Jan 12, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use lib-common DownwardAPI to retrieve pod IP#550

Use lib-common DownwardAPI to retrieve pod IP#550
bshephar wants to merge 1 commit intoopenstack-k8s-operators:mainfrom
bshephar:dowward-api-pod-ip

bshephar commented Jan 7, 2026 •

edited

Loading

Uh oh!

openshift-ci Bot commented Jan 7, 2026

Uh oh!

openshift-ci Bot commented Jan 7, 2026

Uh oh!

bshephar commented Jan 7, 2026

Uh oh!

bshephar commented Jan 7, 2026 •

edited

Loading

Uh oh!

stuggi commented Jan 8, 2026 •

edited

Loading

Uh oh!

fmount commented Jan 12, 2026

Uh oh!

gibizer left a comment

Uh oh!

gibizer Jan 12, 2026

Uh oh!

bshephar Jan 13, 2026

Uh oh!

bshephar commented Jan 12, 2026 •

edited

Loading

Uh oh!

gibizer commented Jan 13, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

bshephar commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci Bot commented Jan 7, 2026

Uh oh!

openshift-ci Bot commented Jan 7, 2026

Uh oh!

bshephar commented Jan 7, 2026

Uh oh!

bshephar commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stuggi commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fmount commented Jan 12, 2026

Uh oh!

gibizer left a comment

Choose a reason for hiding this comment

Uh oh!

gibizer Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

bshephar Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

bshephar commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gibizer commented Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

bshephar commented Jan 7, 2026 •

edited

Loading

bshephar commented Jan 7, 2026 •

edited

Loading

stuggi commented Jan 8, 2026 •

edited

Loading

bshephar commented Jan 12, 2026 •

edited

Loading

gibizer commented Jan 13, 2026 •

edited

Loading