1425238 - Use provisionerId releng-hardware instead of scl3-puppet for worker type gecko-t-*-hw

Status: RESOLVED WONTFIX

(Infrastructure & Operations :: RelOps: General, task)

Description

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

Since https://bugzilla.mozilla.org/show_bug.cgi?id=1368718#c1 the provisionerId scl3-puppet is no longer in use.

The only reference to it is currently in the manually deployed worker with workerId MININT-QE9BQSC for gecko-t-win10-64-hw:

https://tools.taskcluster.net/provisioners/scl3-puppet/worker-types/gecko-t-win10-64-hw/workers/scl3/MININT-QE9BQSC

Please can the generic-worker.config file on this worker be updated to use provisionerId "releng-hardware" instead?

Then we can delete https://tools.taskcluster.net/auth/scopes/assume%3Aworker-type%3Ascl3-puppet%2F*/role:worker-type%3Ascl3-puppet%2F*

Thanks!

Comment 1

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

(In reply to Pete Moore [:pmoore][:pete] from comment #0)

> Then we can delete https://tools.taskcluster.net/auth/scopes/assume%3Aworker-type%3Ascl3-puppet%2F*/role:worker-type%3Ascl3-puppet%2F*

Bugzilla-friendly version:
  https://tools.taskcluster.net/auth/scopes/assume%3Aworker-type%3Ascl3-puppet%2F*/role:worker-type%3Ascl3-puppet%2F%2A


The full list of entities I'd like to delete are:

Clients
1) project/releng/worker/scl3-puppet/gecko-t-win10-64-hw
2) project/releng/worker/scl3-puppet/gecko-t-win7-32-hw

Roles
1) worker-type:scl3-puppet/*

Comment 2

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

Note, I've created two new clients for you to use, with the names:

project/releng/worker/releng-hardware/gecko-t-win10-64-hw
project/releng/worker/releng-hardware/gecko-t-win7-32-hw

You will also need to update the clientId in the workers to use these new values. The access token you can get by going to the following two urls:

https://tools.taskcluster.net/auth/clients/project%2Freleng%2Fworker%2Freleng-hardware%2Fgecko-t-win10-64-hw
https://tools.taskcluster.net/auth/clients/project%2Freleng%2Fworker%2Freleng-hardware%2Fgecko-t-win7-32-hw

and in both cases hitting "Edit client" and then "Reset accessToken".

Make sure to update the accessToken, clientId, and provisionerId in the worker configs, and let me know when you are done, and things are working so I can delete the entitieis in comment 1. Looking at random Mac jobs in treeherder, the workerGroup "scl3" that is currently in use seems appropriate, so I don't think that needs to change. Thanks!

Comment 3

[Mark Cornmesser [:markco]]

(In reply to Pete Moore [:pmoore][:pete] from comment #0)
> Since https://bugzilla.mozilla.org/show_bug.cgi?id=1368718#c1 the
> provisionerId scl3-puppet is no longer in use.
> 
> The only reference to it is currently in the manually deployed worker with
> workerId MININT-QE9BQSC for gecko-t-win10-64-hw:
> 
> https://tools.taskcluster.net/provisioners/scl3-puppet/worker-types/gecko-t-
> win10-64-hw/workers/scl3/MININT-QE9BQSC
> 
> Please can the generic-worker.config file on this worker be updated to use
> provisionerId "releng-hardware" instead?
> 
> Then we can delete
> https://tools.taskcluster.net/auth/scopes/assume%3Aworker-type%3Ascl3-
> puppet%2F*/role:worker-type%3Ascl3-puppet%2F*
> 
> Thanks!

If it is urgent I can just removed that machine. I have been using the scl3-puppet provisionor is cases were I need to run a test on a specific machine. Mostly testing configuration and running performance comparisons. Which has been very helpful. Is it possible to keep this around until the moonshots are in production? Or is there a better way to go about this?

Comment 4

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

(In reply to Mark Cornmesser [:markco] from comment #3)

> If it is urgent I can just removed that machine. I have been using the
> scl3-puppet provisionor is cases were I need to run a test on a specific
> machine. Mostly testing configuration and running performance comparisons.
> Which has been very helpful. Is it possible to keep this around until the
> moonshots are in production? Or is there a better way to go about this?

The requested change is just a name change in the config file on the worker(s) - i.e. updating your generic-worker.config to use the name 'releng-hardware' rather than 'scl3-puppet'. In real terms, there won't be any difference, but it means we can delete the roles/clients we have configured in taskcluster, as it was decided that the name 'scl3-puppet' wasn't a good one in https://bugzilla.mozilla.org/show_bug.cgi?id=1368718#c1. This is just a namespace cleanup, which won't affect worker behaviour in any way.

Comment 5

[Mark Cornmesser [:markco]]

That single machine is gone. 

What I was talking about before was, we have 30 nodes of Win 10 I need to be able to change the configuration on one node to performance tune and run a particular test. I was using scl3-puppet to isolate that one machine. 

With that going away and because I do not have permissions, could you create me an additional worker type for releng-hardware that I could use to test. Maybe something like gecko-t-win10-64-hwtest and gecko-t-win7-32-hwtest.

Comment 6

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

Ah, I see what you mean - so using a different provisionerId was basically a way of namespacing test workers.

This makes sense, in that when we include provisionerId in a task definition, the provisionerId is really just providing a namespacing facility for the workerType - it is kind of confusing that a task needs to know which provisioner provisioned its environment - and this is something we are internally discussing for the future, if we could approach that differently (i.e. separate the role of namespacing worker types with the facility of spawning instances). Maybe something like having workerTypeGroup instead of provisionerId. This separate concerns got a bit blurred, because typically a provisioner is responsible for all workerTypes in a single namespace - but this is a good example when this isn't the case.

Mark, rather than cause you pain, let's leave it as it is for now - you have something working, and I don't want to nitpick and break it. This is a topic we'll be discussing in the team, so maybe when we've decided how we want to approach this in future, we can revisit this bug.

Thanks for the clarification.

Note - we have another limitation, which is workerType name length, so e.g. gecko-t-win10-64-hwtest would probably be too long. This is another opportunity for improvement we are considering internally at the moment (perhaps tagging worker types with labels, and the name be something simple like wt-0123737623487, but e.g. tags "gecko", "win10", "64bit", "hw", "test" or something like that.

Comment 7

[Pete Moore [:pmoore][:pete] [PTO until 13 April 2026]]

(or just extending the limit on the name length of a worker type) ;-)