[Alerting] [Discuss] Modifying alert params within the executor as a migration tool #66608
Labels
discuss
Feature:Alerting
Team:ResponseOps
Label for the ResponseOps team (formerly the Cases and Alerting teams)
Alerts are in beta right now, so we might be pushing a large amount of breaking changes to them. Required alert params might change between minor versions, and so alerts created in a previous version would immediately break.
Can we fix this by including a migration assistant service in alert executors? For example:
timeSize
andtimeUnit
) inside each alertcriteria
(an array of alert conditions), but these are supposed to be the same for each of them. It's redundant and error-prone to repeat the same value inside each array member.timeSize
andtimeUnit
outside of thecriteria
array and into the top-level alertparams
.timeSize
andtimeUnit
are inside of thecriteria
. If they are, it will move them into the top level of params and update the SavedObject of the alert to reflect this change. This code can then be deprecated in the next minor version, assuming that all alerts probably migrated before then.Is something like this already possible with the available
savedObjects
service in alerts, or would a new one be needed? Is this even a good idea? I'd like some opinions.The text was updated successfully, but these errors were encountered: