**Relates to:** https://github.com/elastic/kibana/issues/190035
## Summary
This PR sets proper teams ownership to Security Solution OpenAPI domain
bundles. It will help to avoid unnecessary code review dependencies and
allow teams to focus on OpenAPI domain changes.
## UPDATE
It has been removed the execution of the playwright tests on buildkite,
the execution will be re-enabled as soon as we are ready and as
described below in the PR, there are still steps pending to be done.
## Motivation
**Cypress is not performing well lately.**
* We have been facing significant performance issues with Cypress. For
instance, it takes a long time to open the visual interface and start
executing tests.
**Teams are finding it increasingly challenging to write new tests and
debug existing ones.**
* The time and effort required to create new tests or troubleshoot
existing ones have become burdensome.
**Concern about the impact this could have on our testing practices.**
* Lose motivation to write tests or, worse, skip writing crucial tests.
## Why Playwright?
* Compared to Cypress, Playwright seems to be known for its faster
execution times and lower resource consumption. What could have a
positive impact by having faster feedback during development and
execution of new tests as well as more efficient use of CI resources.
* Provides powerful debugging tools which can make easier to write,
debug and execute tests.
* Seems to provide the same capabilities we currently use in our Cypress
tests.
* Given Playwright's active development and backing by Microsoft, it is
likely to continue evolving rapidly, making it a safe long-term choice.
Considering all the above, Playwright seems to be a strong candidate to
replace Cypress and address all the issues we are facing lately
regarding UI test automation.
## Objective of this POC
To write in Playwright a couple of tests we currently have on Cypress to
check the performance of the tool as well as the development experience.
The tests selected have been:
-
[enable_risk_score_redirect.cy.ts](https://github.com/elastic/kibana/blob/main/x-pack/test/security_solution_cypress/cypress/e2e/entity_analytics/dashboards/enable_risk_score_redirect.cy.ts)
- Owned by Entity Analytics team and selected by its simplicity since it
does not need any special setup to be executed and is short.
-
[manual_rule_run.cy.ts](https://github.com/elastic/kibana/blob/main/x-pack/test/security_solution_cypress/cypress/e2e/detection_response/detection_engine/rule_gaps/manual_rule_run.cy.ts)
- Owned by Detection Engine team and selected because is short and adds
a bit more of complexity due to it needs of clean-up and setting up
initial data through the API.
## How to execute the tests
### Visual mode
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn open:ess` for ESS environment or `yarn open:serverless`
for serverless environment.
### Headless mode
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn run:ess` for ESS environment or `yarn run:serverless`
for serverless environment.
### From VScode
- Install `Playwright Test for VScode` extension by Microsoft
- Navigate to: `x-pack/test/security_solution_playwright`
- Execute: `yarn open:ess` for ESS environment or `yarn open:serverless`
for serverless environment.
- Open your IDE
- Click on the `Testing` icon
- On the `Test Explorer` click on the three dots to select the profile
you are going to execute `ess` or `serverless`
- Click on the test you want to execute or navigate to the spec file of
the test and execute it from the same spec.
## My experience
- Tests are way easier to implement than with Cypress.
- Playwright does not rely on chainable commands. Chainable commands on
Cypress can lead to confusing code.
- Without chainable commands, the flow of the tests is more explicit and
easier to understand.
- You can notice that the tool has been designed with Typescript in
mind.
- Is super easy to implement the Page Object Model pattern (POM).
- With POM the test code is clean and focused on "what" rather than
"how".
- Love the fact that you can execute the tests from the same IDE without
having to switch windows during test development.
- The visual mode execution gives you lots of information out of the
box.
## The scope of this PR
- Sets the initial infrastructure to write and execute tests with
Playwright.
- Has examples and set a basis about how to write tests using the POM.
- Allows the execution of the tests in ESS and serverless (just
stateless environment).
- Integrates the execution of the tests with buildkite.
## Pending to be done/investigate
- Proper readme
- How to split tests and PO between the different teams
- Good reports on CI
- Upload screenshots on CI
- Flaky test suite runner
- Complete the labeling
- Execution of the tests on MKI environments
## FAQ
**Can I start adding tests to playwright?**
Currently, you can explore and experiment with Playwright, but there is
still work pending to be done to make the tool officially usable.
**Why security engineering productivity is the owner of the playwright
folder?**
This is something temporary to make sure that good practices are
followed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: dkirchan <diamantis.kirchantzoglou@elastic.co>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Jon <jon@budzenski.me>
The previous https://github.com/elastic/kibana/pull/190105 was way too
big and made it hard to review without missing any bugs or potential
bugs, Thus we decided we are going to make series of smaller PR to make
things more manageable
We will be splitting it into 4 PR
Phase 1: Creating empty packages for csp and csp-common
Phase 2: Move Types from CSP plugin to the Package + Deleting duplicates
in the CSP plugin where possible
Phase 3: Move Functions, Utils or Helpers, Hooks to Package
Phase 4: Misconfiguration Preview feature (with Cypress test and other
required test)
<img width="681" alt="353329193-5ad22c4e-81c2-4a8b-89f7-fdbc2a686c2d"
src="https://github.com/user-attachments/assets/b369625a-efc5-4292-a690-2c5dffb5483d">
This is Phase 4 of the Process,
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Add the `gemini` model adapter for the `inference` plugin. Had to
perform minor changes on the associated connector
Also update the codeowner files to add the `@elastic/appex-ai-infra`
team as (one of the) owner of the genAI connectors
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Adds a `@kbn/observability-utils` package.
```md
# @kbn/observability-utils
This package contains utilities for Observability plugins. It's a separate package
to get out of dependency hell. You can put anything in here that is stateless and
has no dependency on other plugins (either directly or via other packages).
The utility functions should be used via direct imports to minimize impact on
bundle size and limit the risk on importing browser code to the server and vice versa.
```
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR extracts the kibana privilege component into a package, to
support the work that's been done to integrate role privilege selection
within the newly improved spaces administration app, and is the last in
the series of PR to make this possible. Without this undertaken we would
be creating cyclic dependency between the security and spaces plugin,
the image below provides a visual representation on how this PR resolves
the aforementioned issue;
[^legend]
[^legend]: item marked in blue is the package created in this PR.
This particular component, alongside the components that it's composed
of will now be housed in `@kbn/security-ui-components` (P.S. I'm not too
entirely sure about the naming, suggestions welcome).
<!--
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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>
>[!Note]
> This Change is only applicable to Serverless Security Solution as of
now. In follow-up PRs, support will be added to ESS as well based
data-sources such as index or intergrations.
## Summary
Resolves https://github.com/elastic/kibana/issues/189151
This PR is foundation for the work described in
https://github.com/elastic/kibana/issues/186783. This just enables
expandable flyout for entity details, which is currently only used in
security solution, in discover as well.
As a part of **One Discover** work, we need to make sure that cell
rendering in Discover should behave exactly like it does in security
solution.
To enable this, a new `shared-browser` package
`@kbn/security-solution-common` in `x-pack/packages/security-solution`
has been created which can used to share components between `security
solution` and `discover`. Below is the usage pattern
```mermaid
flowchart TD
disc-utils[@kbn/discover-utils] --> sscommon
sscommon[@kbn/security-solution-common] --> ssplugin[security_solution]
sscommon[@kbn/security-solution-common] --> discover[discover]
disc-utils[@kbn/discover-utils] --> discover
```
## Desk Testing Guide.
1. Enable Security profile in serverless by adding below to `kibana.yml`
```yaml
discover.experimental.enabledProfiles: ['security-root-profile']
```
2. Load Some data
4. Navigate to discover and add `host.name` as one of the column.
5. Should open an expandable flyout as shown below.
https://github.com/user-attachments/assets/92b84c89-8769-45dd-bf7e-a9fe527fdcf0
## Code Review Guide
Most of the changes in the PR are code-organization. There are NO
changes in security solution but only the changes to import statements.
You can focus regarding the changes in below packages:
- x-pack/packages/security-solution/common
- packages/kbn-discover-utils
- packages/kbn-expandable-flyout
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Closeselastic/kibana-operations#101
This PR adds a [Dev Container](https://containers.dev/) to utilize for
Kibana local development in an isolated environment. The original
intention was to create a local environment for FIPS development because
setting up Kibana in FIPS mode is complicated and has the potential to
break the user's OS. However, it has been altered to allow for general
development if an engineer chooses as well. The idea is for this be a
cost efficient replacement for
[kibana-remote-dev](https://github.com/elastic/kibana-remote-dev)
eventually.
### Testing
- In VS Code you should be able to use the `Dev Containers: Clone GitHub
Pull Request in Named Container Volume...` command from the Command
Palette (F1) to easily test this PR.
- See the
[docs](bd125fc230/dev_docs/getting_started/setting_up_a_development_env.mdx (using-the-kibana-dev-container-optional))
for additional information on setting up the Dev Container.
### Bazel
I tried many different solutions to copy the local Bazel cache into the
container to speed up bootstrap, but it either would break Bazel or
didn't provide any meaningful boost in performance. I opted to forgo
keeping it in this PR due to the complexity and since we're planning to
phase out Bazel in the future anyways.
## Summary
This PR
[seals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/seal)
`Object.prototype`, `String.prototype`, `Number.prototype`, and
`Function.prototype` on the Kibana server, which provides some measure
of protection against prototype pollution.
<details>
<summary>The Object.seal() static method seals an object.</summary>
**note** I currently have this marked as `backport:skip` to reduce the
risk of regressions in patch releases.
> The Object.seal() static method seals an object. Sealing an object
[prevents
extensions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)
and makes existing properties non-configurable. A sealed object has a
fixed set of properties: new properties cannot be added, existing
properties cannot be removed, their enumerability and configurability
cannot be changed, and its prototype cannot be re-assigned. Values of
existing properties can still be changed as long as they are writable.
seal() returns the same object that was passed in.
</details>
-----
## Help, this broke something!
Please let us know by opening an issue. If you need to get your
environment up and running quickly, you can disable these protections by
setting the `KBN_UNSAFE_DISABLE_PROTOTYPE_HARDENING` environment
variable to any truthy value.
This may be interfering with normal functionality if you encounter an
error similar to:
> Cannot add property foo, object is not extensible
Where `foo` is some arbitrary string.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR is the final step needed for us to re-enable pointer compression
on serverless.
It introduces a cli later used in a CI check that will prevent the
addition of new native modules on production as discussed and agreed
with Luke and Brandon previously.
It also removes the usages of `cbor-x` and replaces those with a
wrapping package `@kbn/cbor` which relies on the implementation coming
from `borc` with no native modules involved.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Since the Search team wrote this API and has the most context into the
feature, we are transferring ownership from the AppEx Management team to
Search.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Elena Stoeva <59341489+ElenaStoeva@users.noreply.github.com>
## Summary
Scaffolding empty plugin for development of day 0 onboarding work. This
plugin is currently disabled by default and will be enabled for ES3 when
it's ready for users.
## Summary
This PR moves code that is usually impacted by a Puppeteer/Chromium
upgrade to a package. The same work is happening to a lesser degree in
the 7.17 branch. Together, these changes will ease the manual labor of
backporting the upgrades from main to 7.17.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is a precursor to https://github.com/elastic/kibana/pull/189871,
as part of the spaces improvement initiative there's a need to be able
to share the user privilege assignment component between the roles
experience and the new spaces experience to prevent duplication of
business logic and cohesiveness in the privilege assignment experience.
The aforementioned PR extracts the required component into it's own
package so it might be consumed as needed, this PR is particularly
concerned with extracting business logic said UI component depends on
that exists still within the security plugin. For context; the security
plugin already depends on the spaces plugin, so having the spaces plugin
in turn statically depend on the security plugin creates a cyclic
dependency. That being said to complement the eventual state of said
component so it might be imported elsewhere outside of the security
plugin there's a need to extract further logic into standalone packages,
so that the spaces plugin can consume this plugin without the afore
mentioned cyclic dependency problem.
#### Visually;
##### Problem;
##### Proposal
[^legend]
[^legend]: items marked in blue are the packages created in this PR,
whilst the entire diagram is the proposed future state
<!--### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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>
## Summary
Change the ownership from `@elastic/kibana-core` to
`@elastic/appex-ai-infra`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
close https://github.com/elastic/kibana/issues/183687
## Feature
- Implement dashboard view stats UI on top of usage counter that counts
dashboard views for last 90 day and shows weekly histogram.
- (Even if there is not a lot of data, we still show it as a weekly
histogram, so it can be pretty empty intially)
## Implementation
### Server side
Dashboard plugin registers new routes to increase the view count and get
stats. Routes are protected for users with dashboard access only. The
implementation is located in
`@kbn/content-management-content-insights-server` and internally uses
usage counters. The retention is 90 days, so we can only show stats for
last 90 days.
### Client side
- Dashboard uses the client from
`@kbn/content-management-content-insights-public` to increase the view
count every time a user opens a dashboard.
- TableListView opens the flyout from
`@kbn/content-management-content-insights-public`to display the stats
## How to test
- For new views just open a dashboard and check that view stat is
increased
- For old views you can populate the usage counters with historic data.
I used the following script:
https://gist.github.com/Dosant/425042fcf75d5e40e5a46374f6234a54
Addresses https://github.com/elastic/kibana/issues/179549
Relates to https://github.com/elastic/kibana/pull/183113
## Update
Since the Appex QA team has taken on deployment agnostic tests, a lot of
the original implementation of this PR has changed. Now that the Appex
QA team has provided a current directly to write deployment agnostic
tests, the burn rate rule tests have been moved here.
To finish onboarding the burn rate rule test to this new framework, the
following was done.
1. Add an `oblt.stateful.config.ts` file to complement the existing
`oblt.serverless.config.ts` file to ensure the tests are run in CI
2. Ensure our test config is added to the buildkite pipepline
3. Add the alerting service to the new `deployment_agnostic/services`
directory.
4. Port the tests over to the new `deployment_agnostic` directory
To run serverless
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="Burn rate rule"
```
To run stateful
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="Burn rate rule"
```
For context, I've kept the history from the original PR description
below.
## 🍒 History
A new type of config file will be allowed for API integration and
functional tests within the `x-pack/test` folder, using a pattern of
`*.serverless.config.ts` — these config files will specify configuration
needed to run a set of tests in a serverless deployment context.
FTR tests already make use of the `it.tags(['my-tag-1', 'my-tag-2'])`
pattern, and so we would like to stay with that pattern rather than
introducing a new type of mocha tag in the it block's "description" as
it was introduced in this
[POC](https://github.com/elastic/kibana/pull/183113). The difference
with the previous PR in terms of tagging is that we use `suiteTags`
instead of `mochaOps`
Adding following in the config files:
**serverless config**
```
suiteTags: {
include: ['serverless'],
},
```
**ess config**
```
suiteTags: {
include: ['ess'],
},
```
and then adding `this.tags(['serverless', 'ess'])` in the test suite
instructs the test runner to run the same test suite in both
environments.
In order to keep things simple, we stay with the current skip approach,
which means that flaky tests will be skipped for all environments by
appending .skip() to the suite or to specific test cases.
## Description
- This PR uses `suiteTags` for tagging the tests appropriately. We
decide through following labels in which environment the tests are going
to be executed:
- **@ess**: Runs in an ESS environment (on-prem installation) as part of
the CI validation on PRs.
- **@serverless**: Runs in a serverless environment.
- It introduces a new folder
`x-pack/test/observability_solution_api_integration` which will serve as
a centralized location for all tests by obs-ux-management team that must
be run in Serverless and ESS environments. A list of all tests can be
found in the R&D
[issue](https://github.com/elastic/kibana/issues/179549)
- Within this folder, there is a "**config**" subdirectory that stores
base configurations specific to both the Serverless and ESS
environments. These configurations build upon the base configuration
provided by test_serverless and api_integration, incorporating
additional settings such as environment variables and tagging options.
- The file
`x-pack/test/observability_solution_api_integration/test_suites/alerting/burn_rate/burn_rate_rule.ts`
is functional in both Serverless and ESS
- It removes the existing burn rate rule from
`x-pack/test_serverless/api_integration/test_suites/observability/alerting/burn_rate/burn_rate_rule.ts`
- The `alertingApi` and `sloApi` services are moved to
`test/api_integration` servers
In the screenshot below you can see the `test_suites` folder structure,
after having migrated the current slo burn rate rule. We recommend
having an `alerting` and `slo` subfolders. Rest observability apps could
be added as another subfolder under test_suites. As part of this PR, the
`alerting > burn_rate` subfolders are created.
<img width="376" alt="Screenshot 2024-05-13 at 09 21 28"
src="3ccaf0a5-1443-4bad-ad06-daa347488bf1">
## How to run locally
You can navigate into the new `observability_solution_api_integration`
folder and use following commands to run the tests in serverless and ess
environments accordingly. You can find more information in the README
file of the observability_solution_api_integration folder.
```
cd x-pack/test/observability_solution_api_integration
// SERVERLESS
npm run alerting_burn_rate:server:serverless
npm run alerting_burn_rate🏃serverless
// ESS
npm run alerting_burn_rate:server:ess
npm run alerting_burn_rate🏃ess
```
## CI
- It includes a new entry in the `ftr_configs.yml` to execute the newly
added tests in the pipeline.
- It involves the addition of `suiteTags` in both
serverless/config.base.ts and ess/config.base.ts. In the case of
serverless, it includes **@serverless** while excluding
**@skipInServerless**. Similarly, for ess, it includes **@ess** and
excludes **@skipInEss**.
## Quality Gates and MKI pipeline
The Platform team will support config files within `x-pack/test` folder
with a pattern of `*.serverless.config.ts`, so these tests will be
included in Kibana's Quality gates and will be run against a real MKI
environment.
---------
Co-authored-by: Dominique Belcher <dominique.clarke@elastic.co>
Co-authored-by: Dominique Clarke <doclarke71@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Bundled package PR's will be auto-approved + auto-merged now, but this
can't happen while Fleet is a required reviewer on the
`fleet_packages.json` file via CODEOWNERS. This PR removes Fleet as an
owner of that file and allows the automation to take over completely.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Addresses https://github.com/elastic/kibana/issues/56406
## Summary
This PR is part of my June 2024 On-week project. It adds functionality
for persisting table page size (rows per page) and sorting in EUI
tables. When a user changes the size or sort, the new values are saved
in local storage, so that when the user navigates out of the page and
comes back, the page size and sort will be the same.
In this PR, the functionality is added to the following tables:
- Ingest Pipelines
- Index Management - all tables (indices, data streams, index templates,
component templates, enrich policies)
- ILM policies
08b0c004-65a1-4a58-b8fb-99010e1c3248
<!--
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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>
## Summary
The previous [PR ](https://github.com/elastic/kibana/pull/190105) was
way too big and made it hard to review without missing any bugs or
potential bugs, Thus we decided we are going to make series of smaller
PR to make things more manageable
We will be splitting it into 4 PR
Phase 1: Creating empty packages for csp and csp-common
Phase 2: Move Types from CSP plugin to the Package + Deleting duplicates
in the CSP plugin where possible
Phase 3: Move Functions, Utils or Helpers, Hooks to Package
Phase 4: Misconfiguration Preview feature (with Cypress test and other
required test)
This is Phase 1 of the initiative
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Update built in definitions on plugin start. The update overwrites index
templates and ingest pipelines with the latest versions but has to
delete the transforms since we can only update a subset of settings in
the [update
api](https://www.elastic.co/guide/en/elasticsearch/reference/current/update-transform.html)
which does not include the aggregations.
## Testing
### api tests
Since the upgrade logic happens in plugin startup method we cannot
directly trigger it from api tests without some tweaks. I've added a
[fixture
plugin](a87ae8b210/x-pack/test/api_integration/apis/entity_manager/fixture_plugin/server/plugin.ts)
that is launched in the entity manager test server, this plugin creates
a test route exposing the upgrade api which can then be called in api
tests.
### manual
- install builtin definitions `PUT
kbn:/internal/api/entities/managed/enablement`
- bump builtin [service
definition](https://github.com/elastic/kibana/blob/main/x-pack/plugins/observability_solution/entity_manager/server/lib/entities/built_in/services.ts#L23)
version
- restart kibana server
- logs should output `[INFO ][plugins.entityManager] Updating built-in
entity definition [builtin_services] from v0.1.0 to v<new version>`
- `GET kbn:/internal/api/entities/definition` should output the new
definition
- verify latest version of definition components are installed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
During the sync with kibana-security we agreed to disable custom server
arguments override to guarantee all the deployment-agnostic FTR configs
can be executed in MKI/Cloud: FTR cannot apply custom arguments on
MKI/Cloud and having any customisations most likely will break the tests
running there.
Adding possibility to override FTR services, since each team might have
their own ones.
It does not affect feature flags testing capability, since for that we
will use API calls to Kibana server and it will be supported on MKI (at
least QA env)
---------
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
### Summary
This PR adds the `createRepositoryClient` function, which takes the type
of a server route repository as a generic argument and creates a wrapper
around `core.http` that is type bound by the routes defined in the
repository, as well as their request param types and return types.
This function was extracted from the code that exists in the AI
Assistant plugin.
Other changes include:
* Adding usage documentation
* Creation of a new package `@kbn/server-route-repository-client` to
house `createRepositoryClient` so it can be safely imported in browser
side code
* Moving the types from ``@kbn/server-route-repository` to
``@kbn/server-route-repository-utils` in order to use them in both the
server and browser side
* Add some default types to the generics for `createServerRouteFactory`
(`createRepositoryClient` also has default types)
* Allow `registerRoutes` to take a generic to constrain the shape of
`dependencies` so that the type used when calling
`createServerRouteFactory` can be used in both places
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
### This PR introduces a new type of API integration tests in FTR:
deployment-agnostic
#### Test suite is considered deployment-agnostic when it fulfils the
following criteria:
**Functionality**: It tests Kibana APIs that are **logically identical
in both stateful and serverless environments** for the same SAML roles.
**Design**: The test design is **clean and does not require additional
logic** to execute in either stateful or serverless environments.
### How It Works
Most existing stateful tests use basic authentication for API testing.
In contrast, serverless tests use SAML authentication with
project-specific role mapping.
Since stateful deployments also support SAML, deployment-agnostic tests
**configure Elasticsearch and Kibana with SAML authentication in both
cases**. For roles, stateful deployments define 'viewer', 'editor', and
'admin' roles with serverless-alike privileges.
New `samlAuth` service has `AuthProvider` interface with 2 different
implementations: depending on environment context (serverless or
stateful) appropriate implementation is used. But it remains on service
level and hidden in test suite.
test example
```
export default function ({ getService }: DeploymentAgnosticFtrProviderContext) {
const samlAuth = getService('samlAuth');
const supertestWithoutAuth = getService('supertestWithoutAuth');
let roleAuthc: RoleCredentials;
let internalHeaders: InternalRequestHeader;
describe('GET /api/console/api_server', () => {
before(async () => {
roleAuthc = await samlAuth.createM2mApiKeyWithRoleScope('admin');
internalHeaders = samlAuth.getInternalRequestHeader();
});
after(async () => {
await samlAuth.invalidateM2mApiKeyWithRoleScope(roleAuthc);
});
it('returns autocomplete definitions', async () => {
const { body } = await supertestWithoutAuth
.get('/api/console/api_server')
.set(roleAuthc.apiKeyHeader)
.set(internalHeaders)
.set('kbn-xsrf', 'true')
.expect(200);
expect(body.es).to.be.ok();
const {
es: { name, globals, endpoints },
} = body;
expect(name).to.be.ok();
expect(Object.keys(globals).length).to.be.above(0);
expect(Object.keys(endpoints).length).to.be.above(0);
});
});
}
```
Please read
[readme](966822ac87/x-pack/test/api_integration/deployment_agnostic/README.md)
for more details and step-by-step guide. It should help migrating
existing serverless tests to deployment-agnostic, assuming requirements
are met.
### Examples
Deployment-agnostic tests:
```
x-pack/test/api_integration/deployment_agnostic/apis/console/spec_definitions.ts
x-pack/test/api_integration/deployment_agnostic/apis/core/compression.ts
x-pack/test/api_integration/deployment_agnostic/apis/painless_lab/painless_lab.ts
```
Configs to run it:
```
node scripts/functional_tests --config x-pack/test/api_integration/deployment_agnostic/oblt.serverless.config.ts
node scripts/functional_tests --config x-pack/test/api_integration/deployment_agnostic/search.serverless.config.ts
node scripts/functional_tests --config x-pack/test/api_integration/deployment_agnostic/security.serverless.config.ts
node scripts/functional_tests --config x-pack/test/api_integration/deployment_agnostic/stateful.config.ts
```
PR is a compact version of #188737 with reduced changes in existing
serverless tests.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: elena-shostak <165678770+elena-shostak@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
This PR introduces an Inference plugin.
## Goals
- Provide a single place for all interactions with large language models
and other generative AI adjacent tasks.
- Abstract away differences between different LLM providers like OpenAI,
Bedrock and Gemini
- Host commonly used LLM-based tasks like generating ES|QL from natural
language and knowledge base recall.
- Allow us to move gradually to the _inference endpoint without
disrupting engineers.
## Architecture and examples
## Terminology
The following concepts are referenced throughout this POC:
- **chat completion**: the process in which the LLM generates the next
message in the conversation. This is sometimes referred to as inference,
text completion, text generation or content generation.
- **tasks**: higher level tasks that, based on its input, use the LLM in
conjunction with other services like Elasticsearch to achieve a result.
The example in this POC is natural language to ES|QL.
- **tools**: a set of tools that the LLM can choose to use when
generating the next message. In essence, it allows the consumer of the
API to define a schema for structured output instead of plain text, and
having the LLM select the most appropriate one.
- **tool call**: when the LLM has chosen a tool (schema) to use for its
output, and returns a document that matches the schema, this is referred
to as a tool call.
## Usage examples
```ts
class MyPlugin {
setup(coreSetup, pluginsSetup) {
const router = coreSetup.http.createRouter();
router.post(
{
path: '/internal/my_plugin/do_something',
validate: {
body: schema.object({
connectorId: schema.string(),
}),
},
},
async (context, request, response) => {
const [coreStart, pluginsStart] = await coreSetup.getStartServices();
const inferenceClient = pluginsSetup.inference.getClient({ request });
const chatComplete$ = inferenceClient.chatComplete({
connectorId: request.body.connectorId,
system: `Here is my system message`,
messages: [
{
role: MessageRole.User,
content: 'Do something',
},
],
});
const message = await lastValueFrom(
chatComplete$.pipe(withoutTokenCountEvents(), withoutChunkEvents())
);
return response.ok({
body: {
message,
},
});
}
);
}
}
```
## Implementation
The bulk of the work here is implementing a `chatComplete` API. Here's
what it does:
- Formats the request for the specific LLM that is being called (all
have different API specifications).
- Executes the specified connector with the formatted request.
- Creates and returns an Observable, and starts reading from the stream.
- Every event in the stream is normalized to a format that is close to
(but not exactly the same) as OpenAI's format, and emitted as a value
from the Observable.
- When the stream ends, the individual events (chunks) are concatenated
into a single message.
- If the LLM has called any tools, the tool call is validated according
to its schema.
- After emitting the message, the Observable completes
There's also a thin wrapper around this API, which is called the
`output` API. It simplifies a few things:
- It doesn't require a conversation (list of messages), a simple `input`
string suffices.
- You can define a schema for the output of the LLM.
- It drops the token count events that are emitted
- It simplifies the event format (update & complete)
### Observable event streams
These APIs, both on the client and the server, return Observables that
emit events. When converting the Observable into a stream, the following
things happen:
- Errors are caught and serialized as events sent over the stream (after
an error, the stream ends).
- The response stream outputs data as [server-sent
events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events)
- The client that reads the stream, parses the event source as an
Observable, and if it encounters a serialized error, it deserializes it
and throws an error in the Observable.
### Errors
All known errors are instances, and not extensions, from the
`InferenceTaskError` base class, which has a `code`, a `message`, and
`meta` information about the error. This allows us to serialize and
deserialize errors over the wire without a complicated factory pattern.
### Tools
Tools are defined as a record, with a `description` and optionally a
`schema`. The reason why it's a record is because of type-safety. This
allows us to have fully typed tool calls (e.g. when the name of the tool
being called is `x`, its arguments are typed as the schema of `x`).
## Notes for reviewers
- I've only added one reference implementation for a connector adapter,
which is OpenAI. Adding more would create noise in the PR, but I can add
them as well. Bedrock would need simulated function calling, which I
would also expect to be handled by this plugin.
- Similarly, the natural language to ES|QL task just creates dummy
steps, as moving the entire implementation would mean 1000s of
additional LOC due to it needing the documentation, for instance.
- Observables over promises/iterators: Observables are a well-defined
and widely-adopted solution for async programming. Promises are not
suitable for streamed/chunked responses because there are no
intermediate values. Async iterators are not widely adopted for Kibana
engineers.
- JSON Schema over Zod: I've tried using Zod, because I like its
ergonomics over plain JSON Schema, but we need to convert it to JSON
Schema at some point, which is a lossy conversion, creating a risk of
using features that we cannot convert to JSON Schema. Additionally,
tools for converting Zod to and [from JSON Schema are not always
suitable
](https://github.com/StefanTerdell/json-schema-to-zod#use-at-runtime).
I've implemented my own JSON Schema to type definition, as
[json-schema-to-ts](https://github.com/ThomasAribart/json-schema-to-ts)
is very slow.
- There's no option for raw input or output. There could be, but it
would defeat the purpose of the normalization that the `chatComplete`
API handles. At that point it might be better to use the connector
directly.
- That also means that for LangChain, something would be needed to
convert the Observable into an async iterator that returns
OpenAI-compatible output. This is doable, although it would be nice if
we could just use the output from the OpenAI API in that case.
- I have not made room for any vendor-specific parameters in the
`chatComplete` API. We might need it, but hopefully not.
- I think type safety is critical here, so there is some TypeScript
voodoo in some places to make that happen.
- `system` is not a message in the conversation, but a separate
property. Given the semantics of a system message (there can only be
one, and only at the beginning of the conversation), I think it's easier
to make it a top-level property than a message type.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR changes the CODEOWNERS from `obs-knowledge-team` to
`obs-entities` for `x-pack/packages/kbn-entities-schema` and
`x-pack/plugins/observability_solution/entity_manager`
Co-authored-by: Søren Louv-Jansen <soren.louv@elastic.co>
The EBT pacakge has been moved to a separate NPM package
([@elastic/ebt](https://www.npmjs.com/package/@elastic/ebt))
The npm package is on version `0.0.x` until we finish the reviews then
i'll publish the `1.0.0` version before merging this PR.
The PR is mostly code deletes after moving the code to the public ebt
github repo https://github.com/elastic/ebt
The significant changes are:
1. removed the `packages/analytics/ebt` package from kibana
2. remove @kbn/ebt references in favor of the npm package.
3. Added a util package to provide the package with the telemetry
endpoint and headers
This was previously backed into the package but now i've rewired it be
provided from Kibana, this way we have more control over the URL and
headers we use to send EBT telemetry for our elastic endpoint, which
will probably be different between users of this package and this way
we'll also avoid republishing the package if we ever want to change
these details.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Alejandro Fernández Haro <afharo@gmail.com>
## Summary
I noticed `elastic/appex-qa` is pinged for quite many PRs.
with #188606 some test folders became packages with `"owner":
"@elastic/appex-qa",`, that autmatically updated CODEOWNERS file with
appex-qa listed for basically every test path.
https://github.com/elastic/kibana/pull/188606/files#diff-3d36a1bf06148bc6ba1ce2ed3d19de32ea708d955fed212c0d27c536f0bd4da7R878-R881
This PR removes `owner` for the following test "packages"
- x-pack/test_serverless
- test
- x-pack/test
and CODEOWNERS file keeps these paths without specific owner.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
The ML team should be a code owner of the file upload plugin.
This [PR](https://github.com/elastic/kibana/pull/148130) removed them by
accident while removing duplicate entries.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
At the moment, our package generator creates all packages with the type
`shared-common`. This means that we cannot enforce boundaries between
server-side-only code and the browser, and vice-versa.
- [x] I started fixing `packages/core/*`
- [x] It took me to fixing `src/core/` type to be identified by the
`plugin` pattern (`public` and `server` directories) vs. a package
(either common, or single-scoped)
- [x] Unsurprisingly, this extended to packages importing core packages
hitting the boundaries eslint rules. And other packages importing the
latter.
- [x] Also a bunch of `common` logic that shouldn't be so _common_ 🙃
### For maintainers
- [x] 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>
Related to #183220
## Summary
This PR extracts `getEcsGroups` to a package to save ECS groups in the
Alert As Data (AAD) document for the metric threshold rule.
### 🧪 How to test
- Create a metric threshold rule with multiple groups (both ECS and
non-ECS fields)
- Check the related AAD document; you should be able to see the ECS
fields at the root level and not see non-ECS fields there
- Check the same information for the recovered alerts
- Rules without group by should work as before
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
The knowledge team is a codeowner of the other data access plugins and
should be on Logs.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## FTR tests for manual rule run:
For all rule types we cover
- that manual rule run can generate alerts
- that it not create duplicates (except case for threshold and esql)
- that suppression work per execution (except trhreshold)
- that suppression work per time period
For IM rule also covered that `threat_query `not affected by manual rule
run range
Also covered several common cases, but tests are created only for custom
query rule:
- disabling rule, after manual rule run execution started, not affecting
manual run executions
- changing name of the rule after manual rule run started, not affecting
alert generated by manual rule run executions
related:
https://github.com/elastic/security-team/issues/9826#issue-2379978026
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
