1624642 - Setup a tooltool endpoint that accepts credentials from the staging taskcluster.

Status: RESOLVED INCOMPLETE

(Release Engineering :: General, enhancement, P1)

Description

[Tom Prince [:tomprince]]

We had setup the staging instance to do this during the migration, but it would be useful to have a permanent instance that accepts the credentials, so we can move more testing of firefox-ci config changes to the staging cluster.

Bug 1594530 (specifically this commit) had a quick-and-easy fix to point at the right cluster, but something more maintainable would be ideal, long term (perhaps accepting both).

Comment 1

[[e-mail] (:bhearsum)]

I apologize for not commenting here sooner.

There's clearly a good use case for this, so it sounds like we should do it. It sounds like we have two options:

1. Point the existing stage tooltool instance at the staging taskcluster instance
2. Setup a new instance that points at it, and is otherwise configured like production

I would greatly prefer the first option for simplicity and clarity (a staging instance of X only talking to staging instances of other systems is much more understandable IMO). Do you know if there was a reason why we pointed staging tooltool at production taskcluster after the migration was completed?

Comment 2

[Tom Prince [:tomprince]]

(In reply to [e-mail] (:bhearsum) from comment #1)

I apologize for not commenting here sooner.

No worries.

a staging instance of X only talking to staging instances of other systems is much more understandable IMO

I have the exact opposite feeling, though I suspect "staging" may be an overloaded term and may be causing some confusion. Specifically, testing changes to tooltool should not impact testing of other things that depend on tooltool; this is similar to the reason we both the -1- and -1-...-dev` scriptworkers, and why there is a treeherder instance that listens to the staging taskcluster instance, but otherwise matches production. [1]

In this particular case, the instance needs to be able to access artifacts from the production instance (though preferably read-only). I suspect the instance used for testing tooltool does not want to be configured that way.

It would be convenient if it was the production instance (that would avoid needing something like Bug 1594530), but that is is a nice-to-have. I remember chatting with :dustin about figuring out what cluster to verify the credentials against, but they don't include the cluster, so it would have required testing against both cluster to see which one would accept them, so we went with using a different instance for expediency. It might be worth revisiting that.[2]

There's clearly a good use case for this, so it sounds like we should do it. It sounds like we have two options:

1. Point the existing stage tooltool instance at the staging taskcluster instance
2. Setup a new instance that points at it, and is otherwise configured like production

Per the above, I strongly prefer option 2 (or adjusting the production instance to accept read-only credentials.

Do you know if there was a reason why we pointed staging tooltool at production taskcluster after the migration was completed?

I don't know the original reasoning, but using the staging taskcluster instance is still something that definitely has rough edges (I'm working on improving it). I suspect that it was (and probably still is) easier to do testing of tooltool in the production instance. (Bug 1592425 is where staging was originally switched, but that does not have a lot of context)

---

[1] To expand on this a little bit, staging instances of different services should not point at each other, but maybe at non-production instances of other services.
[2] One solution to this that occurred to me as I was writing this is to have taskcluster-proxy include the root url as an additional header (https://github.com/taskcluster/taskcluster-proxy/compare/master...tp-tc:send-root-url) which I think would cover the cases needed here.

Comment 3

[Simon Fraser [:sfraser] ⌚️GMT]

Ran into this issue today with a toolchain-win32-fix-stacks task trying to download visual studio from tooltool. I would also lean towards using the production instance, not only for the above reasons, but it would mean less work submitting tasks to staging: No need to ensure the latest version of a file is present in the different deployments of tooltool, so we can just copy tasks straight over.

Comment 4

[[e-mail] (:bhearsum)]

We don't really use the staging cluster for much right now. This might become important if we revive in the future, but for now this bug has outlived its usefulness.