|
| 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