Closed Bug 1553965 Opened 6 years ago Closed 6 years ago

[worker-manager] implement scheduledForDeletion as a "null" provisioner

Categories

(Taskcluster :: Services, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

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.

Type: defect → task

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

That last point led to bug 1555213. It works fine for now.

  • 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().

WIP on bug1553965 -- I'll wait until bug 1555130 lands.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.