hashicorp / hashicorp/nomad-pack
Strange behavior when used with some nomad interpolation calling filesystem function
- Dominant language
- Go
- Stars
- 447
- Forks
- 65
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
I'm not fluent at all in go and go template and the worst of all I'm quite new to nomad but I found the following behavior strange.
I have a .nomad.tpl file for nomad pack with the following:
```
job "hello_pack" {
…
group "app" {
…
task "server" {
driver = "docker"
…
config {
…
volumes = ["${abspath(".")}/packs/hello_pack:/app"]
}
}
}
}
```
The aim is to mount a relative folder. (I took my inspiration from there https://github.com/hashicorp/nomad/issues/9369#issuecomment-728929474)
Result:
- nomad-pack complains when I try to do a `nomad-pack run`
```
! Failed To Parse Job Specification
Error: input.hcl:122,23-31: Error in function call; Call to function "abspath" failed: filesystem function disabled., and 1 other diagnostic(s)
```
- but when I **render** the final hcl file with `nomad-pack render`, the result is **valid for nomad** and so, the rendered job can be run with the `nomad job run` command.
The behavior seems odd to me (why in one case it's allowed and disallowed in the other?). I would expect the same result (both running).
Version numbers:
- Nomad v1.2.6 (a6c6b475db5073e33885377b4a5c733e1161020c)
- Nomad Pack v0.0.1-techpreview3 (568ac5e)
Contributor guide
Research direction
Reproduce the issue with the provided .nomad.tpl example, comparing `nomad-pack run` with `nomad-pack render` followed by `nomad job run`. Start by tracing the two command entry points and how each parses the `abspath` filesystem function; done means the behavior is consistent or its intended difference is clearly documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100