Stacked on https://github.com/elastic/kibana/pull/204004
<img width="1275" alt="Screenshot 2024-12-12 at 17 19 58"
src="https://github.com/user-attachments/assets/2ad14305-15c0-4522-8e70-5691c50e381b"
/>
Adds some bits to the stream overview page:
* Number of docs for the current time range (let's stop here and don't
build more of Kibana)
* List of child streams for wired streams
* Quick links tab (currently empty)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Removes `react-syntax-highlighter` from APM errors, in favour of
`EuiCodeBlock` for read-only code syntax highlighting. This in turn
removes a bunch of custom styling to bring things more inline with the
design system as well.
Closes#204049
## How to test
* Go to Applications - Service Inventory
* Find a service with errors
* Go to Errors tab for service
* Select an error that is an exception
* View details for the exception and see the syntax highlighted block
for the stack trace.
Closes: #205544
## Description
When user tabs over sync alert status with case status toggle button
under case settings on create case page, screenreader announces On, On
switch without giving any context.
## Preconditions
Security solution -> on cases page -> create case
## Changes made:
1. added context for **EuiSwitch** by passing `aria-labelledby`
attribute
## Screen
[Security Solution] [Attack discovery] Update Attack Discovery
evaluation prompts
This PR updates prompts used to evaluate the initial outputs of Attack
Discovery.
Only text was changed.
## Summary
This PR fixes the performance test pipelines by removing the bits that
rely on the plugins build.
### Details
* The plugin build has been removed with #197125. Since the performance
pipelines are running against a Kibana build (and not against sources),
they should not need the plugin build.
* The `performance-data-set-extraction` pipeline started to fail
immediately after the plugin build has been removed
* This failure went unnoticed since the `scalability-benchmarking`
pipeline continued to work by using the last uploaded artifacts from the
`performance-data-set-extraction` pipeline, which were available for
another month. Once the old artifacts were no longer available, the
`scalability-benchmarking` pipeline also started to fail.
## Summary
This PR removes the `analyzerDatePickersAndSourcererDisabled` feature
flag that was introduced a long time ago and has been in `disabled:
false` state for many months.
I noticed that the line was moved in [this
PR](https://github.com/elastic/kibana/pull/176064) over 6 months ago but
the introduction of the feature precedes that.
No UI changes introduced!
## Summary
[Internal link](https://github.com/elastic/security-team/issues/10820)
to the feature details
These changes add a functionality which enables related integrations
functionality for migration rules:
* related integration are shown in the migration rules table
* user can navigate to the integration page to see instructions about
installation process
### Other tasks and fixes
* Default sorting in the table (by `Stats` => by `Author` => by
`Severity` => by `Updated`)
> [!NOTE]
> This feature needs `siemMigrationsEnabled` experimental flag enabled
to work.
## Screen recording
<img width="1838" alt="Screenshot 2024-12-17 at 19 26 47"
src="https://github.com/user-attachments/assets/c1ed9d5d-e237-4dfe-b144-a80adbf46cd3"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> * This PR has been auto-generated.
> * Any manual contributions will be lost if the 'relocate' script is
re-run.
> * Try to obtain the missing reviews / approvals before applying manual
fixes, and/or keep your changes in a .patch / git stash.
> * Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
Are you trying to rebase this PR to solve merge conflicts? Please follow
the steps describe
[here](https://elastic.slack.com/archives/C07TCKTA22E/p1734019532879269?thread_ts=1734019339.935419&cid=C07TCKTA22E).
#### 3 packages(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/code-editor` |
`src/platform/packages/shared/shared-ux/code_editor/impl` |
| `@kbn/code-editor-mock` |
`src/platform/packages/shared/shared-ux/code_editor/mocks` |
| `@kbn/monaco` | `src/platform/packages/shared/kbn-monaco` |
<details >
<summary>Updated relative paths</summary>
```
src/platform/packages/shared/kbn-monaco/jest.config.js:12
src/platform/packages/shared/kbn-monaco/tsconfig.json:2
src/platform/packages/shared/kbn-monaco/tsconfig.type_check.json:2
src/platform/packages/shared/shared-ux/code_editor/impl/jest.config.js:12
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.json:16
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.json:2
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:18
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:2
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:25
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:28
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:31
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:34
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:37
src/platform/packages/shared/shared-ux/code_editor/impl/tsconfig.type_check.json:40
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.json:16
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.json:2
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.type_check.json:18
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.type_check.json:2
src/platform/packages/shared/shared-ux/code_editor/mocks/tsconfig.type_check.json:25
```
</details>
closes https://github.com/elastic/observability-dev/issues/3777
## Summary
This PR provides scale dimensions for the service map and infra host
pages without introducing any additional requests.
### Global Service Map and Per-service APM Service Map
| Metric | Description |
|----------------|------------------------------------|
| `num_of_nodes` | Total number of discovered nodes (services +
dependenies |
| `num_of_traces` | Total number of traces |
### Infra
| Metric | Description | default
|---------------|---------------------------------| -----------------
| `num_of_hosts` | Total number of hosts |
| `max_hosts_per_page` | Maximum number of host returne `50/100/500` |
100
| Page | Screenshot |
|-------------------------------|-------------------------------------------------------------------------------------------|
| Global Service Map | 
|
| Per-service APM Service Map | 
|
| Infra | !
|
### How to test
- Open any of the above pages
- In the network tab, look for `kibana:plugin_render_time`
## Summary
Closes https://github.com/elastic/kibana/issues/202295
Closes https://github.com/elastic/kibana/issues/202296
This PR adapts Inventory to use the new Entity v2 endpoints.
## Testing
- Use any synthtrace scenario that loads service/hosts/containers data
- Navigate and make sure everything works as expected (navigation to
Discovery/Infra/Services pages, interacting with the table, searching
for some specific entity, interacting with the type filter)
- To check the alerts work, it's easier to connect to a remote cluster.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jenny <dzheni.pavlova@elastic.co>
This PR updates the console definitions to match the latest ones from
the @elastic/elasticsearch-specification repo.
Co-authored-by: Elena Stoeva <59341489+ElenaStoeva@users.noreply.github.com>
**Resolves: #200167**
## Summary
Increase number of fetched package policies to the maximum. Currently
only the first 20 policies (the first page) are returned, which results
in treating all remaining ones as disabled.
I am proposing the simplest change of increasing the limit here to the
maximum. There shouldn't be too many policies there, e.g. in the
reproduction I am running there are 23 instead of 20.
If that is not enough, however, the alternative would be to discover
that there are more policies than the specified limit and the next
page(s) would have to be collected and the results added to the final
list.
#BEFORE
#AFTER
### Checklist
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
This closes https://github.com/elastic/streams-program/issues/54.
The root stream is selectively immutable (processing and fields changes
are not allowed).
## UI
For the UI I've entirely disabled the actions column for the root stream
in the schema editor. All of the information (bar the preview table for
changes) available in the flyout for a field is already available in the
table, so this seems easiest for now to avoid multiple logic forks
wrapping buttons etc.
E.g. flyout vs table
## Summary
[Internal link](https://github.com/elastic/security-team/issues/10820)
to the feature details
These changes add a functionality which allows user to retry failed
migration rules.
### Other tasks and fixes
* Integrated `MigrationReadyPanel` and `MigrationProgressPanel` to show
migration's `ready` and `running` states
* Migration stats pooling issue caused by waiting while there are no
pending migrations left. If any other operation triggers `startPooling`
during the waiting it will be ignored and thus latest stats will never
come back.
> [!NOTE]
> This feature needs `siemMigrationsEnabled` experimental flag enabled
to work.
### Testing note
1. Make sure you have a SIEM migration with failed rules
2. Open that migration via `Security > Rules > SIEM Rules Migrations >
{#MIGRATION_WITH_FAILED_RULES}`
3. You should see a `Reprocess rules (#)` button which triggers failed
rules reprocessing
## Screen recording
https://github.com/user-attachments/assets/d33dc4a0-1791-4869-aa8d-b0322b5f19c3
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Resolves:** https://github.com/elastic/kibana/issues/200134
## Summary
This PR implements concurrency control to make sure user has the recent rule updates data in Rule Upgrade flyout. Any modifications saved in Rule Upgrade flyout are reset upon new `revision` or `version` detected.
## Details
Concurrency control is important to provide better UX. Multiple users work in Kibana in parallel and new prebuilt rules package version can be released in any time. Attempts to upgrade a rule with outdated `revision` and/or `version` results in failed request. Users may experience multiple rule upgrade failure in that case causing a lot of confusion. More experienced users may guess to reload the page to continue.
Typical reasons leading to `revision` and/or `version` change are the following
- Current rule has been edited will bump rule's `revision`. For example the rule currently shown in Rule Upgrade flyout has been edited by someone else.
- Prebuilt rules package got released will give provide rule assets with higher `version`. Rules having upgrades in the currently installed package and in a new one are affected.
This PR mitigates the described issues by implementing concurrency control. It sets up `_review` API endpoint refetch interval to 5 minutes to fetch fresh data. In case a higher `revision` or `version` is detected for some rule this rule's resolved conflicts and customizations performed in Rule Upgrade flyout get cleared.
## Screenshots
- `revision` change (refresh interval was reduced to 30 seconds to make the video shorter)
https://github.com/user-attachments/assets/98d2a22f-9338-482a-a7b2-1e170b9642ce
- `version` change (refresh interval was reduced to 1 minute to make the video shorter)
https://github.com/user-attachments/assets/2b7c23f0-5a50-471e-aa7f-8d9b2aecc957
## How to test locally
There are two cases for testing
- `revision` change
- `version` change
### Test `revision` change
Revision change means the rule has been edited. Use the following steps to test it
- Ensure the `prebuiltRulesCustomizationEnabled` feature flag is enabled
- Allow internal APIs via adding `server.restrictInternalApis: false` to `kibana.dev.yaml`
- Clear Elasticsearch data
- Run Elasticsearch and Kibana locally (do not open Kibana in a web browser)
- Install an outdated version of the `security_detection_engine` Fleet package
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"force":true}' http://localhost:5601/kbn/api/fleet/epm/packages/security_detection_engine/8.14.1
```
- Install prebuilt rules
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 1" -d '{"mode":"ALL_RULES"}' http://localhost:5601/kbn/internal/detection_engine/prebuilt_rules/installation/_perform
```
- Open `Detection Rules (SIEM)` Page -> `Rule Updates`
- Open Rule upgrade flyout for some rule
- Make changes to rule field(s) and save them (do not upgrade the rule)
- Open the other web browser tab with Kibana
- Navigate to the same rule's editing page
- Change any field and save the changes
- Return back to the first tab and wait for data to be refetched (data refresh interval is 5 minutes, wait for `_review` request in the Dev Tool's Network tab)
- Make sure the changes you made for field(s) got reverted
### Test `version` change
Version change means a new package version was released. Do the following to test it
- Ensure the `prebuiltRulesCustomizationEnabled` feature flag is enabled
- Allow internal APIs via adding `server.restrictInternalApis: false` to `kibana.dev.yaml`
- Clear Elasticsearch data
- Run Elasticsearch and Kibana locally (do not open Kibana in a web browser)
- Set `xpack.securitySolution.prebuiltRulesPackageVersion: 8.15.2` in `kibana.dev.yaml`
- Install an outdated version of the `security_detection_engine` Fleet package
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"force":true}' http://localhost:5601/kbn/api/fleet/epm/packages/security_detection_engine/8.14.1
```
- Install prebuilt rules
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 1" -d '{"mode":"ALL_RULES"}' http://localhost:5601/kbn/internal/detection_engine/prebuilt_rules/installation/_perform
```
- Open `Detection Rules (SIEM)` Page -> `Rule Updates`
- Open Rule upgrade flyout for a rule having updates in packages `v8.15.2` and `.8.17.1-beta.1` for example `Suspicious Web Browser Sensitive File Access`
- Make changes to rule field(s) and save them (do not upgrade the rule)
- Set `xpack.securitySolution.prebuiltRulesPackageVersion: 8.17.1-beta.1` in `kibana.dev.yaml`
- Open the other web browser tab with Kibana
- Navigate to Security Solution plugin to install the
OR
install the package `8.17.1-beta.1` via API request
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"force":true}' http://localhost:5601/kbn/api/fleet/epm/packages/security_detection_engine/8.17.1-beta.1
```
- Return back to the first tab and wait for data to be refetched (data refresh interval is 5 minutes, wait for `_review` request in the Dev Tool's Network tab)
- Make sure the changes you made for field(s) got the recent target rule values
Alternatively you can spin up EPR locally and publish package updates with rule's version bumped.
## Summary
- addresses partly https://github.com/elastic/security-team/issues/10878
- shows deprecation warning if siem index was not migrated
### How to test
#### How to create legacy siem index?
run script that used for FTR tests
```bash
node scripts/es_archiver --kibana-url=http://elastic:changeme@localhost:5601 --es-url=http://elastic:changeme@localhost:9200 load x-pack/test/functional/es_archives/signals/legacy_signals_index
node scripts/es_archiver --kibana-url=http://elastic:changeme@localhost:5601 --es-url=http://elastic:changeme@localhost:9200 load x-pack/test/functional/es_archives/signals/legacy_signals_index_non_default_space
```
These would create legacy siem indices. But be aware, it might break
Kibana .alerts indices creation. But sufficient for testing
Visit also detection rules page, to ensure alerts index created.
Otherwise,
https://www.elastic.co/guide/en/security/current/signals-migration-api.html#migration-1
API might not show these indices outdated
#### How to test deprecated feature?
1. Observe warning feature deprecation on Kibana Upgrade page, if you
set up legacy siem signals
<details>
<summary> Kibana Upgrade feature deprecation flyout </summary>
<img width="2540" alt="Screenshot 2024-12-17 at 16 59 04"
src="https://github.com/user-attachments/assets/c6aa420f-af69-4545-8400-6a6513f613a9"
/>
</details>
#### Test outdated indices created in 7.x
1. Create cloud env of 7.x version
2. Create rule, generate alerts for .siem-signals
3. Create cloud env of 8.18 from existing 7.x snapshot (from previous
steps)
4. Connect local Kibana to 8.18 from mirror branch of this
one(https://github.com/elastic/kibana/pull/204621)
5. Add to Kibana dev config following options to enable Upgrade
assistant(UA) showing outdated indices
```yml
xpack.upgrade_assistant.featureSet:
mlSnapshots: true
migrateDataStreams: true
migrateSystemIndices: true
reindexCorrectiveActions: true
```
6. Go to Detection rules page, ensure rule is running and new .alerts
index has been created (visiting rules table page should be enough)
7. Open UA, ensure Kibana deprecations show signals are not migrated
8. Open UA, check Elasticsearch deprecations
9. Find outdated siem-signals index
10. Migrate it
11. Check Kibana deprecations still signals are not migrated
12. Migrate signals using
https://www.elastic.co/guide/en/security/current/signals-migration-api.html
API
13. Ensure Kibana deprecations does not show that space as not migrated
Demo video of migration .siem-signal from another-3 Kibana space
https://github.com/user-attachments/assets/d2729482-d2c8-4a23-a780-ad19d4f52c73
Connected with #195189
## Summary
- Moved params of duration metric inventory threshold rule type to
`/response-ops/rule_params/metric_inventory_threshold/`
- Moved params of metric threshold rule type to
`/response-ops/rule_params/metric_threshold/`
**I did NOT move the corresponding type to the rule_params package due
to the recursive imports it would create.**
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is a pre-requisite for adding aggregation by process name and by
thread name to the Universal Profiling flamegraph view.
It adds three artificial node types to the flamegraph including color
codes.
As a side-effect, the root node now has its own color code. Previously,
it (accidentally) used the color code of "unknown" type frames.
The PR is backwards compatible, so it doesn't change anything in the UI
when connecting with current Elasticsearch.
As soon as [the PR for
ES](https://github.com/elastic/elasticsearch/pull/119115) is merged, the
new aggregations show up.
## Summary
Updates Cytoscape to newer versions, requiring one change with some
`removeListener` usage no longer being valid typing.
Supersedes #205444
## How to test
- Passes CI with no type errors or failed CI jobs for ML
- Job Map or wherever cytoscape is being used on ML doesn't leak event
listeners.
- Usages in APM also do not break.
## Summary
Over a year ago, [this
PR](https://github.com/elastic/kibana/pull/171589) added some
information to the alert details flyout, to show when an alert's status
(`closed`, `open` or `aknowledged`) had been modified last and by which
user.
Shortly after, [this follow up
PR](https://github.com/elastic/kibana/pull/172888) removed the UI from
the alert details flyout, as the information wasn't extremely important
and was taking some valuable vertical space, pushing down below the
`Highlighted fields` section, that users were finding very important.
A few months later, we added the ability to persist which of the top
sections (`About`, `Investigation`, `Visualizations`, `Insights` and
`Response`) were collapsed or expanded. That way the user wouldn't have
to always collapse or expand sections they would often don't need.
This PR brings back the alert's last status changes to the `About`
section, as the vertical space is no longer a big issues, because users
can now collapse the entire `About` section.
#### If data is not present, the last change UI is not shown
#### If the correct data is shown:
### How to test
- have a few alerts in the alerts table
- open the alert details flyout for one alert and change the status
(button in the header)
- verify that the last status change section is shown in the `About`
section
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
This [PR](https://github.com/elastic/kibana/pull/192531) started the
move of the analyzer and session view components from the table to the
flyout. Shortly after we added an advanced settings (via this
[PR](https://github.com/elastic/kibana/pull/194012)) to allow users to
switch back and forth between the old table view and the flyout view.
This current PR focuses on the session view component and enhances its
user experience, when rendered in the expandable flyout.
No changes should be made for the user in the table as well as the other
usages of the session view component (like for example the Kubernetes
dashboard).
#### Old UI (in table)
https://github.com/user-attachments/assets/015b32fc-69bb-4526-a42d-accad085ad43
####. New UI (in flyout)
https://github.com/user-attachments/assets/9a3eacbf-bf2b-43d4-8e74-ea933ee0d498
As can seen in the video above, when the session view component is
opened in the expandable flyout, we show the tree view and the detailed
panel separated. This allow for better use of the horizontal space,
especially visible on a wide monitor. This is also combined with the
fact that the flyout is resizable (and can take the whole screen) and
the preview panel is also resizable, to provide more space to the
detailed panel.
Note: the session view full screen functionality is lost, but this is by
design. As mentioned above, the user can resize the flyout's width to
take the full screen, and the flyout's vertical space is already near
full height.
## Code decisions
To guarantee as much as possible that the usage of the Session View
component in the table or in the other places (like the Kubernetes
dashboard) were not impacted by this PR, only additive changes were
made. All these changes are also protected behind `if` conditions, that
should only be run when the correct props are being passed in.
Some components (like the content of each of the tabs of the detailed
panels - Process, Metadata and Alerts) as well as a hook, are exposed
outisde of the `session_view` plugin, to be reused in the expandable
flyout directly.
Code changes were kept to a bare minimum in the `session_view` plugin!
## What to test
- functionality of the Session View component should be exactly the same
when used in the table as when used in the flyout:
- clicking on a row in the tree should update the detailed panel
accordingly
- jumping to a process from the detailed panel should correctly update
the tree
- viewing the details of an alert should work
- the
- the UI will be mostly the same, with some small tweaks:
- viewing an alert details now opens a preview panel instead of the
flyout. The user can go back to the previous panel by clicking on the
`Back` button in the top-left corner
- the alerts tab does not show the number of alerts as it previously
was. We might be able to get this to work later, but after discussing
with Product this is an acceptable solution as the feature is still
behind an Advanced Settings
- the `Open details` has been replaced by a `expand` icon button, to be
more consistent with the rest of the UI in the flyout
### Notes:
- there is a small update in the analyzer graph to the icon used in the
open detail button. We're now using the `expand` icon to be consistent
with the Session View component (which already has another `eye` icon)
## How to test
- turn on the `securitySolution:enableVisualizationsInFlyout` Advanced
Settings
- generate alerts with data for session view (`yarn test:generate -n
http://elastic:changeme@localhost:9200 -k
http://elastic:changeme@localhost:5601`)
---------
Co-authored-by: Paulo Silva <paulo.henrique@elastic.co>
## Summary
Redoing [this PR](https://github.com/elastic/kibana/pull/203184) which
had to be [reverted](https://github.com/elastic/kibana/pull/204218).
This should not be merged until [this update to the task manager v1
schema](https://github.com/elastic/kibana/pull/204413) is released.
## To verify
1. Set `xpack.task_manager.unsafe.exclude_task_types:
['ad_hoc_run-backfill', 'actions:*']` in your Kibana config.
2. Run Kibana on main and create some detection rules that run
frequently, with actions.
3. Schedule a manual run for your detection rules.
- Because of the config, the `action_task_params` SO and the
`ad_hoc_run_task_params` SO will get written but not read yet.
4. Remove the `exclude_task_types` config and "upgrade" to this PR
branch and verify that rules continue to run and that the actions are
triggered and the manual rule runs go through
5. Re-add the `exclude_task_types` config and let the rule run again to
schedule action. Schedule another manual rule run.
6. Remove the `exclude_task_types` config and "downgrade" back to main
and verify that rules continue to run, the action gets triggered and
manual rule runs go through.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Links dashboard to Streams.
Changes:
- Introduces `IndexStorageAdapter` to manage ES indices - see
https://github.com/dgieselaar/kibana/blob/streams-app-asset-linking/x-pack/solutions/observability/packages/utils_server/es/storage/README.md
for motivation
- Introduces `AssetClient` and `AssetService` to manage asset links with
`IndexStorageAdapter`
- `RepositorySupertestClient` to make it easier to use
`@kbn/server-route-repository` with FTR tests
- refactors related to above changes
---------
Co-authored-by: Chris Cowan <chris@elastic.co>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
As part of v9.0 readiness, we reindex the indices in v.8 but still has
data from v.7x.
As a result of the process, the reindexed indices get `.reindexed-v8-`
prefix.
This PR add that prefix to the valid prefixes list.
# To verify:
Run Kibana and ES in 7.17 (use `-E path.data=your-data-path` to keep the
data in your local)
Create some rules that generate alerts (Observability rules to have AAD)
Let them run for a while.
Stop Kibana and ES, switch to 8.x branch and run ES and Kibana again
Open the Upgrade Assistant.
It should show the `.internal.alerts-*` indices
Click on them and start reindexing on the opened flyout.
Check that `.reindexed-v8-internal.alerts-*` index has been created
Let you rules run for a while again.
Your alerts should be updated and there shouldn't be any error on your
terminal.
---------
Co-authored-by: Ersin Erdal <ersin.erdal@elastic.co>
Co-authored-by: Ersin Erdal <92688503+ersin-erdal@users.noreply.github.com>
