Support terraform init about terraform-resource HOT 9 CLOSED

@analytically unfortunately this resource can't use the built-in remote state backends at all right now. Concourse resources are required to implement a check function that can look for new versions of a resource. To have tighter control over the state files, the resource currently supports only S3. However, now that backends are listed directly in the Terraform config files it becomes even more desirable to support all the backends. I'll have to do some more thinking on this.

Out of curiosity, would you use any backends other than S3?

from terraform-resource.

I'm just using S3.

from terraform-resource.

Opened a Concourse issue here to see if the Concourse team has any ideas for a nice implementation around supporting state backends.

Also if anyone has a strong need for backend support other than the current S3 support this resource provides, please leave a comment 👍

from terraform-resource.

Hello,

That's gonna be a mandatory change to run it automatically before any terraform command because of : https://github.com/hashicorp/terraform/blob/master/CHANGELOG.md#0100-beta1-unreleased

I don't like to have a dependency to terraform's server/availability.
Maybe could it be possible to have an option to share attach an external volume that may contains the providers binaries ? What do you think about it ?

from terraform-resource.

@Seraf thanks for the heads up, I'll start looking into how to handle that breaking change. Definitely agree that adding a runtime dependency on Terraform's servers isn't great. Baking the providers into the docker image and rebuilding on a daily timer or similar doesn't seem too bad.

from terraform-resource.

I agree but then we'll loose the capability to stick with a specific provider version. I'll try to think about how could it be handled

from terraform-resource.

@ljfranklin, I thought a little bit about it, I'm not sure that a docker image with providers will be enough : because of the version constraint in configuration, the providers will be setup in the local .terraform folder.
It also means that each project using different providers should have their own terraform image. Sounds a bit complicated to maintain in the long run.
But anyway, I think it's the same deal than npm, composer, bundle and all these libraries managers, it needs some "cache" from concourse itself. Maybe worth to use http://concourse.ci/running-tasks.html#caches to deal with it ?

Also, there was a new update about the apply feature : https://github.com/hashicorp/terraform/blob/master/website/upgrade-guides/0-10.html.markdown#interactive-approval-in-terraform-apply

It will be a breaking change for the way terraform is used by the terraform resource, so it needs to be handled before switching to the 0.10 version

from terraform-resource.

Here's a branch with the 0.10 changes. This calls init before running other CLI commands in order to download the providers. Will merge after the Terraform team officially releases 0.10.

@Seraf after looking at the provider distribution more closely, it does seem difficult to cache all the providers in the docker image. I'm leaning towards no caching for now and we'll see if anyone has reliability issues when fetching providers from the Hashicorp servers.

@analytically even though the resource now runs init, it still won't support the built-in state backends just yet. Still on my radar though.

from terraform-resource.

The latest image now includes Terraform v0.10.0 which makes calling init mandatory. Spinning out a separate issue for supporting remote state backends: #39.

from terraform-resource.