You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
0.10.4 (I've also tried this on 0.10.3 - same results)
Operating system and Environment details
CentOS 7.7 - though I suspect the issue is OS-independent
Issue
When submitting jobs through the cli with the hcl job format, the local_service_port and local_service_address properties (added in #6358) are not respected. These properties only appear to be respected if jobs are submitted as JSON through the http api.
Reproduction steps
Run the job below via the CLI on any basic nomad cluster: nomad job run countdash.hcl
Run nomad job inspect countdash > countdash.json
cat countdash.json, and see that the LocalServicePort property has a value of "0", instead of the expected "9001".
Modify that json file—in the count-api's service block, change it to say "LocalServicePort": "9001". (Due to Changes to connect stanza get ignored on job re-run #6459 you will also have to edit another property for it to take effect—change the value of the "FOO" variable in the env block from "BAR", to "FOOBAR")
Submit the modified job via the http api, with curl: curl -XPOST -H "Content-Type: application/json" -d @countdash.json http://127.0.0.1:4646/v1/jobs
Observe that the local service port is now correctly reflected when inspecting the job (nomad job inspect | grep "LocalServicePort")
Modify your ORIGINAL job file (the HCL version) and change the local_service_port to something else, like 10001
Re-run the job with the cli: nomad job run countdash.hcl
Observe that once again, inspecting the job shows LocalServicePort has been reverted to "0"
Job file
Below is the "countdash" example job from the nomad consul-connect integration guide... except that I modified it slightly to show this issue. The only changes I made were:
adding the port "api_http" block to the "api" group, with to = 9001
changing the count-api service's port from 9001 to the port label "api_http"
adding the proxy block to the connect sidecar, with the local_service_port = 9001 option
adding an (irrelevant) env block to the "web" task, to make the reproduction steps above easier
This minimally reproduce my current setup, which is a hybrid of consul-connect-enabled and non-connect services, as part of a larger transition plan.
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.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Nomad version
0.10.4 (I've also tried this on 0.10.3 - same results)
Operating system and Environment details
CentOS 7.7 - though I suspect the issue is OS-independent
Issue
When submitting jobs through the cli with the hcl job format, the
local_service_port
andlocal_service_address
properties (added in #6358) are not respected. These properties only appear to be respected if jobs are submitted as JSON through the http api.Reproduction steps
nomad job run countdash.hcl
nomad job inspect countdash > countdash.json
cat countdash.json
, and see that theLocalServicePort
property has a value of"0"
, instead of the expected"9001"
.count-api
's service block, change it to say"LocalServicePort": "9001"
. (Due to Changes to connect stanza get ignored on job re-run #6459 you will also have to edit another property for it to take effect—change the value of the"FOO"
variable in theenv
block from"BAR"
, to"FOOBAR"
)curl -XPOST -H "Content-Type: application/json" -d @countdash.json http://127.0.0.1:4646/v1/jobs
nomad job inspect | grep "LocalServicePort"
)local_service_port
to something else, like10001
nomad job run countdash.hcl
"0"
Job file
Below is the "countdash" example job from the nomad consul-connect integration guide... except that I modified it slightly to show this issue. The only changes I made were:
port "api_http"
block to the "api" group, withto = 9001
count-api
service's port from9001
to the port label"api_http"
proxy
block to the connect sidecar, with thelocal_service_port = 9001
optionenv
block to the "web" task, to make the reproduction steps above easierThis minimally reproduce my current setup, which is a hybrid of consul-connect-enabled and non-connect services, as part of a larger transition plan.
The text was updated successfully, but these errors were encountered: