Panic when referencing ${env["VAR"]} in Docker task args #9956
Comments
|
Thanks for opening this issue @manicminer! We definitely don't want to have a panic here. If we use the As for what you're trying to do, |
tgross
added
theme/hcl
type/bug
stage/accepted
|
I think I'm running into the same issue. The relevant part of my config is (inside a task stanza): This was derived from the example at: https://www.nomadproject.io/docs/job-specification/template#inline-template I've tried various alternatives, I'm not sure what the correct way to do this is. |
|
Sorry, scratch the above comment. The config snippet I pasted is in fact not the problem. Elsewhere in the file I had an example that looked just like the original reporter's |
tgross
moved this from Needs Triage
to Needs Roadmapping
in Nomad - Community Issues Triage
|
Did a little more debugging. This more minimal jobspec throws the same panic: variable "env" {
type = map(string)
default = {
"PORT" = "8000"
}
}
job "http-echo" {
datacenters = ["home"]
group "echo" {
task "server" {
driver = "docker"
config {
image = "hashicorp/http-echo:latest"
args = [
"-listen", ":${env["PORT"]}",
]
}
}
}
}This variant passes validation and doesn't panic, but then throws an error into Unfortunately this jobspec passes validation (which we probably don't want) but then results in the same error after placement: job "http-echo" {
datacenters = ["home"]
group "echo" {
task "server" {
driver = "docker"
config {
image = "hashicorp/http-echo:latest"
args = [
"-listen", ":${env.PORT}",
]
}
}
}
} |
|
So it looks like there's a bit of an architectural problem here. When we implemented HCL2 we pushed as much of the processing as possible down into the gohcl layer so that we didn't have to write a whole bunch of custom decoders, but it looks like that lightweight approach makes it challenging to recover from this kind of error as well. Because this is entirely client side and there's a workaround (not passing invalid HCL), I'm not going to try to hold up Nomad 1.0.4 for it... I'm going to circle up with some of my colleagues and try to figure out what we can do about this sort of problem for 1.1. |
tgross
moved this from In Progress
to Needs Roadmapping
in Nomad - Community Issues Triage
|
We have the same issue as above, is this any known workarounds yet? |
|
@jesper-sjovall the issue only occurs when you supply invalid configuration in a job. Therefore the workaround is to fix your job specification. The problem is that it can be hard to debug without a proper error message. Double-check your variables, especially any usage of |
|
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues. |
For reporting security vulnerabilities please refer to the website.
If you have a question, prepend your issue with
[question]or preferably use the nomad mailing list.If filing a bug please include the following:
Nomad version
Nomad v1.0.3 (08741d9f2003ec26e44c72a2c0e27cdf0eadb6ee)Operating system and Environment details
Linux nomad 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Issue
Trying to reference an environment variable in the
argsattribute of a Docker task. Get a panic when runningnomad job run foo.nomad. I'm not sure if the task syntax is entirely correct but I figured a panic is undesirable either way?Reproduction steps
nomad job run foo.nomadJob file (if appropriate)
Panic trace
The text was updated successfully, but these errors were encountered: