You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
akp_instance.argocd: Modifying... [id=xxxxxxxxxxxx]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to akp_instance.argocd, provider
│ "provider[\"registry.terraform.io/akuity/akp\"]" produced an unexpected new value: .argocd_cm: element
│ "admin.enabled" has vanished.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
While attempting to enable the admin user by setting admin.enable = true and adding accounts.admin = login, the terraform apply shows the error above.
It seems that this is expected since the comment in the example states that "once you add that, remove the "admin.enabled" key". Introducing drift in the provider is a poor workflow for Terraform. The expectation that after enabling the admin user, it requires another change to the Terraform config to remove the admin.enabled key doesn't make sense. In a real-world use case, this would mean that the engineer would need to open a second PR to remove the key after the first change is accepted and applied.
Proposal: admin.enabled key should remain after it's set to true to avoid this confusing workflow and bug.
The text was updated successfully, but these errors were encountered:
While attempting to enable the admin user by setting
admin.enable = true
and addingaccounts.admin = login
, theterraform apply
shows the error above.It seems that this is expected since the comment in the example states that "once you add that, remove the "admin.enabled" key". Introducing drift in the provider is a poor workflow for Terraform. The expectation that after enabling the
admin
user, it requires another change to the Terraform config to remove theadmin.enabled
key doesn't make sense. In a real-world use case, this would mean that the engineer would need to open a second PR to remove the key after the first change is accepted and applied.Proposal:
admin.enabled
key should remain after it's set totrue
to avoid this confusing workflow and bug.The text was updated successfully, but these errors were encountered: