-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
periodic.prohibit_overlap
has unexpected behavior with blocked templating
#12478
Comments
@next-jesusmanuelnavarro it sounds like your issue is because you've got |
First of all, thanks a lot for being so kind as to open this issue yourself. The 'prohibit_overlap = "true"' is intended since, because of the nature of the job, not two instances should ever run at a time. Regarding the failure, those vault secrets are used on the hcl itself, i.e.: template {
data = <<EOH
{{ with secret "some/nonexistent/vault/path" }}
USERNAME = "{{ .Data.data.username }}"
PASSWORD = "{{ .Data.data.password }}"
{{ end }}
EOH
destination = "${NOMAD_SECRETS_DIR}/file.env"
env = true
} This above leads to task "stucked":
Since the job never gets the chance to run, it can't fail either. |
Hi @next-jesusmanuelnavarro ok that all makes sense. This blocking is a feature of consul-template. If you take a look at the templating language docs you'll see there are some options for setting default values. You might want to considering something like that I thought that the new That being said, when I tried to reproduce the same setup, the task eventually times out after 5 minutes. Can you share a more complete jobspec, your client configuration, the full template configuration (including any Here's my setup: Nomad config for VaultRunning Vault in dev mode: vault server -dev \
-dev-listen-address 0.0.0.0:8200 \
$@ Nomad vault config: vault {
enabled = true
address = "http://127.0.0.1:8200"
token = "$token"
allow_unauthenticated = true
} Resulting node attributes:
Vault setup$ export VAULT_TOKEN=$token
$ export VAULT_ADDR=http://127.0.0.1:8200
$ vault secrets enable -path=secrets kv-v2
Success! Enabled the kv-v2 secrets engine at: secrets/
# make sure we have a valid secret so we can verify we're set up correctly
$ vault kv put secrets/myapp key=xyzzy
Key Value
--- -----
created_time 2022-04-15T20:09:38.10578154Z
custom_metadata <nil>
deletion_time n/a
destroyed false
version 1
$ vault policy write myproject ./policy.hcl
Success! Uploaded policy: myproject
$ vault policy read myproject
path "secrets/data/myapp" {
capabilities = ["read"]
} First we'll use a working jobspec to demonstrate the happy case: jobspecjob "batch" {
datacenters = ["dc1"]
type = "batch"
group "group" {
task "task" {
driver = "docker"
config {
image = "busybox:1"
command = "/bin/sh"
args = ["-c", "cat local/index.txt; sleep 300; echo done"]
}
vault {
policies = ["myproject"]
}
template {
data = <<EOH
{{ with secret "secrets/myapp" }}
KEY = "{{ .Data.data.key }}"
{{ end }}
EOH
destination = "local/index.txt"
}
resources {
cpu = 128
memory = 128
}
}
}
} Run our batch job with a working secret:
Then I updated the job to have a non-existent secret and it blocks as expected:
But after 5 minutes I get a permissions failure as the token gets revoked:
|
We've answered this issue as best we can, so I'm going to close it out. If you have more information about the questions I've asked above, please feel free to reopen the issue! Thanks! |
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. |
In #12147 (comment) @next-jesusmanuelnavarro wrote:
The text was updated successfully, but these errors were encountered: