[Alerting] Warn by default when rule schedule interval is set below the minimum configured.

[ymao1]

Resolves #126946

Summary

Updates minimum schedule interval configuration in the following ways:

• Moves config underneath xpack.alerting.rules config keys
• Adds enforce value to specify whether we are enforcing the minimum or not. Defaults to false.
• When enforce = true, behavior is same as described in this PR where existing rules run untouched but rules cannot be created or updated with an interval below the configured minimum.

When enforce = false:

• The UI shows this helper text if user selects minimum below the configured.

• Rule update and creation with interval below the minimum are allows but this warning is logged:

Checklist

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

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

[tylersmalley]

Docker config change LGTM

[ymao1]

@lcawl Can you review the wording of the helper text and server log warning as show in the screenshots?

[mikecote]

Changes LGTM! Tested locally and saw the warnings 👍

[mikecote]

I notice if I increase xpack.alerting.rules.minimumScheduleInterval.value to a value higher than 1m and open the create rule flyout, the interval of 1m is set by default and the warning displays. If this isn't desired behaviour, should we change it so the default rule interval equals minimumScheduleInterval.value when configured to a value higher than 1m?

[ymao1]

That's a good catch @mikecote! Updated in this commit to set the default schedule interval to match the minimum configured if the minimum is greater.

That commit should also fix this bug: #122707

[mikecote]

LGTM, thank you!

That commit should also fix this bug: #122707

I wasn't able to confirm this, I set defaultScheduleInterval with a few varying configurations.

[ersin-erdal]

code-wise LGTM, but due to an ssl issue, couldn't verify it by running the PR locally.
edit: I was able to run it locally. works as expected.

[lcawl]

Minor suggestions, otherwise text LGTM

[klacabane]

LGTM

[ymao1]

@elasticmachine merge upstream

[ymao1]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 8e9f950
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
triggersActionsUi	334	335	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
triggersActionsUi	662.2KB	663.2KB	+1.1KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
alerting	20	21	+1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
triggersActionsUi	96.5KB	96.6KB	+54.0B

History

• 💚 Build #32188 succeeded fe3ccf4
• 💔 Build #32154 failed 7037966
• 💔 Build #31960 failed 7caa1cb
• 💔 Build #31957 failed cb78cd3
• 💛 Build #31533 was flaky 932a078
• 💔 Build #31460 failed 3926543

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @ymao1