Ability to provide multiple locations of .tfvars files with precedence

Managing multiple environments of one terraform module requires holding specific .tfvars (or more than one) for each environment. We need the ability to provide the Terraform object, a list of paths from the same sourceRef that holds a .tfvars files and we also need to specify some kind of precedence between them. How terraform handles var-files:

"Any -var-file options on the command line, in the order they are provided. (This includes variables set by a Terraform Cloud workspace.)"

It can be a new field under Terraform's spec --> varFiles. It will hold a list of paths to .tfvars files and will add them in that order of precedence.

If we're already on the subject, we should also support inline var input.

These var files must be relative to the workspace and can be either pre exist in the cloned repository or mapped using the fileMapping option

After chatting with @bivas

If we're already on the subject, we should also support inline var input.

Already exists with the Spec.vars in Terraform object

There's a big question to talk about: How do we see the precedence between fileMappings, varsFrom, vars and the new field we will create? BTW looks like there are too many ways to pass variables. Good because features are always welcomed, bad because it's confusing.

These var files must be relative to the workspace

There are some cases where we want to use a tfvars file that is stored outside of the workspace but inside the GitRepository listed in sourceRef.

Therefore, We need to be able to specify paths that are relative to the GitRepository root directory.

options 1: a list of paths and locations (similar to how we handle fileMappings), can be workspace or root (a better name for root can be repository, we need to decide). and the API will look like:

kind: Terraform
spec:
  tfvarsPaths: # Need to think of a good name.
    - location: "workspace"
      path: "./staging/override.tfvars" # relative to workspace
    - location: "root"
      path: ".meta/environments/staging/override.tf" # relative to git repository root
  sourceRef: # Already exists
    kind: GitRepository
    name: name

options 2: we don't want to use location. That will require the controller to first try this path under workspace and if not exists will look under the git repository root. This options my cause some issues (same path in both workspace and root) and thus I don't support this one. API will look like:

kind: Terraform
spec:
  tfvarsPaths: # Need to think of a good name.
    - "./staging/override.tfvars" # relative to workspace
    - ".meta/environments/staging/override.tf" # relative to git repository root
  sourceRef: # Already exists
    kind: GitRepository
    name: name

@chanwit @bivas WDYT?

the precedence of the var-files is currently a real issue, we ned a descision.

@bivas I am wondering why workspace relative path is required.

@tomhuang12 That was just to make it easier for some use cases. But you're right by asking, maybe it's not needed and just makes things more confusing. What are your thoughts about all of our var files options and their precedence?

@tomhuang12 that proposal is to simplify the API. The user doesn't know that real path inside the runner. So by asking for a relative path, they don't need to assume anything but that the files exist. I would say it should be relative to the GitRepository mounted inside the runner.

Looking at @itamar-marom example (option 2), I would refine it to:

kind: Terraform
spec:
  tfvarsPaths: # Need to think of a good name.
    - "staging/override.tfvars" # relative to sourceRef
    - "environments/staging/override.tf" # relative to sourceRef
  sourceRef: # Already exists
    kind: GitRepository
    name: name

I dropped the ./ prefix to paths and the files are always relative to sourceRef (kinda like spec.path property)

Hello guys.

The user doesn't know that real path inside the runner.

User can be aware of some of the runner's paths. Let's assume that the user is using external secret store like Hashicorp Vault, and would like to mount secret(s) to the runner's filesystem at runtime.

@SebastianBakala-TomTom user can be aware, but why force them to know the runner internals? If, for instance, the controller will update the runner with a new better image that follow different path standards: using full path will force breaking changes while a relative one will keep your configuration valid.

@chanwit any plans on including this in near future release ?

Morning @itamar-marom, is there a planned date for merge and release of this feature in PR: https://github.com/weaveworks/tf-controller/pull/463?

Hi @cggaldes I would like this feature to be pushed as well. Unfortunately I'm not part of the maintaining team so the only one who can push this is @chanwit

I think #1185 resolves this, but the commit message did not contain a magic keyword (it says Fix Issue #338 instead of Fixes #338 or Resolves #338 without the extra word in the middle). If you think it does please close this issue @itamar-marom, if it does not fully resolve it, please add notes what's missing, thank you.