Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pulp fails to start on hosts that have ipv6 disabled #582

Open
plnordquist opened this issue Jan 17, 2024 · 3 comments
Open

Pulp fails to start on hosts that have ipv6 disabled #582

plnordquist opened this issue Jan 17, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@plnordquist
Copy link

Version
Pulp Operator: v1.0.0-beta.3
Pulp Image: quay.io/pulp/pulp-minimal:3.44.0

Describe the bug
With a Kubernetes cluster that has hosts that include the ipv6.disable=1 option on the Kernel command line, the pulp-content and pulp-api pods fail to start as they attempt to bind to [::]. The pod logs include the following content:

[2024-01-17 00:31:53 +0000] [1] [INFO] Starting gunicorn 21.2.0
[2024-01-17 00:31:53 +0000] [1] [ERROR] Retrying in 1 second.
[2024-01-17 00:31:54 +0000] [1] [ERROR] Retrying in 1 second.
[2024-01-17 00:31:55 +0000] [1] [ERROR] Retrying in 1 second.
[2024-01-17 00:31:56 +0000] [1] [ERROR] Retrying in 1 second.
[2024-01-17 00:31:57 +0000] [1] [ERROR] Retrying in 1 second.
[2024-01-17 00:31:58 +0000] [1] [ERROR] Can't connect to ('::', 24817)

To Reproduce
Steps to reproduce the behavior:

  1. Setup a Kubernetes cluster with hosts that have ipv6.disable=1 in the Kernel command line via GRUB_CMDLINE or grubby --update-kernel=ALL --args="ipv6.disable=1"
  2. Deploy the pulp operator and deploy a pulp CR
  3. Observe the pulp-api and pulp-content pods terminating

Expected behavior
Pulp should be deployable on systems that disable IPv6.

Additional context
As a workaround, I was able to mark the Pulp CR as unmanaged and edit the deployments to use /bin/sh as an entrypoint and command that includes an alternate bind address similar to how the telemetry system in the operator updates the pods at https://github.com/pulp/pulp-operator/blob/main/controllers/telemetry.go#L35-L48.

Another workaround I found was to create a Dockerfile from the quay.io/pulp/pulp-minimal:3.44.0 image and update the entrypoints at /usr/bin/pulp-api and /usr/bin/pulp-content to use an alternate bind address in both statements of the PULP_API_ENTRYPOINT and PULP_CONTENT_ENTRYPOINT environment variables.

@markleary
Copy link

I also ran into this issue and used a similar workaround to rebuild the pulp-minimal image. However, pulp-web also binds to ipv6 using a nginx configmap which is hardcoded here:

https://github.com/pulp/pulp-operator/blob/main/controllers/repo_manager/web.go#L379

@mikedep333 mikedep333 transferred this issue from pulp/pulp-operator Jan 23, 2024
@mikedep333
Copy link
Member

FYI: We moved the issue here because it lies in the pulp-oci-images scripts rather than in pulp-operator.

@mikedep333 mikedep333 added bug Something isn't working and removed Triage-Needed labels Jan 23, 2024
@plnordquist
Copy link
Author

This is probably the best place to make the change although there may be follow on changes required in the operator since the OpenTelemetry feature overrides the default entrypoint to instrument the execution of pulp-api.

I use the ingress-nginx ingress controller at https://github.com/kubernetes/ingress-nginx so I set the is_nginx_ingress option on my Pulp CR and that avoids deploying pulp-web pods. Maybe there needs to be a separate issue for the pulp-web pods in the operator repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants