You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For local development and CI, Kibana, by default, uses Elasticsearch snapshots that are built daily when running tasks that require Elasticsearch (e.g. functional tests).
5
+
6
+
A snapshot is just a group of tarballs, one for each supported distribution/architecture/os of Elasticsearch, and a JSON-based manifest file containing metadata about the distributions.
7
+
8
+
https://ci.kibana.dev/es-snapshots[A dashboard] is available that shows the current status and compatibility of the latest Elasticsearch snapshots.
9
+
10
+
==== Process Overview
11
+
12
+
1. Elasticsearch snapshots are built for each current tracked branch of Kibana.
13
+
2. Each snapshot is uploaded to a public Google Cloud Storage bucket, `kibana-ci-es-snapshots-daily`.
14
+
** At this point, the snapshot is not automatically used in CI or local development. It needs to be tested/verified first.
15
+
3. Each snapshot is tested with the latest commit of the corresponding Kibana branch, using the full CI suite.
16
+
4. After CI
17
+
** If the snapshot passes, it is promoted and automatically used in CI and local development.
18
+
** If the snapshot fails, the issue must be investigated and resolved. A new incompatibility may exist between Elasticsearch and Kibana.
19
+
20
+
==== Using the latest snapshot
21
+
22
+
When developing locally, you may wish to use the most recent Elasticsearch snapshot, even if it's failing CI. To do so, prefix your commands with the follow environment variable:
23
+
24
+
["source","bash"]
25
+
-----------
26
+
KBN_ES_SNAPSHOT_USE_UNVERIFIED=true
27
+
-----------
28
+
29
+
You can use this flag with any command that downloads and runs Elasticsearch snapshots, such as `scripts/es` or the FTR.
30
+
31
+
For example, to run functional tests with the latest snapshot:
Currently, there is not a way to run your pull request with the latest unverified snapshot without a code change. You can, however, do it with a small code change.
41
+
42
+
1. Edit `Jenkinsfile` in the root of the Kibana repo
43
+
2. Add `env.KBN_ES_SNAPSHOT_USE_UNVERIFIED = 'true'` at the top of the file.
44
+
3. Commit the change
45
+
46
+
Your pull request should then use the latest snapshot the next time that it runs. Just don't merge the change to `Jenkinsfile`!
47
+
48
+
==== Google Cloud Storage buckets
49
+
50
+
===== kibana-ci-es-snapshots-daily
51
+
52
+
This bucket stores snapshots that are created on a daily basis, and is the primary location used by `kbn-es` to download snapshots.
53
+
54
+
Snapshots are automatically deleted after 10 days.
55
+
56
+
The file structure for this bucket looks like this:
This bucket stores only the most recently promoted snapshot for each version. Old snapshots are only deleted when new ones are uploaded.
67
+
68
+
This bucket serves as permanent snapshot storage for old branches/versions that are no longer being built. `kbn-es` checks the daily bucket first, followed by this one if no snapshots were found.
69
+
70
+
The file structure for this bucket looks like this:
71
+
72
+
* `<version>/*.tar.gz`
73
+
* `<version>/*.tar.gz.sha512`
74
+
* `<version>/manifest.json`
75
+
76
+
==== How snapshots are built, tested, and promoted
77
+
78
+
Each day, a https://kibana-ci.elastic.co/job/elasticsearch+snapshots+trigger/[Jenkins job] runs that triggers Elasticsearch builds for each currently tracked branch/version. This job is automatically updated with the correct branches whenever we release new versions of Kibana.
79
+
80
+
===== Build
81
+
82
+
https://kibana-ci.elastic.co/job/elasticsearch+snapshots+build/[This Jenkins job] builds the Elasticsearch snapshots and uploads them to GCS.
83
+
84
+
The Jenkins job pipeline definition is https://github.com/elastic/kibana/blob/master/.ci/es-snapshots/Jenkinsfile_build_es[in the kibana repo].
85
+
86
+
1. Checkout Elasticsearch repo for the given branch/version.
87
+
2. Run `./gradlew -p distribution/archives assemble --parallel` to create all of the Elasticsearch distributions.
88
+
3. Create a tarball for each distribution.
89
+
4. Create a manifest JSON file containing info about the distribution, as well as its download URL.
90
+
5. Upload the tarballs and manifest to a unique location in the GCS bucket `kibana-ci-es-snapshots-daily`.
91
+
** e.g. `<version>/archives/<unique id>`
92
+
6. Replace `<version>/manifest-latest.json` in GCS with this newest manifest.
93
+
** This allows the `KBN_ES_SNAPSHOT_USE_UNVERIFIED` flag to work.
94
+
7. Trigger the verification job, to run the full Kibana CI test suite with this snapshot.
95
+
96
+
===== Verification and Promotion
97
+
98
+
https://kibana-ci.elastic.co/job/elasticsearch+snapshots+verify/[This Jenkins job] tests the latest Elasticsearch snapshot with the full Kibana CI pipeline, and promotes if it there are no test failures.
99
+
100
+
The Jenkins job pipeline definition is https://github.com/elastic/kibana/blob/master/.ci/es-snapshots/Jenkinsfile_verify_es[in the kibana repo].
101
+
102
+
1. Checkout Kibana and set up CI environment as normal.
103
+
2. Set the `ES_SNAPSHOT_MANIFEST` env var to point to the latest snapshot manifest.
104
+
3. Run CI (functional tests, integration tests, etc).
105
+
4. After CI
106
+
** If there was a test failure or other build error, send out an e-mail notification and stop.
107
+
** If there were no errors, promote the snapshot.
108
+
109
+
Promotion is done as part of the same pipeline:
110
+
111
+
1. Replace the manifest at `kibana-ci-es-snapshots-daily/<version>/manifest-latest-verified.json` with the manifest from the tested snapshot.
112
+
** At this point, the snapshot has been promoted and will automatically be used in CI and in local development.
113
+
2. Replace the snapshot at `kibana-ci-es-snapshots-permanent/<version>/` with the tested snapshot by copying all of the tarballs and the manifest file.
Copy file name to clipboardExpand all lines: docs/development/core/server/kibana-plugin-core-server.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -263,13 +263,14 @@ The plugin integrates with the core system via lifecycle events: `setup`<!-- -->
263
263
|[SavedObjectAttribute](./kibana-plugin-core-server.savedobjectattribute.md)| Type definition for a Saved Object attribute value |
264
264
|[SavedObjectAttributeSingle](./kibana-plugin-core-server.savedobjectattributesingle.md)| Don't use this type, it's simply a helper type for [SavedObjectAttribute](./kibana-plugin-core-server.savedobjectattribute.md)|
265
265
|[SavedObjectMigrationFn](./kibana-plugin-core-server.savedobjectmigrationfn.md)| A migration function for a [saved object type](./kibana-plugin-core-server.savedobjectstype.md) used to migrate it to a given version |
|[SavedObjectSanitizedDoc](./kibana-plugin-core-server.savedobjectsanitizeddoc.md)|Describes Saved Object documents that have passed through the migration framework and are guaranteed to have a <code>references</code> root property.|
267
267
| [SavedObjectsClientContract](./kibana-plugin-core-server.savedobjectsclientcontract.md) | Saved Objects is Kibana's data persisentence mechanism allowing plugins to use Elasticsearch for storing plugin state.<!-- -->\#\# SavedObjectsClient errors<!-- -->Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to to application code. Ideally, all errors will be either:<!-- -->1. Caused by bad implementation (ie. undefined is not a function) and as such unpredictable 2. An error that has been classified and decorated appropriately by the decorators in [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)<!-- -->Type 1 errors are inevitable, but since all expected/handle-able errors should be Type 2 the <code>isXYZError()</code> helpers exposed at <code>SavedObjectsErrorHelpers</code> should be used to understand and manage error responses from the <code>SavedObjectsClient</code>.<!-- -->Type 2 errors are decorated versions of the source error, so if the elasticsearch client threw an error it will be decorated based on its type. That means that rather than looking for <code>error.body.error.type</code> or doing substring checks on <code>error.body.error.reason</code>, just use the helpers to understand the meaning of the error:<!-- -->\`\`\`<!-- -->js if (SavedObjectsErrorHelpers.isNotFoundError(error)) { // handle 404 }<!-- -->if (SavedObjectsErrorHelpers.isNotAuthorizedError(error)) { // 401 handling should be automatic, but in case you wanted to know }<!-- -->// always rethrow the error unless you handle it throw error; \`\`\`<!-- -->\#\#\# 404s from missing index<!-- -->From the perspective of application code and APIs the SavedObjectsClient is a black box that persists objects. One of the internal details that users have no control over is that we use an elasticsearch index for persistance and that index might be missing.<!-- -->At the time of writing we are in the process of transitioning away from the operating assumption that the SavedObjects index is always available. Part of this transition is handling errors resulting from an index missing. These used to trigger a 500 error in most cases, and in others cause 404s with different error messages.<!-- -->From my (Spencer) perspective, a 404 from the SavedObjectsApi is a 404; The object the request/call was targeting could not be found. This is why \#14141 takes special care to ensure that 404 errors are generic and don't distinguish between index missing or document missing.<!-- -->See [SavedObjectsClient](./kibana-plugin-core-server.savedobjectsclient.md) See [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md) |
268
268
|[SavedObjectsClientFactory](./kibana-plugin-core-server.savedobjectsclientfactory.md)| Describes the factory used to create instances of the Saved Objects Client. |
269
269
|[SavedObjectsClientFactoryProvider](./kibana-plugin-core-server.savedobjectsclientfactoryprovider.md)| Provider to invoke to retrieve a [SavedObjectsClientFactory](./kibana-plugin-core-server.savedobjectsclientfactory.md)<!---->. |
270
270
|[SavedObjectsClientWrapperFactory](./kibana-plugin-core-server.savedobjectsclientwrapperfactory.md)| Describes the factory used to create instances of Saved Objects Client Wrappers. |
271
271
|[SavedObjectsFieldMapping](./kibana-plugin-core-server.savedobjectsfieldmapping.md)| Describe a [saved object type mapping](./kibana-plugin-core-server.savedobjectstypemappingdefinition.md) field.<!---->Please refer to [elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-types.html) For the mapping documentation |
272
272
|[SavedObjectsNamespaceType](./kibana-plugin-core-server.savedobjectsnamespacetype.md)| The namespace type dictates how a saved object can be interacted in relation to namespaces. Each type is mutually exclusive: \* single (default): this type of saved object is namespace-isolated, e.g., it exists in only one namespace. \* multiple: this type of saved object is shareable, e.g., it can exist in one or more namespaces. \* agnostic: this type of saved object is global.<!---->Note: do not write logic that uses this value directly; instead, use the appropriate accessors in the [type registry](./kibana-plugin-core-server.savedobjecttyperegistry.md)<!---->. |
273
+
|[SavedObjectUnsanitizedDoc](./kibana-plugin-core-server.savedobjectunsanitizeddoc.md)| Describes Saved Object documents from Kibana < 7.0.0 which don't have a <code>references</code> root property defined. This type should only be used in migrations. |
273
274
|[ScopeableRequest](./kibana-plugin-core-server.scopeablerequest.md)| A user credentials container. It accommodates the necessary auth credentials to impersonate the current user.<!---->See [KibanaRequest](./kibana-plugin-core-server.kibanarequest.md)<!---->. |
274
275
|[ServiceStatusLevel](./kibana-plugin-core-server.servicestatuslevel.md)| A convenience type that represents the union of each value in [ServiceStatusLevels](./kibana-plugin-core-server.servicestatuslevels.md)<!---->. |
0 commit comments