Closed Bug 1751960 Opened 4 years ago Closed 4 years ago

Ensure Treeherder pulse accounts can access community cluster

Categories

(Webtools :: Pulse, defect)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sclements, Unassigned)

Details

Attachments

(1 file)

We seem to be having an issue listening to the community cluster on Treeherder, even though I'm pretty sure we already have credentials to access it. Can someone please check the Treeherder pulse accounts (treeherder-prod, treeherder-staging, and treeherder-prototype) and ensure those accounts have access?

Flags: needinfo?(pmoore)

I checked:

The last of these (treeherder-prototype) looks suspicious, for the communitytc virtual host, the "read" regexp is:

.*^(queue/treeherder\-prototype/.*|exchange/.*)

I believe the leading .* are break the regexp, since the ^ no longer is interpreted as "line start". I can change to:

^(queue/treeherder\-prototype/.*|exchange/.*)

which would be in line with what we have for the root virtual host (/) which serves firefox ci. However, I don't have an audit history of this setting, so I don't believe I can see how or why the leading .* was introduced, but it certainly looks wrong.

Flags: needinfo?(pmoore)

Thanks for looking. Prototype is only used for testing prs, so you can make that change without any concern about breaking things.

I've applied the change - I think I see what happened! The default is .* so probably when it was created, the new value was copy/pasted into the input box, but the default value of .* was already there, so it ended up being appended instead of replacing it.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

I think there still might be an issue with receiving messages from the community cluster. Right now, we have a pr deployed on prototype that adds additional bindings: exchange/taskcluster-queue/v1/task-completed.route.index.project.mozci.classification. But when I log into Pulse Guardian and look at the queues tab for treeherder-prototype I only see the existing bindings - not the new for mozci (see screenshot).

I've confirmed with cvalaas we do have credentials for both clusters that are being stored/used. Any ideas?

Flags: needinfo?(pmoore)

Ignore my previous comment, we figured the issue and I forgot to cancel the need'info.

Flags: needinfo?(pmoore)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: