[josephtate]

Freshen up #1651 (rebased onto current main, cherry-picked as-is, original authorship preserved) and add the test coverage + changelog fragment the original PR lacked, so maintainers have a working, up-to-date version of this approach to evaluate against #1700, which takes a different approach.

#1651 (by @macwinnie) took the simplest possible fix for #1380: drop the hardcoded IPv4/SingleStack IPFamilies/IPFamilyPolicy entirely from the four Services that set them (pulp-api, pulp-content, database, otel), letting the Kubernetes API server default them from the cluster's own Service CIDR -- exactly how pulp-web and the redis Service already behave today. No new CRD field, no configuration surface at all.

Verified against real kind clusters, not just unit tests:

• Single-stack IPv6-only cluster: Services get real IPv6 ClusterIPs, confirmed independently addressable (curl from a separate pod returns HTTP:200 against the live ClusterIP). This is the actual bug in Operator won't start services in single-stack IPv6 EKS #1380 -- the API server previously rejected these Services outright (spec.ipFamilies[0]: Invalid value: "IPv4": not configured on this cluster).
• Dual-stack cluster: no regression -- the full Pulp stack (api/content/web/worker) still comes up and serves traffic correctly. However, the Services stay single-stack IPv4-only; they do not become dual-stack, since omitting ipFamilies/ipFamilyPolicy makes Kubernetes default a Service to the cluster's primary family (IPv4, since it's listed first in --service-cluster-ip-range), not to dual-stack, even when the cluster supports both.

Caveat: this does not give you a way to opt into dual-stack. It only solves the single-stack-IPv6-only case; a cluster that supports both families will still get IPv4-only Services, identical to today's behavior. #1700 adds explicit spec.ip_family_policy/spec.ip_families CR fields for deliberate dual-stack support, and was verified on the same dual-stack cluster to produce genuinely dual-stack Services (both an IPv4 and an IPv6 ClusterIP simultaneously, both independently reachable).

Original PR by @macwinnie: #1651 (closed as stale, never got a maintainer /ok-to-test, not rejected on technical merit).

AI disclosure

Per the AI policy: the added test coverage, changelog fragment, and this description were written with Hermes Agent running claude-sonnet-5-5 (Anthropic). The commit carries an Assisted By: label. Martin Winter's original commit (cherry-picked unchanged, preserving his authorship) is not covered by this disclosure. I reviewed the code and this description and can explain the change.

closes #1380

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: josephtate
Once this PR has been reviewed and has the lgtm label, please assign git-hyagi 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]

Hi @josephtate. Thanks for your PR.

I'm waiting for a pulp 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.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

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.