What happened?
This issue was reported on the Upbound up CLI, but after some debugging I'm fairly certain it's an issue here in upstream.
Injecting/extracting context to/from the function pipeline in render is done by spinning up a composition function (in the CLI process) and adding it to the function pipeline before it executes. With crossplane internal render we have to do it this way, since context is internal to the composite reconciler and we can't directly get/set it from the outside.
Currently the function we spin up listens on a unix domain socket, which we mount into the crossplane internal render container when using the docker render engine (the default). This works correctly on Linux, but on macOS with Docker Desktop it fails: since the container and the host don't share a kernel, they can't communicate over the socket. This leads to the render timing out because the reconciler running in crossplane internal render can't talk to the context injection/extraction function.
I expect this affects other platforms and container runtimes as well - particularly on macOS, where it's standard/necessary to run Docker in a VM.
How can we reproduce it?
crossplane composition render ... --context-files on macOS with Docker Desktop.
Suggested fix
We already handle letting the crossplane internal render container connect to functions that are listening on TCP on the host. Changing our context function to listen on a TCP port rather than a socket is probably a sufficient fix.
What environment did it happen in?
- Crossplane CLI version: v2.4.0
- Platform (e.g., linux/amd64): macOS
- Container runtime: Docker Desktop
What happened?
This issue was reported on the Upbound
upCLI, but after some debugging I'm fairly certain it's an issue here in upstream.Injecting/extracting context to/from the function pipeline in
renderis done by spinning up a composition function (in the CLI process) and adding it to the function pipeline before it executes. Withcrossplane internal renderwe have to do it this way, since context is internal to the composite reconciler and we can't directly get/set it from the outside.Currently the function we spin up listens on a unix domain socket, which we mount into the
crossplane internal rendercontainer when using the docker render engine (the default). This works correctly on Linux, but on macOS with Docker Desktop it fails: since the container and the host don't share a kernel, they can't communicate over the socket. This leads to the render timing out because the reconciler running incrossplane internal rendercan't talk to the context injection/extraction function.I expect this affects other platforms and container runtimes as well - particularly on macOS, where it's standard/necessary to run Docker in a VM.
How can we reproduce it?
crossplane composition render ... --context-fileson macOS with Docker Desktop.Suggested fix
We already handle letting the
crossplane internal rendercontainer connect to functions that are listening on TCP on the host. Changing our context function to listen on a TCP port rather than a socket is probably a sufficient fix.What environment did it happen in?