-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Exec UI failing when job.ID != job.Name #7814
Comments
Thanks for letting us know about this, I should be able to check it out this week. 💞 |
I couldn't find a place in the doc explaining the difference between Name and ID, so when implementing a new Job with the api.NewServiceJob method, I thought I'd use a UUID as the ID, and something more meaningful like service_type.UUID, and everything was working fine so it was great, until now! When digging into the code while trying to understand the issue, I noticed that in many places, job ID is substituted by job Name. In the API for example, sometimes the variable is called jobName nomad/command/agent/job_endpoint.go Line 66 in 51b6ba8
While in reality it is used as an ID nomad/command/agent/job_endpoint.go Line 630 in 51b6ba8
In the UI, take a job_name parameter Line 18 in 51b6ba8
And rename it to ID in order to find the object Line 19 in 51b6ba8
In the tests of the API, the mock Job has an ID != Name so everything is working and tested as it should be nomad/ui/mirage/factories/job.js Lines 17 to 19 in 51b6ba8
Indeed, if you change the id to something different than the name, you'll notice that the tests for the "Exec" UI ( and some others ) will fail So I don't know how to handle this issue, I began working on a fix for the Exec, and then I saw that the job.Name vs job.ID swap is bigger than just the Exec feature. |
This closes #7814. It’s not testable within the current testing structure, unfortunately.
This closes #7814. It makes URL-generation more central and changes the exec URL to include job id instead of name.
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
Output from
nomad version
Operating system and Environment details
Debian buster
Issue
I am running a job:
ID: f5e3edd3-deeb-46ed-a4d4-2852c3a7a5bd
Name: w000t.f5e3edd3-deeb-46ed-a4d4-2852c3a7a5bd
When trying to use the new Exec feature from the UI, I get on the job view:
https://server/ui/jobs/f5e3edd3-deeb-46ed-a4d4-2852c3a7a5bd
When I click on "Exec", a pop up opens with this:
URL of the popup :
https://server/ui/exec/w000t.f5e3edd3-deeb-46ed-a4d4-2852c3a7a5bd
If I manually change the URL to https://server/ui/exec/f5e3edd3-deeb-46ed-a4d4-2852c3a7a5bd , everything runs correctly, the Exec page is loaded and working
Reproduction steps
Create a Job with an ID that is not the same as the Name ( I do it with the golang library using this method )
Go to the web UI, try to "Exec" in the job, you'll see that the UI is trying to load the job by its name rather than its ID
Nomad Server logs
The text was updated successfully, but these errors were encountered: