Skip to content
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

(reopen #1402) azuread_application_app_role always either deletes / recreates the role on each apply #1411

Closed
AlexcFrench opened this issue Jun 19, 2024 · 4 comments

Comments

@AlexcFrench
Copy link

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureAD Provider) Version

Terraform v1.8.5
on windows_amd64

  • provider registry.terraform.io/hashicorp/azuread v2.52.0
  • provider registry.terraform.io/hashicorp/azurerm v3.108.0

Affected Resource(s)

azuread_application_app_role

  • azuread_XXXXX

Terraform Configuration Files

resource "azuread_application" "appreg" {
  display_name = "test123"
}

resource "azuread_application_app_role" "role1" {
  application_id       = azuread_application.appreg.id
  role_id              = "6bd5554f-a935-4e9f-9223-c87a64c22fba"
  allowed_member_types = ["User"]
  description          = "desc"
  display_name         = "displayname"
  value                = "123"
}

Debug Output

Panic Output

Expected Behavior

once applied there should be no changes required on subsequent plan/apply runs

Actual Behavior

a tf plan / apply creates the role
Another plan / apply deletes the role
Another plan / apply recreates the role

No code changes at any point

Steps to Reproduce

tf init
tf plan
tf apply
tf plan
tf apply

Important Factoids

was opened initially as #1402, related to #1344 but #1344 was closed last week as part of #1403.
I've used 2.52.0 but the problem still exists

References

  • #0000
@AlexcFrench AlexcFrench changed the title (reopen #1402) (reopen #1402) azuread_application_app_role always either deletes / recreates the role on each apply Jun 19, 2024
@nbaju1
Copy link

nbaju1 commented Jun 20, 2024

You need to add the ignore_changes lifecycle argument to the azuread_application resource when using this in combination with azuread_application_app_role.

resource "azuread_application" "appreg" {
  display_name = "test123"
  
  lifecycle {
    ignore_changes = [
      app_role,
    ]
  }
}

resource "azuread_application_app_role" "role1" {
  application_id       = azuread_application.appreg.id
  role_id              = "6bd5554f-a935-4e9f-9223-c87a64c22fba"
  allowed_member_types = ["User"]
  description          = "desc"
  display_name         = "displayname"
  value                = "123"
}

Ref: https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/application_app_role

@AlexcFrench
Copy link
Author

AlexcFrench commented Jun 20, 2024

Hi @nbaju1 - thanks very much and I can confirm that works. I had read the documentation but assumed it meant if there was a conflicting block 'app_roles' in the app reg definition and an app roles resource it would need the ignore_changes so that's my mistake and thanks for the solution.

Any ideas why it works this way?? In AzureRM if I create vnet resource and a subnet resource I do not have to 'ignore_changes' for the subnets in the vnet configuration...

Something specific to AzureAD and graph?

@manicminer
Copy link
Contributor

@AlexcFrench In both the AzureRM and AzureAD providers, due to upstream changes in Terraform over time, we are phasing out the use of so-called "optional & computed" properties -this is the mechanism by which we have historically masked these diffs. Existing implementations of this will be removed as we release new major versions of the each provider, whilst we are intentionally avoiding adding new implementations of this.

Going forward, particularly in the next major releases of each provider, it will be necessary to use ignore_changes for any properties or blocks that are managed by more than one resource in the same configuration.

@AlexcFrench
Copy link
Author

Thanks @manicminer I was not aware of this but it's very useful and we can start future proofing now.

Thanks for all your great work chaps :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants