"failed to connect to any docker daemon" when using docker.getRegistryImage with docker.Provider and DOCKER_HOST changes
#1106
Comments
korosccj
added
kind/bug
blampe
added
impact/usability
|
Thank you @korosccj for the excellent repro! I can confirm I see the value of DOCKER_HOST persisted in state and then provided to the subsequent Configure call despite the environment variable being unset. This might be an issue with TF bridging, I need to look into it more. |
|
Ah, I overlooked the refresh in your example and I think that's the root of it. Refresh simply uses whatever you previously persisted in your state, so when you refresh after unsetting the environment variable it will still use the previous host value. This is why things work when the environment variable is unset and socat is still running. You could argue that the precedence of |
|
That does make sense in the case where |
The refresh will fail because it will alway use whatever the last successful update used (the original socat value). However if you change the value of This is admittedly awkward because we're mixing shared state with configuration that's scoped to a workstation. |
|
OK. I will test that. I do worry about the implications of not forcing the refresh before attempting to apply changes since it is a shared state with many other resources. Any thoughts on how best to safely proceed using that method since switching the env var precedence sounds like a change that would not happen? |
|
@blampe So do you have an idea in mind of what can be improved here? Should we not store |
Following up. We attempted to operate without requiring a refresh prior to applying changes to the stack and that caused other issues. Specifically in our case we have a flow like this,
The archive created in step 2 would not exist on a workstation other than the original creator. The We have since reverted back to requiring the refresh prior to any updates and continue to deal with the DOCKER_HOST issue. |
What happened?
What were you trying to accomplish?
Modify a pulumi stack from a system that had a different DOCKER_HOST configuration than the system that created the initial stack.
What did you expect to happen?
The stack to be updated successfully.
Which resources are involved?
Example
https://github.com/korosccj/pulumi-docker-test
Output of
pulumi aboutCLI
Version 3.112.0
Go Version go1.22.1
Go Compiler gc
Plugins
NAME VERSION
docker 4.5.3
nodejs unknown
Host
OS darwin
Version 13.5.2
Arch arm64
This project is written in nodejs: executable='/opt/homebrew/bin/node' version='v22.1.0'
Current Stack: organization/pulumi-docker-test/pulumi-docker-test
TYPE URN
pulumi:pulumi:Stack urn:pulumi:pulumi-docker-test::pulumi-docker-test::pulumi:pulumi:Stack::pulumi-docker-test-pulumi-docker-test
pulumi:providers:docker urn:pulumi:pulumi-docker-test::pulumi-docker-test::pulumi:providers:docker::docker-provider
docker:index/remoteImage:RemoteImage urn:pulumi:pulumi-docker-test::pulumi-docker-test::docker:index/remoteImage:RemoteImage::docker-container-pull
Found no pending operations associated with pulumi-docker-test
Backend
Name X-MacBook-Pro-1028.local
URL file://./
User X
Organizations
Token type personal
Dependencies:
NAME VERSION
@pulumi/docker 4.5.3
@pulumi/pulumi 3.116.1
@types/node 20.12.12
ts-node 10.9.2
typescript 5.4.5
Pulumi locates its logs in /var/folders/2s/w8c3231d7gv1yw2qdrd5nbsm0000gn/T/ by default
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: