rhythmic-finland-36256
09/02/2019, 7:25 PMdirenv
. Maybe this also works for Azure ARM env vars. But is there a better concept? If not, are there plans of doing so or are there good reasons for always having a default in place? Thanks for your help!white-balloon-205
aws:region
) which will ensure all resources that are created with the default provider will fail. This indeed does require a per-stack setting though.
https://github.com/pulumi/pulumi/issues/2059 is related and/or the same depending on which approach we take to address this.rhythmic-finland-36256
09/03/2019, 1:48 PMStackReference
output, this already works fine by setting pulumi config set kubernetes:context invalid-context-disabling-default-provider
that gives a good error message if there is a resource not using an explicit provider.
Would you recommend to also use explicit providers for the cloud providers? In the beginning (e.g. working with just one Azure subscription, using explicit providers seems like too much effort as the error will not happen when clientId
, clientSecret
, tenantId
, … are defined for the stack. This only gets problematic as soon as a second, explicit provider (e.g. to control global dns) is introduced, which then would mean to switch everything to explicit configuration. So I’d still like to see some flag at that point in time that allows to disable the default provider to avoid an accidental use of it.azure:clientId
notation so one can leverage creating a provider by just passing a full config object (mirroring all the same keys that exist under azure
)?