The only has the provider information, what happens next?

A project I inherited as the typical and files as expected, and a /vars directory tor the tfvars configurations. In the root alongside are several other tf files which create load balancers, firewalls, virtual machines, etc. All of the configurations are in the TFVARs files and each module is reading them in as a variable from the file.

The question I have is to know how this flows. The looks like this:

provider “google” {
version = “~> 3.45”
project = var.project_id
region = var.region

So since doesn’t specify any of the modules, and I can’t seem to find anywhere which does, what happens here? Does need modified or is there just something I’m missing?

Hi @farslayer9,

Unfortunately it’s quite hard to work backwards from a particular .tf file to find everything that led to it, because in the Terraform language the caller specifies the callee, rather than the other way around.

I assume there must be some directory somewhere that has the root module in it. If you are in a monorepo situation or can somehow else search across the entire set of applicable code you might be able to track down the root module(s) by looking for backend blocks, since those are meaningful only in root modules.

For example, for a configuration which uses the “gcs” (Google Cloud Storage) backend, the root module would contain a block like this:

terraform {
  # ...
  backend "gcs" {
    # ...
  # ...

If you can find the .tf files which have backend blocks like this (keeping in mind that they won’t necessarily be using the “gcs” backend in particular) that would suggest to me that the directories containing those files are each a root module where you could run terraform apply, and so from there you can find module blocks and other artifacts that might refer into other directories and help you map out how these different files and directories relate to one another.

The other possible complication here is that this codebase might be expecting some third-party wrapping automation that automatically generates or transforms files before running Terraform. If so, that would make it hard to infer exactly how this system is put together unless you can track down that automation system and its configuration.

Thanks for your help, you actually greatly helped me to confirm that something else is going on. actually is the root module, there are only a couple of other .tf files, some create vpc firewall rules, another creates a vm, simple stuff. I did find that a Jenkins job may indeed be the caller, so it’s possible that’s what’s happening. I’m not used to having a in the root that only specifies the provider. So I assume it’s possible that the is being called by Jenkins, and then calling each module individually. No one else uses any of these modules, the modules are built to build out a very small infrastructure, a vpc, a few vms, some firewall rules, a load balancer, an external ip, nothing fancy at all. In fact, the other .tf files define modules whose sources are the modules built by others ( luch as git “source = git::”). Unfortunately the state files aren’t set to be stored in a backend, at least not in Terraform (who knows what is happening in Jenkins).

Hi @farslayer9 , it sounds like you are thinking there is some special meaning in the name - but there is not.

Actually Terraform loads all of the *.tf files in a directory, and processes them together as a single unit. Therefore there is no need (or indeed any syntax) for to reference other *.tf files in the same directory, as that doesn’t affect Terraform’s behaviour.

Please see this section of the documentation: Files and Directories - Configuration Language | Terraform by HashiCorp