Skip to content

PMM-14912-dynamic-thresholds (FB) - #4449

Draft
matejkubinec wants to merge 17 commits into
v3from
PMM-14912-dynamic-thresholds
Draft

PMM-14912-dynamic-thresholds (FB)#4449
matejkubinec wants to merge 17 commits into
v3from
PMM-14912-dynamic-thresholds

Conversation

@matejkubinec

@matejkubinec matejkubinec commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Custom branches:

@JNKPercona

Copy link
Copy Markdown
Collaborator

Looks like there are outdated source branches.
Please update them and restart the job
percona/grafana#912

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/6665/

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/6837/

@JNKPercona

Copy link
Copy Markdown
Collaborator

Looks like there are outdated source branches.
Please update them and restart the job
percona/pmm#5579

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/6869/

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/6872/

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/6875/

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/6876/

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/6894/

@JNKPercona

Copy link
Copy Markdown
Collaborator

Looks like there are outdated source branches.
Please update them and restart the job
percona/pmm#5579
percona/grafana#912

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7222/

Copy link
Copy Markdown
Contributor

The red @fb-alerting|@fb-settings UI tests check on this PR reproduced, and it is a pmm-qa test bug, not a problem with your change — nothing here needs fixing on your side. All 13 actionable failures are in codeceptjs-e2e/tests/ia/ruleTemplates_test.js and share one cause: the rule-template row-action locators address a template via //td[contains(text(), "NAME")], and the new Name-column Cell renderer in percona/grafana#912 moves the name into <td><div><span>NAME</span></div></td> — XPath text() only sees a node's direct text children, so every lookup by name matches nothing.

Verified on a throwaway VM running this PR's own build perconalab/pmm-server-fb:PR-4449-3eded28: against the live table the current locator returns 0 matches and a row-scoped contains(.) one returns 1, and the suite goes from 13 passed, 13 failed to 26 passed, 0 failed with only the locators changed.

Fix: percona/pmm-qa#1297. It matches both DOM shapes (re-verified green on perconalab/pmm-server:3-dev-latest too), so it is not blocked on grafana#912 and needs no coordination with your merge. Once it lands, this check should go green on your next FB build.


Generated by Claude Code

@JNKPercona

Copy link
Copy Markdown
Collaborator

Looks like there are outdated source branches.
Please update them and restart the job
percona/grafana#912

@JNKPercona

Copy link
Copy Markdown
Collaborator

Looks like there are outdated source branches.
Please update them and restart the job
percona/pmm#5878

@JNKPercona

Copy link
Copy Markdown
Collaborator

@JNKPercona

Copy link
Copy Markdown
Collaborator

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7354/

Copy link
Copy Markdown
Contributor

Both red checks on run 34601581070 were looked at, and neither is caused by your change — I re-ran the failed jobs and both came back green (helm-tests success, @pmm-ps-integration success with its tests actually executing and passing).

Helm tests failed on a transient external error, not on PMM: helm show values --version 1.4.0 percona/pmm got a 500 Internal Server Error fetching pmm-1.4.0.tgz from GitHub release assets. That URL serves 200 again, the chart is intact in the index, the same command ran 20/20 clean on a throwaway VM, and helm-tests has been green on pmm-qa main for ten consecutive scheduled runs including the one 12 hours before yours. Nothing to fix.

@pmm-ps-integration is a pmm-qa CI problem that predates this PR. The job provisions two PS clusters (six package-based MySQL installs, one node at a time) before any test runs, and on slow runners that setup takes 43.8–57.2 min against a 60 min job timeout — so the job gets killed in provisioning and the tests never run. It hit 57 min on your run; seven of the ten FB runs before yours, across six different branches, died the same way, and only one of ten ever executed the suite. The same setup completes in 9m37s on an uncontended VM and took 8m24s on your re-run, so it is apt/mirror throughput on the runners, not PMM and not the tests.

Fix for the timeout: percona/pmm-qa#1413. Nothing is needed from you on either check.


Generated by Claude Code

Copy link
Copy Markdown
Contributor

Correction to my earlier note: the verdict for your PR is unchanged (both failures were environmental, nothing needed from you), but the fix I linked, percona/pmm-qa#1413, is closed — its diagnosis was wrong.

I had attributed the 43.8–57.2 min setups to apt throughput on busy runners and raised the job timeout. That does not hold: an FB run on 09-10 at 07:43 UTC did the same setup in 9m14s on the same pmm-qa commit and the same runner image. The slowness is degraded network egress on individual runner VMs — in one run here @pmm-ps-integration finished setup in 7m23s while @ssl-postgres spent 50 min in the same step, and re-running the latter an hour later took 2m27s.

The real exposure is that each job re-downloads ~1.43 GB of identical packages (once per each of 5 containers), so a slow VM turns a 35-second download into hours. Sharing that cache is the actual fix and is what I will pursue instead of a bigger timeout.


Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants