Splunk OnCall migration tool

[joeyorlando]

What this PR does

Refactors the PagerDuty migration script to be a bit more generic + adds a migration script to migrate from Splunk OnCall (VictorOps)

tldr;

❯ docker build -t oncall-migrator .
[+] Building 0.4s (10/10) FINISHED
❯ docker run --rm \
-e MIGRATING_FROM="pagerduty" \
-e MODE="plan" \
-e ONCALL_API_URL="http://localhost:8080" \
-e ONCALL_API_TOKEN="<ONCALL_API_TOKEN>" \
-e PAGERDUTY_API_TOKEN="<PAGERDUTY_API_TOKEN>" \
oncall-migrator
running pagerduty migration script...

❯ docker run --rm \
-e MIGRATING_FROM="splunk" \
-e MODE="plan" \
-e ONCALL_API_URL="http://localhost:8080" \
-e ONCALL_API_TOKEN="<ONCALL_API_TOKEN>" \
-e SPLUNK_API_ID="<SPLUNK_API_ID>" \
-e SPLUNK_API_KEY="<SPLUNK_API_KEY>" \
oncall-migrator
migrating from splunk oncall...

https://www.loom.com/share/a855062d436a4ef79f030e22528d8c71

Checklist

• Unit, integration, and e2e (if applicable) tests updated
• 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.

[joeyorlando]

this has been moved to [tools/migrators/add_users_to_grafana.py](https://github.com/grafana/oncall/pull/4267/files#diff-2b8ae690c66ef69beb40bffa232e3d9a03be89122cb0864ecae24b36ffa5156a) (+ slightly refactored to support migrating users from Splunk OnCall -> Grafana OnCall)

[matiasb]

LGTM, minor questions added (and nice to see complex schedule test cases! 👍 )

[matiasb]

To be sure, isn't this equivalent to our "Notify all users from a team" step?

[joeyorlando]

Correct, it is. However, we don't currently have a script to migrate Splunk (or PagerDuty) teams to Grafana/Grafana OnCall teams (I considered adding it, and even left most of the code for it there, but commented out)

I suppose we could support this escalation step type and attempt to find the team match, and if we don't, just skip it. Maybe I'll do a follow up PR with support for this 👍

[matiasb]

To be sure, do we get TZ information from the Splunk API? are we potentially overriding that by the replace above? or do we always expect to get UTC timestamps?

[joeyorlando]

I think it's okay here. They return the timezone, but they also return the start attribute in UTC. Just double checked their API response for schedule rotation shifts:

{
  "label": "multi-day stuff",
  "timezone": "America/Toronto",
  "start": "2024-04-24T21:00:00Z",
  "duration": 7,
  "shifttype": "cstm",
  "periods": [],
  "current": {},
  "next": {},
  "shiftMembers": [
    {
      "username": "joeyorlando1",
      "slug": "rtm-h8lTf3VyNUAenaRXGVWD"
    },
    {
      "username": "joeyorlando",
      "slug": "rtm-QIRzjSe3jyatvpIcutLt"
    }
  ]
}

We use this function on the start attribute. This shift is set to start at 17h (America/Toronto tz).. which is 21h UTC. With that said, I suppose I don't need to do dt.replace(tzinfo=datetime.timezone.utc)

[matiasb]

Curious, I guess there isn't a default/important distinction in Splunk, right? Are we leaving important policy empty then? Should allow some config to duplicate/default?

[joeyorlando]

Correct, they have a concept called "custom paging policies", but those really don't map to how we model user notification policies, so I just decided to map Primary Paging Policy -> Default and ignore custom ones:

(the PagerDuty migrator also hardcodes created user notification policies to "important": False)