feat(coderd): add filters and fix template for provisioner daemons #16558
Conversation
This change adds provisioner daemon ID filter to the provisioner daemons endpoint, and also implements the limiting to 50 results. Test coverage is greatly improved and template information for jobs associated to the daemon was also fixed.
| -- Current job information. | ||
| LEFT JOIN | ||
| template_versions version ON version.id = (current_job.input->>'template_version_id')::uuid | ||
| workspace_builds current_build ON current_build.id = CASE WHEN current_job.input ? 'workspace_build_id' THEN (current_job.input->>'workspace_build_id')::uuid END | ||
| LEFT JOIN | ||
| templates tmpl ON tmpl.id = version.template_id | ||
| -- We should always have a template version, either explicitly or implicitly via workspace build. | ||
| template_versions current_version ON current_version.id = CASE WHEN current_job.input ? 'template_version_id' THEN (current_job.input->>'template_version_id')::uuid ELSE current_build.template_version_id END | ||
| LEFT JOIN | ||
| templates current_template ON current_template.id = current_version.template_id | ||
| -- Previous job information. | ||
| LEFT JOIN | ||
| workspace_builds previous_build ON previous_build.id = CASE WHEN previous_job.input ? 'workspace_build_id' THEN (previous_job.input->>'workspace_build_id')::uuid END | ||
| LEFT JOIN | ||
| -- We should always have a template version, either explicitly or implicitly via workspace build. | ||
| template_versions previous_version ON previous_version.id = CASE WHEN previous_job.input ? 'template_version_id' THEN (previous_job.input->>'template_version_id')::uuid ELSE previous_build.template_version_id END | ||
| LEFT JOIN | ||
| templates previous_template ON previous_template.id = previous_version.template_id |
There was a problem hiding this comment.
Review: I completed this because it was missing some things. But I wonder if we need to take RBAC into consideration now?
The endpoint previously returned a job ID/status only, now it also returns information regarding the template that job is associated with.
This has some implications considering regular members are allowed to view provisioner daemon resources. WDYT @johnstcn?
I'm not particularly fond of it, but we could add the same authorization to the API endpoint as for jobs:
// For now, only owners and template admins can access provisioner jobs.
if !api.Authorize(r, policy.ActionRead, rbac.ResourceProvisionerJobs.InOrg(org.ID)) {
httpapi.ResourceNotFound(rw)
return nil, false
}There was a problem hiding this comment.
I don't know how sensitive template or template_version fields can be, but a red flag for me would be if this could cross org boundaries.
I think some further questions we need to answer before we can even update the RBAC rules are:
- Who can view a template import job not linked to any workspace? (Suggestion: anyone who can read the linked template)
- Who can view a workspace build job? (Suggestion: anyone who can read the linked workspace)
To be safe, I think we should promote the same level of access control as for provisioner jobs for now. We should add a follow-up issue to take provisioner job ownership and template-level ACLs into account.
Does that sound reasonable to you?
| tags := database.StringMap{} | ||
| if tagsRaw != "" { | ||
| if err := tags.Scan([]byte(tagsRaw)); err != nil { | ||
| httpapi.Write(ctx, rw, http.StatusBadRequest, codersdk.Response{ | ||
| Message: "Invalid tags query parameter", | ||
| Detail: err.Error(), | ||
| }) | ||
| return | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
non-blocking, suggestion: qp.StringMap could be a nice QoL feature to have here!
There was a problem hiding this comment.
Ended up implementing that here: #16578
|
Thanks for the reviews @johnstcn and @mtojek! I’ll merge this now to unblock @BrunoQuaresma and follow-up on Monday on both the RBAC change and open an issue for improvements. As well as that qp.StringMap (nice suggestion!) |
This change adds provisioner daemon ID filter to the provisioner daemons
endpoint, and also implements the limiting to 50 results.
Test coverage is greatly improved and template information for jobs
associated to the daemon was also fixed.
Updates #15084
Updates #15192
Related #16532