-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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, | ||
}, | ||
), | ||
] |
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -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( | ||||
"sentry.MonitorCheckIn", related_name="closed_incidents", null=True | ||||
) | ||||
grouphash = models.CharField(max_length=32) | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we just use a UUID field? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess but wanted to keep it consistent with sentry/src/sentry/models/grouphash.py Line 25 in 2cba1ab
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 |
||||
date_added = models.DateTimeField(default=timezone.now) |
There was a problem hiding this comment.
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_checkin
and
resolved_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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense