hey all. I'm relatively new to pulumi, and I've just run into the issues around regions in AWS and using custom providers. I'm wondering if there's an easy way to get a custom provider to use all the configs defined for a default provider, like

aws:profile

or whatnot. Mostly what I'm doing is just instantiating custom providers to do multi-region work, and I want all the rest of the config the same, but when I do a

pulumi.Provider("aws", region="regionname")

in python, the custom provider seems to be missing all that config.

Yes, you can get the contents of the aws config namespace and use that if you want. You can merge it with hardcoded values, or values from other namespaces (aws-us-west-2. maybe?). You may want to set this if that is what you want:

pulumi:disable-default-providers:
  - aws

well I guess I'm just confused. I'm unsure how to get all the values from the

aws

namespace and pass them to

aws.Provider()

other than doing them one at a time. what's the function to return all config values under that namespace?

Nothing wrong with getting them one at a time and putting them into an object to pass around. There's only a few. Alternatively you could drop the aws namespace and define your own namespace with the same values, in an object. You can load objects from config.

well there's over 30 config vars that can be potentially modified according to the docs, and they could be added or changed with provider updates. I don't want my codebase to have to track all potential upstream config vars as they change and evolve. defining my own namespace doesn't help me avoid that problem either.

Do you really want to allow your stacks to provide all those values? I wouldn't.

what I want is for my stacks to be able to set anything in the documented configs for the provider and have them work as expected. it's not really that crazy. 🤷‍♀️

It is to me 🙂 AWS allows a lot of config that I prohibit in my org. A lot of it does not follow our required practices.

ok, so that's an unusual problem specific to you I guess. most languages and libraries understand the idea of default config values that get overridden, it seems very odd that pulumi providers don't have an easy way to do that, since it's been pretty standard since I started working in software in the 90s.

I'm not providing a language. I'm providing a way to create infrastructure in my accounts. I want to control that. I don't want the root account to be allowed to do that. I don't want long-life creds used. I prohibit these things.

sure. that's your use case. but can you see that many, perhaps even most, folks need a use case where they can just define some defaults and have them stay active even when using a custom provider to work cross-region? it's not exactly an uncommon scenario.

You're the first to request it 🙂

wild. I've done this with tons of different IAC tools across a bunch of different orgs, and it was rarely me who implemented it. Salt made this kind of thing super trivial, and had a whole hierarchy of config priority and stuff that worked really well.

Yea, I think so? However it probably won't be too much work. I don't think the provider has changed much since OIDC was added. That's about 20 months ago, maybe?

that's a bonus for sure. appreciate you confirming I wasn't missing something obvious, any way.