Add support for prompting user to unfreezing indices to the Upgrade Assistant

[dakrone]

In 8.last, we're going to add a migration API issue where a user must unfreeze an index before upgrading to 9.0. The Upgrade Assistant should take this issue from the API and give the user the ability to unfreeze the index (or delete it) before the upgrade.

/cc @elastic/kibana-core @Bamieh

[PeteGillinElastic]

There was actually already a deprecation issue for this, but only at WARNING level. I have increased that to CRITICAL and updated the wording in elastic/elasticsearch#119879.

[jloleysens]

Hey @dakrone ! Is it true that all frozen indices will be 7.x indices? When I attempted to create a frozen index I needed to do so on 7.x (which also meant creating an index <8). The 8.18.0 migration deprecation info reported:

  "index_settings":
....
    "myindex1": [
      {
        "level": "critical",
        "message": "Old index with a compatibility version < 8.0",
        "url": "https://www.elastic.co/guide/en/elasticsearch/reference/current/migrating-8.0.html#breaking-changes-8.0",
        "details": "This index has version: 7.17.25",
        "resolve_during_rolling_upgrade": false,
        "_meta": {
          "reindex_required": true
        }
      },
      {
        "level": "critical",
        "message": "Index [myindex1] is a frozen index. The frozen indices feature is deprecated and will be removed in version 9.0.",
        "url": "https://www.elastic.co/guide/en/elasticsearch/reference/master/frozen-indices.html",
        "details": "Frozen indices must be unfrozen before upgrading to version 9.0. (The legacy frozen indices feature no longer offers any advantages. You may consider cold or frozen tiers in place of frozen indices.)",
        "resolve_during_rolling_upgrade": false
      }
    ]
...

If this is true, we could just "fix" the frozen index by following our reindex flow. The alternative being that users delete this data.

[jloleysens]

cc @Bamieh @gsoldevila

[dakrone]

If this is true, we could just "fix" the frozen index by following our reindex flow. The alternative being that users delete this data.

Forcing a re-index could be unnecessary here. The user could unfreeze the index, and then mark it as a verified read-only and allow it to be read without re-indexing by using the N-2 support. Or is that what you mean by the re-index flow?

[jloleysens]

That's a good point. In that case, making an index "read-only" would involve unfreezing yeah. But is the assumption about them being <8 preserved?

[jloleysens]

from a UI/end user perspective, we could do this all under the hood is what I was thinking (avoiding UI changes). Or is there value in the user also knowing that this is a frozen index?

[dakrone]

is the assumption about them being <8 preserved?

Yes, the only way they would be frozen would be if they came from a 7.x cluster. The /_freeze API was completely removed for all of 8.x.

we could do this all under the hood is what I was thinking (avoiding UI changes). Or is there value in the user also knowing that this is a frozen index?

We can definitely do this under the hood, if that's an option for the Kibana side.

[gsoldevila]

I've created frozen indices in 7.last and tested the UA in 8.x.
For each of the frozen indices I get two 'index_settings' deprecations:

        {
            "index": "logs_frozen_6",
            "type": "index_settings",
            "details": "This index has version: 7.17.28-8.0.0",
            "message": "Old index with a compatibility version < 8.0",
            "url": "https://www.elastic.co/guide/en/elasticsearch/reference/current/migrating-8.0.html#breaking-changes-8.0",
            "isCritical": true,
            "resolveDuringUpgrade": false,
            "correctiveAction": {
                "type": "reindex"
            }
        },
        {
            "index": "logs_frozen_6",
            "type": "index_settings",
            "details": "Frozen indices must be unfrozen before upgrading to version 9.0. (The legacy frozen indices feature no longer offers any advantages. You may consider cold or frozen tiers in place of frozen indices.)",
            "message": "Index [logs_frozen_6] is a frozen index. The frozen indices feature is deprecated and will be removed in version 9.0.",
            "url": "https://www.elastic.co/guide/en/elasticsearch/reference/master/frozen-indices.html",
            "isCritical": true,
            "resolveDuringUpgrade": false
        },

When running the reindex flow, It successfully reindexes frozen indices without any extra action.
The original indices are then deleted, so there's no need to explicitly unfreeze those indices.

If we are certain that any frozen indices will also be "Old, aka < 8.0", then we can simply:

• Ignore the critical deprecations about frozen indices (filter them out from the list).
• Perhaps add a small paragraph in the flyout description, stating that on top of being old, the index is frozen, and that it will be deleted as part of the reindex process, as frozen indices will no longer be supported from 9.0.

[dakrone]

If we are certain that any frozen indices will also be "Old, aka < 8.0", then we can simply:
Ignore the critical deprecations about frozen indices (filter them out from the list).
Perhaps add a small paragraph in the flyout description, stating that on top of being old, the index is frozen, and that it will be deleted as part of the reindex process, as frozen indices will no longer be supported from 9.0.

In the event that a user decides to mark the index with a verified read-only flag (i.e., they have decided they're fine with it being read-only via the N-2 support in 9.0), we still need to force them to unfreeze the index, as the /_unfreeze API is removed in 9.0, and they'd run into issues with the unknown setting on upgrade.