Remove Alerts Endpoint option from Integrations list

mentioned in merge request !48293 (closed)

FYI @ameliabauerly @crystalpoole Here is a follow up issue to the integrations work to get the Alerts Endpoint options removed from the Project and group level integrations lists. Since the functionality was moved to Settings > Operations > Alerts, we need to remove it from here.

Sounds great, thanks for creating the issue @sarahwaldner!

changed milestone to %13.8

added devopsmonitor grouprespond sectionops labels

added [deprecated] Accepting merge requests label

mentioned in merge request !49561 (merged)

added workflowin review label

@syasonik @splattael Is this issue going to require frontend AND backend? My guess is that this is only frontend

@sarahwaldner Yes, it also requires backend work, probably there isn't too much backend code to remove (release M) but we should create a migration script to remove all the existing AlertsService integration from the database (release M+1).

DELETE FROM services where type = 'AlertsService'

Happy to help with the backend reviews and you can ping @justin_ho to help with the frontend review.

We also need to remove the documentation related to this integration.

Caveat: AlertsService is still used for the OpsGenieMVC, so we won't want to remove the database records until removing that first - #273657 (closed).

I'm thinking #255501 (closed) could probably end up covering the model & data removal from a backend perspective.

@sarahwaldner I think some of this removal work may require a little more breakdown to get the dependencies right. I'll do some research and see if I can come up with a plan by tomorrow EOD.

Another thing, the service data is also stored in a separate table alerts_service_data. We have AlertsService and AlertsServiceData models, at the end removing the backend code is not trivial.

@arturoherrero Thanks for your input.

@syasonik is going to suggest a plan for doing this.

Ok! With the various issues we've got coming up in %13.8, I see three deprecation/removal issues:

#273657 (closed) (Remove link to Opsgenie alert lists)
#292396 (closed) (Remove Alerts Endpoint option from Integrations list)
#255501 (closed) (Clean up unused integration code from the REST integration)

Tasks this includes:

	Domain: task	Blocking relationships	Issue
A	Frontend: remove Opsgenie from the alert integrations list	Not blocked!	#273657 (closed)
B	Frontend: remove Opsgenie active state from alerts list	Not blocked!	#273657 (closed)
C	Frontend: remove alerts service section of integration list	Not blocked!	#292396 (closed)
D	Frontend or Backened: hide/remove deprecation notice from list	Not blocked!	#292396 (closed)
E	Backend: remove Opsgenie logic	Blocked by A+B	#273657 (closed)
F	Backend: remove Opsgenie data	Blocked by A+B+E	#273657 (closed)
G	Backend: remove Alerts service logic	Blocked by A+B+E	#292396 (closed), #255501 (closed)
H	Backend: remove Alerts service data	Blocked by A+B+E+F; Optionally combined with F	#292396 (closed), #255501 (closed)

In the chart above, I think we need A+B+C+D in order for the deprecated features to be "gone." So I think it might make sense to break the issues down by backend and frontend. 4 issues total, covering (A+B), (C+D), (E+F), and (G+H). Then we can treat them explicitly and independently.

@sarahwaldner What do you think?

@syasonik Great I like the plan. Shall we do it like this?

A + B => use #273657
C + D => use #292396
E + F => use #255501
G + H => use need to create issue

If you like this, I can take a stab at adjusting the scope of all of these issues.

That's great @sarahwaldner. Maybe let's use #255501 (closed) for G+H, though, & create a new issue for E+F?

@syasonik Done. New issue for E+F => #292991 (closed)

Also I created an epic for this, Integrations Clean-up, and I've catalogued all of these under it. They are all tentatively scheduled for %13.8 with the intention of moving them to %13.9 is needed.

FYI @ameliabauerly @crystalpoole