-
Notifications
You must be signed in to change notification settings - Fork 939
feat: add provisioner job metadata #16454
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -130,21 +130,43 @@ SELECT | |
AND pj.organization_id = pd.organization_id | ||
AND pj.provisioner = ANY(pd.provisioners) | ||
AND provisioner_tagset_contains(pd.tags, pj.tags) | ||
) AS available_workers | ||
) AS available_workers, | ||
-- Include template and workspace information. | ||
COALESCE(tv.name, '') AS template_version_name, | ||
t.id AS template_id, | ||
COALESCE(t.name, '') AS template_name, | ||
COALESCE(t.display_name, '') AS template_display_name, | ||
w.id AS workspace_id, | ||
COALESCE(w.name, '') AS workspace_name | ||
FROM | ||
provisioner_jobs pj | ||
LEFT JOIN | ||
queue_position qp ON qp.id = pj.id | ||
LEFT JOIN | ||
queue_size qs ON TRUE | ||
LEFT JOIN | ||
workspace_builds wb ON wb.id = CASE WHEN pj.input ? 'workspace_build_id' THEN (pj.input->>'workspace_build_id')::uuid END | ||
LEFT JOIN | ||
workspaces w ON wb.workspace_id = w.id | ||
Comment on lines
+149
to
+150
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it possible that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, if the job is a template version import. |
||
LEFT JOIN | ||
-- We should always have a template version, either explicitly or implicitly via workspace build. | ||
template_versions tv ON tv.id = CASE WHEN pj.input ? 'template_version_id' THEN (pj.input->>'template_version_id')::uuid ELSE wb.template_version_id END | ||
Comment on lines
+152
to
+153
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the issue here that either There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not quite. Both could be null in the future, all we need to do is add a new provisioner job type/input. What we do get currently though, assuming correct input, is that there always exists a template version either directly (id) or indirectly (workspace build). This makes sure we join the template version (and thus, template) in both cases. And in the case that neither exists in input, the template and template version info will be null. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Gotcha. It might be good to add some querier tests for these eventualities just to make sure we're not surprised in the future. |
||
LEFT JOIN | ||
templates t ON tv.template_id = t.id | ||
WHERE | ||
(sqlc.narg('organization_id')::uuid IS NULL OR pj.organization_id = @organization_id) | ||
AND (COALESCE(array_length(@ids::uuid[], 1), 0) = 0 OR pj.id = ANY(@ids::uuid[])) | ||
AND (COALESCE(array_length(@status::provisioner_job_status[], 1), 0) = 0 OR pj.job_status = ANY(@status::provisioner_job_status[])) | ||
GROUP BY | ||
pj.id, | ||
qp.queue_position, | ||
qs.count | ||
qs.count, | ||
tv.name, | ||
t.id, | ||
t.name, | ||
t.display_name, | ||
w.id, | ||
w.name | ||
ORDER BY | ||
pj.created_at DESC | ||
LIMIT | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which party will consume the metadata later? I mean, is it human or machine?
If human, perhaps we can remove
template_id
andworkspace_id
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either machine or human. For now, this is needed in the UI to show and link relevant workspace/template. I'll defer to @BrunoQuaresma as to what's needed, but I don't see any harm in keeping the IDs in? If I was an admin debugging provisioner jobs, I'd imagine it could come in handy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would agree with leaving this information available in the JSON output. This is my general experience with other CLI tooling as well (e.g.
kubectl
ordocker
) -- if you need all the info, dump the JSON or YAML and read it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why I raised this comment is my concern about the response size. IMHO we could always add these properties later, but if you find these could be useful for debugging then leave them as is. I understand that admins don't use them for troubleshooting but rather default to template/template version/workspace names, and IDs seem to be internal references.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Response size is a valid concern @mtojek, especially considering we didn't limit the response of this endpoint previously. In the regular response size (say 50 entries), these UUIDs are quite harmless and the endpoint isn't going to be very actively used. I haven't personally needed to debug provisioner jobs so I went for more rather than less, but happy to go either way here (assuming @BrunoQuaresma doesn't need the IDs).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW @BrunoQuaresma is out today, and since it is not a huge issue I don't have anything against merging it as is 👍