Tom, as you migrate worker types in AWS Provisioner to worker pools running under AWS Provider, it might be a good opportunity to rename that staging worker types we have for Windows. These are typically used for testing generic-worker updates. What do you think of the following names? ``` Production Windows worker pools =============================== aws-provisioner-v1/gecko-1-b-win2012 => gecko-1/b-win2012 aws-provisioner-v1/gecko-t-win10-64 => gecko-t/t-win10-64 aws-provisioner-v1/gecko-t-win10-64-gpu => gecko-t/t-win10-64-gpu aws-provisioner-v1/gecko-t-win7-32 => gecko-t/t-win7-32 aws-provisioner-v1/gecko-t-win7-32-gpu => gecko-t/t-win7-32-gpu Staging Windows worker pools ============================ aws-provisioner-v1/gecko-1-b-win2012-beta => staging-gecko-1/b-win2012 aws-provisioner-v1/gecko-t-win10-64-beta => staging-gecko-t/t-win10-64 aws-provisioner-v1/gecko-t-win10-64-gpu-b => staging-gecko-t/t-win10-64-gpu aws-provisioner-v1/gecko-t-win7-32-beta => staging-gecko-t/t-win7-32 aws-provisioner-v1/gecko-t-win7-32-gpu-b => staging-gecko-t/t-win7-32-gpu ``` The following are used by the generic-worker CI to run the generic-worker unit and integration tests on production-like worker environments: ``` aws-provisioner-v1/gecko-t-win10-64-cu aws-provisioner-v1/gecko-t-win7-32-cu aws-provisioner-v1/win2012r2-cu ``` We could potentially run these workers in the community cluster rather than the firefox-ci cluster, although it would be beneficial if we have a means to keep the images in sync with the firefox-ci counterpart images, in order that we detect integration issues as swiftly/efficiently as possible. Since the mercurial `ci-configuration` repository is separate from the github community cluster config repository (whose name I've unfortunately forgotten), I'm not sure how easy it will be to keep the two in sync, and therefore it may be more practical to leave workers in the firefox-ci deployment for generic-worker CI so that the images can be easily shared across the worker pools. What are your thoughts on this? Note, we need a separate worker pool than the staging worker pool, since the generic-worker config is different on the staging pool and the CI pool (in the CI, generic-worker need to run tasks as `root`/`LocalSystem` so runs with config setting `runTasksAsCurrentUser` set to `true`, unlike the staging workers that have this setting set to `false`, as does production). If it is ok to have some worker pools in firefox-ci for the specific purpose of integration testing worker changes, I would propose the following names. What do you think? ``` aws-provisioner-v1/gecko-t-win10-64-cu => taskcluster-ci/gecko-t-win10-64 aws-provisioner-v1/gecko-t-win7-32-cu => taskcluster-ci/gecko-t-win7-32 aws-provisioner-v1/win2012r2-cu => taskcluster-ci/gecko-1-b-win2012 ```
Bug 1588834 Comment 15 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Tom, as you migrate worker types in AWS Provisioner to worker pools running under AWS Provider, it might be a good opportunity to rename the staging worker types we have for Windows. These are typically used for testing generic-worker updates. What do you think of the following names? ``` Production Windows worker pools =============================== aws-provisioner-v1/gecko-1-b-win2012 => gecko-1/b-win2012 aws-provisioner-v1/gecko-t-win10-64 => gecko-t/t-win10-64 aws-provisioner-v1/gecko-t-win10-64-gpu => gecko-t/t-win10-64-gpu aws-provisioner-v1/gecko-t-win7-32 => gecko-t/t-win7-32 aws-provisioner-v1/gecko-t-win7-32-gpu => gecko-t/t-win7-32-gpu Staging Windows worker pools ============================ aws-provisioner-v1/gecko-1-b-win2012-beta => staging-gecko-1/b-win2012 aws-provisioner-v1/gecko-t-win10-64-beta => staging-gecko-t/t-win10-64 aws-provisioner-v1/gecko-t-win10-64-gpu-b => staging-gecko-t/t-win10-64-gpu aws-provisioner-v1/gecko-t-win7-32-beta => staging-gecko-t/t-win7-32 aws-provisioner-v1/gecko-t-win7-32-gpu-b => staging-gecko-t/t-win7-32-gpu ``` The following are used by the generic-worker CI to run the generic-worker unit and integration tests on production-like worker environments: ``` aws-provisioner-v1/gecko-t-win10-64-cu aws-provisioner-v1/gecko-t-win7-32-cu aws-provisioner-v1/win2012r2-cu ``` We could potentially run these workers in the community cluster rather than the firefox-ci cluster, although it would be beneficial if we have a means to keep the images in sync with the firefox-ci counterpart images, in order that we detect integration issues as swiftly/efficiently as possible. Since the mercurial `ci-configuration` repository is separate from the github community cluster config repository (whose name I've unfortunately forgotten), I'm not sure how easy it will be to keep the two in sync, and therefore it may be more practical to leave workers in the firefox-ci deployment for generic-worker CI so that the images can be easily shared across the worker pools. What are your thoughts on this? Note, we need a separate worker pool than the staging worker pool, since the generic-worker config is different on the staging pool and the CI pool (in the CI, generic-worker need to run tasks as `root`/`LocalSystem` so runs with config setting `runTasksAsCurrentUser` set to `true`, unlike the staging workers that have this setting set to `false`, as does production). If it is ok to have some worker pools in firefox-ci for the specific purpose of integration testing worker changes, I would propose the following names. What do you think? ``` aws-provisioner-v1/gecko-t-win10-64-cu => taskcluster-ci/gecko-t-win10-64 aws-provisioner-v1/gecko-t-win7-32-cu => taskcluster-ci/gecko-t-win7-32 aws-provisioner-v1/win2012r2-cu => taskcluster-ci/gecko-1-b-win2012 ```