Closed
Description
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- 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
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform Version
Terraform v1.5.0
Provider: scaleway v2.48.0
Affected Resource(s)
- scaleway_instance_server
Terraform Configuration Files
resource "scaleway_instance_server" "defender_instance" {
image = data.scaleway_instance_image.instance_image.id
type = var.instance_type
name = "test-${var.instance_uuid}"
ip_id = local.public_ip_id
zone = var.provider_zone
security_group_id = scaleway_instance_security_group.security_group.id
root_volume {
volume_type = "sbs_volume"
}
lifecycle {
ignore_changes = [
state,
image
]
replace_triggered_by = [terraform_data.cloud_init_config]
}
}
Expected Behavior
The block storage volume (sbs_volume) associated with the instance should have been automatically deleted when terraform destroy was executed, as the delete_on_termination = true setting implies.
Actual Behavior
The associated block storage volume persists even after terraform destroy is executed, despite the delete_on_termination = true configuration. This behavior is unexpected and problematic, as it results in orphaned volumes and potential unnecessary costs.
Steps to Reproduce
terraform apply
Important Factoids
References
- #0000