Skip to content

Provisioner using PSK will not be selected if a scope tag is absent #9234

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

Closed
pratheekrebala opened this issue Aug 21, 2023 · 4 comments · Fixed by #9436
Closed

Provisioner using PSK will not be selected if a scope tag is absent #9234

pratheekrebala opened this issue Aug 21, 2023 · 4 comments · Fixed by #9436
Assignees
Labels
s2 Broken use cases or features (with a workaround). Only humans may set this.

Comments

@pratheekrebala
Copy link

pratheekrebala commented Aug 21, 2023

Good Evening!

I have been trying to deploy external provisioners using the pre-shared key based authentication. Despite various attempts using different configurations, I was unable to get the provisioner to be selected. However, I was able to select the provisioner when using my personal user token.

Upon further inspection, it seems that an external provisioner that is missing an scope=organization tag will never be selected. I am not sure if this is intended behaviour. It would make sense that provisioner deployments have to be explicit about specific the scopes that they would be serving. I only realized this when looking at the /api/v2/organizations/me/provisionerdaemons endpoint and noticed that all the inbuilt provisioners have the scope=organization tag on them.

The current helm chart does not add this tag which means that jobs will just hang unless the in-built provisioner daemons are enabled.

@cdr-bot cdr-bot bot added the bug label Aug 21, 2023
@pratheekrebala
Copy link
Author

I think the issue could be happening because of the difference in logic here (assuming defaulting to org scope is acceptable):

coder/coderd/coderd.go

Lines 1083 to 1091 in 69ec8d7

daemon, err := api.Database.InsertProvisionerDaemon(dbauthz.AsSystemRestricted(ctx), database.InsertProvisionerDaemonParams{
ID: uuid.New(),
CreatedAt: database.Now(),
Name: name,
Provisioners: []database.ProvisionerType{database.ProvisionerTypeEcho, database.ProvisionerTypeTerraform},
Tags: database.StringMap{
provisionerdserver.TagScope: provisionerdserver.ScopeOrganization,
},
})

daemon, err := api.Database.InsertProvisionerDaemon(ctx, database.InsertProvisionerDaemonParams{
ID: uuid.New(),
CreatedAt: database.Now(),
Name: name,
Provisioners: provisioners,
Tags: tags,
})

@bpmct
Copy link
Member

bpmct commented Aug 22, 2023

cc @spikecurtis

@spikecurtis spikecurtis self-assigned this Aug 22, 2023
@spikecurtis
Copy link
Contributor

All provisioner jobs default to scope=organization, unless they are specifically set to scope=user.

I guess we should also default this tag for external provisioners. In the meantime @pratheekrebala, you can work around the issue by explicitly setting the tag in your Helm values.yaml.

@spikecurtis spikecurtis added the s2 Broken use cases or features (with a workaround). Only humans may set this. label Aug 22, 2023
@johnstcn
Copy link
Member

johnstcn commented Sep 1, 2023

@pratheekrebala PSK auth will now automatically set the provisionerd scope to organization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
s2 Broken use cases or features (with a workaround). Only humans may set this.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants