PMM-14665 Skip nodes internal to a PMM deployment when adding a service - #919
Merged
ademidoff merged 5 commits intoSep 3, 2026
Merged
Conversation
Filter the Nodes which PMM Server reports as internal (is_pmm_internal_node) out of the Nodes dropdown: they are dedicated to PMM's own infrastructure, such as the persistence layer of an HA deployment. Preselect a Node other than a PMM Server one in an HA deployment, where the PMM Server pods are meant to stay free of monitoring workloads. A single-node deployment keeps preselecting pmm-server as before.
This was referenced Jul 27, 2026
fabio-silva
approved these changes
Aug 18, 2026
matejkubinec
approved these changes
Aug 24, 2026
The Nodes dropdown compared Node and Agent identifiers against the literal "pmm-server". Those identifiers are moving to generated ones, at which point the comparisons would quietly stop matching: no Node would be preselected and the address would be prefilled with localhost for the PMM Server Node too. Every one of them is replaced by the is_pmm_server_node flag the API already reports, which carries the same meaning without depending on an identifier. Preselection now takes the PMM Server Node where it is still offered, and the first eligible Node otherwise, which is what an HA deployment gets now that PMM Server reports its own Nodes as internal. A Node running several pmm-agents is left for the user to pick from, as before.
Two suites depended on behaviour this branch changed. The internal-node test asked for the client node by text while it is now also the preselected value, so it matched both the selected value and the menu option. It now asserts on both matches, which doubles as proof that the menu is open and the absence assertions above it are not passing vacuously. The payload test paired the PMM Server Agent with a Node that was not flagged as the PMM Server one, which only worked while the metrics mode was decided by the Agent identifier. The fixture now says what it means and keeps covering PULL.
ademidoff
deleted the
PMM-14665-skip-non-eligible-nodes-from-add-service
branch
September 3, 2026 06:25
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ticket: https://perconadev.atlassian.net/browse/PMM-14665
The "Nodes" dropdown on Add Service listed every node running a pmm-agent. In an HA deployment that includes the pods of the PostgreSQL cluster backing PMM's own persistence layer, which are dedicated and must not take on extra monitoring workloads.
is_pmm_internal_node, added in percona/pmm) are filtered out of the dropdown.pmm-serveras before.Requires the corresponding percona/pmm change, otherwise the new field is simply absent and the dropdown behaves as it does today.