Open evandam opened 2 years ago
For anyone reading this, it took me a while to realize that those params that are being changed to null are not passed in the original config.
The workaround is to set them to the actual default values or to required values in the resource configuration, like this:
resource "aws_cognito_identity_provider" "example" {
user_pool_id = aws_cognito_user_pool.example.id
provider_name = "Google"
provider_type = "Google"
provider_details = {
authorize_scopes = "email"
client_id = "redacted.apps.googleusercontent.com"
client_secret = "redacted"
attributes_url = null
attributes_url_add_attributes = true
...
...
}
attribute_mapping = {
email = "email"
username = "sub"
}
}
Hey @AutomationD, sorry if it was confusing!
For example, provider_details.attributes_url_add_attributes
is null
by default if excluded in Terraform, but Cognito seems to set it to "true"
by default, so I need to go in and update my configs to match the defaults, along with all the other attributes null by default.
I'm not sure how many of these are specific to the Google provider, but it would be nice if the resource set matching defaults to Cognito whenever possible if it makes sense.
I'm also assuming using ignore_changes
would work well.
Thanks @evandam, finally sorted it out. I was surprise this hasn't surfaced up in the cognito modules' issue trackers. Cheers!
@evandam where I work we got the same issue for access_token_validity
, id_token_validity
and token_validity_units
. They got set once to non-null values, then they were set back to null and now plan always show changes.
I had a look to AWS API:
AccessTokenValidity
, IdTokenValidity
and TokenValidityUnits
which prevents terraform aws provider from using Default
in the Schema for those attributes.Computed
in the Schema (which leads to "known after apply") for those attributes.typical Create API Response (no params except name and user pool id)
{
"UserPoolClient": {
"UserPoolId": XXXX,
"ClientName": ZZZZ,
"ClientId": YYYY,
"LastModifiedDate": 1661357178.444,
"CreationDate": 1661357178.444,
"RefreshTokenValidity": 30,
"TokenValidityUnits": {},
"AllowedOAuthFlowsUserPoolClient": false,
"EnableTokenRevocation": true,
"EnablePropagateAdditionalUserContextData": false
}
}
I have the feeling it's rather an "issue" on AWS API than in terraform aws provider itself. We use the same workaround as you do.
aws doc was updated and default values are the following: AccessTokenValidity: 1 hour IdTokenvalidity: 1 hour RefreshTokenValidity: 30 days
This should allow to set default values in the provider and avoid plan showing changes endlessly.
For me, I've copied values from a diff and put it in my provider_details , hence fixed the diff
Terraform docs are not fantastic on any of the default properties Probably, many of you found it somewhere in GitHub examples which are not up to date
Example :
~ provider_details = {
- "attributes_url" = "https://people.googleapis.com/v1/people/me?personFields=" -> null
Fix was to add the "attributes_url" = "https://people.googleapis.com/v1/people/me?personFields="
to provider_details
Community Note
Terraform CLI and Terraform AWS Provider Version
Affected Resource(s)
Terraform Configuration Files
Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
Expected Behavior
No changes after initial apply and subsequent ones
Actual Behavior
Steps to Reproduce
terraform apply
Important Factoids
The workaround seems to just be backporting the proposed changes in the plan to the resources, but there shouldn't be a need to do this.
References
0000