r_studio_server_pro_app_settings for aws_sagemaker_domain/default_user_settings, aws_sagemaker_user_profile/user_settings
Expected Behavior
When setting the r_studio_server_pro_app_settings to disabled for the resource aws_sagemaker_user_profile or the resource aws_sagemaker_domain, Terraform should not try to set the r_studio_server_pro_app_settings user_group. Running multiple applies with no code changes should not detect drift regardless.
Actual Behavior
When setting the r_studio_server_pro_app_settings to disabled for the resource aws_sagemaker_user_profile or the resource aws_sagemaker_domain, Terraform repeatedly tries to set the user_group, even without code changes. If you don't set the r_studio_server_pro_app_settings at all you get a similar behavior where TF tries to "reset" access_status = "DISABLED" to null every time Terraform is run.Running back to back plan/apply with r_studio_server_pro_app_settings access_status set to "disabled" results in a "change" detected for each user and the domain:
Not setting the r_studio_server_pro_app_settings at all results in multiple applies detect drift as well:
aws_sagemaker_domain.sagemaker_domain output:
Run terraform plan, Terraform detects wanting to change the r_studio_server_pro_app_settings attribute user_group to "R_STUDIO_USER" even though the access_status is set to "DISABLED". Letting Terraform apply the "changes" then running apply again after no code changes ends in same result, Terraform detects a change to the r_studio_server_pro_app_settings attribute user_group to "R_STUDIO_USER".
Debug Output
No response
Panic Output
No response
Important Factoids
Updated to latest Terraform (1.7) and AWS provider (5.26) with same results.
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
Volunteering to Work on This Issue
If you are interested in working on this issue, please leave a comment.
If this would be your first contribution, please review the contribution guide.
Terraform Core Version
1.4.6, 1.7.0
AWS Provider Version
5.1.0, 5.26.0
Affected Resource(s)
r_studio_server_pro_app_settings for aws_sagemaker_domain/default_user_settings, aws_sagemaker_user_profile/user_settings
Expected Behavior
When setting the r_studio_server_pro_app_settings to disabled for the resource aws_sagemaker_user_profile or the resource aws_sagemaker_domain, Terraform should not try to set the r_studio_server_pro_app_settings user_group. Running multiple applies with no code changes should not detect drift regardless.
Actual Behavior
When setting the r_studio_server_pro_app_settings to disabled for the resource aws_sagemaker_user_profile or the resource aws_sagemaker_domain, Terraform repeatedly tries to set the user_group, even without code changes. If you don't set the r_studio_server_pro_app_settings at all you get a similar behavior where TF tries to "reset" access_status = "DISABLED" to null every time Terraform is run.Running back to back plan/apply with r_studio_server_pro_app_settings access_status set to "disabled" results in a "change" detected for each user and the domain:
aws_sagemaker_domain.sagemaker_domain output:
sagemaker_domain.aws_sagemaker_user_profile.default_user output:
Not setting the r_studio_server_pro_app_settings at all results in multiple applies detect drift as well: aws_sagemaker_domain.sagemaker_domain output:
sagemaker_domain.aws_sagemaker_user_profile.default_user output:
Relevant Error/Panic Output Snippet
No response
Terraform Configuration Files
Steps to Reproduce
Run terraform plan, Terraform detects wanting to change the r_studio_server_pro_app_settings attribute user_group to "R_STUDIO_USER" even though the access_status is set to "DISABLED". Letting Terraform apply the "changes" then running apply again after no code changes ends in same result, Terraform detects a change to the r_studio_server_pro_app_settings attribute user_group to "R_STUDIO_USER".
Debug Output
No response
Panic Output
No response
Important Factoids
Updated to latest Terraform (1.7) and AWS provider (5.26) with same results.
References
https://github.com/hashicorp/terraform-provider-aws/issues/33034
Would you like to implement a fix?
None