`awscc_ec2_network_insights_path` perpetual diff

[coreylane]

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
• The resources and data sources in this provider are generated from the CloudFormation schema, so they can only support the actions that the underlying schema supports. For this reason submitted bugs should be limited to defects in the generation and runtime code of the provider. Customizing behavior of the resource, or noting a gap in behavior are not valid bugs and should be submitted as enhancements to AWS via the CloudFormation Open Coverage Roadmap.

Terraform CLI and Terraform AWS Cloud Control Provider Version

Terraform v1.7.4
on darwin_arm64
+ provider registry.terraform.io/hashicorp/awscc v0.70.0

Affected Resource(s)

• awscc_ec2_network_insights_path

Terraform Configuration Files

resource "awscc_ec2_network_insights_path" "test" {
  destination_ip = "192.168.1.1"
  protocol       = "tcp"
  source         = "arn:aws:ec2:us-east-1:111122223333:instance/i-fd89a03890a3890a"
}

provider "awscc" {}

Debug Output

https://gist.githubusercontent.com/coreylane/900e0058638c7937b07a3fa6b58e9013/raw/5ebc6d0e133dce6ee90512c2e450d2263d2869c6/awscc_ec2_network_insights_path.log

Expected Behavior

awscc_ec2_network_insights_path resource should be created without having to provide the optional destination argument. The above snippet is supported in the console.

Actual Behavior

The apply fails with a message stating the Destination parameter must be included.

│ Error: AWS SDK Go Service Operation Incomplete │ │ with awscc_ec2_network_insights_path.test, │ on main.tf line 1, in resource "awscc_ec2_network_insights_path" "test": │ 1: resource "awscc_ec2_network_insights_path" "test" { │ │ Waiting for Cloud Control API service CreateResource operation completion returned: waiter state transitioned to FAILED. StatusMessage: The request must include either the Destination parameter or the FilterAtSource.DestinationAddress parameter. Add the required parameter and retry the request. (Service: Ec2, │ Status Code: 400, Request ID: ddf56316-0d09-4556-bb77-ff081654b103). ErrorCode: InvalidRequest

Steps to Reproduce

1. terraform apply

References

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-networkinsightspath.html

[coreylane]

This was user error, the block below fixed it. But now I'm having major perpetual diff issues with this resource.

resource "awscc_ec2_network_insights_path" "test" {
  protocol = "tcp"
  source   = "arn:aws:ec2:us-east-1:111122223333:instance/i-0b5e5"

  filter_at_source = {
    destination_address = "192.168.1.1"
  }
}

[kadrach]

The underlying schema only requires Protocol and Source properties, hence this auto-generated provider only requires these.

https://github.com/hashicorp/terraform-provider-awscc/blob/main/internal/service/cloudformation/schemas/AWS_EC2_NetworkInsightsPath.json#L121-L124

This schema should be modified upstream to look something like the below, which would allow the provider to infer that one or the other attribute is required.

{
    "typeName": "AWS::EC2::NetworkInsightsPath",
    "properties": {...},
    "required": ["Protocol", "Source"], // always required
    "oneOf": [ // also requires one of these
        {"required": ["ThisOne"]},
        {"required": ["OrThisOtherOne"]}
    ],
    ...
}

[coreylane]

Thank you for digging into that. So cloud formation registry would have to be updated.

I've never used the awscc provider before, is it normal to have diff issues like this? I changed nothing in the configuration on this resource, but the provider is picking up many changes that are forcing replacement. Am I doing something wrong or is this a bug with this particular resource?

❯ terraform apply
awscc_ec2_network_insights_path.test: Refreshing state... [id=nip-0000000000000]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # awscc_ec2_network_insights_path.test must be replaced
-/+ resource "awscc_ec2_network_insights_path" "test" {
      ~ created_date              = "2024-02-22T06:52:37.599Z" -> (known after apply)
      + destination               = (known after apply) # forces replacement
      + destination_arn           = (known after apply)
      + destination_ip            = (known after apply) # forces replacement
      + destination_port          = (known after apply) # forces replacement
      + filter_at_destination     = (known after apply) # forces replacement
      ~ filter_at_source          = { # forces replacement
          + destination_port_range = (known after apply)
          + source_address         = (known after apply)
          + source_port_range      = (known after apply)
            # (1 unchanged attribute hidden)
        }
      ~ id                        = "nip-0000000000000" -> (known after apply)
      ~ network_insights_path_arn = "arn:aws:ec2:us-east-1:111122223333:network-insights-path/nip-0000000000000" -> (known after apply)
      ~ network_insights_path_id  = "nip-0000000000000" -> (known after apply)
      ~ source                    = "i-0000000000000" -> "arn:aws:ec2:us-east-1:111122223333:instance/i-0000000000000" # forces replacement
      ~ source_arn                = "arn:aws:ec2:us-east-1:111122223333:instance/i-0000000000000" -> (known after apply)
      + source_ip                 = (known after apply) # forces replacement
      + tags                      = (known after apply)
        # (1 unchanged attribute hidden)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

[kadrach]

This is also an upstream issue, or otherwise an issue this provider cannot currently deal with.

The resource handlers for AWS::EC2::NetworkInsightsPath (which this provider uses) mutate the input, in this case the input Source ARN is returned, transformed into an ID.

% aws cloudcontrol create-resource --type-name AWS::EC2::NetworkInsightsPath --desired-state '{"Source":"arn:aws:ec2:ap-southeast-2:000000000000:instance/i-xxx","Protocol":"tcp", "FilterAtSource":{"DestinationAddress":"192.168.1.1"}}'
{
    "ProgressEvent": {
        "TypeName": "AWS::EC2::NetworkInsightsPath",
        "RequestToken": "...",
        "Operation": "CREATE",
        "OperationStatus": "IN_PROGRESS",
        "EventTime": "2024-02-23T15:52:04.549000+11:00"
    }
}

% aws cloudcontrol list-resources --type-name AWS::EC2::NetworkInsightsPath | jq '.ResourceDescriptions[1].Properties | fromjson'
{
  "SourceArn": "arn:aws:ec2:ap-southeast-2:00000000000:instance/i-xxx",
  "NetworkInsightsPathId": "nip-003a9ce010085ebc1",
  "CreatedDate": "2024-02-23T04:10:42.103Z",
  "FilterAtSource": {
    "DestinationAddress": "192.168.1.1"
  },
  "NetworkInsightsPathArn": "arn:aws:ec2:ap-southeast-2:000000000000:network-insights-path/nip-003a9ce010085ebc1",
  "Protocol": "tcp",
  "Source": "i-xxx"  # Not an ARN anymore. Terraform sees a change.
}

Three things I can think of:

• The handler should not do this in the first place
• The resource provider specification allows for propertyTransform attributes to allow for such a scenario, however the awscc provider does not currently implement support for these JSONATA transforms, nor does the resource at hand contain a propertyTransform in its schema.
• Your immediate problem goes away if you use an instance ID, not an ARN, in your HCL files.

@wellsiau-aws

[coreylane]

Your immediate problem goes away if you use an instance ID, not an ARN, in your HCL files.

I will try to eliminate ARNs from my configuration if possible, but the majority of my use cases are for testing cross-account connectivity paths, which require the use of ARNs.

While not ideal, I don't mind the replacement occurring each time the pipeline runs, seeing how this configuration isn't even possible with the standard aws provider atm, it will have to do.

Thank you for investigating!

[wellsiau-aws]

Thanks for reporting this issue. I'll submit ticket to the upstream service team to take a look.