You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FIX REST API: PagerDuty notification rule integration key format
The REST API was writing the PagerDuty integration key to
notification_parameter.mk as ("routing_key", key) — the legacy 2-tuple form.
The notification dispatcher's get_password_from_env_or_context() builds a list
of all PARAMETER_ROUTING_KEY* env vars and only recognises the 3-tuple form
("cmk_postprocessed", "explicit_password", (uuid, key)) by the literal string
"explicit_password" in that list. The 2-tuple form falls through to the
password-store branch which tries to look up "routing_key" as a store ID,
fails, and the plugin exits with "Unable to retrieve password from
passwordstore".
The GUI's FormSpec migrate (_migrate_to_password in
cmk/gui/wato/_notification_parameter/_pagerduty.py) already produces the
3-tuple form for UI-touched rules; the REST API path bypassed it.
Replace APIPagerDutyKeyOption with APICheckmkPassword_FromKey (which already
sits directly above APIPagerDutyKeyOption in the same file and is used by all
other key-bearing notification plugins). PagerDutyPluginModel.routing_key is
re-typed from RoutingKeyType to CheckmkPassword. A normalizer in
PagerDutyPlugin.from_mk_file_format() handles existing on-disk rules in the
legacy form so they keep working through the API and are rewritten in the new
format on next save.
Werk: 20007
Tested:
- ruff format and lint pass on all changed files
- pre-commit lightweight hooks pass (whitespace, license, secrets, namespace)
- Bazel-backed pre-commit hooks (format/lint/mypy/unittest) not run locally;
CI will validate
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
0 commit comments