In the Taskcluster team meeting yesterday, Tom mentioned needing to verify that the GCP builders had the proper CoT keys available before we cut-over the tier 1 builders from AWS.

If there are any other things we should verify before cutting over, let's get them listed and start working through the list.

Similarly, if there are pending releases that would prevent us from cutting over on a certain date, let's make those know too.

I've tentatively given us a week (until Nov 26) to make the cut-over, but if that needs to change, I'd like to know sooner.

Releng: assuming no capacity issues in GCP, are there any other concerns that would prevent us from cutting over builds from AWS to GCP? Any concern with level 1 vs level 3 builds?

:fubar is going to be driving the process to document and review the network setup in Bug 1597771.

I also don't see any worker images with trusted chain-of-trust keys. New images will need to be built with those keys. I think (but am not sure) those images should probably live in the level-3 project. They should definitely only be shared with that project.

(In reply to Tom Prince [:tomprince] from comment #2)

I also don't see any worker images with trusted chain-of-trust keys. New images will need to be built with those keys. I think (but am not sure) those images should probably live in the level-3 project. They should definitely only be shared with that project.

Can we cut-over level-1/Try builds before level-3 is ready, or do we want/need to do this wholesale?

I have two concerns, neither of which are blocking:

1. I'm not sure if the level-1 network setup supports live logs or interactive tasks, currently.
2. Switching gecko-1/linux to gcp (without also switching gecko-3/linux, is that if there are issues that depend on the difference, it will be hard to test. That said, I wouldn't expect that kind of issue.

Those both seem like tradeoffs that might be reasonable to make (though, as the don't impact me, I may not be the best judge).

Found in triaging.
@Tom: do we still need this or has this bug outlived its purpose given that bug 1547111 is going along smoothly?

I don't see anything actionable to do in here, resolving.