(In reply to Pete Moore [:pmoore][:pete] from comment #5) > Thanks John! > > I'll run it shortly... I'll put a note in #ci first... The config update script seems to have run correctly, and worker type definitions and taskcluster secrets have been updated. Rob, Simon, I wanted to bring this bug to your attention. You will notice that the public generic-worker config settings from the "secrets" section of the worker type definitions is now duplicated under "userData" section of the worker type definitions, and new taskcluster secrets have been created, called `worker-type:aws-provisioner-v1/<workerType>` that now contain the secret keys. The new workers (generic-worker 13.0.2 onwards) will use the "userData" section and the taskcluster-secrets service to retrieve their config, together with the secrets from the secret service, rather than the "secrets" section that generic-worker previously used. This enables us to publish the worker type definitions, which will then be secret-free. When each worker type is upgraded to use generic-worker 13.0.2 (or later), we can remove the "secrets" section from its worker type definition, but for now the config exists in both sections so that they will work with old and new workers. I'll be creating PRs for the upgrades to your worker types in due course to upgrade to generic-worker 13. @Rob I'm aware you are already upgrading to generic-worker 12 in bug 1524592. Do you prefer to continue with that, and I make a separate gw 13 PR, or do you prefer to jump straight to version 13 and skip version 12 entirely? I don't mind either way. @Simon I can create a staging worker type for you for servo, if you like, so that you can test installing generic-worker 13.0.2 on it and running some test jobs. Note, version 12 introduced a new requirement, that in addition to creating the openpgp private key required by the chain-of-trust task feature, an additional ed25519 key needs to be created. The `generic-worker --help` text explains how to create it, but it is essentially the same as the way to create the openpgp key, just a slightly different option: ``` generic-worker new-ed25519-keypair --file ED25519-PRIVATE-KEY-FILE generic-worker new-openpgp-keypair --file OPENPGP-PRIVATE-KEY-FILE new-ed25519-keypair This will generate a fresh, new ed25519 compliant private/public key pair. The public key will be written to stdout and the private key will be written to the specified file. new-openpgp-keypair This will generate a fresh, new OpenPGP compliant private/public key pair. The public key will be written to stdout and the private key will be written to the specified file. ``` So the long and short of it is that you need to run both `generic-worker new-ed25519-keypair` _and_ `generic-worker new-openpgp-keypair` before running the worker for the first time. I think servo doesn't use the chain of trust feature, but it isn't an optional feature so I'm afraid you will need to have both types of keys on the workers. Let me know if you have any questions!
Bug 1375182 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Pete Moore [:pmoore][:pete] from comment #5) > Thanks John! > > I'll run it shortly... I'll put a note in #ci first... The config update script seems to have run correctly, and worker type definitions and taskcluster secrets have been updated. Rob, Simon, I wanted to bring this bug to your attention. You will notice that the public generic-worker config settings from the "secrets" section of the worker type definitions is now duplicated under "userData" section of the worker type definitions, and new taskcluster secrets have been created, called `worker-type:aws-provisioner-v1/<workerType>` that now contain the secret keys. The new workers (generic-worker 13.0.2 onwards) will use the `userData` section and the worker type definitions to retrieve their public config, together with the secrets from the secret service to get their private config, rather than the "secrets" section that generic-worker previously used. This enables us to publish the worker type definitions, which will then be secret-free. When each worker type is upgraded to use generic-worker 13.0.2 (or later), we can remove the "secrets" section from its worker type definition, but for now the config exists in both sections so that they will work with old and new workers. I'll be creating PRs for the upgrades to your worker types in due course to upgrade to generic-worker 13. @Rob I'm aware you are already upgrading to generic-worker 12 in bug 1524592. Do you prefer to continue with that, and I make a separate gw 13 PR, or do you prefer to jump straight to version 13 and skip version 12 entirely? I don't mind either way. @Simon I can create a staging worker type for you for servo, if you like, so that you can test installing generic-worker 13.0.2 on it and running some test jobs. Note, version 12 introduced a new requirement, that in addition to creating the openpgp private key required by the chain-of-trust task feature, an additional ed25519 key needs to be created. The `generic-worker --help` text explains how to create it, but it is essentially the same as the way to create the openpgp key, just a slightly different option: ``` generic-worker new-ed25519-keypair --file ED25519-PRIVATE-KEY-FILE generic-worker new-openpgp-keypair --file OPENPGP-PRIVATE-KEY-FILE new-ed25519-keypair This will generate a fresh, new ed25519 compliant private/public key pair. The public key will be written to stdout and the private key will be written to the specified file. new-openpgp-keypair This will generate a fresh, new OpenPGP compliant private/public key pair. The public key will be written to stdout and the private key will be written to the specified file. ``` So the long and short of it is that you need to run both `generic-worker new-ed25519-keypair` _and_ `generic-worker new-openpgp-keypair` before running the worker for the first time. I think servo doesn't use the chain of trust feature, but it isn't an optional feature so I'm afraid you will need to have both types of keys on the workers. Let me know if you have any questions!
(In reply to Pete Moore [:pmoore][:pete] from comment #5) > Thanks John! > > I'll run it shortly... I'll put a note in #ci first... The config update script seems to have run correctly, and worker type definitions and taskcluster secrets have been updated. Rob, Simon, I wanted to bring this bug to your attention. You will notice that the public generic-worker config settings from the "secrets" section of the worker type definitions is now duplicated under "userData" section of the worker type definitions, and new taskcluster secrets have been created, called `worker-type:aws-provisioner-v1/<workerType>` that now contain the secret keys. The new workers (generic-worker 13.0.2 onwards) will use the `userData` section and the worker type definitions to retrieve their public config, together with the secrets from the secret service to get their private config, rather than the "secrets" section that generic-worker previously used. This enables us to publish the worker type definitions, which will then be secret-free. When each worker type is upgraded to use generic-worker 13.0.2 (or later), we can remove the "secrets" section from its worker type definition, but for now the config exists in both sections so that they will work with old and new workers. @Rob I'm aware you are already upgrading to generic-worker 12 in bug 1524592. Bug 1375157 is the bug to upgrade to generic-worker 13. I'll put a separate needinfo for you in that bug about whether you prefer us to upgrade to v12 and v13 in separate steps, or if we should do them together in a single upgrade. The needinfo here was mostly to alert you to the new data under "userData" of worker type definitions, so you don't wonder where it comes from, and don't delete it etc, and bug 1375157 is about the associated rollout of the new worker version to OCC managed worker types. @Simon I can create a staging worker type for you for servo, if you like, so that you can test installing generic-worker 13.0.2 on it and running some test jobs. Note, version 12 introduced a new requirement, that in addition to creating the openpgp private key required by the chain-of-trust task feature, an additional ed25519 key needs to be created. The `generic-worker --help` text explains how to create it, but it is essentially the same as the way to create the openpgp key, just a slightly different option: ``` generic-worker new-ed25519-keypair --file ED25519-PRIVATE-KEY-FILE generic-worker new-openpgp-keypair --file OPENPGP-PRIVATE-KEY-FILE new-ed25519-keypair This will generate a fresh, new ed25519 compliant private/public key pair. The public key will be written to stdout and the private key will be written to the specified file. new-openpgp-keypair This will generate a fresh, new OpenPGP compliant private/public key pair. The public key will be written to stdout and the private key will be written to the specified file. ``` So the long and short of it is that you need to run both `generic-worker new-ed25519-keypair` _and_ `generic-worker new-openpgp-keypair` before running the worker for the first time. I think servo doesn't use the chain of trust feature, but it isn't an optional feature so I'm afraid you will need to have both types of keys on the workers. Let me know if you have any questions!