## Summary
Refactor bulk delete monitor and params routes !!
We need to remove usage for body from DELETE route.
### Params
Params can be bulk delete now with POST request to
`/params/_bulk_delete` endpoint
### Monitors
Monitors can be bulk delete now with POST request to
`/monitors/_bulk_delete` endpoint
## Summary
Fixes https://github.com/elastic/kibana/issues/167781
In docs we says that only key/value pairs are required, but in actual
edit, that means rest of the data was being lost on edits
Allow partial updates to params edit API !!
This PR makes sure prev objects is fetched and merged with new data
hence allowing partial updates !!
We are also allowing the ability to view value of the secret once it's
saved via API !!
### Value is hidden
Param value will not be visible unless user is `super_user` or
`kibana_admin`, though user can assign new value.
---------
Co-authored-by: Justin Kambic <jk@elastic.co>
## Summary
Allow deletion of monitor via id param !!
User can now delete monitor via passing id as url param
`DELETE <kibana host>:<port>/api/synthetics/monitors/<config_id>`
Previous bulk delete via list of ids via API body still works as well !!
Docs are updated !!
## Summary
Passing default solution from cloud onboarding process.
1. Renaming. Solution changes are not released yet, would be shipped
with `8.15`, so it's fine to do it.
- `search` -> `es`
- `observability` -> `oblt`
- Adjusted telemetry accordingly
2. Added `cloud` as optional dependency to `spaces` plugin to use
`onboarding.defaultSolution` passed through setup contract.
### How to test
1. Set `xpack.cloud.onboarding.default_solution` to `es | oblt |
security`
2. Check that default space was created with provided solution `GET
kbn:/api/spaces/space/default`
### Checklist
- [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
### 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)
__Fixes: https://github.com/elastic/kibana/issues/184999__
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Added solution property for the space.
- Forbidden in serverless.
- To facilitate iterative development made the property as optional in
stateful offering until all of the workstreams are complete.
### How to test API changes
```
# Should create space
POST kbn:/api/spaces/space
{
"name": "space without solution",
"id": "my-space-solution-1",
"description": "a description",
"color": "#5c5959",
"disabledFeatures": []
}
# Should fail with 400
POST kbn:/api/spaces/space
{
"name": "space with solution",
"id": "my-space-solution-2",
"description": "a description",
"color": "#5c5959",
"solution": "some_solution",
"disabledFeatures": []
}
# Should fail with 400
POST kbn:/api/spaces/space
{
"name": "space with solution",
"id": "my-space-solution-2",
"description": "a description",
"color": "#5c5959",
"solution": null,
"disabledFeatures": []
}
# Should create space
POST kbn:/api/spaces/space
{
"name": "space with solution",
"id": "my-space-solution-2",
"description": "a description",
"color": "#5c5959",
"solution": "search",
"disabledFeatures": []
}
# Should get 'my-space-solution-1' space without solution field
GET kbn:/api/spaces/space/my-space-solution-1
# Should get 'my-space-solution-2' space with solution field
GET kbn:/api/spaces/space/my-space-solution-2
# Should fail to update with 400
PUT kbn:/api/spaces/space/my-space-solution-1
{
"id": "my-space-solution-1",
"name": "my-space-solution-1 name",
"solution": "some_solution"
}
# Should fail to update with 400
PUT kbn:/api/spaces/space/my-space-solution-1
{
"id": "my-space-solution-1",
"name": "my-space-solution-1 name",
"solution": null
}
# Should update 'my-space-solution-1'
PUT kbn:/api/spaces/space/my-space-solution-1
{
"id": "my-space-solution-1",
"name": "my-space-solution-1 name",
"solution": "security"
}
# Should get 'my-space-solution-1' space wit solution field set to 'security'
GET kbn:/api/spaces/space/my-space-solution-1
# Should return list where
# 1. 'my-space-solution-1' has solution 'security'
# 2. 'my-space-solution-2' has solution 'search'
# 3. Other spaces don't have solution field present
GET kbn:/api/spaces/space
```
### Checklist
- [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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed ([Security and Spaces
config](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6076),
[Spaces only
config](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6075))
### 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)
__Fixes: https://github.com/elastic/kibana/issues/183559__
## Release note
Added optional solution property for Space in a stateful offering.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/169547
View docs at [Changed
pages](https://kibana_169928.docs-preview.app.elstc.co/diff)
Add monitor api public api
### Testing
Make sure you have some monitors populated before testing this PR and
before switching to the branch
- [ ] Try editing already added monitors via API
- [ ] Test adding monitors via API, and then edit those via and
subsqeuently try editing via API the same monitor
- [ ] Test editing monitors via API
- [ ] Test deleting monitors via API
- [ ] Test getting monitors via API
- [ ] Testing private as well public locations
Basic workflow that i am interesting in testing is to make sure, you can
add/edit via both API and UI without any issues
Test each of HTTP/TCP/ICMP browser examples
<img width="1728" alt="image"
src="3575d93a-5f04-4c80-ac62-038643f466f8">
---------
Co-authored-by: Justin Kambic <jk@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
## Summary
Docs for the swap references api -
https://github.com/elastic/kibana/pull/163225
The docs are on the terse side - I think this makes sense since this is
a tool that should be used infrequently and only by people who use saved
object references.
---------
Co-authored-by: amyjtechwriter <61687663+amyjtechwriter@users.noreply.github.com>
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
Contributes to https://github.com/elastic/security-docs/issues/4536 by
documenting the new **Timeout** setting and `timeout` API parameter in
Osquery docs.
---------
Co-authored-by: nastasha.solomon <nastasha.solomon@elastic.co>
Co-authored-by: Benjamin Ironside Goldstein <91905639+benironside@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/150079
Add support for the `*` wildcard for by-type export, allowing to more
easily export all the exportable SO types
```
POST /api/saved_objects/_export
{
types: '*',
}
```
## Release Note
The savedObjects export API now supports exporting all types using the
`*` wildcard. Please refer to the documentation
for more details and examples.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes the documentation for the "update data view fields" API which used an incorrect route in the provided examples (data-view instead of data_view)
## Summary
Moves the response codes documented for the copy saved object API to the
correct document file.
Documentation was incorrectly located in
https://github.com/elastic/kibana/pull/158036
Fixes#155978
## Summary
- Remove the `fields` parameter from the find cases API
- Limit the `searchFields` parameter in the find cases API
One of the FTR tests was actually successfully calling the find_cases
API while passing the fields parameter but only certain combinations of
fields would actually work.
Passing single fields would not work.
I just removed the test as we won't support the `fields` param anymore.
---------
Co-authored-by: lcawl <lcawley@elastic.co>
Fixes https://github.com/elastic/kibana/issues/151938
In this PR, I'm re-writing the Task Manager poller so it doesn't run
concurrently when timeouts occur while also fixing the issue where
polling requests would pile up when polling takes time. To support this,
I've also made the following changes:
- Removed the observable monitor and the
`xpack.task_manager.max_poll_inactivity_cycles` setting
- Make the task store `search` and `updateByQuery` functions have no
retries. This prevents the request from retrying 5x whenever a timeout
occurs, causing each call taking up to 2 1/2 minutes before Kibana sees
the error (now down to 30s each). We have polling to manage retries in
these situations.
- Switch the task poller tests to use `sinon` for faking timers
- Removing the `assertStillInSetup` checks on plugin setup. Felt like a
maintenance burden that wasn't necessary to fix with my code changes.
The main code changes are within these files (to review thoroughly so
the polling cycle doesn't suddenly stop):
- x-pack/plugins/task_manager/server/polling/task_poller.ts
- x-pack/plugins/task_manager/server/polling_lifecycle.ts (easier to
review if you disregard whitespace `?w=1`)
## To verify
1. Tasks run normally (create a rule or something that goes through task
manager regularly).
2. When the update by query takes a while, the request is cancelled
after 30s or the time manually configured.
4. When the search for claimed tasks query takes a while, the request is
cancelled after 30s or the time manually configured.
**Tips:**
<details><summary>how to slowdown search for claimed task
queries</summary>
```
diff --git a/x-pack/plugins/task_manager/server/queries/task_claiming.ts b/x-pack/plugins/task_manager/server/queries/task_claiming.ts
index 07042650a37..2caefd63672 100644
--- a/x-pack/plugins/task_manager/server/queries/task_claiming.ts
+++ b/x-pack/plugins/task_manager/server/queries/task_claiming.ts
@@ -247,7 +247,7 @@ export class TaskClaiming {
taskTypes,
});
- const docs = tasksUpdated > 0 ? await this.sweepForClaimedTasks(taskTypes, size) : [];
+ const docs = await this.sweepForClaimedTasks(taskTypes, size);
this.emitEvents(docs.map((doc) => asTaskClaimEvent(doc.id, asOk(doc))));
@@ -346,6 +346,13 @@ export class TaskClaiming {
size,
sort: SortByRunAtAndRetryAt,
seq_no_primary_term: true,
+ aggs: {
+ delay: {
+ shard_delay: {
+ value: '40s',
+ },
+ },
+ },
});
return docs;
```
</details>
<details><summary>how to slow down update by queries</summary>
Not the cleanest way but you'll see occasional request timeouts from the
updateByQuery calls. I had more luck creating rules running every 1s.
```
diff --git a/x-pack/plugins/task_manager/server/task_store.ts b/x-pack/plugins/task_manager/server/task_store.ts
index a06ee7b918a..07aa81e5388 100644
--- a/x-pack/plugins/task_manager/server/task_store.ts
+++ b/x-pack/plugins/task_manager/server/task_store.ts
@@ -126,6 +126,7 @@ export class TaskStore {
// Timeouts are retried and make requests timeout after (requestTimeout * (1 + maxRetries))
// The poller doesn't need retry logic because it will try again at the next polling cycle
maxRetries: 0,
+ requestTimeout: 900,
});
}
@@ -458,6 +459,7 @@ export class TaskStore {
ignore_unavailable: true,
refresh: true,
conflicts: 'proceed',
+ requests_per_second: 1,
body: {
...opts,
max_docs,
```
</details>
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
