Turn off ILM policy name validation

[stevengoossensB]

I'm looking for ways to turn off the ILM policy name validation. Since it has no SRVxxxxxx code assigned, it cannot be covered as such in the validation.yml

[jsoriano]

Hey @stevengoossensB, what would be the use case for skipping this check?

[jsoriano]

And to what validation you are specifically referring? Could you share the error you see?

[stevengoossensB]

..../data_stream/log/manifest.yml" is invalid: field ilm_policy must start with ....

The validation requires the ILM policy which is configured in the manifest to start with .<data_stream_name>. However, in the package-spec, it is described as follows:

ilm_policy:
description: The name of an existing ILM (Index Lifecycle Management) policy
type: string
examples:

• diagnostics

The use case for skipping the check is when you want to reuse the same ILM policy across integrations instead of creating a specific one per integration.

[jsoriano]

The use case for skipping the check is when you want to reuse the same ILM policy across integrations instead of creating a specific one per integration.

Ah yes, we have an internal issue about improving the story around customization of ILM policies for packages.

For this use case I think that the approach should be:

• User creates ILM policies with their desired settings.
• User assigns ILM policies to data streams. <- This part is problematic now, and we want to improve it.

Including an ILM policy in a package to be used by others can be problematic because there is no concept of dependency between packages, so there could be problems if the packages that use the ILM policy are installed before installing the package with the ILM policy.

[stevengoossensB]

Including an ILM policy in a package to be used by others can be problematic because there is no concept of dependency between packages, so there could be problems if the packages that use the ILM policy are installed before installing the package with the ILM policy.

I see the problem with dependencies, but it exists for shared included pipelines, shared enrichment policies,... as well. Untill there is a good way to handle those dependencies (by creating a dependency package which gets installed first?), it would be great to be able to turn off the warning, rather then having to ignore it.

On top of that, the spec is misleading here, as it contains diagnostics as an example, which would also fail the validation.