https://pulumi.com
Join Slack
Hey all. I'm a huge fan of Pulumi but I have to admit I'm pretty stumped on this one. After having ...
# general
c
Hey all. I'm a huge fan of Pulumi but I have to admit I'm pretty stumped on this one. After having switched to using a local path for my state, and then trying to make sure I had backups of that in the cloud, now I'm struggling to perform even the most basic of operations. For instance, after logging into the same directory I've always used, I'm getting errors when just trying to run 
pulumi logout
- 
error: getwd: no such file or directory
I'm also getting warnings when running 
pulumi about
-
Copy code
warning: Failed to read project: getwd: no such file or directory
warning: Failed to get information about the current stack: getwd: no such file or directory
Any idea what might be going on? If there's a more appropriate channel for this, let me know!
l
This is the right channel. Unlikely to be a Pulumi-specific solution, but something Pulumi is doing is incorrectly configured. We'll figure it out. Are you running from a container (Docker or similar?)? Have you looked for paths in your various yaml files and other configuration?
c
No to docker. Current setup is a normal linux desktop with pulumi 3.137.0 installed with brew. I'm curious if a local file login is supposed to be into a directory or a file
and what its relationship is with the 
~/.pulumi/
folder
l
When you log into 
--local
then your stacks are stored in ~/.pulumi
So if that path is wrong in some way (e.g. you've changed the meaning of ~), then Pulumi won't handle it.
c
what about when you use 
login file:///home/joshua/my_pulumi_state_folder/
l
Then ~/.pulumi is used only for the normal stuff (remembering which stack each project is logged into, etc.), and /home/joshua/my_pulumi_state_folder/ holds all your state files.
c
OK that is pretty helpful. I didn't realize the ~/.pulumi folder was so important - I figured whatever folder you 'logged into' had everything you needed
l
No, the Pulumi CLI stuff always goes in ~/.pulumi. Only the state stuff can be configured
c
If I've lost my original ~/.pulumi/ folder is it safe to say I'm not getting my state back? even if I have the those 'logged into' folders elsewhere?
l
Your state isn't lost. You've lost things like your "current" stack for each project (the asterisk beside the stack name in 
pulumi stack ls
) and the saved creds for your cloud backend. And your plugins. But you can recover from all of those things with very little effort.
You don't need to worry about restoring.
c
ok 'cause every time I try to log my old state folder, I'm not seeing any stacks and it makes a new 
.pulumi/
folder inside the folder I log into.
(and that 
.pulumi/
directory is, of course, empty)
l
And does that folder have directories like plugins/, templates/ and workspaces/? It should have a credentials.json, but that's all.
Except for local file state storage, which has no credentials 🙂
So a local empty .pulumi/ is ok for file:// backend.
Oh there's a double-meaning in a previous question, so I need to qualify my answer. You asked if you'd lost ~/.pulumi, is your state lost, and I said "no" because I assumed that your state was in the Pulumi service, S3 or similar. If your state was in ~/.pulumi and you'd lost that directory, then yes, your state is actually lost.
c
When I log in now, and try to say 'stack ls', I get "if you have not created a project yet, use pulumi new'
l
Are you in a project directory when you run 
pulumi stack ls
?
c
I was not, but now I moved to one, and it worked
fascinating
let me try a state refresh
l
Why fascinating?
c
this is the first time it's worked in about 3 hours of fighting this
l
You can't list the stacks in a non-project, it doesn't have any
c
"in a non-project" - so the pulumi cli always cares deeply about where you are (cwd) ?
l
Yes. Either cwd or the 
--cwd
parameter needs to be a directory with a Pulumi.yaml file.
c
OK thank you so much. So there's really nothing important in ~/.pulumi/ if I'm logged into a different directory? It can always get re-built?
l
Yes, so long as your state isn't in that directly also. It's your specific config, nothing to do with the infra or state. You can log in on other machines and use your app or S3 state from there too. However if you have logged in to file://~ (e.g. 
pulumi login --local
), then your state is also stored in ~/.pulumi. And it's nowhere else. So you can lose that state.
c
ya I've never used 
login --local
The goal here btw is to be able to use pulumi from multiple computers, and have the state actually stay in sync between them, with external synchronization software.
There shouldn't be anything inherently wrong with this approach, correct?
l
Yes, nothing wrong with that. 
file://
is the least-good storage for that, but it will work. Pulumi even does locking correctly, so if one person is running 
pulumi up
and writing to the state files, then another person can run 
pulumi up
and it'll wait intelligently until the state is safe to read.
However, all the other backends (s3, azblob, Pulumi service, etc.) are better for this.
c
least-good - curious why you say that. We had massive performance problems trying to use object storage as the backend.
l
Sorry to hear that. Object storage is being successfully used elsewhere. Object storage is intended for multiple-access scenarios, has backup built in, comes with "free" access controls and security, etc. It's just a better place to store business-critical files.
c
We'll still be backing up to GCS - we just dont't want to interact with it for the actual operations as it can take 100x longer
l
Ooo. That's significant.
c
ya, it's crazy. We actually timeout on our GCS access it can take so long.
2 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by