Data tiers: migrate the coldest node attribute

[andreidan]

This fixes the migrate to data tiers routing API to take into account
the scenario where the node attribute configuration for an index is more
accurate than the existing _tier_preference configuration.

Previously we would simply remove the node attributes routing if there
was a _tier_preference configured for the index.

With this commit, we'll look if either the require.data or
include.data custom routings are colder than the existing _tier_preference
configuration (ie. cold vs data_warm,data_hot) and update the tier
routing accordingly.

eg.

{
  index.routing.allocation.require.data: "warm",
  index.routing.allocation.include.data: "cold",
  index.routing.allocation.include._tier_preference: "data_hot"
}

will be migrated to:

{
  index.routing.allocation.include._tier_preference: "data_cold,data_warm,data_hot"
}

This also removes the existing invariant that had the require.data
configuration take precedence over a possible include.data
configuration, and will now migrate the coldest configuration to the
corresponding _tier_preference.

eg.

{
  index.routing.allocation.require.data: "warm",
  index.routing.allocation.include.data: "cold"
}

will be migrated to:

{
  index.routing.allocation.include._tier_preference: "data_cold,data_warm,data_hot"
}

Fixes #81633

[elasticmachine]

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

[dakrone]

The code LGTM, but I think we need to update the docs also?

[andreidan]

@elasticmachine update branch

[andreidan]

@dakrone handling the case where an index has the following configuration. Not entirely happy with treating data_content as equal to data_hot (as they are not comparable, or shouldn't be) but I guess it'll have to do unless you have a better suggestion?

"routing" : {
          "allocation" : {
            "include" : {
              "_tier_preference" : "data_content"
            },
            "require" : {
              "data" : "warm"
            }
          }
        }

[dakrone]

I don't think there's any way around it unfortunately. Functionally though, we consider them to be on the same hardware, so I don't think this is so bad, since it's only for the purpose of (internal) ordering rather than overwriting.

[dakrone]

This LGTM (with the data_content fix), but we still need to change the docs for the migrate API to document this behavior

[dakrone]

I don't think there's any way around it unfortunately. Functionally though, we consider them to be on the same hardware, so I don't think this is so bad, since it's only for the purpose of (internal) ordering rather than overwriting.

[andreidan]

@elasticmachine update branch

[andreidan]

@dakrone the documentation for the API doesn't go into details about how exactly it migrates the entities. We have the manual migration guide that does. I've updated the guide in 8ba044c

Maybe we should rework the docs for the API to be more detailed? Especially with #82170 coming in soon? Or maybe it's ok we're keeping the docs rather high level? @debadair what do you think?

@dakrone in any case, I think if we decide to refactor the docs we should do that in a follow-up and take #82170 into account once that's done. What do you think?

[dakrone]

LGTM, I left one comment about Latin pedantry :)

I think if we decide to refactor the docs we should do that in a follow-up and take #82170 into account once that's done. What do you think?

This sounds good to me 👍

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	8.0
✅	7.17