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

[ResponseOps] space-agnostic admin-only route to return all rules / connectors #137352

Closed
pmuellr opened this issue Jul 27, 2022 · 2 comments
Closed
Labels
Feature:Actions/Framework Issues related to the Actions Framework Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@pmuellr
Copy link
Member

pmuellr commented Jul 27, 2022

For support purposes, and specifically the Kibana diagnostics tool, we're considering adding routes for rules and connectors that would return all the relevant SO's like their find routes currently do, except it would return ALL the rules / connectors across all spaces, and presumably require "superuser" access, or equivalent sort of authorization gating.

This would greatly simplify the ability for users to pull all the alerting rules / connectors in a much smaller set of requests. The alternative is:

  • find all spaces (may require pagination)
  • for each space:
    • find all rules in this space (may require pagination)
    • find all connectors in this space (may require pagination)

This would change to:

  • find all rules (may require pagination)
  • find all connectors (may require pagination)

I don't believe we actually return the space in the rules or connectors, and we'd need to do that for this call, so we'd need to figure out how to do that. For instance:

  • add a new field to the returned output data for rules / connectors indicating the spaces
  • return the spaces as top-level keys of the response, with the value being an array of the data relevant to that space
  • some even more complex data structure (more indirection; for example, an array of spaces, array of rule/connectors, final array of pairs of those indices)

The first sounds better - the data shape is easier to deal with, and will be less confusing when we support rules / connectors in multiple spaces (in the second form, presumably objects in multiple spaces would be duplicated under each space key).

Note: I don't think we have an issue open for this, and did a cursory search and didn't find one. But if we do, we can close this as a DUP

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

Pinging @elastic/response-ops (Team:ResponseOps)

@pmuellr
Copy link
Member Author

pmuellr commented Jan 3, 2023

During a backlog grooming session, we decided to close this issue in favor of the new capability of Allowing users to see event logs from all spaces they have access to, implemented in #140449

At least for the non-diagnostic tool purposes (mentioned in the top comment), we think this should handle the needs users will have for cross-space visibility of alerting status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Actions/Framework Issues related to the Actions Framework Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
Development

No branches or pull requests

2 participants