The pkg/cluster package still shells out via exec for kind, kubectl, and (where still used) docker/podman CLIs. We already use the Kubernetes and Docker APIs extensively elsewhere in func.
Longer-term goal: replace those exec calls with library/API usage (kind Go API, client-go apply, docker/podman SDK) the same way builders graduated from wrapping CLIs to library calls.
Context
Raised by @matejvasek on #3856 (in-cluster registry migration); tracking here so the stepping-stone path stays explicit:
why we use exec() instead of using Go code, kind/kubectl is Go code. Also why call docker via CLI exec()? Why not API?
Scripts -> Go with the current structure is the intentional first step; next is replace execs with stdlib/APIs where possible.
Suggested Stages:
- kind: create/delete/cluster ops via kind's Go API
- kubectl apply / wait: client-go (or existing apply helpers) for resources we already model as objects
- docker/podman host config: daemon.json / registries.conf via API or small pure-Go writers (already partially pure file I/O)
See also:
The
pkg/clusterpackage still shells out viaexecfor kind, kubectl, and (where still used) docker/podman CLIs. We already use the Kubernetes and Docker APIs extensively elsewhere in func.Longer-term goal: replace those
execcalls with library/API usage (kind Go API, client-go apply, docker/podman SDK) the same way builders graduated from wrapping CLIs to library calls.Context
Raised by @matejvasek on #3856 (in-cluster registry migration); tracking here so the stepping-stone path stays explicit:
Scripts -> Go with the current structure is the intentional first step; next is replace execs with stdlib/APIs where possible.
Suggested Stages:
See also: