Open acwwat opened 3 weeks ago
Thank you for opening the issue @acwwat . I can reproduce it with the instance example you have provided.
On the subsequent apply:
awscc_lightsail_instance.example: Refreshing state... [id=example-instance]
Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# awscc_lightsail_instance.example will be updated in-place
~ resource "awscc_lightsail_instance" "example" {
+ add_ons = (known after apply)
id = "example-instance"
+ tags = (known after apply)
+ user_data = (known after apply)
# (18 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
The statefile on the initial apply is missing values for the above fields and are marked as null.
{
"version": 4,
"terraform_version": "1.8.4",
"resources": [
{
"mode": "managed",
"type": "awscc_lightsail_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/awscc\"]",
"instances": [
{
"schema_version": 1,
"attributes": {
"add_ons": null,
.......
"tags": null,
"user_data": null,
"user_name": "ec2-user"
},
"sensitive_attributes": []
}
]
}
],
"check_results": null
}
On my test, the debug logs detected change in the attribute networking
:
2024-06-28T14:39:28.923-0700 [DEBUG] provider.terraform-provider-awscc_v1.4.0_x5: Detected value change between proposed new state and prior state: tf_provider_addr=registry.terraform.io/hashicorp/awscc tf_req_id=9a35c22d-cf48-56e3-4712-e7e2332da199 tf_attribute_path=networking @module=sdk.framework tf_resource_type=awscc_lightsail_instance tf_rpc=PlanResourceChange @caller=github.com/hashicorp/terraform-plugin-framework@v1.9.0/internal/fwserver/server_planresourcechange.go:208 timestamp=2024-06-28T14:39:28.923-0700
upon further investigation, this is related to #1216.
Here is the debug log snapshot (some details omitted for brevity)
PlanResourceChange_Request_PriorState
{
"blueprint_id": "amazon_linux_2023",
"bundle_id": "nano_3_0",
"id": "example-instance",
"instance_arn": "arn:aws:lightsail:us-east-1:204034886740:Instance/d7536891-2ba5-4429-9b6b-826413ae98f2",
"instance_name": "example-instance",
. . .
"networking": {
"monthly_transfer": {
"gb_per_month_allocated": "1024"
},
. . .
}
PlanResourceChange_Request_ProposedNewState
notice how the networking
attribute was set to null by Terraform.
{
"blueprint_id": "amazon_linux_2023",
"bundle_id": "nano_3_0",
"id": "example-instance",
"instance_arn": "arn:aws:lightsail:us-east-1:204034886740:Instance/d7536891-2ba5-4429-9b6b-826413ae98f2",
"instance_name": "example-instance",
. . .
"networking": null,
. . .
}
PlanResourceChange_Response_PlannedState further down, plan modifiers recover the value from the statefile, but at this point, Terraform already "thinks" that there is change / drift.
{
"blueprint_id": "amazon_linux_2023",
"bundle_id": "nano_3_0",
"id": "example-instance",
"instance_arn": "arn:aws:lightsail:us-east-1:204034886740:Instance/d7536891-2ba5-4429-9b6b-826413ae98f2",
"instance_name": "example-instance",
. . .
"networking": {
"monthly_transfer": {
"gb_per_month_allocated": "1024"
},
. . .
}
Local test by removing required
flag on the attribute networking
confirms that the drift is no longer occurring, however this is not the right approach to fix the problem.
diff --git a/internal/aws/lightsail/instance_resource_gen.go b/internal/aws/lightsail/instance_resource_gen.go
index d867daebe..b7961cd8d 100644
--- a/internal/aws/lightsail/instance_resource_gen.go
+++ b/internal/aws/lightsail/instance_resource_gen.go
@@ -708,7 +708,9 @@ func instanceResource(ctx context.Context) (resource.Resource, error) {
}, /*END SCHEMA*/
}, /*END NESTED OBJECT*/
Description: "Ports to the Instance.",
- Required: true,
+ // Required: true,
+ Optional: true,
+ Computed: true,
}, /*END ATTRIBUTE*/
}, /*END SCHEMA*/
Description: "Networking of the Instance.",
Plan output:
╷
│ Warning: Provider development overrides are in effect
│
│ The following provider development overrides are set in the CLI configuration:
│ - hashicorp/awscc in /usr/local/go/bin
│
│ The behavior may therefore not match any released version of the provider and applying changes may cause
│ the state to become incompatible with published releases.
╵
awscc_lightsail_instance.example: Refreshing state... [id=example-instance]
No changes. Your infrastructure matches the configuration.
@acwwat , thank you for reporting this issue. We are still finalizing the appropriate fix to this problem, which may require upstream dependencies as well.
Community Note
Terraform CLI and Terraform AWS Cloud Control Provider Version
Affected Resource(s)
awscc_lightsail_instance
Terraform Configuration Files
Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.
Debug Output
Panic Output
n/a
Expected Behavior
There should not be any changes to the
aws_lightsail_instance
resource identified when runningterraform apply
after the firstterraform apply
is run to create the resource.Actual Behavior
terraform apply
identifies changes to theadd_ons
,tags
, anduser_data
arguments, and if I proceed, the resource update does not stop until I kill the process. I would assume that it would also reach a timeout eventually, but I couldn't wait long enough to see it.Steps to Reproduce
terraform apply
terraform apply
again, without any changes to the Terraform configurationImportant Factoids
n/a
References
n/a