Skip to content

Commit 315c456

Browse files
authored
Add howto about migrating a package to package spec v2 (#964)
1 parent 9123e12 commit 315c456

File tree

1 file changed

+61
-0
lines changed

1 file changed

+61
-0
lines changed
Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# Update between Package Spec major versions
2+
3+
Each Package Spec major version may bring breaking changes or additional
4+
validations that may make tests to fail for some packages. Find here guidelines
5+
about how to fix these issues.
6+
7+
Version of the Package Spec used by a package is defined by the `format_version`
8+
setting in the `manifest.yml` file.
9+
10+
## Troubleshooting upgrades from Package Spec v1 to v2
11+
12+
### field (root): Additional property license is not allowed
13+
14+
The `license` field was deprecated in Package Spec 1.13.0 and removed in 2.0.0.
15+
This field was used to indicate the required subscription. The `elastic.subscription`
16+
condition should be used instead.
17+
18+
So, for example, for a package with `license: basic`, you must remove this line
19+
and add the following condition:
20+
```
21+
conditions:
22+
elastic.subscription: basic
23+
```
24+
25+
### field ... is not normalized as expected: expected array, found ...
26+
27+
ECS fields can indicate normalization rules. `elastic-package` checks that they
28+
are followed in test documents.
29+
30+
To solve this, modify the ingest pipeline of the package to produce an array
31+
instead of single values. This is needed even when the field is only going to
32+
store a single value.
33+
34+
This only affects how the data is represented in the source documents, it
35+
doesn't affect how the data can be queried.
36+
37+
For example the following processor:
38+
```
39+
- set:
40+
field: event.category
41+
value: "web"
42+
```
43+
44+
Should be replaced with:
45+
```
46+
- set:
47+
field: event.category
48+
value: ["web"]
49+
```
50+
51+
### field "event.type" value ... is not one of the expected values (...) for ...
52+
53+
Some ECS fields can add restrictions on the values that `event.type` can have.
54+
So when using any of these fields, the values of `event.type` must be aligned
55+
with the expected values.
56+
57+
To solve this, ensure that the generated documents have the `event.type` set to
58+
some of the expected values.
59+
60+
For example if a document contains `event.category: web`, the value of
61+
`event.type` must be `access`, `error` or `info` according to ECS 8.4.

0 commit comments

Comments
 (0)