HCL2 and HTTP API

Nomad
1

We have some utilities that communicate with Nomad with its HTTP API.
We would like to start utilising some of the HCL2 features like variables but not sure how to make it work at the moment.

When submitting jobs, we use the /v1/jobs/parse endpoint to convert HCL to JSON and then submit the JSON as required by the API. However, with HCL2 it seems like some pre-processing is required when it comes to variables.

Our utilities are written with Python so that makes things worse since I don’t think there is an official HCL2 library for Python.
I really don’t wont to fork out to external nomad process to do this, is there any other way?

1 Like
2

Bump… trying again.

3

Hi @m1keil the HCL2 parsing is done entirely CLI-side. The assumption here is that if you’re using the HTTP API you’re already in a “programmatic” environment where manipulating the request body isn’t a problem. Note that because the variable values can come from the CLI environment (either env vars or even local files), it’s not really feasible for the HTTP API to do the variable interpolation: the environment values would be for the server host instead of the CLI host.

4

Thanks for confirming my suspicions. But in this case, isn’t this very limiting? As far as I know, there are no official HCL2 parsers for Python, JS, Ruby and so on. So any nomad file that is written in HCL2 needs to be adapted before it can be consumed by these languages.

I understand the problem of local context I just don’t think this is very clear. It seems that some parts of HCL2 are ok to use but others don’t. How can we tell?

For example, passing this via Nomad UI won’t work:

variable "version" {
  type = string
}

job "example" {
    task "redis" {
      driver = "docker"

      config {
        image = "redis:${var.version}"
      }
    }
  }
}

But this does:

locals {
  version = 3.2
}

job "example" {
  datacenters = ["dc1"]

  group "cache" {
    task "redis" {
      driver = "docker"

      config {
        image = "redis:${local.version}"
      }
    }
  }
}

(certain config parts were omitted for clarity).

And then there is Levant… It would be nice to get an official stance on where this is going. Should we invest in HCL2, should we invest in Levant, should we keep using our own templating layer with Jinja2 or maybe something else entirely.

1 Like
5

Even though the endpoint seems to accept Variables and VariableFlags (nomad 1.6), I couldn’t get that to work . I went with calling nomad run -output -var x=y path/to/file.nomad with python’s subprocess and using that :upside_down_face: