The resource "expires" after a while ...

[saedalavinia]

Ever since we migrated the backend, we have noticed that the output of the terraform becomes unavailable after a while, as if the terraform has never run and as though the resource "expires" after sometimes.

In our pipeline, we only run (put) terraform in a very specific job. All the subsequent jobs do a "get" to get the terraform outputs and parse it for different reasons.

However, recently it seems that the subsequent jobs fail to get the resource after a while. When I click on the resource, no version of that resource is available, and if I manually run the job that does a "get" of the terraform resource, I get: "no versions satisfy passed constraints".
The s3 file is still in the bucket and therefore it should work.

Here is an example:

jobs: 
- name: execute-terraform
  plan:
  - put: some-terraform
    params:
        env_name: my_env
        vars: [some_vars]
        var_files: [some_var_files]

- name: use-terraform-1 
   plan: 
   - get: some-terraform 
      passed: execute-terraform
  - task: do-something-cool-2

- name: use-terraform-2 
   plan: 
   - get: some-terraform 
      passed: execute-terraform
  - task: do-something-cool-2

- name: use-terraform-3
   plan: 
   - get: some-other-resource
     trigger: true
   - get: some-terraform 
      passed: [use-terraform-1, use-terraform-2]
  - task: do-something-cool-3

resource_types:
- name: terraform
  type: docker-image
  source:
    repository: ljfranklin/terraform-resource
    tag: latest

resources: 
- name: some-terraform
  type: terraform
  source:
    terraform_source: /path/to/source
    backend_type: s3
    backend_config:
      some_config

In this case, use-terraform-1 , use-terraform-2 and use-terraform-3 work for the first run of the pipeline. If sometimes pass and I want to manually trigger use-terraform-1 , use-terraform-2 and use-terraform-3, they will wait on some-terraform forever, indicating that no version of the resource is available. The only way to work this is to re-execute execute-terraform again. This also preventssome-other-resource to trigger theuse-terraform-3` because not all inputs are satisfied.

[ljfranklin]

@saedalavinia interesting, I wonder if it has something to do with this section in the check code. Can you try setting resources[0].source.env_name: <your_env_name> and see if the problem goes away? This assumes your pipeline only manages a single environment.

[saedalavinia]

Thanks for getting back to me Lyle.
I edited my pipeline.yml in the above comment with some info I had originally left out.
In summary, I am defining my env_name within the params of the resource I put into.
Is it necessary to move it down to the resources section?

Specifically added this:

        env_name: my_env
        vars: [some_vars]
        var_files: [some_var_files]

[ljfranklin]

Try moving it into the resources section at resources[0].source.env_name: <your_env_name>. Concourse populates the version list by calling the resource's check function. The check function is passed the source params but not the put params. To be clear this shouldn't be necessary but if moving env_name into source fixes the issue it means there's a bug in the check function.

[saedalavinia]

Oh I see ... sorry ... I misread that as a misuse as opposed to debugging step.
I can only try this since I am using a single env ... but this could be an issue for multi envs

Trying ...

[saedalavinia]

It might take me a few days to get back as we haven't been able to figure out how long it takes before the resource "expires"

[saedalavinia]

FYI, before we could really test if the suggestion resolved the issue, we ran into this:
concourse/concourse#4336

So at this point, we don't know how this is going to act ...

[npike-vmware]

I believe I am currently hitting this issue as well. The pipeline runs fine until jobs expire, then it fails to find the latest version of the resource even tho we can validate that the resource is available within the Azure S3 bucket.

I will try your recommendation above to add a var entry of type to the resource:
resources[0].source.env_name: ((environment))
within the pipeline and see if this resolves the issue.

- name: env-state-((iaas))
  type: terraform
  source:
    backend_type: azurerm
    backend_config:
      storage_account_name: ((storage_account_name))
      container_name: ((iaas))
      key: ((iaas)).((environment)).terraform.tfstate
      access_key: ((azure-access-key))
    vars:
      environment_name: ((environment))
      subscription_id: ((azure_credentials.subscription_id))
      tenant_id: ((azure_credentials.tenant_id))
      client_id: ((azure_credentials.client_id))
      client_secret: ((azure_credentials.client_secret))
      location: ((azure_location))
      hosted_zone: ((iaas)).ianad.dev
      resources[0].source.env_name: ((environment))

[dumptruckman]

I've been running into this same issue though I didn't initialize realize it was because the terraform resource version list was being wiped. I am attempting to fix this by moving the env_name into the resource definition. If this doesn't work, I will post an update here. If you don't hear back I think you can assume it fixed the issue.

[dumptruckman]

Just today, one of our pipelines exhibited this behavior even after moving the env_name into the resource definition. Something else is going on here.