Open Bug 1580570 Opened 5 years ago Updated 5 years ago

[image-generation] automated baking of worker images

Categories

(Taskcluster :: Workers, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: miles, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

Attachments

(3 files)

This bug covers automating the generation of production taskcluster worker images.

At a high level, we will need:

  • Workers in AWS and GCP with cloud permissions to spin up other instances, snapshot, etc.
  • Due to security concerns, these instances should probably live in an independent AWS account from taskcluster-prod, and a separate GCP project
  • Support retrying image generation failures

This probably looks like a main task that farms out individual builder tasks to generate images, so that each can be retried individually.

Depends on: 1580571
Depends on: 1580572
Depends on: 1580593

We have a worker-pool created for this, but a few more steps to take:

  • we need AWS and GCP credentials for baking images that workers in the worker-pool can access (stored as tc secrets)
    • it would probably be easiest to use the taskcluster-staging AWS account for this as it doesn't require creating a new account
  • implement the task that builds images, or a decision style task that triggers image building subtasks
  • more, probably

We have a preliminary pass of this baking GCP images in taskcluster here: https://github.com/taskcluster/monopacker/pull/22.

Here is an example task triggered by a commit to the master branch of monopacker:

The task has an artifact generated by Packer that details the output image IDs. For now, do not have production secrets in place - that is the next and hopefully last step towards real production images being generated automatically in CI.

We've run into a blocker for automating this process in taskcluster: storing the CoT key in taskcluster secrets violates the independent second factor intent of chain of trust.

Per aki: "The CoT key is supposed to be a second factor, separate from Taskcluster scopes. If it's deployable with Taskcluster scopes, it's no longer an independent second factor."

There are changes to the chain of trust implementation in the works that would make automating this in the taskcluster platform more feasible in the future.

For now, any kind of automation can be used to trigger monopacker - as long as there is a secure place to store secrets and run jobs that is independent of taskcluster, that should be sufficient.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: