[worker-manager] implement scheduledForDeletion as a "null" provisioner
Categories
(Taskcluster :: Services, task)
Tracking
(Not tracked)
People
(Reporter: dustin, Assigned: dustin)
Details
The idea here is to introduce a null
provisionerType and hard-wired null
provisionerId which never creates a worker and thus has no cleanup to do.
Then "deletion" of a workerType is accomplished by setting its providerId to "null" in the usual way (moving the existing provider into previousProviderIds
). Then a cron job can delete workers where provisionerId=="null"
and previousProviderIds==[]
, which will occur once any remaining workers are destroyed.
We can special-case this providerId in the UI so that it shows a "deleting*" indication, but it should still be possible to edit such a workerType, even setting its providerId back to something other than null
.
While I'm at it, I'd like to include the previousProviderIds
property in the API response, as that may be useful to users to monitor which providerIds are hanging around on a workerType.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
•
|
||
Notes to self:
- [DONE] remove scheduledForDeletion
- [DONE] remove deleteWorkerPool API method
- [DONE] update other API methods
- [DONE] write a null provider and always configure it as providerId "null"
- [DONE] write an expireWorkerPools job
- add previousProviderIds to API response
- ensure that worker scanning drops previous providers when they have no workers
Assignee | ||
Comment 2•6 years ago
|
||
That last point led to bug 1555213. It works fine for now.
Assignee | ||
Comment 3•6 years ago
|
||
- add previousProviderIds to API response
This would mean that you can't call updateWorkerPool()
with a JSON body you got back from workerPool()
. If it proves useful, we can add another API method like workerPoolStatus()
.
Assignee | ||
Comment 4•6 years ago
|
||
WIP on bug1553965 -- I'll wait until bug 1555130 lands.
Assignee | ||
Comment 5•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Description
•