)]}'
{"doc/source/job-content.rst":[{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"7a86dcda6fdfaf5a41015b1f1a201883f3f8cb7b","unresolved":false,"context_lines":[{"line_number":655,"context_line":"   .. var:: node_priority"},{"line_number":656,"context_line":""},{"line_number":657,"context_line":"      The priority of this job\u0027s node. Lower numbers correspond to higher"},{"line_number":658,"context_line":"      priority"},{"line_number":659,"context_line":""},{"line_number":660,"context_line":".. var:: zuul_success"},{"line_number":661,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"0745adb8_acdfd44e","line":658,"updated":"2022-07-20 22:29:31.000000000","message":"A more accurate description would be:\n\nThe relative priority of this queue item\u0027s node requests compared to other items in the same pipeline in the same tenant at the time the build request for this job was enqueued (though the value here does not reflect whether this tenant actually has the relative_priority feature enabled).","commit_id":"6ed659409b78d79f3a50a54cdd38d3a7ad4689c4"}],"releasenotes/notes/node_priority-ffa7f9bd0e348694.yaml":[{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"7a86dcda6fdfaf5a41015b1f1a201883f3f8cb7b","unresolved":false,"context_lines":[{"line_number":4,"context_line":"    Jobs are now passed the `zuul.node_priority` variable so that they can"},{"line_number":5,"context_line":"    determine their priority relative to other jobs. This can be useful for"},{"line_number":6,"context_line":"    jobs that allocate resources that support a priority mechanism to ensure"},{"line_number":7,"context_line":"    that the job priority is preserved when the resource is allocated."}],"source_content_type":"text/x-yaml","patch_set":2,"id":"dc6bb9db_b0c3572d","line":7,"updated":"2022-07-20 22:29:31.000000000","message":"This is using the relative priority calculation, but it uses it regardless of whether or not relative priority is enabled for a tenant, so it won\u0027t match what we pass to Nodepool.  That may be a little counter-intuitive for some folks.\n\nAlso, since it\u0027s intended for use by Nodepool it has some intentional optimizations that shouldn\u0027t make a difference for that use case but could be confusing; it quantizes the values at certain levels.\n\nThe number is intended to change frequently until Nodepool actually allocates a node.  The fact that it\u0027s frozen in place when the build is enqueued means it won\u0027t work the same way in a build.  Imagine a job that happens to start with a very low priority.  Circumstances change and it\u0027s at the top of the queue now.  But other items right behind it start and they actually have a higher priority.  In short, I think it\u0027s potentially dangerous to use this in a job, and I think it should be limited and retained for its intended use as an internal value.","commit_id":"6ed659409b78d79f3a50a54cdd38d3a7ad4689c4"}]}