If I have set all the `azure-native` properties in...
# azure
w
If I have set all the
azure-native
properties in my
Pulumi.<stack>.yaml
file, I thought they would be used if I do
new azure.Provider(<name>)
in the code, but that doesn't seem to be the case in my case.... or maybe I've got it wrong?
If that isn't the case, is there a way to use the settings in the yaml file when creating the provider?
Looking at the
ProviderArgs
I wonder how I do I set the default
location
when doing it programmatically? The
location
doesn't seem to be a property on the
ProviderArgs
.
I did discover this when I was missing the
location
on the provider causing it to fail... when I then tried to set the
location
I couldn't find the
location
among the arguments when creating the provider, so what is the default way of setting the default
location
for a provider so I don't have to specify it on the resources?
h
Not currently - the location is a required field on all resources so no way of leaving it off. Hypothetically you could leave the location off if your language didn’t enforce default properties (i.e. not Typescript) then you could use a stack transformation to add location if it’s not defined.
** I’ve not tested this, but think it should work
w
@happy-parrot-60128 , that's ok. But how does the provider use it when it is set as a config parameter? Intuitively I thought I would be able to provide the location when I created the provider programmatically, but that wasn't the case.
h
I don't think the provider uses a location config variable at all because it's always set on a per-resource basis
w
So when you set
azure-native:location
you set the default value on all resources and not on the provider? If yes, is there a way to set that default value programmatically?
h
Location doesn’t exist as a config variable - so it does nothing https://www.pulumi.com/registry/packages/azure-native/api-docs/provider/#inputs
w
I'm pretty sure you can set in as a config in the yank file, see the note on this page: https://www.pulumi.com/docs/get-started/azure/review-project/
h
Ah yes - it does appear to be optional on some resources - it’s odd because it’s not documented on the configuration object. Looks like Guin has opened a ticket summarising this issue here: https://github.com/pulumi/pulumi-azure-native/issues/1604
So back to your original question - perhaps when you’re creating an explicit provider, it doesn’t pull from the config file – or it uses a different key prefix.
w
Yeah, it didn't pull any of the variables, but since I was also logged in it only complained about the location. Is there a way to make the provider pull config when creating it or do I have to read them myself and the provide them when creating the constructor?
The way I checked which clientId that was used was by calling
getClientConfig
with the provider and it returned the client id for my user and not the SP I had configured in the config file.
h
A quick review of the code indicates what you’re doing should work. Does this work correctly when using the default provider rather than an explicit provider?
w
I can try to create a small repro of what works and doesn't work later today. Vacation mode, so not that much in front of the computer :)
I can update the ticket with the inconsistencies and how I would expect it to work.
h
No probs … have asked internally around differences between explicit vs default providers loading config so will see if someone else can cast some light on it. Either way, it seems the schema is missing the location in the provider args
👍 1
Ok - have confirmed that the behaviour you’re seeing is by-design – only the default provider uses the config file. Providers instantiated explicitly will only use ENV variables or the explicit args which are passed in to the provider constructor
w
@happy-parrot-60128 , got it. But should it be possible to provide the location when creating the provider?
h
Yes, it should be possible, but it’s missing. Have got this issue open for fixing it: https://github.com/pulumi/pulumi-azure-native/issues/1604
👍 1
Interestingly, on my journey through the I’ve also noticed that if you just set the location on your root resource group, then the resources which reference it can inherit its location.
w
I think that make sense. But is it pulumi behavior or is that the default behavior on azure?
h
The use of configuration for only default providers is global pulumi behaviour