trying to understand some patterns here - is there...
# general
b
trying to understand some patterns here - is there a reason config values aren’t stored in the state file?
l
So you can change them. It's a plain text file that you can view and edit. When you edit it, you know you have to deploy afterwards: it has the same priority as your source code. The state file is not (supposed to be) editable, and it represents what Pulumi has already pushed to the cloud. It's a record of what was done in the past. If you change that, then you've changed what Pulumi thanks has happened in the past, as opposed to what Pulumi plans to change in the future.
b
yeah i guess in my head config was state that was associated with a stack
whereas you can have different configs for the same stack
l
No, you can't. Config is stack level.
In pseduocode:
Copy code
state = deploy_to_cloud(config, code);
Config goes in to Pulumi; state comes out of Pulumi. You can't edit state: Pulumi does that. If you edit state, nothing happens and state is wrong. If you edit config then deploy, then state is updated by Pulumi and is right (because it reflects changes that Pulumi has made to the cloud).
b
i guess what i’m saying is if i have secret values i was hoping i could set it directly in the state
that way it doesn’t depend on an extra config file
l
You can create a simple custom resource and put the value in there. Mark the value as a secret and it'll be encrypted in state. That would be fine. How would you get the value into state though? You wouldn't want to hard code it in your project file, I think?
Or you could fetch it from somewhere else, like a vault or SSM parameters or equivalent.
But you cannot write directly to state. The only way to write to state is via
pulumi up
.
State is not a config file. The Pulumi config file is a config file: state is a database of deployed resources.
b
yeah i’m aware of state as a concept, have done a lot of work with iac tool internals ultimately though a separate config file is effectively two pieces of state we currently do use SSM and was wondering about creating a custom resource instead
l
No, config is not another piece of state: it's another source code file. You could create a custom resource. I don't know how you'd get the value in, though: your options are in source code, in config, or manually put into a vault or other cloud storage. Source code has the advantage of good review cover (PRs etc.) but it doesn't make encryption of config values easy; a vault is good for encryption but not so great for getting other devs to review changes; config files offer both advantages.