chore(docs): update external provisioners documentation #12315
Conversation
johnstcn
commented
Feb 27, 2024
- Removes the verbiage regarding 'generic provisioners'
- Adds details regarding tag matching logic
| coder templates push on-prem \ | ||
| --provisioner-tag scope=user | ||
| ``` | ||
| > Provisioners have two important tags: `scope` and `owner`. Coder sets these |
There was a problem hiding this comment.
I'm not sure "important" is the right word. Maybe scope and owner are implicit tags and then we can talk about explicit tags being the ones you explicitly set on the command line
There was a problem hiding this comment.
Yeah "explicit" vs "implicit" is good wording.
|
|
||
| 1. The provisioner and job tags are both organization-scoped and both have no | ||
| additional tags set, | ||
| 1. The set of tags of the build job is a subset of the set of tags of the |
There was a problem hiding this comment.
This makes it sound like if the job is organization scoped with no further tags it can run on any org-scoped provisioner.
I thought such a job can only run on an org-scoped provisioner with no further tags?
The way I would explain it is that scope and owner are implicit tags.
An job with no explicit tags can only be run on a provisioner with no explicit tags. This way you can introduce tagging into your deployment without disrupting existing provisioners and jobs.
If a job has any explicit tags, it can only run on a provisioner with those explicit tags (the provisioner could have additional tags).
| A provisioner can run a given build job if one of the below is true: | ||
|
|
||
| 1. The provisioner and job tags are both organization-scoped and both have no | ||
| additional tags set, |
There was a problem hiding this comment.
What if the job is user-scoped and has no additional tags set? Can it run on a user-scoped provisioner that has tags?
There was a problem hiding this comment.
Yes, it currently can. There's no extra special-casing for user-scoped provisioners.
| | `{"owner":"","scope":"organization"}` | `{"owner":"","scope":"organization"}` | true | | ||
| | `{"owner":"","scope":"organization"}` | `{"environment":"on_prem","owner":"","scope":"organization"}` | false | | ||
| | `{"environment":"on_prem","owner":"","scope":"organization"}` | `{"owner":"","scope":"organization"}` | false | | ||
| | `{"environment":"on_prem","owner":"","scope":"organization"}` | `{"foo":"bar","owner":"","scope":"organization"}` | true | |
There was a problem hiding this comment.
shouldn't this be false because the provisioner doesn't have foo=bar?
There was a problem hiding this comment.
Good catch. I updated this to be auto-generated #12347
|
|
||
| | Provisioner Tags | Job Tags | Can run job? | | ||
| | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------ | | ||
| | `{"owner":"","scope":"organization"}` | `{"owner":"","scope":"organization"}` | true | |
There was a problem hiding this comment.
I think these would be easier to read if it was just in key1=value1, key2=value2 format instead of JSON.
| | `{"owner":"aaa","scope":"owner"}` | `{"owner":"bbb","scope":"owner"}` | false | | ||
| | `{"owner":"","scope":"organization"}` | `{"owner":"aaa","scope":"owner"}` | false | | ||
|
|
||
| The external provisioner in the above example can run build jobs with tags: |
There was a problem hiding this comment.
which is the above example? The one on line 86? If so, this should be moved to before the table
| - `data_center=chicago` | ||
| - `environment=on_prem datacenter=chicago` | ||
| - `environment=cloud datacenter=chicago` | ||
| - `environment=on_prem datacenter=new_york` |
There was a problem hiding this comment.
if the provisioner has a datacenter tag, it can't run both datacenter=chicago and datacenter=new_york jobs.
| - `environment=on_prem` | ||
| - `data_center=chicago` | ||
| - `environment=on_prem datacenter=chicago` | ||
| - `environment=cloud datacenter=chicago` |
There was a problem hiding this comment.
it shouldn't be able to run environment=cloud jobs if it is tagged environment=on_prem