Crons: Support user defined org-unique slug per monitor

[evanpurkhiser]

To support #42881 we need to allow users to specify a unique slug for their monitor. The same way they can specify a slug for their org or project. This will allow for creation of monitors (via upsert) without the client needing to maintain a mapping of GUIDs.

We will be removing GUIDs from monitors and only using slugs. Existing GUIDs will be migrated to become slugs. This means all monitor lookups will need to have organization context now.

URLs will have two flavors due to Hybrid Cloud

https://sentry.io/api/0/organizations/:org_slug/monitor/:monitor_slug/

https://org_slug.sentry.io/api/0/monitor/:monitor_slug/

Checkins however, will still need to support the orgless routes

https://sentry.io/api/0/monitors/:monitor_slug/checkin/:checkin_uuid/

https://org_slug.sentry.io/api/0/monitors/:monitor_slug/checkin/:checkin_uuid/

Tasks

Preview Give feedback

1. feat(crons): Add new slug column #45227
   Scope: Backend +1
2. feat(crons): Write new monitor GUIDs to monitor slug #45258
   Scope: Backend +1
3. feat(crons): Migrate guid to slug #45270
   Scope: Backend +1
4. feat(crons): Remove slug null=True #45276
   Scope: Backend +1
5. feat(crons): Enforce slug unique constraint #45292
   Scope: Backend +1
6. feat(crons): Allow lookup via organization level monitor slug #45279
   Scope: Backend +1
7. feat(crons): Add monitor slug to APIs #45294
   Scope: Backend +1

Open questions about slugs

• Should we allow monitor slugs to be edited (I assume yes) but we should indicate that it will break any usages they have using that slug at the moment

Followups

• Crons: Consider removal of GUIDs #45328
• Crons: Allow slugs to be configured and edited in the UI #45340

[getsantry]

Routing to @getsentry/crons for triage, due by Wednesday, March 1st at 2:26 pm (sfo). ⏲️

[dcramer]

If we're going to talk about removing GUIDs lets talk about that as a separate thing. To support slugs we dont need to remove GUIDs, and they may still be needed for a variety of reasons. You can still use the same URLs if you want and just make it so a monitor slug or a GUID is a usable key.

I would allow slugs to be editable - its up to the user if they want to break their system, but if they name a slug incorrectly and want to fix it (e.g. before its even used), why stop them?

[evanpurkhiser]

We can keep around GUIDs, but that does add some complexity that is worth being aware of.

We can dual lookup on the slug and GUID, this means we'll try and parse the UUID first, and if that fails we'll query on the slug. In the case of the checkin endpoint which has a orgless route we'll only allow the GUID to be used.

We should decide if we want to expose slugs in the UI at all in this case, we don't need them yet so we can get away with keeping all of that functionality hidden for now.

We can definitely follow up with removing GUIDs after the fact

[evanpurkhiser]

We should decide if we want to expose slugs in the UI at all in this case, we don't need them yet so we can get away with keeping all of that functionality hidden for now.

For now I am leaving slugs out of the UI, but it will be part of the API. They default to whatever the GUID is set to.

[evanpurkhiser]

@gaprl Let's spin out the two [FUTURE WORK] tasks into a new ticket that we'll track for improving the slugs / names / GUIDs UX in the UI

[evanpurkhiser]

This is complete.