Implement lxd_instance_file data resource

[tarruda]

This data source provides a simple method for reading data from files in the instance (not created by the current terraform config).

It can also be used as a method to synchronize instance creation and transfer data between them, as shown in the following example:

# Explanation of what happens in order:
#
# - c1 is created
# - c1 installs nginx and writes its own LAN ip to /my-lan-ip file
# - c2, which was waiting for "c1_ip" to be read, is started
# - c2 invokes curl to read nginx index.html (running in c1) and converts to a text file (/index.txt)
# - output value is set.

data "lxd_instance_file" "c1_ip" {
  instance_name = lxd_instance.c1.name
  target_file = "/my-lan-ip"
  timeout = 30
}

data "lxd_instance_file" "index_txt" {
  instance_name = lxd_instance.c2.name
  target_file = "/index.txt"
  timeout = 30
}

resource "lxd_instance" "c1" {
  name = "c1"
  image = "ubuntu:20.04"
  config = {
    "user.user-data": <<-EOF
    #cloud-config
    package_update: true
    runcmd:
      - apt-get install --no-install-recommends -y nginx
      # get LAN ip
      - ip route get 8.8.8.8 | sed -n '/src/{s/.*src *\([^ ]*\).*/\1/p;q}' > /my-lan-ip
    EOF
  }
}

resource "lxd_instance" "c2" {
  name = "c2"
  image = "ubuntu:20.04"
  config = {
    "user.user-data": <<-EOF
    #cloud-config
    package_update: true
    runcmd:
      - apt-get install --no-install-recommends -y lynx
      - curl http://${trimspace(data.lxd_instance_file.c1_ip.content)} > index.html
      - lynx --dump index.html > /index.txt
    EOF
  }
}

output "out" {
  value = trimspace(data.lxd_instance_file.index_txt.content)
}

[tarruda]

@jtopjian @adamcstephens this is ready for review

[adamcstephens]

Do you have another use case besides the example given? It seems to me that using wait_for_network along with the computed ipv4 address would be a simpler way of getting this data.

[tarruda]

Do you have another use case besides the example given? It seems to me that using wait_for_network along with the computed ipv4 address would be a simpler way of getting this data.

Yes. I'm using this for passing a ca certificate generated in one container (A squid package cache) to another container that uses it as a proxy.

I'm sure there are more use cases for reading files from a container/VM though.

[adamcstephens]

Are you aware that resource output data gets put into the terraform state? The fact that the content is returned concerns me.

[tarruda]

Are you aware that resource output data gets put into the terraform state? The fact that the content is returned concerns me.

Yes, but this is the case for other similar data resources: https://registry.terraform.io/providers/hashicorp/local/latest/docs/data-sources/file

[adamcstephens]

Thanks for that link. I'm ok with this resource given that example.

We'll need some acceptance tests for this resource to ensure it works as desired. I'm thinking we need at least the cases where the file is retrieved and when the timeout occurs. I assume there is no case of missing file, since the retries will happen until the timeout.

You can see some examples in the other resources, and here are a couple links:

https://developer.hashicorp.com/terraform/plugin/sdkv2/testing/acceptance-tests
https://pkg.go.dev/github.com/hashicorp/terraform-plugin-sdk/v2/helper/resource#TestCase

[tarruda]

@adamcstephens I've tried writing an acceptance test based on the existing one for instance file resource and this one

It doesn't look the tests are running correctly in my machine though (test always succeed).

[adamcstephens]

Are you sure you're running the acceptance tests? You can run them with make testacc. I plan on disabling the debug in that task, so a heads up it's quite verbose.

[tarruda]

I'm closing this since I've found shell script provider which has everything I need to automate LXD with terraform. If anyone else is interested, feel free to pick up where I stopped.