Respond: Create & link model classes for tables that are missing them

Please see #442736 (closed) for details.

For Respond, we have identified 2 tables that are missing a Rails model and can benefit from it:

• issues_prometheus_alert_events
• issues_self_managed_prometheus_alert_events

These tables need to have a Rails model backing them because:

• once we have that, we can set a desired_sharding_key on these models. Setting of desired sharding keys requires a Rails model to be present for a table because we need to validate that the belongs_to association used to backfill this column actually exists and is valid.

Implementation plan:

• Create a Rails model for this table.
• Set up the belongs_to associations on this model based on the current state of columns on this table.
• Link the class to the table using the table's db/docs/table_name.yml file, with the classes key. Example.

Once class has been added in the yml, grouptenant scale can run automations to set desired sharding keys for these tables.

PS: If the table is no longer used or is not needed, you needn't add a model, rather you can work on dropping the table altogether.

added grouprespond label

marked this issue as related to #435028 (closed)

added devopsmonitor sectionanalytics labels

marked this issue as blocking #442736 (closed)

mentioned in issue #435028 (closed)

PS: If the table is no longer used or is not needed, you needn't add a model, rather you can work on dropping the table altogether.

This is indeed the case for the above tables. They should be dropped, as the Category:Metrics is deprecated/mostly removed. --> Monitor: Metrics Deprecation and Removal (&10107)

@syasonik Hello thank you for the input

I checked the data in these tables via database-lab, and unfortunately it still contains some rows, so it cannot be exempted from sharding key requirements (like we did in !147541 (diffs)).

Do you think your team can get the work started on dropping these tables?

Do you think your team can get the work started on dropping these tables?

@manojmj That's tricky. Unfortunately, there aren't really engineers remaining on grouprespond.

@msaleiko from groupincubation technically owns the category currently, but I'm not sure where this might fall in relative priority.

@manojmj I think we could just drop the two tables. The models have been removed before during feature removal. Would that work for you?

@msaleiko that definitely works, could you open an issue to track that work? If we have an issue to drop the tables, we can close this one out

FYI I'm OOO next week, so this will likely happen after that.

@msaleiko Shall we move this issue to %17.0 as you are back from OOO?

@msaleiko Moving this to %17.1.

If I understand this correctly, we want to drop two tables:

• issues_prometheus_alert_events
• issues_self_managed_prometheus_alert_events

What do you think about creating an issue adding Seeking community contributions and quick win, so community contributors can find this and hopefully help us.

@msaleiko Did you create an issue to drop the tables? I want to add Seeking community contributions for that.

@arturoherrero I just created Drop old unused tables for prometheus alerts (#461838 - closed) and applied the labels.

So we can close this issue

Great!

added to epic &13145 (closed)

assigned to @msaleiko

changed milestone to %17.0

@arturoherrero - please see the following guidance and update this issue.

	1 Error
	Please add typebug typefeature, typemaintenance and optionally a subtype label to this issue.

If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.

This message was generated automatically. You're welcome to improve it.

added typemaintenance label

added typefeature label and removed typemaintenance label

added typemaintenance label and removed typefeature label

changed milestone to %17.1

marked this issue as related to #461838 (closed)

mentioned in issue #461838 (closed)

closed