Skip to content

Conversation

@trujillo-adam
Copy link
Contributor

This PR reverses the strategy applied in PR-530 and aggregates meta-arguments into their own reference section with separate pages for each argument.

@github-actions
Copy link
Contributor

github-actions bot commented Oct 24, 2025

Vercel Previews Deployed

Name Status Preview Updated (UTC)
Dev Portal 🔄 Building (Inspect) --- ---
Unified Docs API ✅ Ready (Inspect) Visit Preview Thu Oct 30 03:14:38 UTC 2025

@github-actions
Copy link
Contributor

github-actions bot commented Oct 24, 2025

Broken Link Checker

No broken links found! 🎉


# `depends_on` reference

The `depends_on` meta-argument establishes dependencies between resources that do not directly reference one another. Use the `depends_on` argument to explicitly set the order in which Terraform creates resources.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is accurate because Terraform uses depends on during lots of operations, not just creation. Is there a reason not to use the original language here?

}
```

Note that this is a simplified example and does not represent a real-world use case. The `depends_on` argument changes the dependency graph so that Terraform creates the resources in a linear order. Without the argument, Terraform would still successfully create the resources.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use this example if it's not a real use case? Let's find a real one instead

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I don't believe there's ever a case this would happen, at least off of the top of my head.

What about a scenario where configuration requires an RDS instance to be launched first before the user spins up an EC2 instance that connects to it? It's not a relationship you have to explicitly declare 100% of the time (if you pass the DB IP through the EC2 resource user_data string, for example), but there's plenty of times a user could run into this.

Full config example, feel free to chop down if you go this route

provider "aws" {
  region = "us-east-2"
}

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

resource "aws_db_instance" "api" {
  allocated_storage   = 10
  db_name             = "api_db"
  engine              = "postgres"
  engine_version      = "17.4"
  instance_class      = "db.t3.micro"
  username            = "foo"
  password            = "foobarbaz"
  skip_final_snapshot = true
}

resource "aws_instance" "api" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  depends_on = [aws_db_instance.api]
}

}
```

### `count` objects
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about putting this above the Usage section, since we use the count.index value in the example above? Not sure if that breaks our content type too much, though.


## Usage

The `count` meta-argument accepts a whole number and creates that many instances of the resource or module. Each instance has a distinct infrastructure object associated with it, and each is separately created, updated, or destroyed when the configuration is applied. In the folllowing example, Terraform creates four `aws_instance.server` resources that use the same AMI and instance type:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the exact wording here depends if we decide to move the "count objects" H2 above this or not, but we should call out what ${count.index} is doing in this context

}
```

Note that this is a simplified example and does not represent a real-world use case. The `depends_on` argument changes the dependency graph so that Terraform creates the resources in a linear order. Without the argument, Terraform would still successfully create the resources.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I don't believe there's ever a case this would happen, at least off of the top of my head.

What about a scenario where configuration requires an RDS instance to be launched first before the user spins up an EC2 instance that connects to it? It's not a relationship you have to explicitly declare 100% of the time (if you pass the DB IP through the EC2 resource user_data string, for example), but there's plenty of times a user could run into this.

Full config example, feel free to chop down if you go this route

provider "aws" {
  region = "us-east-2"
}

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

resource "aws_db_instance" "api" {
  allocated_storage   = 10
  db_name             = "api_db"
  engine              = "postgres"
  engine_version      = "17.4"
  instance_class      = "db.t3.micro"
  username            = "foo"
  password            = "foobarbaz"
  skip_final_snapshot = true
}

resource "aws_instance" "api" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  depends_on = [aws_db_instance.api]
}

@trujillo-adam trujillo-adam marked this pull request as ready for review October 27, 2025 23:39
@trujillo-adam trujillo-adam requested review from a team as code owners October 27, 2025 23:39
Copy link
Contributor

@judithpatudith judithpatudith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't make it all the way through the blocks pages, but I looked at all the meta-argument pages and they look really good! Thank you for these!


The provider developer determines resource-specific arguments, but all resources support meta-arguments that let you manage resources' infrastructure lifecycle, including destruction behavior, preventing destruction, and establishing dependencies between resources. Terraform provides the following meta-arguments.

<Note>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we only want this note in the 1.14 docs and onward?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other way around. We added it as a temporary way to make the beta features more discoverable. We'll take it out when 1.14 becomes the latest.


By default, child modules inherit the default provider configurations of their parent module. You can specify an alternate provider configuration in the `module` block using the `providers` argument. The `providers` argument instructs Terraform to use the reference provider configuration to create the module resources. Refer to the [`providers` reference](/terraform/language/meta-arguments/providers) for details.

## `lifecycle`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this come before provider and providers to match the order of the reference pages?


You can use `replace_triggered_by` in [`resource`](/terraform/language/block/resource) blocks.

### `precondition`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many of the other H3s have examples but pre and post conditions don't. I do see there are examples in the examples section, so this isn't a blocker, just inconsistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants