fix(local-setup): auto-detect podman socket for cloud-provider-kind

[silvi-t]

Description

• cloud-provider-kind hardcodes docker commands internally and fails when using podman unless DOCKER_HOST is explicitly set (upstream issue)
• The start-cloud-provider target now auto-detects podman and resolves the correct socket path, so make local-setup works out of the box with podman without requiring manual symlinks or docker context configuration

Changes

Bug Fix

• Detect podman runtime via $(CONTAINER_ENGINE) --version output
• Resolve podman socket path per platform:
  • macOS: podman machine inspect --format '{{.ConnectionInfo.PodmanSocket.Path}}'
  • Linux (rootful): /run/podman/podman.sock
  • Linux (rootless): /run/user/<uid>/podman/podman.sock
• Pass DOCKER_HOST through sudo env on macOS so the env var reaches the cloud-provider-kind process
• Docker users are unaffected — the podman detection is skipped when docker is the container engine

Verification steps

1. With podman: CONTAINER_ENGINE=podman make local-setup — verify LoadBalancer services get external IPs assigned
2. With docker: make local-setup — verify no change in behavior

Summary by CodeRabbit

Release Notes

• Chores
  • Enhanced cloud provider startup to better support Podman by auto-detecting an appropriate Docker-compatible socket (with macOS and Linux handling) and applying it to the running service.
  • Added clearer failure messaging when the Podman socket can’t be found.
  • Improved cluster existence checks to align with the selected container runtime.
• Documentation
  • Updated setup instructions for Linux Podman users to ensure the socket is available before running local setup.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 54b86b6e-7a74-46c2-a464-068375033afd

📥 Commits

Reviewing files that changed from the base of the PR and between 9502067 and 98abe8c.

📒 Files selected for processing (3)

• README.md
• make/dependencies.mk
• make/kind.mk

✅ Files skipped from review due to trivial changes (1)

• README.md

🚧 Files skipped from review as they are similar to previous changes (1)

• make/dependencies.mk

---

📝 Walkthrough

Walkthrough

The start-cloud-provider make target is updated to detect the Podman Docker-compatible socket when $(CONTAINER_ENGINE) is Podman, computing DOCKER_HOST_ENV via OS-specific methods and injecting it when starting cloud-provider-kind. The KIND cluster pre-check is aligned to use the same container engine provider. Linux Podman setup documentation is added.

Changes

Podman Socket Detection and Container Engine Alignment

Layer / File(s)	Summary
Podman socket detection and environment injection make/dependencies.mk	When $(CONTAINER_ENGINE) is Podman, detects the Docker-compatible socket via podman machine inspect on macOS or common Linux paths, validates the socket exists, sets DOCKER_HOST_ENV, logs the socket location, and injects the environment when starting cloud-provider-kind. On macOS, uses sudo env; on other platforms, runs directly without sudo.
KIND cluster check provider alignment make/kind.mk	The cluster-existence pre-check in kind-create-cluster now runs kind get clusters with KIND_EXPERIMENTAL_PROVIDER set to $(CONTAINER_ENGINE), ensuring the pre-check uses the same provider as cluster creation.
Setup documentation for Linux Podman README.md	Linux Podman users are instructed to enable the Podman user socket via systemctl --user enable --now podman.socket before running make local-setup.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Kuadrant/testsuite#973: Modifies the same start-cloud-provider target in make/dependencies.mk, introducing the start/stop mechanism that this PR extends with Podman socket detection and environment injection.

Suggested reviewers

• emmaaroche
• crstrn13

Poem

🐇 A rabbit hops through sockets and shells,
Sniffing out Podman wherever it dwells.
On macOS it shouts "sudo env, if you please!"
On Linux it runs with remarkable ease.
The cloud-provider starts with a socket in hand —
All furry paws working just as planned! 🌥️

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: auto-detecting the podman socket for cloud-provider-kind, which is the primary objective of the PR.
Description check	✅ Passed	The PR description is comprehensive and complete, covering the problem statement, detailed changes across multiple files, and verification steps for both podman and docker scenarios.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@make/dependencies.mk`:
- Around line 26-34: The rootless fallback socket path at the else branch (for
/run/user/$$(id -u)/podman/podman.sock) is assigned without validating that the
socket actually exists, unlike the first check which uses the -S test operator.
Add a validation check using the -S test operator for the rootless socket path
before assigning it to SOCKET, so that DOCKER_HOST is only set when the socket
path actually exists. This prevents setting DOCKER_HOST to a non-existent socket
that would cause failures later.
- Around line 37-40: The Linux path on line 40 fails to properly set the
DOCKER_HOST environment variable when launching cloud-provider-kind because it
uses $$DOCKER_HOST_ENV cloud-provider-kind directly, which causes the shell to
interpret the variable value as a command name rather than an environment
assignment. The macOS path correctly uses sudo env $$DOCKER_HOST_ENV to handle
this. Fix the Linux path by adding env before $$DOCKER_HOST_ENV on line 40,
changing it from $$DOCKER_HOST_ENV cloud-provider-kind to env $$DOCKER_HOST_ENV
cloud-provider-kind, so the environment variable is properly set before the
cloud-provider-kind command executes.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 9177e668-766d-4a43-a0e5-81dbfc4cfd1a

📥 Commits

Reviewing files that changed from the base of the PR and between b56b498 and 9502067.

📒 Files selected for processing (1)

• make/dependencies.mk

[didierofrivia]

LGTM 👍🏼