https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
b
i don't think it's possible at the moment, you'd need to set a property on the provider and then use 
pulumi.Config
in your main program and pass it in from there
f
ah, I see... thanks!
Is this documented somewhere and I missed it?
b
i'll try dig up the issue, but it's there somewhere
in general it's best not to have config in providers or components like this anyway
f
how so?
b
providers and components are intended to be reused, if you're adding config, you're making that less possible
example:
Copy code
export interface MyAppArgs {
  configItem: string
}

export interface MyApp {
  // do some stuff here
  const foo= args.configItem 
}
if you follow this pattern, you can let the user decided if they want to set the config
if not, you're forcing the user to use config
r
Amongst probably other reasons, your component should have explicit dependencies defined as part of their inputs, having a dependency on config is hidden away in the implementation and reliant on global state. The reason that this doesn’t work though is probably because dynamic providers are serialized into state, and config is not available at the time of serialization. Also, even if it were, you would only have the config value at the time of serialization stored in state.
👍 1
b
Komal with the much better explanation than i could hope to give 😄
❤️ 1
f
Gotcha, thanks for the explanation.
Sorry to revive a thread, but I must have a bad mental model of the under-the-hood differences between dynamic providers and "normal" providers. I don't have to specify, say, my 
aws:region
on every AWS resource I want to create. What's the distinction that I'm missing?
(Thanks in advance 🙇)
r
For aws I believe the region is a property set on the default provider
So the provider object being passed around to each resource contains the region. It all just happens sort of magically when you don’t use an explicit provider object
f
Right, but I still don't need to set the region as an input to any specific resource. Is it different with a dynamic provider because the provider is (or at least seems to be) bundled up with the resource itself?
r
Right, but I still don’t need to set the region as an input to any specific resource.
But you do need to set it as an input to the provider which itself is an input to each resource.
f
So... my particular dynamic resource needs to access the configuration information from another provider (to be concrete, I need to work around a hole in the Vault provider to create a particular resource in Vault, so I want to use the same Vault connection parameters that the rest of my project is using). However, it doesn't even appear that I can call, say, 
pulumi.Config().require("vault:address")
anywhere in my program (dynamic resource implementation or otherwise), without it trying to look for it in 
my-project:vault:address
. Is there a better way to try and approach this? Do I need to eschew the default Vault provider entirely, specify the relevant configuration parameters in my project's own namespace, create the provider in my code, and then manually pass that provider into every resource?
r
Have you tried 
pulumi.Config("vault").require("address")
?
Like to access “aws:region” you would do
Copy code
cfg = pulumi.Config("aws")
region = cfg.require("region")
So I wonder if the namespaced config is what you’re missing
f
Wow, I'm not sure how I overlooked that; this is exactly what I need! Thanks!
✨ 1
149 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