Updates the text on the landing page
**Before**

**After**

Adds a new feature flag to allow the `Create filebeat configuration`
card to be hidden. This has been
[requested](https://github.com/elastic/enterprise-search-team/issues/7075)
for the serverless search project and so the `serverless.es.yml` has
been updated to include this flag.
**Before**

**After**

Adds a setting in the `aiAssistantManagementSelection` plugin that
allows users to set the preferred Assistant type. The allowed values
are:
- `default`: the status quo, which is: show the Observability AI
Assistant in Observability apps, the Security AI Assistant in Security
solution apps, and none in the other apps.
- `never`: Never show any AI Assistant.
- `observability`: Show the Observability AI Assistant everywhere,
except for Security solution apps.
- `security`: ~Show the Security AI Assistant everywhere, except for
Observability apps.~
it is up to the solutions to respect the setting. See
[x-pack/plugins/observability_solution/observability_ai_assistant_app/public/hooks/is_nav_control_visible.tsx](https://github.com/elastic/kibana/pull/179233/files#diff-753a9aae298da45c5bd96bc2cacaa437ac53e165069ad6323973dd3c2879d4ae)
for an example. It should also be set in the specific Serverless config:
[config/serverless.oblt.yml](https://github.com/elastic/kibana/pull/179233/files#diff-358680d2b72268283dca4f3efb976cd924b7b5bce822e07c8871d061b4bb339e).
Update: this is now labeled as an Observability-only setting.

---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#179110
This adds a series of feature flags to all plugins that are currently
using the **Rule Form Flyout**, in preparation for development of the
new Create Rule Flow V2 (#175634).
Unfortunately true Kibana feature-flagging is still not yet implemented,
so we need to implement this as a config option for every individual
affected plugin. The following `kibana.yml` config will enable the
upcoming V2 rule form:
```yaml
xpack.trigger_actions_ui.enableExperimental: ['ruleFormV2']
xpack.infra.featureFlags.ruleFormV2Enabled: true
xpack.ml.experimental.ruleFormV2.enabled: true
xpack.transform.experimental.ruleFormV2Enabled: true
xpack.legacy_uptime.experimental.ruleFormV2Enabled: true
xpack.observability.unsafe.ruleFormV2.enabled: true
xpack.slo.experimental.ruleFormV2.enabled: true
xpack.apm.featureFlags.ruleFormV2Enabled: true
discover.experimental.ruleFormV2Enabled: true
```
**These feature flags will not enable anything yet.** This PR is for the
sole purpose of adding these browser-enabled flags now, so that we can
reduce the amount of code committed later.
### Why feature flag every plugin?
The V1 rule form is currently exported from Triggers Actions UI. In V2,
we're moving away from this model and exporting the rule form in a KBN
package. Therefore we can't simply export the results of a single
feature flag from Triggers Actions UI, we need to signal to each
individual plugin whether it should be pulling from the new KBN package
or from the old cross-plugin export.
### Plugins affected
#### Triggers Actions UI, Infra, Observability, APM
These plugins already contained interfaces for experimental features or
feature flags, so this PR simply adds a new flag to these existing
structures.
#### Discover, ML, Transform, Uptime, SLO
These plugins did **not** have existing browser-exposed feature flag
systems, so this PR adds these interfaces. The transform plugin notably
did not yet have any config options configured at all.
The AppEx Management team was recently renamed on GitHub from
`platform-deployment-management` to `kibana-management`. This PR updates
the Codeowners file and all references to the team name.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The goal of this PR is to set up a kibana.yml setting
`share.new_version.enabled: <true|false>`, to toggle the older and new
implementation for the share context menu to modals.
This will allow for easier incremental implementation into main for me
and @eokoneyo without breaking the share context menu until the project
is completed. This setting is false by default and if not specified in
the yml to not disturb others while this project is underway. This
setting can be removed once the redesign is completed.
This PR is focused on just setting up the setting. The new version opens
a modal but subsequent PRs will address opening the modal to a
functioning implementation.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/174771
While the security team works on Custom Roles for serverless, we want to
hide the content behind a feature flag.
An existing config option that was used to hide the Roles UI during the
initial phases of serverless has been repurposed, and will now toggle
both the Roles UI and the Roles Routes
`xpack.security.confg.ui.roleManagementEnabled` has been changed to
`xpack.security.confg.roleManagementEnabled` and will have to be set to
`true` in a config file while in serverless mode to show the Roles card
on the management screen and enable the UI/routes.
## Reviewers
Ive included a `viewer`:`changeme` user for testing (It will be removed
after approval).
## Testing
### xpack.security.config.roleManagementEnabled
1. In your `kibana.yml`, add
`xpack.security.confg.roleManagementEnabled: true`
2. Start up in serverless mode locally, login in with
`elastic_serverless`:`changeme`
3. Click `Project Settings` > `Management`
4. `Roles` card should display under `Other`
5. Navigate to `Roles`, it displays, but the `Edit Roles` page does not
work yet.
### Test as Viewer
1. In your `kibana.yml`, add either above option as you prefer
2. Start up in serverless mode locally, login in with
`viewer`:`changeme`
3. Click `Project Settings` > `Management`
4. `Roles` card should NOT display under `Other` and the `roles` URL
should not work.
## Screenshots
Roles card
<img width="1281" alt="Screenshot 2024-02-05 at 3 22 12 PM"
src="a1285ada-7ff7-495f-88a6-9847b3245518">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
## Summary
This PR adds a dev config to Console to enable a migration to the Monaco
editor. The config value is `false` by default and can be changed by
adding `console.dev.enableMonaco: true` to `kibana.dev.yml`. Also a new
custom Monaco language is registered for Console in the package
`kbn/monaco` and will be worked on behind the config flag iteratively in
the next weeks.
To not let the dev config get into 8.13 release, this PR will only be
merged **after** 8.13 has been branched.
After this PR is merged, the team will start re-implementing existing
Console features in the new Monaco editor, see
https://github.com/elastic/kibana/issues/176723 and
https://github.com/elastic/kibana/issues/176926
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
Refactoring general ui service (test helpers), to a kbn package.
- Optimize methods and drop some code duplication.
### Why
- Makes the service easily available from multiple code areas.
- This is a preparation to potentially moving tests to plugins /
packages, where they would no longer be able to import thing from test
or x-pack/test but only from a package.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/165672
### Summary
This PR adds support for custom output and Fleet server hosts with
proxies in serverless mode:
- Proxies are re-enabled in serverless.
- It is possible to add custom Fleet server hosts in serverless, with
the constraint that the host URL must match the Elasticsearch URL of the
default host.
- New Elasticsearch outputs must also have the default host URL.
### Testing
The below requirements should be tested in serverless mode for
observability and security project types:
```sh
# elasticsearch
yarn es serverless --kill
# kibana: one of
yarn serverless-oblt
yarn serverless-security
```
⚠️ In addition, stateful mode should **not** be affected by any of these
changes.
#### Config
In order to test this change, you will need the following configuration
to mirror a serverless setup.
Create a `serverless.dev.yml` if you don't have one already and set a
project id (this is required for Fleet's `cloud.isServerlessEnabled` to
correctly be `true`):
```yaml
xpack.cloud.serverless.project_id: test-123
```
In `kibana.devl.yml`, make sure the default Fleet server hosts and
default output have the expected ids:
```yaml
xpack.fleet.fleetServerHosts:
- id: default-fleet-server
name: Default Fleet server
is_default: true
host_urls: ['https://host.docker.internal:8220']
xpack.fleet.outputs:
- id: es-default-output
name: Default output
type: elasticsearch
is_default: true
is_default_monitoring: true
hosts: ['https://host.docker.internal:9200']
```
#### Requirements
- [ ] User can create proxy configurations in the Fleet UI and API.
- [ ] User can create new Fleet server host via the UI
- The Fleet Server Hosts dropdown is disabled and set to the default
host URL
- [ ] User can create new Fleet server host via the API
- The request should succeed if the host URL is set the the default one
- Otherwise the request should fail
- [ ] User can add a proxy config to the Fleet server host config
- [ ] User can select a custom Fleet Server host configuration from the
Agent policy settings page
- [ ] User can create new Fleet Elasticsearch output via the UI
- The Hosts dropdown is disabled and set to the default Elasticsearch
URL
- [ ] User can create new Fleet Elasticsearch output via the API
- The request should succeed if the host URL is set the the default one
- Otherwise the request should fail
- [ ] User can add a proxy config to the Elasticsearch output
- [ ] User can select a custom Elasticsearch output configuration from
the Agent policy settings page
- [ ] User can create a custom Logstash output with proxy
- [ ] User can create a custom Kafka output with proxy
### Checklist
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
### Screenshots
Fleet settings (proxies available):


Adding and editing a Fleet server host:


Adding and editing an Elasticsearch output:


---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Introduced the console.ui.embeddedEnabled (boolean) value to allow
disabling the embedded console in serverless security and observability
projects.
This also replaces an index management specific config value to do that
same thing which is removed here as well. Adding this console
configuration will allow us to have one value to set instead of N which
was the pattern I had started to use, but then decided against.
### Checklist
- [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
- [x] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- Rename `log_explorer` to `logs_explorer` and move it to an
`observability_solution` subfolder
- Rename `observability_log_explorer` to `observability_logs_explorer`
and move it to an `observability_solution` subfolder
- Use `renameFromRoot` to rename old configs
Related to https://github.com/elastic/kibana/issues/171991 and
https://github.com/elastic/kibana/pull/170759
This PR is mostly focused on renaming the plugins, follow ups will be
created to change mentions of `log explorer`, `logExplorer` etc.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani01@gmail.com>
Closes https://github.com/elastic/kibana/issues/175016
## Summary
This PR disables the Profiling integration in Infra and APM by default
on the plugin configuration level because this integration require users
to first configure the main `profiling` plugin. On-prem users will have
to manually enable both integrations once they enabled the Universal
Profiling for their hosts. Cloud users will have Infra and APM
integrations enabled by default because on Cloud instances Universal
Profiling is already configured. A PR for the default Cloud settings
will follow after this one is merged.
Changes I've made:
* Disabled the Infra integration be default
* Introduced a new APM feature flag for the Profiling integration
* Made sure all the places in APM that rely on Profiling integration
respect the new feature flag
* Fixed a bug in APM when Universal Profiling was shown even though the
integration was disabled in UI settings
65dfbb5b-1850-4d18-a92a-6ad59e0436a3
## How To Test
1. Checkout locally
2. Make sure you don't have `xpack.infra.featureFlags.profilingEnabled`
already enabled in `kibana.yml`
3. Open kibana and make sure you don't see "Universal Profiling" tab in
Host and Service details
4. Enabled both flags in `kibana.yml`:
`xpack.infra.featureFlags.profilingEnabled` and
`xpack.apm.featureFlags.profilingIntegrationAvailable: true`
5. Check that now you see "Universal Profiling" tab in the details
screens in both Infra and APM
6. Go to Infra settings view and disable the Profiling integration, make
sure the tab disappears
7. 6. Go to APM settings view and disable the Profiling integration,
make sure the tab disappears
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This adds a new "Universal Profiling" tab to asset details with a
flamegrapth for a selected host. The tab is behind a feature flag and is
disabled by default. It will be enabled by default for clound/onprem
once we implement Profiling empty state, serverless is tbd.
* Added two new endpoints for fetching profiling status (not used by the
FE yet) and flamegraph data.
* Added a `profilingEnabled` feature flag
* Added a new tab in the UI and integrated the Flamegraph embeddable

## How to test
* Connect local kibana to oblt cluster that has Profiling configured
(e.g. edge)
* Add this to your dev `kibana.yml`
```
xpack.profiling.enabled: true
xpack.infra.profilingEnabled: true
# Direct ES URL on the oblt cluster that you're using, in case of edge it's https://edge-oblt.es.us-west2.gcp.elastic-cloud.com:443
xpack.profiling.elasticsearch.hosts: REMOTE_CLUSTER_ES_URL
# If needed create a new user on the remote oblt cluster
xpack.profiling.elasticsearch.username: REMOTE_CLUSTER_USER
xpack.profiling.elasticsearch.password: REMOTE_CLUSTER_PASWORD
```
* Open kibana, go to Hosts
* Open a flyout for one of the hosts and make sure you see the Profiling
tab with a flamegraph
* Open Host details as a full page and also make sure you see the new
tab
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
Address https://github.com/elastic/kibana/issues/82002 and
https://github.com/elastic/kibana/issues/75440
I think I found a breakthrough for this flaky behavior. I run the
integration test 800x locally, with different settings:
Adjusting both the delayed emission (send 1 char at a time), and the
socket idle timeout to have exacly the same value (e.g. `10 millis`), I
managed to get the `ECONNRESET` 100% of the times.
Thus, IIUC the ECONNRESET happens when the client tries to send a
character over the socket and at the same time the server responds with
the idle timeout.
Adjusting the values so that the delay between character emissions is
significantly larger than the idle timeout, e.g. 20 vs 5, I get `socket
hang up` 100% of the times.
Flaky Test Runner Pipeline - 300x 🟢https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4030
## Summary
This PR removes the [duplicated RedirectAppLinks
component](https://github.com/elastic/kibana/blob/v8.10.4/src/plugins/kibana_react/public/app_links/redirect_app_link.tsx)
which has been marked as deprecated since
74a00fad20.
All references to the previous import declaration from
`@kbn/kibana-react-plugin/public` have been replaced with
`@kbn/shared-ux-link-redirect-app`, this change ensures that the current
app behaviour is preserved, and changes to match the expectation of the
new component have been applied where necessary.
Changes relating to the new `RedirectAppLinks` component;
- The component does not accept a `className` anymore as it is not a
presentational component despite it being used as one previously,
there's change to make accommodation for how it had been used.
- The component introduces a`data-test-subj` attribute with the value
`kbnRedirectAppLink` on the dom node that wraps it's children.
### Checklist
<!--
Delete any items that are not applicable to this PR.
~- [ ] 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]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
<!--
~- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard
accessibility](https://webaim.org/techniques/keyboard/))~
~- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))~
~- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)~
~- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))~
~- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)~
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/169339
## Summary
* Hides the "Alerts and rule" dropdown in the Infra header behind a
feature flag in serverless
* Moves serverless infra tests to the `index.feature_flags.ts` to
prevent failures on MKI

## How to test
* Run in serverless
* Make sure the Alerts and rules dropdown is not there anymore
* Run in stateful
* Make sure dropdown works as before
### Summary
Fix https://github.com/elastic/kibana/issues/166688
Implements dynamic contract resolving for plugins, allowing to retrieve
contracts after their respective lifecycle is completed, and therefore
working around cyclic dependencies.
In term of workflow execution, we're basically going from
<img width="842" alt="Screenshot 2023-09-27 at 08 09 27"
src="251637d1-ec97-4071-a445-2f59512ce187">
to:
<img width="1092" alt="Screenshot 2023-09-27 at 08 09 32"
src="de466cda-7e43-4fd3-81ec-4339d05d279d">
### API
This functionality is exposed by the now publicly exposed `plugins`
service contracts:
```ts
setup(core) {
core.plugins.onSetup<{pluginA: SetupContractA, pluginB: SetupContractA}>('pluginA', 'pluginB')
.then(({ pluginA, pluginB }) => {
if(pluginA.found && pluginB.found) {
// do something with pluginA.contract and pluginB.contract
}
});
}
```
```ts
start(core) {
core.plugins.onStart<{pluginA: StartContractA, pluginB: StartContractA}>('pluginA', 'pluginB')
.then(({ pluginA, pluginB }) => {
if(pluginA.found && pluginB.found) {
// do something with pluginA.contract and pluginB.contract
}
});
}
```
**remark:** the `setup` contract exposed both `onSetup` and `onStart`,
while the `start` contract only exposed `onStart`. The intent is to
avoid fully disrupting the concept of lifecycle stages.
### Guardrails
To prevent developer from abusing this new API, or at least to add some
visibility on its adoption, plugins can only perforn dynamic contract
resolving against dependencies explicitly defined in their manifest:
- any required dependencies (*existing concept*)
- any optional dependencies (*existing concept*)
- any runtime dependencies (**new concept**)
Runtime dependencies must be specified using the new
`runtimePluginDependencies` field of a plugin's manifest.
```json
{
"type": "plugin",
"id": "@kbn/some-id",
"owner": "@elastic/kibana-core",
"plugin": {
"id": "some-id",
"...": "...",
"runtimePluginDependencies" : ["someOtherPluginId"]
}
}
```
Using the contract resolving API will throw at call time when trying to
resolve the contract for an undeclared dependency.
E.g this would throw at invocation time (not returning a rejected
promise - throw).
```ts
setup(core) {
core.plugins.onSetup<{undeclaredDependency: SomeContract}>('undeclaredDependency');
}
```
The reasoning behind throwing is that these errors should only occur
during the development process, and an hard fail is way more visible
than a promise rejection that should be more easily shallowed.
### Code reviews
This PR defines @elastic/kibana-core as codeowner of all `kibana.jsonc`
files in the `src/plugins` and `x-pack/plugins` directories, so that a
code review will be triggered whenever anyone changes something in any
manifest. The intent is to be able to monitor new usages of the feature,
via the addition of entries in the `runtimePluginDependencies` option of
the manifest.
### Remarks
Exposing this API, and therefore making possible cyclic dependencies
between plugins, opens the door to other questions.
For instance, cross-plugin type imports are not technically possible at
the moment, given that plugins are referencing each others via TS refs,
and refs forbid cyclic dependencies. Which means that to leverage this
to address cyclic dependency issues, the public types of **at least one
of the two** plugins will have to be extracted to a shared place (likely
a package).
Resolving, or trying to improve the developer experience around this
issue, is absolutely out of scope of the current PR (and the issue it
addresses).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/167654
## Summary
This PR removes the Storage size column in Data stream in serverless as
the data stream stats API on serverless doesn't currently return the
storage size.
### How to test:
Verify that the column is not displayed in serverless:
1. Start Es with `yarn es serverless` and Kibana with `yarn
serverless-{es/oblt/security}`
2. Go to Stack Management -> Index Management -> Data Streams
3. Switch on the "Include stats" toggle
4. Verify that the "Storage size" column is not shown in the table.
Verify that the column is displayed in stateful:
1. Start Es with `yarn es snapshot` and Kibana with `yarn start`
2. Go to Stack Management -> Index Management -> Data Streams
3. Switch on the "Include stats" toggle
4. Verify that the "Storage size" column is shown in the table.
<!---
### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
-->
## Summary
Fixes https://github.com/elastic/kibana/issues/165895
This PR limits which index settings are displayed on the index details
page, "Settings" tab in the edit mode. On serverless only a handful of
index settings will be editable by the user. The UI only prevents
displaying some index settings, but it's still possible for the user to
type in a setting that can't be edited. That is the case on dedicated as
well.
### How to test
1. Start Serverless ES and Kibana
2. Navigate to Index Management and create a test index
3. Click on the index name and on the details page click the tab
"Settings"
4. Toggle the "Edit mode" switch and verify that only editable settings
are displayed.
#### Screenshot
<img width="527" alt="Screenshot 2023-10-16 at 20 25 49"
src="e6678cca-3494-4c63-ae66-ace9c823d12d">
Closes https://github.com/elastic/kibana/issues/164683
## Summary
This PR disables the infrastructure, metrics and logs alerts rule in
Serverless:
- Deletes the code responsible for the "Metric Anomaly" rule as it was
[previously disabled](https://github.com/elastic/kibana/pull/93813) with
plans to re-enable it as the previous PR describes but that never
happened.
- Adds feature flags for all three types of alert rules
- Prevents rules registration in serverless based on the feature flags
- Adds logic for showing/hiding items in the "Alerts and rules" dropdown
- Disables custom threshold rule in the Infra UI by default in
serverless as the rule needs to first be enabled by default by
@elastic/actionable-observability team
([context](https://elastic.slack.com/archives/C023GDA0WMP/p1696853751040269))
**Dropdown**

**Host details**

### How to test
- Checkout locally Run in Serveless mode
- Enable, Infra plugin, custom threshold in Infra, and custom threshold
rule in general:
```
xpack.infra.enabled: true
xpack.infra.featureFlags.customThresholdAlertsEnabled: true
xpack.observability.unsafe.thresholdRule.enabled: true
```
- Go to `/app/metrics/hosts` and make sure there are no "Infrastructure"
and "Metrics" items in the "Alerts and rules" dropdown
- Click on "Manage rules" in the "Alerts and rules" dropdown, then
"Create rule" to open the rule selection flyout
- Make sure there are no rules for "Inventory", "Metrics" or "Logs"
threshold
- Run Kibana in traditional mode
- Make sure the "Alerts and rules" dropdown looks as usual and you can
create "Infrastructure" and "Metrics" alerts
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR implements a standard way to have different static settings for
the serverless and ess (stateful) environments. It centralizes flags,
which were set using different approaches previously, in a single
configuration.
This aims to make it easier for developers to enable/disable parts of
the application in serverless projects.
Default:
```
sideNavEnabled: true,
ILMEnabled: true,
ESQLEnabled: true,
```
Serverless:
```
xpack.securitySolution.offeringSettings: {
sideNavEnabled: false, # Internal security side navigation disabled, the serverless global chrome navigation is used instead
ILMEnabled: false, # Index Lifecycle Management (ILM) functionalities disabled, not supported by serverless Elasticsearch
ESQLEnabled: false, # ES|QL disabled, not supported by serverless Elasticsearch
}
```
### Consume the settings
#### Server
- Plugin parsed `ConfigType`:
`this.config.settings.ESQLEnabled`
#### UI
- Plugin attribute:
`this.configSettings.ESQLEnabled`.
- Components can access it from Kibana services:
`useKibana().services.configSettings.ESQLEnabled;`
---------
Co-authored-by: Vitalii Dmyterko <92328789+vitaliidm@users.noreply.github.com>
closes https://github.com/elastic/kibana/issues/166977
## Summary
This PR creates a feature flag to disable logs UI features in
serverless.
_Serverless_
**Frontend routes**
<img width="1466" alt="image"
src="a856055b-f78b-4d47-b27e-678e19bdfae4">
`/logs/stream`
<img width="1714" alt="image"
src="83d50be2-ed3a-4441-b31c-1afe6f8fd0b9">
`/logs/log-categories`
<img width="1714" alt="image"
src="85cd369d-55b2-46a2-a61a-135c5f18e299">
`/logs/anomalies`
<img width="1714" alt="image"
src="d68e6f91-fe29-483f-931d-d05f4303effa">
**Server routes**
These will return 404
```
POST kbn://api/infra/log_analysis/results/log_entry_anomalies_datasets
POST kbn://api/infra/log_analysis/results/log_entry_anomalies
POST kbn://api/infra/log_analysis/results/log_entry_categories
POST kbn://api/infra/log_analysis/results/latest_log_entry_category_datasets_stats
POST kbn://api/infra/log_analysis/results/log_entry_category_datasets
POST kbn://api/infra/log_analysis/results/log_entry_category_examples
POST kbn://api/infra/log_analysis/results/log_entry_examples
POST kbn://api/infra/log_analysis/results/log_entry_datasets
POST kbn://api/infra/log_analysis/results/log_entry_rate_indices
POST kbn://api/infra/log_alerts/chart_preview_data
```
_Stateful_
<img width="1716" alt="image"
src="4406434f-78e4-437f-b3b5-1b03dc23f3c0">
**Server routes**
These will return 400 - currently there is no way to pass `version` via
dev tools
```
POST kbn://api/infra/log_analysis/results/log_entry_anomalies_datasets
POST kbn://api/infra/log_analysis/results/log_entry_anomalies
POST kbn://api/infra/log_analysis/results/log_entry_categories
POST kbn://api/infra/log_analysis/results/latest_log_entry_category_datasets_stats
POST kbn://api/infra/log_analysis/results/log_entry_category_datasets
POST kbn://api/infra/log_analysis/results/log_entry_category_examples
POST kbn://api/infra/log_analysis/results/log_entry_examples
POST kbn://api/infra/log_analysis/results/log_entry_datasets
POST kbn://api/infra/log_analysis/results/log_entry_rate_indices
POST kbn://api/infra/log_alerts/chart_preview_data
```
### How to test
### How to test
- Start a local es instance: `yarn es serverless --kill --clean
--license trial --ssl`
- Enable `infra` in the `serverless.oblt.dev.yml` file:
- `xpack.infra.enabled: true`
- Start a local kibana instance: `yarn serverless-oblt --ssl`
- Verify the items listed above both on serverless and stateful
Closes#167142Closes#157126
## Summary
Fortifies the rendering service tests by introducing a retry loop to get
injected metadata after navigation. The `kbn-injected-metadata` tag that
we're relying on in this test gets removed some time after navigation
(e.g. to `.../render/core`). It appears that occasionally this test
fails to read the tag before it is removed.
Flaky test runner:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3363
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/166612
## Summary
- Adds a `customThresholdAlertsEnabled` feature flag
- Based on the feature flag shows an additional menu item in the alerts
dropdown
- Adds flyout component for rendering the custom alerts flyout
**Serverless**
<video
src="4fc79427-1e0c-4692-8525-b3b35e8a04e9"
controls="controls"></video>
**Traditional**

## How to test
- Checkout locally and run in serverless mode (infra plugin on)
- Make sure you see the "Create custom threshold alert" menu item in the
"Alerts and rules" dropdown
- Click on the item and make sure you can create an alert
- Run Kibana in traditional mode and make sure the dropdown item is not
there
closes https://github.com/elastic/kibana/issues/163280
## Summary
Disables OSquery in serverless.
<img width="1670" alt="image"
src="0ece0503-a5f3-46a1-a99b-29285088526c">
<img width="1670" alt="image"
src="5d20aaa4-7bdc-47e5-b9c2-469ecf62ab1f">
<img width="1670" alt="image"
src="97874aee-be98-4f0a-984a-562abbd4187d">
Osquery is now only used in the Asset Details flyout/full-page view. The
header component in the Asset Details now checks the feature flag object
to show/hide the OSquery tab.
### How to test
- Start a local es instance: `yarn es serverless --kill --clean
--license trial --ssl`
- Enable `infra` in the `serverless.oblt.dev.yml` file:
- `xpack.infra.enabled: true`
- Start a local kibana instance: `yarn serverless-oblt --ssl` and see if
the side nav contains the Infrastructure item
- Navigate to `https://0.0.0.0:5601/ftw/app/metrics` and open the Asset
Details flyout from Inventory and Hosts View. Navigate to the details
view and check that Osquery tab isn't present.
- Confirm if OSquery tab is present in stateful.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>