1578922 - Let's move `workerConfig` up to the top level of workerPool configs in worker-manager

Status: NEW

(Taskcluster :: Services, enhancement)

Description

[Brian Stack [:bstack]]

This will allow us to do a better job documenting it and possibly even schematizing it. This works because worker-runner will pull from it even for static instances.

Comment 2

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

My understanding of the decision last night:

• Each WorkerPool has a top-level workerConfig property
• That config might be exposed through the response to registerWorker, or maybe through another API method
• tc-worker-runner would be modified to get the configuration from wherever it's exposed and merge it into the worker config
• worker config would no longer be included in instance metadata

I'm not sure how schematizing would work -- how would a worker implementation register its schema? How would worker-manager know which version of which worker implementation a particular worker pool corresponded to?

Comment 3

[[:owlish] 🦉 PST]

Each WorkerPool has a top-level workerConfig property

...which is optional, we seemed to agree?

how would a worker implementation register its schema?

The workerConfig object schema will probably live in worker-manager, for the cases when it's set manually through workerPool... Is there a separate schema checks in workers and/or worker-manager?

Comment 4

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

Yes, good point -- it's optional.

What do you mean by "live in worker-manager"? In the source, or in an Azure table?

Comment 5

[Brian Stack [:bstack]]

worker config would no longer be included in instance metadata I think it would still be there for the cloud use-cases to use if they want. Then we can provide a separate endpoint to fetch it for static?

Comment 6

[Pete Moore [:pmoore][:pete]]

(In reply to Brian Stack [:bstack] from comment #5)

worker config would no longer be included in instance metadata I think it would still be there for the cloud use-cases to use if they want. Then we can provide a separate endpoint to fetch it for static?

I think this would already be covered by workermanager.workerPool.