Terraform provider http STOPPED working for data "http" "env-vars" & data "http" "app-versions"

Terraform
1

Please I need help !
My setup uses env-vars and app-version

data "http" "env-vars" {
  url = "https://gitlab.xxx/api/v4/projects/68/repository/files/${local.env_json_path}/raw?ref=${
  request_headers = {
    Accept        = "application/json"
    Private-Token = local.gitlab-token
  }
}

&&&

data "http" "app-versions" {
  url = "https://gitlab.xxx/api/v4/projects/64/repository/files/appversions.lock/raw?ref=${var.release}"
  request_headers = {
    Accept        = "application/json"
    Private-Token = local.gitlab-token
  }
}

I get these error even tho the environment json file has the attributed specified in the error message

 Error: Unsupported attribute
│ 
│   on ../secrets/secrets.tf line 21, in resource "kubernetes_secret" "consumer-secret":
│   21:     DB_PASSWORD = base64decode(var.env-vars.DB_PASSWORD)
│     ├────────────────
│     │ var.env-vars is object with 2 attributes
│ 
│ This object does not have an attribute named "DB_PASSWORD".

ANY IDEAS WHY?

2

Hi @sforze,

Unfortunately I think you’ve skipped a step in what you shared here. The two code examples are for data "http" blocks, but the error message is about a resource "kubernetes_secret" block and seems to involve an input variable called “env-vars”, neither of which are in the code snippets you sent.

It would be helpful if you would post a followup that includes all of the source code relevant to this problem, which at least includes the resource block the error was about and the declarations and assignments of everything this expression refers to.

Thanks!

3

@apparentlymart thanks for quick responds!. the error message TF is showing is misleading as we just found out that the issue was due to expired gitlab token.
All good now with the TF plan and deployments. Thanks again

4

Thanks for following up!

Based on the incomplete information you shared, my assumption is that you’re taking the response body from data.http.env-vars and using jsondecode to decode it, and then using that to populate var.env-vars in whatever module contains the kubernetes_secret resource.

If that’s true, then perhaps what happened here is that the GitLab server returned an error that was also in JSON format, and so the jsondecode worked but returned an object describing GitLab’s error response rather than the content of the file you intended to retrieve. That means that the two attributes of var.env-vars are whatever properties GitLab includes in its JSON error responses, rather than your environment variables.

If you think that seems like a plausible explanation for the confusing error message, I would suggest adding a postcondition block to your data block to cause it to fail with a more relevant error message when the server returns a non-successful response:

data "http" "env-vars" {
  url = "https://gitlab.xxx/api/v4/projects/68/repository/files/${local.env_json_path}/raw?ref=${...}"
  request_headers = {
    Accept        = "application/json"
    Private-Token = local.gitlab-token
  }

  lifecycle {
    postcondition {
      condition     = self.status_code == 200
      error_message = "GitLab API returned status ${self.status_code}."
    }
  }
}

With that addition, Terraform will check whether the response had the 200 OK status code and return an error immediately if not, rather than continuing to evaluate downstream expressions.

That suggestion does assume that GitLab would’ve returned an error status code such as 401 Unauthorized or 403 Forbidden when you sent an expired token, which I’ve not actually confirmed, but hopefully GitLab’s API follows the typical conventions for reporting errors.

5

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.