-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Detect rule param changes for rolling upgrades and rollback assessment #173936
Detect rule param changes for rolling upgrades and rollback assessment #173936
Conversation
69d8613
to
bc465a3
Compare
97a94c9
to
7c3b37f
Compare
/ci |
…ibana into poc/detect-rule-param-changes
@elasticmachine merge upstream |
/ci |
/ci |
…ibana into poc/detect-rule-param-changes
/ci |
/ci |
Pinging @elastic/response-ops (Team:ResponseOps) |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Response ops changes LGTM
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
Pinging @elastic/obs-ux-management-team (Team:obs-ux-management) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kibana-gis changes LGTM
code review only
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed changes to Detection Engine code. Both the referenced schema and their associated types look correct, as well as the relevant snapshot tests. LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obs UX changes LGTM 💯 I checked the rules/alerts locally and tested it as described.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ML and Transform changes LGTM
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Public APIs missing comments
History
To update your PR or re-run it, just comment with: |
elastic#173936) In this PR, I'm adding a test in the alerting framework to detect changes in a rule type's params schema that will require a snapshot to be updated. This snapshot will provide a centralized place to view history on alerting rule params in case we need to asses risk for rolling upgrades or rollbacks of a release (serverless). The only rule types affected are those running in serverless in any of the three project types. When a rule type is used in serverless, it must provide one of the following configuration to their rule type on top of everything else: ``` // Zod schema schemas: { params: { type: 'zod', schema: UnifiedQueryRuleParams }, }, // config-schema schemas: { params: { type: 'config-schema', schema: EsQueryRuleParamsSchema, }, }, ``` We are working on documenting guidelines so engineers and response ops can ensure a change to rule parameters will work properly in rolling upgrade and rollback scenarios and be part of the PR review process. NOTE to rule type owners: I pass the same schema used to validate to the `schemas.params` attribute in the rule type. It will be important to keep them in sync. Down the road, we plan to make `validate.params` optional and use the schema as a starting point so it's easier to have a single variable passed in. ## To verify 1. Make changes to the params schema of the ES query rule type. ``` diff --git a/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts b/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts index 73e8eae32cf..09ec74104ec 100644 --- a/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts +++ b/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts @@ -39,6 +39,7 @@ export type EsQueryRuleParamsExtractedParams = Omit<EsQueryRuleParams, 'searchCo }; const EsQueryRuleParamsSchemaProperties = { + foo: schema.boolean(), size: schema.number({ min: 0, max: ES_QUERY_MAX_HITS_PER_EXECUTION }), timeWindowSize: schema.number({ min: 1 }), excludeHitsFromPreviousRun: schema.boolean({ defaultValue: true }), ``` 2. Run the jest integration test to update the snapshot file ``` node scripts/jest_integration.js x-pack/plugins/alerting/server/integration_tests/serverless_upgrade_and_rollback_checks.test.ts -u ``` 3. Notice the `x-pack/plugins/alerting/server/integration_tests/__snapshots__/serverless_upgrade_and_rollback_checks.test.ts.snap` file got updated ``` "foo": Object { "flags": Object { "error": [Function], }, "type": "boolean", }, ``` --------- Co-authored-by: kibanamachine <[email protected]>
elastic#173936) In this PR, I'm adding a test in the alerting framework to detect changes in a rule type's params schema that will require a snapshot to be updated. This snapshot will provide a centralized place to view history on alerting rule params in case we need to asses risk for rolling upgrades or rollbacks of a release (serverless). The only rule types affected are those running in serverless in any of the three project types. When a rule type is used in serverless, it must provide one of the following configuration to their rule type on top of everything else: ``` // Zod schema schemas: { params: { type: 'zod', schema: UnifiedQueryRuleParams }, }, // config-schema schemas: { params: { type: 'config-schema', schema: EsQueryRuleParamsSchema, }, }, ``` We are working on documenting guidelines so engineers and response ops can ensure a change to rule parameters will work properly in rolling upgrade and rollback scenarios and be part of the PR review process. NOTE to rule type owners: I pass the same schema used to validate to the `schemas.params` attribute in the rule type. It will be important to keep them in sync. Down the road, we plan to make `validate.params` optional and use the schema as a starting point so it's easier to have a single variable passed in. ## To verify 1. Make changes to the params schema of the ES query rule type. ``` diff --git a/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts b/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts index 73e8eae32cf..09ec74104ec 100644 --- a/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts +++ b/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts @@ -39,6 +39,7 @@ export type EsQueryRuleParamsExtractedParams = Omit<EsQueryRuleParams, 'searchCo }; const EsQueryRuleParamsSchemaProperties = { + foo: schema.boolean(), size: schema.number({ min: 0, max: ES_QUERY_MAX_HITS_PER_EXECUTION }), timeWindowSize: schema.number({ min: 1 }), excludeHitsFromPreviousRun: schema.boolean({ defaultValue: true }), ``` 2. Run the jest integration test to update the snapshot file ``` node scripts/jest_integration.js x-pack/plugins/alerting/server/integration_tests/serverless_upgrade_and_rollback_checks.test.ts -u ``` 3. Notice the `x-pack/plugins/alerting/server/integration_tests/__snapshots__/serverless_upgrade_and_rollback_checks.test.ts.snap` file got updated ``` "foo": Object { "flags": Object { "error": [Function], }, "type": "boolean", }, ``` --------- Co-authored-by: kibanamachine <[email protected]>
elastic#173936) In this PR, I'm adding a test in the alerting framework to detect changes in a rule type's params schema that will require a snapshot to be updated. This snapshot will provide a centralized place to view history on alerting rule params in case we need to asses risk for rolling upgrades or rollbacks of a release (serverless). The only rule types affected are those running in serverless in any of the three project types. When a rule type is used in serverless, it must provide one of the following configuration to their rule type on top of everything else: ``` // Zod schema schemas: { params: { type: 'zod', schema: UnifiedQueryRuleParams }, }, // config-schema schemas: { params: { type: 'config-schema', schema: EsQueryRuleParamsSchema, }, }, ``` We are working on documenting guidelines so engineers and response ops can ensure a change to rule parameters will work properly in rolling upgrade and rollback scenarios and be part of the PR review process. NOTE to rule type owners: I pass the same schema used to validate to the `schemas.params` attribute in the rule type. It will be important to keep them in sync. Down the road, we plan to make `validate.params` optional and use the schema as a starting point so it's easier to have a single variable passed in. ## To verify 1. Make changes to the params schema of the ES query rule type. ``` diff --git a/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts b/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts index 73e8eae32cf..09ec74104ec 100644 --- a/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts +++ b/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type_params.ts @@ -39,6 +39,7 @@ export type EsQueryRuleParamsExtractedParams = Omit<EsQueryRuleParams, 'searchCo }; const EsQueryRuleParamsSchemaProperties = { + foo: schema.boolean(), size: schema.number({ min: 0, max: ES_QUERY_MAX_HITS_PER_EXECUTION }), timeWindowSize: schema.number({ min: 1 }), excludeHitsFromPreviousRun: schema.boolean({ defaultValue: true }), ``` 2. Run the jest integration test to update the snapshot file ``` node scripts/jest_integration.js x-pack/plugins/alerting/server/integration_tests/serverless_upgrade_and_rollback_checks.test.ts -u ``` 3. Notice the `x-pack/plugins/alerting/server/integration_tests/__snapshots__/serverless_upgrade_and_rollback_checks.test.ts.snap` file got updated ``` "foo": Object { "flags": Object { "error": [Function], }, "type": "boolean", }, ``` --------- Co-authored-by: kibanamachine <[email protected]>
In this PR, I'm adding a test in the alerting framework to detect changes in a rule type's params schema that will require a snapshot to be updated. This snapshot will provide a centralized place to view history on alerting rule params in case we need to asses risk for rolling upgrades or rollbacks of a release (serverless). The only rule types affected are those running in serverless in any of the three project types.
When a rule type is used in serverless, it must provide one of the following configuration to their rule type on top of everything else:
We are working on documenting guidelines so engineers and response ops can ensure a change to rule parameters will work properly in rolling upgrade and rollback scenarios and be part of the PR review process.
NOTE to rule type owners: I pass the same schema used to validate to the
schemas.params
attribute in the rule type. It will be important to keep them in sync. Down the road, we plan to makevalidate.params
optional and use the schema as a starting point so it's easier to have a single variable passed in.To verify
x-pack/plugins/alerting/server/integration_tests/__snapshots__/serverless_upgrade_and_rollback_checks.test.ts.snap
file got updated