-
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
RFD: Job Name #2248
Comments
Why don't you use task groups to manage versions, inside of a single job spec ? |
@nanoz That presents a different set of challenges with regards to rolling updates and continuity of service. |
Doing some issue clean up. Filter queries enable most of this today. It'd be possible to add logic to query by name and then ID on the write path as well, but realistically this doesn't have a high value for us in terms of the investment. I'm going to close this one as a wontfix. |
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. |
Problem: Nomad's Job ID has become the canonical lookup mechanism and is an integral part of
nomad
's UX, not the Job Name. For background: the Job ID is name at the top of the Job file, for example, the Job ID in the following isabcd-pgbouncer-123
and the job name ispgbouncer
:Nomad has support for a Job Name, which is automatically populated by the Job ID when the name is missing. At present, however, nothing uses the Job Name, making the parameter largely useless, and that's unfortunate because its existence and use could solve a number of problems in the area of release engineering and job management. We've been lucky in avoiding this being a problem because
nomad status ${JOB_ID}
actually does a prefix match and most of our job IDs are actually, and incorrectly, just the job name, or begin with the job name.In an exaggerated and unrealistic world, the software should be usable if the Job ID were a UUID that that was generated by a software deployment bot.
Right now
nomad status
emits Job IDs and similarly does a prefix match on the Job ID. For example:What we care about and want is continuity of the Job Name, not the Job ID. The Job ID currently contains both the Job Name and Git SHA making the Job ID semi-friendly, but also random when observed as a whole. In an idealized world, the UX would be Job Name centric, not Job ID centric. For example:
The Job Name-centric view of the world solves a few problems, notably:
nomad status ${JOB_NAME}
will return stopped allocs and stopped Job IDs until all stopped Job IDs have been reaped.grep(1)
friendlyThere's room for more refinement in those mocked up UIs, but the important take away from this RFD is that the Job Name becomes the primary point of aggregation and forward lookup mechanism for an aggregation of Jobs, not the Job ID.
The text was updated successfully, but these errors were encountered: