-
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
Consul Connect job with exposed check plan diff always shows changes #10099
Comments
Thanks for reporting, @evandam! Indeed we shouldn't be including that dynamically generated port label in the job diff. |
IIRC this has been an issue since the introduction of network {
mode = "bridge"
port "exposed" {}
}
...
check {
expose = true
type = "http"
port = "exposed" // **hardcode port label exposed**
path = "/hc"
interval = "10s"
timeout = "60s"
} |
This PR uses the checksum of the check for which a dynamic exposed port is being generated (instead of a UUID prefix) so that the generated port label is deterministic. This fixes 2 bugs: - 'job plan' output is now idempotent for jobs making use of injected ports - tasks will no longer be destructively when jobs making use of injected ports are re-run without changing any user specified part of job config. Fixes: #10099
This PR uses the checksum of the check for which a dynamic exposed port is being generated (instead of a UUID prefix) so that the generated port label is deterministic. This fixes 2 bugs: - 'job plan' output is now idempotent for jobs making use of injected ports - tasks will no longer be destructively updated when jobs making use of injected ports are re-run without changing any user specified part of job config. Closes: #10099
This PR uses the checksum of the check for which a dynamic exposed port is being generated (instead of a UUID prefix) so that the generated port label is deterministic. This fixes 2 bugs: - 'job plan' output is now idempotent for jobs making use of injected ports - tasks will no longer be destructively updated when jobs making use of injected ports are re-run without changing any user specified part of job config. Closes: #10099
This PR uses the checksum of the check for which a dynamic exposed port is being generated (instead of a UUID prefix) so that the generated port label is deterministic. This fixes 2 bugs: - 'job plan' output is now idempotent for jobs making use of injected ports - tasks will no longer be destructively updated when jobs making use of injected ports are re-run without changing any user specified part of job config. Closes: #10099
This PR uses the checksum of the check for which a dynamic exposed port is being generated (instead of a UUID prefix) so that the generated port label is deterministic. This fixes 2 bugs: - 'job plan' output is now idempotent for jobs making use of injected ports - tasks will no longer be destructively updated when jobs making use of injected ports are re-run without changing any user specified part of job config. Closes: #10099
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. |
Nomad version
Nomad v1.0.4 (9294f35f9aa8dbb4acb6e85fa88e3e2534a3e41a)
Operating system and Environment details
Ubuntu 18.04
Issue
When running a job with Consul Connect enabled with an exposed check, Nomad always sees check port as changed in the plan. It also throws a warning that the allocation cannot be placed, but that doesn't actually seem to be the case.
Reproduction steps
Job file (if appropriate)
Nomad Client logs (if appropriate)
The text was updated successfully, but these errors were encountered: