Many thanks for raising this. I think after I've explained the rationale behind the current design, it will make much more sense. `workerConfig` is the only section in the worker pool definition that exists to serve runtime configuration to a worker running a prebaked image. Therefore _any_ system that runs on the worker relies on this single section to retrieve runtime configuration. One of the pieces of software that runs on the worker is the worker itself. It therefore seems reasonable for it not to claim all of the available configuration for itself, when other software may be installed on the worker that requires workerpool-specific configuration too. Even early on we've seen that this was useful for example for OCC, which also runs on the workers, so that workerpool-specific OCC configuration could be included in the workerConfig section. If generic-worker had claimed the entire blob, OCC would have had no way to obtain workerpool-specific config at runtime. This explains the reason for the top level `genericWorker` config property. The reason for the `config` property below that is that the runtime generic worker configuration is more than just the config settings in the `generic-worker.config` file. That indeed covers most of its configuration, however, generic-worker also provides a mechanism (since its very first release) that allows workers to be bootstrapped with additional files. This can be workerpool-specific files that cannot be baked into an AMI that may be shared with other worker pools, or secrets that we do not want to bake into the machine images for privacy reasons. This is used to bootstrap secrets onto workers, and provide a means that secrets can be rotated without needing to build new machine images. In the old days, there was no secrets service, and those secrets were contained inside the AWS Provisioner Worker Type definition which was the reason that we could not make the worker type definitions public information, and viewing worker type definitions was guarded behind scopes. Then we migrated the private bootstrap files to the taskcluster-secrets service (for example [here](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fwin2012r2)), where they still remain. However, `generic-worker` still supports bootstrapping workers with non-private workerpool-specific files via the top level `files` property. We would lose this ability if we made the top level generic-worker config property correspond 1:1 with its config file. We can probably do a better job of documenting the bootstrapping features, and explain the reason for the top level `genericWorker` property, as without this information, it is easy to conclude that the config is nested unnecessarily. However, historically, having both levels has saved us, since it has enabled us to bootstrap workers with worker pool specific content, _and_ to include config for other systems running on the workers (such as OCC). The ability to bootstrap workers with worker pool specific files will become more important when generic-worker machine images are shared across worker pools, which is happening with the move to ci-admin/tc-admin, so we should probably shouldn't rush into changing anything quite yet.
Bug 1592844 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Many thanks for raising this. I think after I've explained the rationale behind the current design, it will make much more sense. `workerConfig` is the only section in the worker pool definition that exists to serve runtime configuration to a worker running a prebaked image. Therefore _any_ system that runs on the worker relies on this single section to retrieve runtime configuration. One of the pieces of software that runs on the worker is the worker itself. It therefore seems reasonable for it not to claim all of the available configuration for itself, when other software may be installed on the worker that requires workerpool-specific configuration too. Even early on we've seen that this was useful for example for OCC, which also runs on the workers, so that workerpool-specific OCC configuration could be included in the workerConfig section. If generic-worker had claimed the entire blob, OCC would have had no way to obtain workerpool-specific config at runtime. This explains the reason for the top level `genericWorker` config property. The reason for the `config` property below that is that the runtime generic worker configuration is more than just the config settings in the `generic-worker.config` file. That indeed covers most of its configuration, however, generic-worker also provides a mechanism (since its very first release) that allows workers to be bootstrapped with additional files. This can be workerpool-specific files that cannot be baked into an AMI that may be shared with other worker pools, or secrets that we do not want to bake into the machine images for privacy reasons. This is used to bootstrap secrets onto workers, and provide a means that secrets can be rotated without needing to build new machine images. In the old days, there was no secrets service, and those secrets were contained inside the AWS Provisioner Worker Type definition which was the reason that we could not make the worker type definitions public information, and viewing worker type definitions was guarded behind scopes. Then we migrated the private bootstrap files to the taskcluster-secrets service (for example [here](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fwin2012r2)), where they still remain. However, `generic-worker` still supports bootstrapping workers with non-private workerpool-specific files via the top level `files` property. We would lose this ability if we made the top level generic-worker config property corresponded 1:1 with its config file. We can probably do a better job of documenting the bootstrapping features, and explain the reason for the top level `genericWorker` property, as without this information, it is easy to conclude that the config is nested unnecessarily. However, historically, having both levels has saved us, since it has enabled us to bootstrap workers with worker pool specific content, _and_ to include config for other systems running on the workers (such as OCC). The ability to bootstrap workers with worker pool specific files will become more important when generic-worker machine images are shared across worker pools, which is happening with the move to ci-admin/tc-admin, so we should probably shouldn't rush into changing anything quite yet.
Many thanks for raising this. I think after I've explained the rationale behind the current design, it will make much more sense. `workerConfig` is the only section in the worker pool definition that exists to serve runtime configuration to a worker running a prebaked image. Therefore _any_ system that runs on the worker relies on this single section to retrieve runtime configuration. One of the pieces of software that runs on the worker is the worker application. It therefore seems reasonable for it not to claim all of the available configuration for itself, when other software may be installed on the worker that requires workerpool-specific configuration too. Even early on we've seen that this was useful for example for OCC, which also runs on the workers, so that workerpool-specific OCC configuration could be included in the workerConfig section. If generic-worker had claimed the entire blob, OCC would have had no way to obtain workerpool-specific config at runtime. This explains the reason for the top level `genericWorker` config property. The reason for the `config` property below that is that the runtime generic worker configuration is more than just the config settings in the `generic-worker.config` file. That indeed covers most of its configuration, however, generic-worker also provides a mechanism (since its very first release) that allows workers to be bootstrapped with additional files. This can be workerpool-specific files that cannot be baked into an AMI that may be shared with other worker pools, or secrets that we do not want to bake into the machine images for privacy reasons. This is used to bootstrap secrets onto workers, and provide a means that secrets can be rotated without needing to build new machine images. In the old days, there was no secrets service, and those secrets were contained inside the AWS Provisioner Worker Type definition which was the reason that we could not make the worker type definitions public information, and viewing worker type definitions was guarded behind scopes. Then we migrated the private bootstrap files to the taskcluster-secrets service (for example [here](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fwin2012r2)), where they still remain. However, `generic-worker` still supports bootstrapping workers with non-private workerpool-specific files via the top level `files` property. We would lose this ability if we made the top level generic-worker config property corresponded 1:1 with its config file. We can probably do a better job of documenting the bootstrapping features, and explain the reason for the top level `genericWorker` property, as without this information, it is easy to conclude that the config is nested unnecessarily. However, historically, having both levels has saved us, since it has enabled us to bootstrap workers with worker pool specific content, _and_ to include config for other systems running on the workers (such as OCC). The ability to bootstrap workers with worker pool specific files will become more important when generic-worker machine images are shared across worker pools, which is happening with the move to ci-admin/tc-admin, so we should probably shouldn't rush into changing anything quite yet.
Many thanks for raising this. I think after I've explained the rationale behind the current design, it will make much more sense. `workerConfig` is the only section in the worker pool definition that exists to serve runtime configuration to a worker running a prebaked image. Therefore _any_ system that runs on the worker relies on this single section to retrieve runtime configuration. One of the pieces of software that runs on the worker is the worker application (generic-worker/docker-worker/script-worker etc). It therefore seems reasonable for it not to claim all of the available configuration for itself, when other software may be installed on the worker that requires workerpool-specific configuration too. Even early on we've seen that this was useful for example for OCC, which also runs on the workers, so that workerpool-specific OCC configuration could be included in the workerConfig section. If generic-worker had claimed the entire blob, OCC would have had no way to obtain workerpool-specific config at runtime. This explains the reason for the top level `genericWorker` config property. The reason for the `config` property below that is that the runtime generic worker configuration is more than just the config settings in the `generic-worker.config` file. That indeed covers most of its configuration, however, generic-worker also provides a mechanism (since its very first release) that allows workers to be bootstrapped with additional files. This can be workerpool-specific files that cannot be baked into an AMI that may be shared with other worker pools, or secrets that we do not want to bake into the machine images for privacy reasons. This is used to bootstrap secrets onto workers, and provide a means that secrets can be rotated without needing to build new machine images. In the old days, there was no secrets service, and those secrets were contained inside the AWS Provisioner Worker Type definition which was the reason that we could not make the worker type definitions public information, and viewing worker type definitions was guarded behind scopes. Then we migrated the private bootstrap files to the taskcluster-secrets service (for example [here](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fwin2012r2)), where they still remain. However, `generic-worker` still supports bootstrapping workers with non-private workerpool-specific files via the top level `files` property. We would lose this ability if we made the top level generic-worker config property corresponded 1:1 with its config file. We can probably do a better job of documenting the bootstrapping features, and explain the reason for the top level `genericWorker` property, as without this information, it is easy to conclude that the config is nested unnecessarily. However, historically, having both levels has saved us, since it has enabled us to bootstrap workers with worker pool specific content, _and_ to include config for other systems running on the workers (such as OCC). The ability to bootstrap workers with worker pool specific files will become more important when generic-worker machine images are shared across worker pools, which is happening with the move to ci-admin/tc-admin, so we should probably shouldn't rush into changing anything quite yet.
Many thanks for raising this. I think after I've explained the rationale behind the current design, it will make much more sense. `workerConfig` is the only section in the worker pool definition that exists to serve runtime configuration to a worker running a prebaked image. Therefore _any_ system that runs on the worker relies on this single section to retrieve runtime configuration. One of the pieces of software that runs on the worker is the worker application (generic-worker/docker-worker/script-worker etc). It therefore seems reasonable for it not to claim all of the available configuration for itself, when other software may be installed on the worker that requires workerpool-specific configuration too. Even early on we've seen that this was useful for example for OCC, which also runs on the workers, so that workerpool-specific OCC configuration could be included in the workerConfig section. If generic-worker had claimed the entire blob, OCC would have had no way to obtain workerpool-specific config at runtime. This explains the reason for the top level `genericWorker` config property. The reason for the `config` property below that is that the runtime generic worker configuration is more than just the config settings in the `generic-worker.config` file. That indeed covers most of its configuration, however, generic-worker also provides a mechanism (since its very first release) that allows workers to be bootstrapped with additional files. This can be workerpool-specific files that cannot be baked into an AMI that may be shared with other worker pools, or secrets that we do not want to bake into the machine images for privacy reasons. For the specific case of secrets, this provides a means to rotate without secrets without needing to build new machine images, and to make machine images public for shared use. In the old days, there was no secrets service, and those secrets were contained inside the AWS Provisioner Worker Type definition which was the reason that we could not make the worker type definitions public information, and viewing worker type definitions was guarded behind scopes. Then we migrated the private bootstrap files to the taskcluster-secrets service (for example [here](https://tools.taskcluster.net/secrets/worker-type%3Aaws-provisioner-v1%2Fwin2012r2)), where they still remain. However, `generic-worker` still supports bootstrapping workers with non-private workerpool-specific files via the top level `files` property. We would lose this ability if we made the top level generic-worker config property corresponded 1:1 with its config file. We can probably do a better job of documenting the bootstrapping features, and explain the reason for the top level `genericWorker` property, as without this information, it is easy to conclude that the config is nested unnecessarily. However, historically, having both levels has saved us, since it has enabled us to bootstrap workers with worker pool specific content, _and_ to include config for other systems running on the workers (such as OCC). The ability to bootstrap workers with worker pool specific files will become more important when generic-worker machine images are shared across worker pools, which is happening with the move to ci-admin/tc-admin, so we should probably shouldn't rush into changing anything quite yet.
Many thanks for raising this. I think after I've explained the rationale behind the current design, it will make much more sense. `workerConfig` is the only section in the worker pool definition that exists to serve runtime configuration to a worker running a prebaked image. Therefore _any_ system that runs on the worker relies on this single section to retrieve runtime configuration. One of the pieces of software that runs on the worker is the worker application (generic-worker/docker-worker/script-worker etc). It therefore seems reasonable for it not to claim all of the available configuration for itself, when other software may be installed on the worker that requires workerpool-specific configuration too. Even early on we've seen that this was useful for example for OCC, which also runs on the workers, so that workerpool-specific OCC configuration could be included in the workerConfig section. If generic-worker had claimed the entire blob, OCC would have had no way to obtain workerpool-specific config at runtime. This explains the reason for the top level `genericWorker` config property. The reason for the `config` property below that is that the runtime generic worker configuration is more than just the config settings in the `generic-worker.config` file. That indeed covers most of its configuration, however, generic-worker also provides a mechanism (since its very first release) that allows workers to be bootstrapped with additional files. This can be workerpool-specific files that cannot be baked into an AMI that may be shared with other worker pools, or secrets that we do not want to bake into the machine images for privacy reasons. For the specific case of secrets, this provides a means to rotate without secrets without needing to build new machine images, and to make machine images public for shared use. Historically, secrets were baked into AWS Provisioner Worker Type definitions, and worker type definitions weren't public. Then the taskcluster-secrets service was created and the secrets migrated there, but non-secret workerpool-specific files can still be provided in worker type definitions (or workerpool definitions). Being able to bootstrap workers with workerpool-specific content when the base image is shared across worker pools is a really useful feature. Even if we removed this feature (which I don't propose we do) there is always the possibility of future features requiring configuration which sits outside of the generic-worker config file, so it is useful to apportion one property for the generic-worker config file, to allow other properties for other features, such as this one. Currently generic-worker understands `config` (for its config file) and `files` (for bootstrapping files). If we moved the properties up, we'd lose this feature. We can probably do a better job of documenting the bootstrapping features, and explain the reason for the top level `genericWorker` property, as without this information, it is easy to conclude that the config is nested unnecessarily. However, historically, having both levels has saved us, since it has enabled us to bootstrap workers with worker pool specific content, _and_ to include config for other systems running on the workers (such as OCC). The ability to bootstrap workers with worker pool specific files will become more important when generic-worker machine images are shared across worker pools, which is happening with the move to ci-admin/tc-admin, so we should probably shouldn't rush into changing anything quite yet.
Many thanks for raising this. I think after I've explained the rationale behind the current design, it will make much more sense. `workerConfig` is the only section in the worker pool definition that exists to serve runtime configuration to a worker running a prebaked image. Therefore _any_ system that runs on the worker relies on this single section to retrieve runtime configuration. One of the pieces of software that runs on the worker is the worker application (generic-worker/docker-worker/script-worker etc). It therefore seems reasonable for it not to claim all of the available configuration for itself, when other software may be installed on the worker that requires workerpool-specific configuration too. Even early on we've seen that this was useful for example for OpenCloudConfig, which also runs on the workers, so that workerpool-specific OCC configuration could be included in the workerConfig section. If generic-worker had claimed the entire blob, OCC would have had no way to obtain workerpool-specific config at runtime. This explains the reason for the top level `genericWorker` config property. The reason for the `config` property below that is that the runtime generic worker configuration is more than just the config settings in the `generic-worker.config` file. That indeed covers most of its configuration, however, generic-worker also provides a mechanism (since its very first release) that allows workers to be bootstrapped with additional files. This can be workerpool-specific files that cannot be baked into an AMI that may be shared with other worker pools, or secrets that we do not want to bake into the machine images for privacy reasons. For the specific case of secrets, this provides a means to rotate without secrets without needing to build new machine images, and to make machine images public for shared use. Historically, secrets were baked into AWS Provisioner Worker Type definitions, and worker type definitions weren't public. Then the taskcluster-secrets service was created and the secrets migrated there, but non-secret workerpool-specific files can still be provided in worker type definitions (or workerpool definitions). Being able to bootstrap workers with workerpool-specific content when the base image is shared across worker pools is a really useful feature. Even if we removed this feature (which I don't propose we do) there is always the possibility of future features requiring configuration which sits outside of the generic-worker config file, so it is useful to apportion one property for the generic-worker config file, to allow other properties for other features, such as this one. Currently generic-worker understands `config` (for its config file) and `files` (for bootstrapping files). If we moved the properties up, we'd lose this feature. We can probably do a better job of documenting the bootstrapping features, and explain the reason for the top level `genericWorker` property, as without this information, it is easy to conclude that the config is nested unnecessarily. However, historically, having both levels has saved us, since it has enabled us to bootstrap workers with worker pool specific content, _and_ to include config for other systems running on the workers (such as OCC). The ability to bootstrap workers with worker pool specific files will become more important when generic-worker machine images are shared across worker pools, which is happening with the move to ci-admin/tc-admin, so we should probably shouldn't rush into changing anything quite yet.