Still trying to figure out what `pulumi up` freeze...
# general
Still trying to figure out what
pulumi up
freezes everytime. Can someone familiar with go tell me what
is doing? It seem to be the function that is stuck.
Copy code
$ pulumi up --logtostderr -v=9
I0507 13:47:42.755386   28275 backend.go:410] found username for access token
I0507 13:47:43.697486   28275 backend.go:410] found username for access token
Previewing update (dev):
I0507 13:47:44.093878   28275 backend.go:410] found username for access token
I0507 13:47:44.093702   28275 backend.go:887] Stack dev being updated to version 1
I0507 13:47:44.476166   28275 plugins.go:76] gatherPluginsFromProgram(): gathering plugins from language host
I0507 13:47:44.476447   28275 plugins.go:426] GetPluginPath(language, nodejs, <nil>): found on $PATH /home/gsuess/.pulumi/bin/pulumi-language-nodejs
I0507 13:47:44.476491   28275 plugin.go:83] Launching plugin 'nodejs' from '/home/gsuess/.pulumi/bin/pulumi-language-nodejs' with args:
I0507 13:47:44.553950   28275 langruntime_plugin.go:170] langhost[nodejs].GetPluginInfo() executing
I0507 13:47:44.554275   28275 langruntime_plugin.go:83] langhost[nodejs].GetRequiredPlugins(proj=leaderboard,pwd=/home/gsuess/meteor-leaderboard,program=.) executing
     Type                 Name             Plan     
     pulumi:pulumi:Stack  leaderboard-dev           
System Messages
  ^C received; cancelling. If you would like to terminate immediately, press ^C again.
  ^C received; terminating
I've tried to isolate the problem, but could not bisect it (seems to be very prone to some cache somewhere). Related thread about past attempts to get this problem isolated here: Any help would be really appreciated. Can't figure this one out so far.
To reproduce this, run:
Copy code
curl <> | sh
meteor create --minimal mymeteor-app
cd mymeteor-app
meteor npm install @empirica/meteor-deploy
npx meteor-deploy init
Copy code
pulumi stack select
Copy code
npx meteor-deploy stack configure aws-ecs-ec2 --instanceType t2.medium
pulumi up --logtostderr -v=9
Pulumi is trying to install the plugins required for the project
if it's AWS resources then it will autoacquire the aws plugin binary
I'm not qute sure what meteor is so I'm not sure how it's execting the command
Does it even integrate with Pulumi?
meteor shouldn ot be a relevant, here. its just a nodejs platform.
so what is the application that Pulumi is trying to deploy?
i am buiding
a tool that deploys a meteor project.
can you show me the code that Pulumi is deploying?
the reason why i say meteor is not relevent is because I am confident that it does not hit any of its code.
FWIW, there is no way of being able to invoke Pulumi other than the CLI itself - if you are wrapping Pulumi with another tool and trying to invoke other than CLI, it will not work
yea, i figured that out already. But I am running it through
pulumi up
. so that's not the issue either.
Ok, I have just tried running the above commands in docker image. And could not reproduce the issue.
seems to be some symlink problem.
Anyway this is the code that it is running:
So given that it's not reproducible on a docker image I suspect that it's either nvm or some symlinks created by
npm link
on my machine
it is reproducible in docker?
So given that it's reproducible on a docker
sorry, i meant "not reproducible *"
will check with nvm now.
use any caches ?
it will check to see if there is a version of the plugin available in the plugin cache
it will be in the pulumi directory
pulumi plugin ls will tell you what is currently install
but it will always go through node_modules to check what plugins it needs? There is no cache for the check itself?
i am asking because I am iteratively trying to isolate the problem.
caches can make this hard.
@wonderful-dog-9045 no, it doesn't store the plugins in node_modules
it uses where Pulumi is installed by default
▶️ ls $HOME/.pulumi/plugins
what i meant by that question is whether
caches the result of the check itself (not the plugins)
given that it seems to crash on the check and not on the installation of the plugins
it does not - it will make it on each request AFAICR
the plugin can be removed at any time so it needs to check for the plugin to be there
So I am running on the assumption that it hangs on a circular symlink:
However checking
there are symlinks
can you point me to the implementation of the check loop so I can see which directories it is trying to traverse?
(nvm is giving me a headache with installation on docker, I guess it doesn't like to be run as root.) So i am trying to figure this out from the other side.)
ok the issue is not with npm
After hours and hours of picking into things I finally found the culprit. I had an uncommitted package.json in completely unrelated subdirectory. Did not expect pulumi to poke into it, but it did and it found some dodgy file:/ dependency in it.
Took me at least 4 hours to find this.