Skip to content

migration(crons): Add MonitorIncident table #56403

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 81 additions & 0 deletions src/sentry/monitors/migrations/0001_add_monitorincident_table.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
# Generated by Django 3.2.20 on 2023-09-18 17:44

import django.db.models.deletion
import django.utils.timezone
from django.db import migrations, models

import sentry.db.models.fields.bounded
import sentry.db.models.fields.foreignkey
from sentry.new_migrations.migrations import CheckedMigration


class Migration(CheckedMigration):
# This flag is used to mark that a migration shouldn't be automatically run in production. For
# the most part, this should only be used for operations where it's safe to run the migration
# after your code has deployed. So this should not be used for most operations that alter the
# schema of a table.
# Here are some things that make sense to mark as dangerous:
# - Large data migrations. Typically we want these to be run manually by ops so that they can
# be monitored and not block the deploy for a long period of time while they run.
# - Adding indexes to large tables. Since this can take a long time, we'd generally prefer to
# have ops run this and not block the deploy. Note that while adding an index is a schema
# change, it's completely safe to run the operation after the code has deployed.
is_dangerous = False

initial = True

dependencies = [
("sentry", "0554_add_team_replica"),
]

operations = [
migrations.CreateModel(
name="MonitorEnvironment",
fields=[
(
"id",
sentry.db.models.fields.bounded.BoundedBigAutoField(
primary_key=True, serialize=False
),
),
("grouphash", models.CharField(max_length=32)),
("date_added", models.DateTimeField(default=django.utils.timezone.now)),
(
"closing_checkin",
sentry.db.models.fields.foreignkey.FlexibleForeignKey(
null=True,
on_delete=django.db.models.deletion.CASCADE,
related_name="closed_incidents",
to="sentry.monitorcheckin",
),
),
(
"monitor",
sentry.db.models.fields.foreignkey.FlexibleForeignKey(
on_delete=django.db.models.deletion.CASCADE,
related_name="incidents",
to="sentry.monitor",
),
),
(
"monitor_environment",
sentry.db.models.fields.foreignkey.FlexibleForeignKey(
on_delete=django.db.models.deletion.CASCADE,
related_name="incidents",
to="sentry.monitorenvironment",
),
),
(
"opening_checkin",
sentry.db.models.fields.foreignkey.FlexibleForeignKey(
on_delete=django.db.models.deletion.CASCADE,
related_name="created_incidents",
to="sentry.monitorcheckin",
),
),
],
options={
"abstract": False,
},
),
]
Empty file.
14 changes: 14 additions & 0 deletions src/sentry/monitors/models.py
Original file line number Diff line number Diff line change
Expand Up @@ -591,3 +591,17 @@ def check_monitor_environment_limits(sender, instance, **kwargs):
raise MonitorEnvironmentLimitsExceeded(
f"You may not exceed {settings.MAX_ENVIRONMENTS_PER_MONITOR} environments per monitor"
)


@region_silo_only_model
class MonitorEnvironment(Model):
__relocation_scope__ = RelocationScope.Excluded

monitor = FlexibleForeignKey("sentry.Monitor", related_name="incidents")
monitor_environment = FlexibleForeignKey("sentry.MonitorEnvironment", related_name="incidents")
opening_checkin = FlexibleForeignKey("sentry.MonitorCheckIn", related_name="created_incidents")
closing_checkin = FlexibleForeignKey(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These feel like misnomers, I think we probably want 'starting_checkinandresolved_checkin`

and for good measure, we should probably add some comments to these fields to clearly indicate which checkins in the lifecycle of an incident these would be.

Also Important, these should probably be nullablabe since the checkins will be removed, in which case, I think we almost definitely would probably want to either

  1. Also remove the incident when any checkins are removed
  2. Keep start and end date and allow empty start and end check ins

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense

"sentry.MonitorCheckIn", related_name="closed_incidents", null=True
)
grouphash = models.CharField(max_length=32)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just use a UUID field?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess but wanted to keep it consistent with

hash = models.CharField(max_length=32)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

date_added = models.DateTimeField(default=timezone.now)