-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistency issue between pulumi-azuread & pulumi-azure? #38
Comments
Hi @juchom you are correct - each of the packages don't reflect the same configuration variables and they both should. I have opened a PR in our tfgen generation repo that creates the configuration to ensure we pick this validation up in the future With regards to using the same Thoughts? Paul |
Hi @stack72 , I'm not sure to understand how things will change after your PR? Could you please give an example of the config before -> after. Julien |
Hi @juchom The issue is, we are missing some fields that are not mapped in the azure provider. Therefore when this PR gets merged we will be alerted to those and then we can roll those changes out This PR helps us understand the underlying schema better so we are fully covered Paul |
Ok, when I opened this issue, I had this in mind: Imagine you use the azure & azuread provider in your stack, we can do that with config variables:
But if we use the environment variable we only have I see your point to keep |
I'd love this. Having them share the same env vars is a massive pain when trying to configure them to access different tenants. Instead of CI simply setting appropriate env vars for both, one has to jump through hoops. Even an optional dedicated set of AD env vars that are checked before the default "ARM" ones would be fantastic, and still provide backwards compatibility. |
I'm currently working with both packages in my solution and according to the pulumi documentation the configuration for each package use the following variables:
pulumi-azure
pulumi-azuread
Would it make sense to rename azuread:* to azure:* because they use the same environment variables?
The text was updated successfully, but these errors were encountered: