Inconsistent formatting of ILM Phase's min_age in XPack usage API

[swallez]

Elasticsearch Version

Since 7.0.0

Installed Plugins

No response

Java Version

bundled

OS Version

all

Problem Description

The format used to serialize ILM policy phases to JSON in GET _xpack/usage is not the same as the one used for GET _ilm/policy. The min_age property is serialized a millisecond value in the former (e.g. 172800000) (code), and as a TimeValue (e.g. "2d") il the latter (code).

Furthermore, the format used in xpack/usage is incompatible with PUT /_ilm/policy/{name} (RestPutLifecycleAction) that expects a TimeValue, meaning one cannot take the JSON output of _xpack/usage and use is to create an ILM policy.

Steps to Reproduce

On an ES with ILM policies, compare the output of GET _xpack/usage and GET _ilm/policy.

Logs (if relevant)

No response

[elasticmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[dakrone]

This is because the XPack telemetry is intended to be machine-readable and indexed into a numeric field. The GET-policy output is human-readable (and in the format the user provides).

the format used in xpack/usage is incompatible with PUT /_ilm/policy/{name} ..., meaning one cannot take the JSON output of _xpack/usage and use is to create an ILM policy.

These APIs are not intended to be counterparts to each other, they have different functions. Can you share some more information about why you want to take the output of a telemetry/usage API and feed it into the create policy API?

[swallez]

Can you share some more information about why you want to take the output of a telemetry/usage API and feed it into the create policy API?

There is no formally identified use case, we found this issue while testing the ILM and XPack API specifications that use the same data structure for ILM phases. The @esquirk annotation there indicates an inconsistency that client libraries code generators have to take special care of, as durations are generally expressed as a string with an associated xxx_as_millis number property.

We could also avoid the @esquik by creating two separate data structures, but that doesn't feel right as they really are the same, except for this property's format.