1011167 - Worker CI

Status: RESOLVED INVALID

(Taskcluster :: Workers, defect)

Description

[James Lal [:lightsofapollo]]

Deploying a worker right now is painful... First you need a custom configuration with the correct credentials then you must run packer and finally update your desired worker-type in the provisioner. The other effect this has is we never run tests directly on production ready worker types.

This is easy to solve:

1. Define common configurations "somewhere" (do we need a UI?) this includes the correct credentials, etc... needed to operate the worker.

2. Have a "CI" (intentionally vague) listen for incoming commits, pull requests and 1. build the ami, 2. deploy the ami, 3. run the tests for the given ami. (we cn make 1 fast by running packer on a aws chroot).

3. If everything is green "deploy" the ami as the correct worker type.

Comment 1

[Jonas Finnemann Jensen (:jonasfj)]

I think adding an API on the provisioner to manage:
 A) Worker types and their definition
 B) AMI registered (and deregister them by reference count)think managing AMIs using the provision

With respect to credentials that needs to be distributed I suspect that we could store them on the provisioner and substitute them into user-data the same way we substitute data into task-graphs on the scheduler.

Regarding CI integration, I'm a bit torn on that. We could use travis-ci, security of secret variables might be good enough. Either way, when auth is added to provisioner, the CI system or person who builds a new docker-worker AMI should have taskcluster credentials to talk to provisioner.

But yeah, store the configuration "somewhere" makes sense... Substituting it into the JSON on the provisioner seems like a sounds plan to me.