Reporting ILM policy

[kobelb]

Currently, Reporting manually creates a weekly .reporting-${date} index. Since these are normal dot-prefixed indices, users can create an index template that specifies an ILM policy or they can manually delete older .reporting-${date} indices.

However, starting in 8.0 after Reporting has switched to use system-indices, end-users will no longer be able to create index templates or manually delete older .reporting-${date} indices. However, we want to provide them with a method of configuring a retention policy for their reports.

To address this limitation, the Reporting plugin should do three things:

1. On start-up, create a kibana-reporting ILM policy with the default phases
2. When creating new .reporting-${date} indices, specify the index.lifecycle.name: kibana-reporting setting.
3. Integrate with the 8.0 Upgrade Assistant to update all existing .reporting-* indices to have the index.lifecycle.name: kibana-reporting. This can be done in bulk per the docs.

This will allow the user to use the ILM management UI in Kibana to configure the phases for their Reporting system-indices. This isn't a perfect solution, as end-users can delete the kibana-reporting ILM policy and then on start-up Kibana will recreate it. However, we have this existing limitation with ILM policies that are created by default already.

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[kobelb]

/cc @jaymode @gwbrown

[tsullivan]

Do you all anticipate us only needing to allow users to configure the maximum index size and the maximum age for the .reporting-* indices

This sounds good to me - I'm not sure the users would need more than that

[kobelb]

@ppisljar can we get this added to the App Services team roadmap to be implemented by 8.0?

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[kobelb]

@tsullivan, I've updated the issue description based on recent input from @jaymode and some research of my own.

[tsullivan]

3. Integrate with the 8.0 Upgrade Assistant to update all existing .reporting-* indices to have the index.lifecycle.name: kibana-reporting. This can be done in bulk per the docs.

It is possible that the user may have defined a custom ILM policy for reporting indices. I have recommended this before: https://discuss.elastic.co/t/deleting-old-reporting-index/273684/3?u=tsullivan

Question: How do we prevent a built-in policy from conflicting with a custom policy the user may have defined before 7.14? Would it be a problem if there are so-called conflicting policies, meaning: mulitple ILM policies that apply to the same pattern of indices?

cc @kobelb @jloleysens @lhuet

[jloleysens]

Great point @tsullivan! I'd like to unpack "How do we prevent a built-in policy from conflicting with a custom policy" a bit further.

As I understand it the policy that is set in the index settings will override any policy that may be set by an index template. Therefore the "conflict" may be that old indices don't have this value set and are governed by a previous, custom policy where new indices are governed by our provisioned policy. Is this what you had in mind re "conflict"?

If so, I believe this is where the Upgrade Assistant deprecation notice is intended to assist users. There is still a possibility that indices are governed by different policies for a time. I believe this is something we could address in the UI: enable users to link to the reporting ILM policy (view it/update it), re-create it, or update their existing indices to be managed by the same policy (same action that would be performing from UA). I think there are 3 states that need to be reflected to the user (if ILM is enabled):

1. Conflicting (inconsistent) ILM policies on reporting indices

2. Reporting ILM policy does not exist

3. Reporting policy exists and is uniformly set on all reporting indices (base case)

What do you think?

[tsullivan]

@jloleysens the options all look achievable, and I like that you've thought further with # 2, that the user may have deleted the the kibana-reporting policy and could need a way to restore it.

What do you think?

I think it will work, and looks good.

[tsullivan]

@jloleysens take a look at this issue as well - #101438 our built-in policies will have an indication that they are managed in the listing page for policies.