SG ID not imported for FSx

[onur-sam-gtn-ai]

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 "me too" comments, 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 v0.12.6

Affected Resource(s)

• aws_fsx_lustre_file_system

Expected Behavior

• terraform import for FSx Lustre should have imported security_group_ids as well

Actual Behavior

# aws_fsx_lustre_file_system.lustre[0] must be replaced
-/+ resource "aws_fsx_lustre_file_system" "lustre" {
      ~ arn                           = "redacted" -> (known after apply)
      ~ dns_name                      = "redacted.amazonaws.com" -> (known after apply)
        export_path                   = "s3://redacted"
      ~ id                            = "fs-redacted" -> (known after apply)
        import_path                   = "s3://redacted"
      ~ imported_file_chunk_size      = 2048 -> (known after apply)
      ~ network_interface_ids         = [
          - "eni-redacted",
          - "eni-redacted",
        ] -> (known after apply)
      ~ owner_id                      = "redacted" -> (known after apply)
      + security_group_ids            = [
          + "SAME SG ID AS THE ONE ALREADY ON THE FSx",
        ] # forces replacement

FSx support was only recently merged, see PR-9761.

[bflad]

Hi @onur-sam-gtn-ai 👋 Thank you for reporting this.

Currently, the FSx API does not provide a method for reading this information, so therefore Terraform cannot know this information during resource import. We try to note this in the import section the resource documentation along with a workaround:

Certain resource arguments, like security_group_ids, do not have a FSx API method for reading the information after creation. If the argument is set in the Terraform configuration on an imported resource, Terraform will always show a difference. To workaround this behavior, either omit the argument from the Terraform configuration or use ignore_changes to hide the difference

So for your Terraform configuration:

resource "aws_fsx_lustre_file_system" "lustre" {
  # ... other configuration ...

  # There is no FSx API for reading security_group_ids
  lifecycle {
    ignore_changes = [security_group_ids]
  }
}

If you would like to see this support added, we would suggest opening a AWS Support Case or reaching out to your AWS account team if you have one. When the information is available from the API, this limitation can be removed from the Terraform resource. 👍 Also, if we can improve our documentation, please let us know. Thanks again.

[onur-sam-gtn-ai]

I'm no Terraform expert so excuse my ignorance, but isn't it possible to just query the returned ENI's and store the SG information there in the state file during the FSx import?

[slapula]

@onur-sam-gtn-ai That would involve several calls to non-FSx APIs (EC2 and or VPC if I recall) that is not practical or encouraged when developing resources (@bflad can correct me if I'm wrong here). IMO, this is a bug that AWS needs to fix. This is data that should be returned when calling a Describe on a filesystem even if it can only be set during creation time.

[bflad]

@onur-sam-gtn-ai potentially, but there are caveats to performing that sort of logic outside the AWS service's handling/API:

• At best we will be guessing about the underlying implementation, the implementation may change over time, and operators/AWS may have the ability to adjust those ENI security groups in ways that could break assumptions in the implementation. We typically try to avoid the maintenance burden of special handling such as this.
• As a general project principle, we try extremely hard to avoid cross-AWS-service logic within resources. Most operators when working with a specific Terraform resource only expect it to be accessing the service that implements the resource itself and may have otherwise restrictive IAM Policies that prevent accessing other services.

We might be able to accept an implementation if it is documented by the AWS service team, has compatibility guarantees, and falls back to not causing the Terraform resource to return an error.

[onur-sam-gtn-ai]

No worries, I'll raise a support ticket with AWS regarding this at the first opportunity. Thanks for all the prompt responses!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!