terraform get always creates absolute symlinks in .terraform/modules

Created on 26 Oct 2016  ยท  6Comments  ยท  Source: hashicorp/terraform

Terraform Version

Terraform v0.7.7

Terraform Configuration Files

variable "name"              { }
variable "region"            { }
variable "sub_domain"        { }

variable "vpc_cidr"        { }
variable "azs"             { }
variable "private_subnets" { }
variable "public_subnets"  { }

provider "aws" {
  region = "${var.region}"
}

resource "terraform_remote_state" "aws_global" {
  backend = "s3"

  config {
    region = "${var.region}"
    bucket = "XXXXXXXXXXXXX"
    key    = "XXXXX"
  }

  lifecycle { create_before_destroy = true }
}

module "network" {
  source = "../../../modules/aws/network"

  name            = "${var.name}"
  vpc_cidr        = "${var.vpc_cidr}"
  azs             = "${var.azs}"
  region          = "${var.region}"
  private_subnets = "${var.private_subnets}"
  public_subnets  = "${var.public_subnets}"
}
#!/usr/bin/env bash
terraform remote config -backend=s3 -backend-config="bucket=XXXXXXXXXXXXX" -backend-config="region=XXXXXX" -backend-config="key=XXXXX"

The stuff in ../../../modules/aws/network is based on the Terraform Best Practices repo, somewhat trimmed down.

Expected Behavior

When running terraform get it creates a bunch of symlinks in .terraform/modules. The symlinks are absolute:

$ ls -l .terraform/modules/
total 40
lrwxr-xr-x  1 me  me  59 Oct 26 13:31 3186e0874dcc270f3e466349086537c4 -> /Users/me/tf/modules/aws/network/public_subnet
lrwxr-xr-x  1 me  me  49 Oct 26 13:31 58f53f37bccd55bbec80511f5fcec98d -> /Users/me/tf/modules/aws/network/nat
lrwxr-xr-x  1 me  me  45 Oct 26 13:31 873a64152da23c16f9bda09b7de9bb07 -> /Users/me/tf/modules/aws/network
lrwxr-xr-x  1 me  me  60 Oct 26 13:31 a5dd3afa9db6b71de3c78241390b4e2a -> /Users/me/tf/modules/aws/network/private_subnet
lrwxr-xr-x  1 me  me  49 Oct 26 13:31 f6c62c67f55db3e9c1b9f1157a6dc691 -> /Users/me/tf/modules/aws/network/vpc

Unfortunately, that means the modules folder is now set in stone. If I move things around, the links break. It's a pain having to update those links every time.

Relative links would be far more portable. You could tar.gz the whole thing up, drop it somewhere else, and it would Just Work.

I'm not asking to change the default behavior of terraform get (although I do think relative symlinks are the right choice almost always). At the very least, add an option to the get command to create relative links instead.

Thank you.

Most helpful comment

@FlorinAndrei Because this isn't meant to be a configurable option: it is working as designed. Portability isn't a design for .terraform so having a command line option to enable that would be extending the design. It is something we want to support, but not that way. Another reason is that if we introduce an option, its hard and annoying to remove it for the end user. Its easier to say "this isn't supported right now at all" vs. "supported with this flag, but going to change completely in a bit".

And finally, if we did support that flag, I'm sure other bugs would appear related to that flag (since it wasn't part of the initial design), and we'd be on the hook to fix those bugs. Without the flag, we can more properly say that this isn't an intended use case, so we can't expect that to work: you're in "undefined behavior" territory.

Rest assured, I do want portability to work at some point, but probably via another command of some sort.

All 6 comments

I think 'terraform get' is redundant since you still always have to specify a path for the module. I think it might make sense for the terraform to automatically do a 'get' using a specified source path if module is not found.
I would go even further and propose that terraform removes symlinks after the run. That way 'get' is run automatically every time if modules are used.

We actually made this change relatively recently. Before that they were in fact relative symlinks. I can't remember the exact issue number but this was done to fix some other issues. For local files though, doing a terraform get again isn't painful at all (near instant).

We've talked before about creating a way that your terraform config + modules could become "packaged" to be portable but haven't made any movement on supporting that use case. The ".terraform" folder is not meant to do that currently so this isn't a design goal. But, in a future world, it is.

Going to close this since we unfortunately must do this for now to avoid other issues.

@mitchellh Why not add a command-line option? Then keep the default any way you like.

@FlorinAndrei Because this isn't meant to be a configurable option: it is working as designed. Portability isn't a design for .terraform so having a command line option to enable that would be extending the design. It is something we want to support, but not that way. Another reason is that if we introduce an option, its hard and annoying to remove it for the end user. Its easier to say "this isn't supported right now at all" vs. "supported with this flag, but going to change completely in a bit".

And finally, if we did support that flag, I'm sure other bugs would appear related to that flag (since it wasn't part of the initial design), and we'd be on the hook to fix those bugs. Without the flag, we can more properly say that this isn't an intended use case, so we can't expect that to work: you're in "undefined behavior" territory.

Rest assured, I do want portability to work at some point, but probably via another command of some sort.

Alright, I get it. I'll make terraform get part of the post-move ritual. Maybe via some kind of wrapper. It's one extra step, but it should work. Thanks!

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings