Breaking change on 5.0.0 #185
Assignees
Labels
Comments
|
Hi @mreadings Please can you give us the crash logs so we can try and pin-point this? Thanks Paul |
|
I am getting exact same error when I upgrade to version 5 with a similar setup as @mreadings did: |
|
Same for me after upgrading to 5.2.0. Getting back to 4.3.0 made it work again. |
Closed
|
Issue is still present in 5.3. |
|
I noticed somewhere in Terraform issues that right now you should provide owners for application or/and service principal. Check if something similar to the following will help you (C#): |
|
I found this issue after some research, which is related to the terraform azuread provider hashicorp/terraform-provider-azuread#494. It looks like the After exporting the stack, removing the The thing about So in general it looks like that pulumi azuread 4.x state is not directly compatible with the pulumi azuread 5.x state |
|
@stack72 Hi Paul, could you please let us know if the issue is with Pulumi or a dependency? If the latter, we can chase at source. |
|
Issue is still present in 5.5. Neither of the workarounds suggested by @PawelStadnicki or @nicro950 works for me. |
|
Also seeing this on versions up to 5.5. Reverting to 4.3.0 works ok |
|
Issue still present in 5.6 |
|
Just wondering if this is something that will be looked at or whether the solution proposed for migrating from azure classic to azure native would be the correct course of action: https://www.pulumi.com/registry/packages/azure-native/from-classic/ We are reluctant to reimport our stack and would rather not expend the effort if there is a migration tool in dev |
|
AFAIK, there is no 'native' equivalent so you cannot migrate. Azure Native provider has only support for Azure AD B2C tenants. If I remember correctly, this is because Microsoft hasn't ported Azure AD to Azure Resource Manager, hence we have to keep using terraform. The fact that Pulumi is not even commenting on this ticket is really disappointing :-( |
|
We have now upgraded several stacks to use the new 5.x azure ad instead of the 4.x azure ad. The way we achieved it is the following:
It is also possible to try and remove the complete output block from the azure ad app registration resource. |
|
Thank you @nicro950, we followed your instructions successfully. We needed to tweak the settings of some resources later, but I consider that to be expected. |
|
I confirm @nicro950 workaround is working fine - many thanks! |
|
Seeing this with 5.11 as well. Had to revert back to 4.3. Also tried @nicro950's workaround to no avail 😞 |
|
Kristin man any chance you’d be willing to get on a cal with me so I can
understand this?
If so can you ping me on Twitter and we can work out a time
Paul
…On Tue, 14 Dec 2021 at 12:45, Kristian Hellang ***@***.***> wrote:
Seeing this with 5.11 as well. Had to revert back to 4.3. Also tried
@nicro950 <https://github.com/nicro950>'s fix to no avail 😞
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#185 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABXT3YKWMSN3RD4QBG6A6TUQ437LANCNFSM5DIYJIEQ>
.
|
|
I don't think I'll have time this week. We're pretty busy dealing with Log4Shell 😅 This is what I'm getting after updating to 5.x: I'm not sure if it's helpful. Let me know if there's anything more I can provide to make it easier to debug. I must say, it sounds like @nicro950 is onto something with #185 (comment). |
|
That looks like the exact same problem we had, but we manage to fix it with the steps I explained in an earlier comment. It could be that there is another field which is a bool value in the 4.x provider, and has a more complex value in the 5.x provider. @khellang Could it be that there is more than one ad application in the state? |
No, just one application. We are setting |
|
Was there any need to change the type of any fields when upgrading to the 5.x library? A way of troubleshooting that I used was upgrading the state to use the latest 5.x client and run refresh. That should result in the same problem being displayed, and then it is possible to remove one output block at a time to figure out what field is causing the problem. But from the error message it should be a field that is a bool in the 4.x provider, and something else in the 5.x provider. Not sure if there is more then the publicClient and _meta fields. |
No, it was a simple version bump and everything compiled cleanly. When running |
|
Hmm, very strage, we have updated probably between 10 and 20 stacks by now, and we have not encountered any other problems than I described in my previous comment with publicClient and the _meta field. It could also be worth a shot to remove all the output blocks from the azure ad resources in the stack, then reimport the stack. |
|
I had the same above error ( I am looking to upgrade a TS, using the Automation API, stack from v4.0.0 to v5.12.0 |
|
I also run into the issue with That's migrating the |
|
The only workaround I could find for the The changes I had to make:
|
|
I've been getting a 403 when calling |
|
Issue is still present with |
|
This appears to be resolved upstream. I was able to successfully run the following program to completion with Pulumi.AzureAD v5.26.1: using Pulumi;
return await Deployment.RunAsync(() =>
{
new Pulumi.AzureAD.Application("myapp", new Pulumi.AzureAD.ApplicationArgs
{
DisplayName = "myApp"
});
}); |
|
I am upgrading Pulumi.AzureAD from 2.6.1 to 5.32.0 and I am seeing this issue. |
|
Still an issue as of 5.37.0 upgrading from 4.x. Had to edit the state file. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Updated to pulumi-azuread 5.0.0
dotnet add package pulumi.AzureAD --version 5.0.0
now crashes when calling
var adApp = new Pulumi.AzureAD.Application(appName, new ApplicationArgs() { DisplayName = appName });
The text was updated successfully, but these errors were encountered: