1164455 - reduce scopes that buildbot bridge credentials have

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[[e-mail] (:bhearsum)]

I gave them "*" originally because I wasn't sure what they would actually need. Now that things are a bit more fleshed out we should be able to scope them down some. The only new work that might require more scopes that I know of is bug 1156305, which will have the bridge calling createTask in some situations.

Comment 1

[Jonas Finnemann Jensen (:jonasfj)]

queue.claimTask, queue.reclaimTask:
  queue:claim-task
  assume:worker-type:<provisionerId>/<workerType>
  assume:worker-id:<workerGroup>/<workerId>

queue.createArtifact: (I believe I've seen this one in use)
  queue:create-artifact:<name>
  assume:worker-id:<workerGroup>/<workerId>

queue.rerunTask:
  queue:rerun-task
  assume:scheduler-id:<schedulerId>/<taskGroupId>

queue.cancelTask:
  queue:cancel-task
  assume:scheduler-id:<schedulerId>/<taskGroupId>

queue.reportCompleted, queue.reportException, queue.reportFailed:
  queue:resolve-task
  assume:worker-id:<workerGroup>/<workerId>


Formally, I suggest the following:
  queue:claim-task
  queue:cancel-task
  queue:rerun-task  
  queue:create-artifact:*
  queue:resolve-task

  assume:worker-type:buildbot-bridge/buildbot-bridge
  assume:worker-id:buildbot-bridge/buildbot-bridge
  assume:scheduler-id:*

Did I miss any API calls?

--------------- for creating tasks in the future:
queue.createTask:
  queue:create-task:<provisionerId>/<workerType>
  queue:route:<route> // if you need to specify task.routes = [...]
  *  // if you want to create tasks that can have arbitrary scopes in task.scopes

You can also use:
  queue.defineTask
  queue.scheduleTask
If you want a two step process, first define then schedule.
Similar, but slightly different scopes are required for this.

If the goal here is to reflect tasks, I suspect you won't need task.routes or task.scopes.
So you'll just need something like:
  queue:create-task:buildbot-bridge/buildbot-slave
  assume:worker-type:buildbot-bridge/buildbot-slave
  assume:worker-id:buildbot-bridge/buildbot-slave

Obviously, you'll need a different workerType for the tasks that are created in TC only to reflect
state from BB. Ie. these tasks are scheduled by BB and not TC (as I understand them).

Comment 2

[[e-mail] (:bhearsum)]

(In reply to Jonas Finnemann Jensen (:jonasfj) from comment #1)
> Formally, I suggest the following:
>   queue:claim-task
>   queue:cancel-task
>   queue:rerun-task  
>   queue:create-artifact:*
>   queue:resolve-task
> 
>   assume:worker-type:buildbot-bridge/buildbot-bridge
>   assume:worker-id:buildbot-bridge/buildbot-bridge
>   assume:scheduler-id:*
> 
> Did I miss any API calls?

You didn't miss any API calls but I _think_ we also need queue:schedule-task for rerunTask based on http://docs.taskcluster.net/queue/api-docs/#rerunTask...unless we switch to reportException(worker-shutdown). I've granted queue:schedule-task for now and we can remove that if/when we switch.

> --------------- for creating tasks in the future:
> queue.createTask:
>   queue:create-task:<provisionerId>/<workerType>
>   queue:route:<route> // if you need to specify task.routes = [...]
>   *  // if you want to create tasks that can have arbitrary scopes in
> task.scopes
> 
> You can also use:
>   queue.defineTask
>   queue.scheduleTask
> If you want a two step process, first define then schedule.
> Similar, but slightly different scopes are required for this.
> 
> If the goal here is to reflect tasks, I suspect you won't need task.routes
> or task.scopes.
> So you'll just need something like:
>   queue:create-task:buildbot-bridge/buildbot-slave
>   assume:worker-type:buildbot-bridge/buildbot-slave
>   assume:worker-id:buildbot-bridge/buildbot-slave
> 
> Obviously, you'll need a different workerType for the tasks that are created
> in TC only to reflect
> state from BB. Ie. these tasks are scheduled by BB and not TC (as I
> understand them).

I'm not certain I fully understand why we'd want a different workerType...let's take this over to bug 1156305 though. I'm not going to add any scopes for this until I tackle that bug.

Comment 3

[Jonas Finnemann Jensen (:jonasfj)]

So unless a scope is listed in the documentation for an API end-point, either in the list of scopes,
or in the documentation text for the API end-point, then:
  A) the scope isn't required
  B) there is a bug (I take scope documentation bugs more serious, than other documentation bugs)
     (scopes does prevent things from working)

I don't see "queue:schedule-task" required for either:
 1) queue.rerunTask        (queue:rerun-task, assume:scheduler-id:*)
 2) queue.reportException  (queue:resolve-task, assume:worker-id:buildbot-bridge/buildbot-bridge)
                           ^ these should do, and are in the list of scopes I recommended.

Note, "queue:schedule-task" is afaik only required for queue.scheduleTask, which only does the first
time scheduling. Not something bb-bridge should do.

Comment 4

[[e-mail] (:bhearsum)]

(In reply to Jonas Finnemann Jensen (:jonasfj) from comment #3)
> So unless a scope is listed in the documentation for an API end-point,
> either in the list of scopes,
> or in the documentation text for the API end-point, then:
>   A) the scope isn't required
>   B) there is a bug (I take scope documentation bugs more serious, than
> other documentation bugs)
>      (scopes does prevent things from working)
> 
> I don't see "queue:schedule-task" required for either:
>  1) queue.rerunTask        (queue:rerun-task, assume:scheduler-id:*)
>  2) queue.reportException  (queue:resolve-task,
> assume:worker-id:buildbot-bridge/buildbot-bridge)
>                            ^ these should do, and are in the list of scopes
> I recommended.
> 
> Note, "queue:schedule-task" is afaik only required for queue.scheduleTask,
> which only does the first
> time scheduling. Not something bb-bridge should do.

Whoops, looks like this was a misread on my part. I dropped the queue:schedule-task scope. I managed to run through an entire job with just the scopes from comment#1 set in my dev environment, so I've gone ahead and adjusted the production scopes to match.

I'll leave this bug open so we can address the task creation scopes when I get to bug 1156305.

Comment 5

[Dustin J. Mitchell [:dustin] (he/him)]

This is sufficiently limited to not block bug 1137827 anymore

Comment 6

[Chris Cooper [:coop] (he/him)]

Ben: is there more work to do here?

Comment 7

[[e-mail] (:bhearsum)]

(In reply to Chris Cooper [:coop] from comment #6)
> Ben: is there more work to do here?

Probably good enough now that we don't have a * scope.