Skip to content
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

[alerting] allow connector/rule types to provide hooks/feedback during create/update/delete calls #106724

Open
pmuellr opened this issue Jul 26, 2021 · 3 comments
Labels
discuss estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Actions/ConnectorsManagement Issues related to Connectors Management UX Feature:Actions/Framework Issues related to the Actions Framework Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting insight Issues related to user insight into platform operations and resilience Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@pmuellr
Copy link
Member

pmuellr commented Jul 26, 2021

Currently, alerting connector types are only invoked to execute the connector. We've had some scenarios where it would be useful to allow connectors to provide some feedback during create. Specifically, to do some checking against 3rd party services (Swimlane and ServiceNow), and be able to "veto" the creation. Think of it as an additional validation, that's done at the time of the create, given the connector parameters.

One way to view this is just as an additional type of validation, where the connector type could register to have this additional validation run on the create. Another way to think about it is a general "hook" mechanism, where the connector type can be invoked on interesting calls (create/update/delete), and "provide feedback", where one form of that feedback would be to not allow the creation, and presumably provide an error message.

The "additional validation" approach is likely easier, but also less flexible, if we find we need to do other "interesting" things later.

This is also possibly something we'd want for rules, as well as connectors.

@pmuellr pmuellr added discuss Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework labels Jul 26, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@pmuellr
Copy link
Member Author

pmuellr commented Jul 26, 2021

I was unable to find a Swimlane issue / PR where we had mentioned this before, so will need to do some research on the exact needs.

I believe the story is similar to the ServiceNow one though - today, we can do this "additional work" in the alerting UI, and prevent the Save from occurring if we need to, by customizing the UI. But we can't do this if the connector is being created by the HTTP API. IIRC, for Swimlane, we needed to get some field mappings from the Swimlane service.

@cnasikas
Copy link
Member

cnasikas commented Jul 27, 2021

Hi @pmuellr. That is correct. We need to get some field mappings from the Swimlane service in the UI so the user can configure the connector.

The connector's configuration has two steps: a) instance configuration b) mappings configuration. The user has to first fill in the username and password and then go to the second step. In the second step, the minimum requirement is to select the connector type. The problem is that the user could press Save without going to the second step. To bypass this problem, we made an assumption and set the connector type to a default of our choice. It would be nice to have the create hook and return a message to the user about the mapping configuration (instead of a schema error).

Also, based on the connector type some of the fields in the mapping are required. Having that hook would enable us to do that kind of validation if someone tries to use the API directly.

Swimlane PR: #100086

@mikecote mikecote changed the title [alerting] allow rule types to provide feedback during create/update/delete calls [alerting] allow connector types to provide feedback during create/update/delete calls Jul 28, 2021
@mikecote mikecote added the loe:needs-research This issue requires some research before it can be worked on or estimated label Jul 28, 2021
@gmmorris gmmorris added insight Issues related to user insight into platform operations and resilience estimate:needs-research Estimated as too large and requires research to break down into workable issues labels Aug 16, 2021
@gmmorris gmmorris removed the loe:needs-research This issue requires some research before it can be worked on or estimated label Sep 2, 2021
@pmuellr pmuellr changed the title [alerting] allow connector types to provide feedback during create/update/delete calls [alerting] allow connector types to provide hooks/feedback during create/update/delete calls Oct 7, 2021
@pmuellr pmuellr added Feature:Actions/Framework Issues related to the Actions Framework Feature:Actions/ConnectorsManagement Issues related to Connectors Management UX labels Oct 20, 2021
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
@pmuellr pmuellr changed the title [alerting] allow connector types to provide hooks/feedback during create/update/delete calls [alerting] allow connector/rule types to provide hooks/feedback during create/update/delete calls Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Actions/ConnectorsManagement Issues related to Connectors Management UX Feature:Actions/Framework Issues related to the Actions Framework Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting insight Issues related to user insight into platform operations and resilience Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
Development

No branches or pull requests

6 participants