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.

Sign up for GitHub

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

Jump to bottom

[Research] Ability for alert / action types to define migrations #50216

Open
mikecote opened this issue Nov 11, 2019 · 9 comments
Open

[Research] Ability for alert / action types to define migrations #50216

mikecote opened this issue Nov 11, 2019 · 9 comments
Assignees
@JiaweiWu
Labels
DX Issues related to Developer Experience estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Actions/Framework Issues related to the Actions Framework Feature:Actions Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting migration-resilience Issues related to migration resilience in terms of scale, performance & backwards compatibility NeededFor:Detections and Resp NeededFor:logs-metrics-ui Project:MoreRuleTypes Alerting team project for providing more ways to construct rules. Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@mikecote
Copy link
Contributor

mikecote commented Nov 11, 2019 •
edited
Loading

In scenario they changed the parameters for their alert / action type.
In the scenario we added name to alert.

This will be needed once we support mappings for config, params, etc
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-stack-services (Team:Stack Services)

@FrankHassanabad FrankHassanabad mentioned this issue Nov 11, 2019
Closed
@bmcconaghy bmcconaghy added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) and removed Team:Stack Services labels Dec 12, 2019
@mikecote mikecote mentioned this issue May 14, 2020
Closed
@mikecote mikecote mentioned this issue Jun 2, 2020
Open
59 tasks
@mikecote
Copy link
Contributor Author

Some additional comments in issue #66608

@mikecote mikecote mentioned this issue Jul 9, 2020
Closed
@mikecote mikecote mentioned this issue Dec 4, 2020
Closed
@mikecote
Copy link
Contributor Author

mikecote commented Dec 4, 2020

Linking with #84907 as it could help us here.

@spong
Copy link
Member

spong commented Dec 7, 2020 •
edited
Loading

+1 here from the Security Detections side. It would be beneficial for us to be able to leverage dedicated SO migrations for Detection Rules (and not having to embed the migration within Alerting). A recent example here is in needing to find all Detection Rules that reference a set of Exception Lists, whose reference is currently being stored in the Rule's AlertParams and cannot be searched. We don't currently have a back reference on our Exception Lists, so one solution would be to move the Rule's Exception List reference from AlertParams to internal tags within an SO migration (or leverage the existing SO references array).

@yctercero yctercero mentioned this issue Jan 4, 2021
Merged
7 tasks
@mikecote mikecote mentioned this issue Feb 3, 2021
Closed
@mikecote
Copy link
Contributor Author

mikecote commented Feb 4, 2021

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.

@stacey-gammon
Copy link
Contributor

stacey-gammon commented Jun 17, 2021 •
edited
Loading

@joshdover @ppisljar - This looks like another use case for Persistable State. This is an interesting one though because it appears that the registrar can define mappings on the saved object. I was hoping we could get away with just leveraging "migrateToLatest" functionality rather than the SO-required object mapping (of version to migrate function), but because of this use case, we may need to continue to support both.

@gmmorris gmmorris added NeededFor:logs-metrics-ui NeededFor:Detections and Resp Project:MoreRuleTypes Alerting team project for providing more ways to construct rules. Feature:Actions/Framework Issues related to the Actions Framework Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Actions labels Jun 30, 2021
@gmmorris gmmorris added the loe:large Large Level of Effort label Jul 14, 2021
@gmmorris gmmorris added loe:needs-research This issue requires some research before it can be worked on or estimated and removed loe:large Large Level of Effort labels Jul 14, 2021
@gmmorris gmmorris added DX Issues related to Developer Experience migration-resilience Issues related to migration resilience in terms of scale, performance & backwards compatibility estimate:needs-research Estimated as too large and requires research to break down into workable issues labels Aug 13, 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
@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
@kobelb kobelb mentioned this issue Jun 6, 2024
Closed
@banderror banderror mentioned this issue Jun 7, 2024
Open
@banderror banderror mentioned this issue Jul 5, 2024
Open
@mikecote mikecote changed the title Ability for alert / action types to define migrations [Research] Ability for alert / action types to define migrations Jan 29, 2025
@pmuellr
Copy link
Member

pmuellr commented Jan 31, 2025

Closing, as things have changed SOOO much since this was created! In particular, our newest constraints surrounding rule/connector data shape changes is reflected in 2024-01 Requiring intermediate releases to change rule or connector schemas in serverless

@pmuellr pmuellr closed this as completed Jan 31, 2025
@pmuellr
Copy link
Member

pmuellr commented Jan 31, 2025

hahahaha - I just noticed Mike assigned this to JiaweiWu YESTERDAY hahahahaha ... so I'll re-open, it would be good to get some prose from @mikecote on what we're expecting here ...

@pmuellr pmuellr reopened this Jan 31, 2025
@mikecote
Copy link
Contributor Author

mikecote commented Feb 3, 2025

hahahaha - I just noticed Mike assigned this to JiaweiWu YESTERDAY hahahahaha ... so I'll re-open, it would be good to get some prose from @mikecote on what we're expecting here ...

😁 We'll need to find a way using the new migration strategy to allow rule types to migrate their parameters so they can have the rule type running with the latest parameters at all times. It will simplify the codebase for teams as they don't have to migrate on the fly anywhere they access an object. Jiawei will create a PoC and assess our options 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@JiaweiWu JiaweiWu

Labels
DX Issues related to Developer Experience estimate:needs-research Estimated as too large and requires research to break down into workable issues Feature:Actions/Framework Issues related to the Actions Framework Feature:Actions Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework Feature:Alerting migration-resilience Issues related to migration resilience in terms of scale, performance & backwards compatibility NeededFor:Detections and Resp NeededFor:logs-metrics-ui Project:MoreRuleTypes Alerting team project for providing more ways to construct rules. Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
AppEx: ResponseOps - Rules & Alerts Management
Status: No status
Milestone
No milestone
Development

No branches or pull requests
9 participants
@pmuellr @gmmorris @kobelb @bmcconaghy @spong @mikecote @elasticmachine @stacey-gammon @JiaweiWu