Documentation: aws_default_subnet lacks import instructions

[ianwestcott]

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 CLI and Terraform AWS Provider Version

Terraform v0.14.4
+ provider registry.terraform.io/hashicorp/aws v3.23.0

Affected Resource(s)

• aws_default_subnet

Issue Description

The documentation for the aws_default_subnet resource lacks an "Import" section. I was able to import a default subnet by mimicking the instructions for importing a regular subnet, so it is possible. This functionality should be documented.

I was unable to find the source code for the AWS provider documentation, but if it's possible for me to contribute this improvement myself, please point me in the right direction. Thanks!

[ewbankkit]

@ianwestcott Thanks for raising this issue.
The aws_default_subnet resource does not require terraform import functionality as creating a resource of this type actually does the import:

terraform-provider-aws/aws/resource_aws_default_subnet.go

Lines 58 to 80 in 9c9de45

	func resourceAwsDefaultSubnetCreate(d *schema.ResourceData, meta interface{}) error {
	conn := meta.(*AWSClient).ec2conn
	req := &ec2.DescribeSubnetsInput{}
	req.Filters = buildEC2AttributeFilterList(
	map[string]string{
	"availabilityZone": d.Get("availability_zone").(string),
	"defaultForAz": "true",
	},
	)
	log.Printf("[DEBUG] Reading Default Subnet: %s", req)
	resp, err := conn.DescribeSubnets(req)
	if err != nil {
	return err
	}
	if len(resp.Subnets) != 1 || resp.Subnets[0] == nil {
	return fmt.Errorf("Default subnet not found")
	}
	d.SetId(aws.StringValue(resp.Subnets[0].SubnetId))
	return resourceAwsSubnetUpdate(d, meta)
	}

This may change when we implement full lifecycle functionality for default subnets: #4957.

[ianwestcott]

@ewbankkit thanks for clarifying that.

The auto-import functionality was unclear to me, because when I ran terraform plan the output implied that Terraform would attempt to create the resource:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_default_subnet.default will be created
  + resource "aws_default_subnet" "default" {
      + arn                             = (known after apply)
      + assign_ipv6_address_on_creation = (known after apply)
      + availability_zone               = "us-east-1f"
      + availability_zone_id            = (known after apply)
      + cidr_block                      = (known after apply)
      + id                              = (known after apply)
      + ipv6_cidr_block                 = (known after apply)
      + ipv6_cidr_block_association_id  = (known after apply)
      + map_public_ip_on_launch         = (known after apply)
      + owner_id                        = (known after apply)
      + vpc_id                          = (known after apply)
    }

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

Given that the resource already existed, my next recourse was to try importing it, and that worked despite the lack of documentation.

Is it expected behavior for Terraform to show aws_default_subnet resources as pending creation when running terraform plan, and "adopt" them into state only on apply? If so, that could be made clearer in either the plan output, or the documentation, or both. I'd be happy to open a new ticket for that issue if it makes sense, but I wanted clarify the expected behavior first. (Alternatively, please let me know if there's a better forum for this discussion.) Thanks!

[ewbankkit]

Yes, that is "expected". Terraform core knows only that a resource is to be created, not that the resource doesn't actually create anything at AWS but instead adopts the resource into management.
There's an issue - #17374 - that I have open collecting some suggestions for additions to the maintainer documentation about various non-standard resource or attribute patterns and I'll add an item there.

The practitioner documentation comment we have is

Can you think of a better way of capturing the behavior?

[ianwestcott]

@ewbankkit I think that's a good start, but I would want to see a note added to clarify that the adoption happens at the apply stage, and caveat that the resource will show in the terraform plan output as needing to be "created", even though no state will be manipulated in AWS during apply. In my case, the plan output gave me pause, because I was concerned about making unwanted changes to my infrastructure. That's what led me to try to import it, and create this ticket.

[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!