The actual 'value' of the secret (secret_data) is in the secret version result: https://www.pulumi.com/registry/packages/gcp/api-docs/secretmanager/getsecretversion/#result

@prehistoric-activity-61023 do you have any insight here btw?

Just to clarify, you want to create CloudSQL user with password acquired from GCP secret manager?

Can you paste the code you have right now?

Again I surmise because the secretmanager hasn't actually created the secret version as yet...?

but I guess (for now) you can workaround that by running

pulumi up

twice (first it’s gonna enable the service and fail with “API is disabled”, on the second run it should be fine)

Regarding the second one… well, maybe it’s right? Are you sure that

DB_PASS

already exists in secretmanager?

oh wait… you’re enabling the secretmanager WITHIN that stack, am I right?

it means you’re probably creating the password within this stack as well

if that’s so, can’t you use the password value directly? 🤔

basically, can you describe how you’re creating the secret version?

You most probably can simply reuse this value (and it will implicitly create a dependency graph within pulumi based on Input/Output mechanism) but it will be much easier if you paste some code 🙂.

@fast-arm-63150 I’ll wait for the code snippet where you actually create a secret version.

@prehistoric-activity-61023 how I create gcp secrets and secret versions

Ok, you’re using

depends_on

here and that part probably works. I assume it complains when it first executes

secretmanager.get_secret_version

and I think there’s no way to include

depends_on

in InvokeOptions. That’s the main reason why I have 2 separated projects for GCP (

gcp-project-bootstrap

where I enable all APIs and configure things such as top-level IAM rules and

gcp-project

where I actually create resources such as cloud sql, gke, memory store etc.). Additionally, I think

get_*

functions are only used when you need to get resources managed outside of your pulumi stack (or to get resources not managed by any IaC at all). In your case, you’re creating the secret and CloudSQL user in the same stack so there’s no need for that and you can pass these values directly.