oncall-engine/tools/migrators/lib/pagerduty/migrate.py

318 lines
11 KiB
Python
Raw Normal View History

import datetime
2022-06-14 19:26:32 +03:00
from pdpyras import APISession
from lib.common.report import TAB
from lib.common.resources.users import match_user
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
from lib.grafana.service_model_client import ServiceModelClient
from lib.oncall.api_client import OnCallAPIClient
from lib.pagerduty.config import (
EXPERIMENTAL_MIGRATE_EVENT_RULES,
MIGRATE_USERS,
MODE,
MODE_PLAN,
PAGERDUTY_API_TOKEN,
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
PAGERDUTY_FILTER_USERS,
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
PAGERDUTY_MIGRATE_SERVICES,
)
from lib.pagerduty.report import (
2022-06-14 19:26:32 +03:00
escalation_policy_report,
format_escalation_policy,
format_integration,
format_ruleset,
2022-06-14 19:26:32 +03:00
format_schedule,
format_user,
integration_report,
ruleset_report,
2022-06-14 19:26:32 +03:00
schedule_report,
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
services_report,
2022-06-14 19:26:32 +03:00
user_report,
)
from lib.pagerduty.resources.escalation_policies import (
filter_escalation_policies,
2022-06-14 19:26:32 +03:00
match_escalation_policy,
match_escalation_policy_for_integration,
migrate_escalation_policy,
)
from lib.pagerduty.resources.integrations import (
filter_integrations,
2022-06-14 19:26:32 +03:00
match_integration,
match_integration_type,
migrate_integration,
)
from lib.pagerduty.resources.notification_rules import migrate_notification_rules
from lib.pagerduty.resources.rulesets import match_ruleset, migrate_ruleset
from lib.pagerduty.resources.schedules import (
filter_schedules,
match_schedule,
migrate_schedule,
)
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
from lib.pagerduty.resources.services import (
BusinessService,
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
TechnicalService,
filter_services,
get_all_business_services_with_metadata,
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
get_all_technical_services_with_metadata,
migrate_all_services,
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
)
from lib.pagerduty.resources.users import (
filter_users,
2022-06-14 19:26:32 +03:00
match_users_and_schedules_for_escalation_policy,
match_users_for_schedule,
)
def migrate() -> None:
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
# Set up API sessions and timeout
2022-06-14 19:26:32 +03:00
session = APISession(PAGERDUTY_API_TOKEN)
session.timeout = 20
2022-06-14 19:26:32 +03:00
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
# Use a flag to track how many resources were eligible for migration in the final report
filtered_resources_summary = {
"schedules": 0,
"escalation_policies": 0,
"integrations": 0,
}
# Process users only if MIGRATE_USERS is true
users = []
oncall_users = []
user_id_map = {}
if MIGRATE_USERS:
print("▶ Fetching users...")
users = session.list_all("users", params={"include[]": "notification_rules"})
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
oncall_users = OnCallAPIClient.list_users_with_notification_rules()
2022-06-14 19:26:32 +03:00
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
# Apply filtering to users if specified
if PAGERDUTY_FILTER_USERS:
print("▶ Filtering users based on PAGERDUTY_FILTER_USERS...")
users = filter_users(users)
# Match users with Grafana OnCall users
for user in users:
match_user(user, oncall_users)
# Create a mapping from PagerDuty user IDs to Grafana OnCall user IDs
user_id_map = {
u["id"]: u["oncall_user"]["id"] if u["oncall_user"] else None for u in users
}
else:
print("▶ Skipping user fetching and migration as MIGRATE_USERS is false...")
2022-06-14 19:26:32 +03:00
print("▶ Fetching schedules...")
# Fetch schedules from PagerDuty
schedules = session.list_all(
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
"schedules",
params={"include[]": ["schedule_layers", "teams"], "time_zone": "UTC"},
)
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
# Apply filters to schedules
schedules = filter_schedules(schedules)
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
filtered_resources_summary["schedules"] = len(schedules)
print(f"Found {len(schedules)} schedules after filtering")
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
# Fetch overrides from PagerDuty
since = datetime.datetime.now(datetime.timezone.utc)
until = since + datetime.timedelta(
days=365
) # fetch overrides up to 1 year from now
for schedule in schedules:
response = session.jget(
f"schedules/{schedule['id']}/overrides",
params={"since": since.isoformat(), "until": until.isoformat()},
)
schedule["overrides"] = response["overrides"]
# Fetch schedules from OnCall
oncall_schedules = OnCallAPIClient.list_all("schedules")
2022-06-14 19:26:32 +03:00
print("▶ Fetching escalation policies...")
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
escalation_policies = session.list_all(
"escalation_policies", params={"include[]": "teams"}
)
# Apply filters to escalation policies
escalation_policies = filter_escalation_policies(escalation_policies)
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
filtered_resources_summary["escalation_policies"] = len(escalation_policies)
print(f"Found {len(escalation_policies)} escalation policies after filtering")
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
oncall_escalation_chains = OnCallAPIClient.list_all("escalation_chains")
2022-06-14 19:26:32 +03:00
print("▶ Fetching integrations...")
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
services = session.list_all(
"services", params={"include[]": ["integrations", "teams"]}
)
2022-06-14 19:26:32 +03:00
vendors = session.list_all("vendors")
integrations = []
for service in services:
service_integrations = service.pop("integrations")
for integration in service_integrations:
integration["service"] = service
integrations.append(integration)
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
# Apply filters to integrations
integrations = filter_integrations(integrations)
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
filtered_resources_summary["integrations"] = len(integrations)
print(f"Found {len(integrations)} integrations after filtering")
PagerDuty Migrator: Add filtering capabilities and fix user notification rule preservation (#5454) This PR adds filtering capabilities to the PagerDuty migrator tool and fixes user notification rule preservation behavior. Closes https://github.com/grafana/irm/issues/612 ## Changes ### 1. Added Resource Filtering Added the ability to filter PagerDuty resources during migration based on: - Team membership - User association - Name patterns (using regex) New environment variables for filtering: ``` PAGERDUTY_FILTER_TEAM PAGERDUTY_FILTER_USERS PAGERDUTY_FILTER_SCHEDULE_REGEX PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX PAGERDUTY_FILTER_INTEGRATION_REGEX ``` #### Example Usage Filter by team: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_TEAM="SRE Team" \ oncall-migrator ``` Filter by specific users: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_USERS="P123ABC,P456DEF" \ oncall-migrator ``` Filter schedules by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_SCHEDULE_REGEX="^(Primary|Secondary)" \ oncall-migrator ``` Filter escalation policies by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_ESCALATION_POLICY_REGEX="^Prod" \ oncall-migrator ``` Filter integrations by name pattern: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="plan" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PAGERDUTY_FILTER_INTEGRATION_REGEX="Prometheus$" \ oncall-migrator ``` ### 2. Fixed User Notification Rule Preservation Introduces a `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` config (default of `true`). The migrator now: - does not delete user notification rules in Grafana OnCall, if the Grafana user already has some defined, AND `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is True - if the Grafana user has no personal notification rules defined in OnCall, we will create them - deletes existing user notification rules, and creates new ones, in Grafana OnCall, if `PRESERVE_EXISTING_USER_NOTIFICATION_RULES` is False - basically make sure that the state in Grafana OnCall matches the _latest_ state in PagerDuty - Improves logging to clearly indicate when rules are being preserved #### Example Usage Preserve existing notification policies (default): ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ oncall-migrator ``` Replace existing notification policies: ```bash docker run --rm \ -e MIGRATING_FROM="pagerduty" \ -e MODE="migrate" \ -e ONCALL_API_URL="<your-oncall-api-url>" \ -e ONCALL_API_TOKEN="<your-oncall-api-token>" \ -e PAGERDUTY_API_TOKEN="<your-pd-api-token>" \ -e PRESERVE_EXISTING_USER_NOTIFICATION_RULES="false" \ oncall-migrator ``` ### 3. Improved Testing Added comprehensive test coverage for filtering functionality and updated user notification rule preservation tests ## Testing Done - Manual testing of filtering capabilities in both plan and migrate modes - Verified notification policy preservation behavior
2025-02-18 08:12:05 -05:00
oncall_integrations = OnCallAPIClient.list_all("integrations")
2022-06-14 19:26:32 +03:00
rulesets = None
if EXPERIMENTAL_MIGRATE_EVENT_RULES:
print("▶ Fetching event rules (global rulesets)...")
rulesets = session.list_all("rulesets")
for ruleset in rulesets:
rules = session.list_all(f"rulesets/{ruleset['id']}/rules")
ruleset["rules"] = rules
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
# Match resources if we have users
2022-06-14 19:26:32 +03:00
for schedule in schedules:
match_schedule(schedule, oncall_schedules, user_id_map)
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
if MIGRATE_USERS:
match_users_for_schedule(schedule, users)
else:
# When not migrating users, mark schedule as having no unmatched users
schedule["unmatched_users"] = []
schedule["migration_errors"] = []
2022-06-14 19:26:32 +03:00
for policy in escalation_policies:
match_escalation_policy(policy, oncall_escalation_chains)
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
if MIGRATE_USERS:
match_users_and_schedules_for_escalation_policy(policy, users, schedules)
else:
# When not migrating users, mark policy as having no unmatched users
policy["unmatched_users"] = []
policy["flawed_schedules"] = []
2022-06-14 19:26:32 +03:00
for integration in integrations:
match_integration(integration, oncall_integrations)
match_integration_type(integration, vendors)
match_escalation_policy_for_integration(integration, escalation_policies)
if rulesets is not None:
for ruleset in rulesets:
match_ruleset(
ruleset,
oncall_integrations,
escalation_policies,
services,
integrations,
)
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
if PAGERDUTY_MIGRATE_SERVICES:
client = ServiceModelClient()
# Get all services
all_technical_services = get_all_technical_services_with_metadata(session)
technical_service_map = {
service.id: service for service in all_technical_services
}
all_business_services = get_all_business_services_with_metadata(
session, technical_service_map
)
# Apply filters to services
filtered_technical_data = filter_services(
[service.raw_data for service in all_technical_services]
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
)
filtered_business_data = filter_services(
[service.raw_data for service in all_business_services]
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
)
# Convert filtered data back to service objects
technical_services = [
TechnicalService(service) for service in filtered_technical_data
]
business_services = [
BusinessService(service) for service in filtered_business_data
]
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
# Print filtering and matching summary
print("\n▶ Migration summary after filtering and matching:")
if MIGRATE_USERS:
print(
f"Users: {sum(1 for u in users if u.get('oncall_user'))} matched of {len(users)} total"
)
print(
f"Schedules: {sum(1 for s in schedules if not s.get('unmatched_users') and not s.get('migration_errors'))} eligible of {filtered_resources_summary['schedules']} filtered"
)
print(
f"Escalation policies: {sum(1 for p in escalation_policies if not p.get('unmatched_users') and not p.get('flawed_schedules'))} eligible of {filtered_resources_summary['escalation_policies']} filtered"
)
print(
f"Integrations: {sum(1 for i in integrations if i.get('oncall_type') and not i.get('is_escalation_policy_flawed'))} eligible of {filtered_resources_summary['integrations']} filtered\n"
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
)
2022-06-14 19:26:32 +03:00
if MODE == MODE_PLAN:
feat: enhance PagerDuty migrator filtering + and improve user migration operations (#5471) ## Summary of Changes ### Improved Filtering Logic - Changed filtering logic to use OR operations between filter types (team, users, regex) - Resources matching ANY filter are now included in the migration - Made filtering more intuitive and aligned with user expectations ### New `PAGERDUTY_FILTER_USERS` option for `add_users_to_grafana.py` script - This new config (environment variable) allows importing only a subset of users from your PagerDuty instance. - Added full test coverage for `add_users_to_grafana.py` - Updated documentation to reflect latest changes ### Added Verbose Logging Option - Added `PAGERDUTY_VERBOSE_LOGGING` environment variable to control output verbosity - When disabled, only shows summary counts without detailed per-resource output - Significantly reduces output for large PagerDuty instances ### Fixed User Handling - Properly skips user fetching and processing when `MIGRATE_USERS=false` - Marks schedules and escalation policies properly when not migrating users - When `MIGRATE_USERS=true` and `PAGERDUTY_FILTER_USERS` is set, only those specific users are migrated ### Added Migration Progress Summary - Shows counts of filtered resources and those eligible for migration - Provides better visibility into the migration process ### Updated Tests - Added comprehensive tests for the new OR-based filtering logic - Added tests for user filtering - Added tests for verbose and non-verbose logging modes ### Updated Documentation - Clearly documented the new filtering behavior - Explained the verbose logging option - Updated configuration descriptions to be more accurate These changes address issues with filtering behavior and user handling, making the PagerDuty migrator more intuitive, efficient, and flexible.
2025-03-17 08:04:05 -04:00
if MIGRATE_USERS:
print(user_report(users), end="\n\n")
print(schedule_report(schedules), end="\n\n")
print(escalation_policy_report(escalation_policies), end="\n\n")
print(integration_report(integrations), end="\n\n")
if rulesets is not None:
print(ruleset_report(rulesets), end="\n\n")
2022-06-14 19:26:32 +03:00
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
if PAGERDUTY_MIGRATE_SERVICES:
print(
services_report(
all_technical_services,
all_business_services,
technical_services,
business_services,
),
end="\n\n",
)
return
2022-06-14 19:26:32 +03:00
return
if MIGRATE_USERS:
print("▶ Migrating user notification rules...")
for user in users:
if user["oncall_user"]:
migrate_notification_rules(user)
print(TAB + format_user(user))
else:
print(
"▶ Skipping migrating user notification rules as MIGRATE_USERS is false..."
)
2022-06-14 19:26:32 +03:00
print("▶ Migrating schedules...")
for schedule in schedules:
if not schedule["unmatched_users"] and not schedule["migration_errors"]:
migrate_schedule(schedule, user_id_map)
2022-06-14 19:26:32 +03:00
print(TAB + format_schedule(schedule))
print("▶ Migrating escalation policies...")
for policy in escalation_policies:
if not policy["unmatched_users"] and not policy["flawed_schedules"]:
migrate_escalation_policy(policy, users, schedules)
print(TAB + format_escalation_policy(policy))
print("▶ Migrating integrations...")
for integration in integrations:
if (
integration["oncall_type"]
and not integration["is_escalation_policy_flawed"]
):
migrate_integration(integration, escalation_policies)
print(TAB + format_integration(integration))
if rulesets is not None:
print("▶ Migrating event rules (global rulesets)...")
for ruleset in rulesets:
if not ruleset["flawed_escalation_policies"]:
migrate_ruleset(ruleset, escalation_policies, services)
print(TAB + format_ruleset(ruleset))
Service to service model migration (#5485) # What this PR does Adds Service and Business Service migration to the Pager Duty Migrator. To test, in addition to the OnCall configs, you need to crate a Grafana Service Account with `Admin` permission and generate a token. You will set `GRAFANA_SERVICE_ACCOUNT_URL`, per the README, to `https://<namespace>:<token>@<server>` The namespace is the stack id, in the format of `stacks-<stack id>` Service migration is configurable, filterable, and idempotent. ## Which issue(s) this PR closes Related to [issue link here] <!-- *Note*: If you want the issue to be auto-closed once the PR is merged, change "Related to" to "Closes" in the line above. If you have more than one GitHub issue that this PR closes, be sure to preface each issue link with a [closing keyword](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). This ensures that the issue(s) are auto-closed once the PR has been merged. --> ## Checklist - [x] Unit, integration, and e2e (if applicable) tests updated - [x] Documentation added (or `pr:no public docs` PR label added if not required) - [ ] Added the relevant release notes label (see labels prefixed w/ `release:`). These labels dictate how your PR will show up in the autogenerated release notes. --------- Co-authored-by: Joey Orlando <joey.orlando@grafana.com> Co-authored-by: GitHub Actions <actions@github.com> Co-authored-by: grafana-irm-app[bot] <165293418+grafana-irm-app[bot]@users.noreply.github.com> Co-authored-by: Joey Orlando <joseph.t.orlando@gmail.com>
2025-03-15 19:07:59 -06:00
if PAGERDUTY_MIGRATE_SERVICES:
print("▶ Migrating services to Grafana's service model...")
migrate_all_services(
client, technical_services, business_services, dry_run=False
)
else:
print("▶ Skipping service migration as PAGERDUTY_MIGRATE_SERVICES is false...")