Azure snapshots can not be restored anymore

[dadoonet]

While working on #26751 and doing some manual integration testing I found that this #22858 removed an important line of our code:

AzureRepository overrides default initializeSnapshot method which creates metadata files and do other stuff.

But with PR #22858, I wrote:

    @Override
    public void initializeSnapshot(SnapshotId snapshotId, List<IndexId> indices, MetaData clusterMetadata) {
        if (blobStore.doesContainerExist(blobStore.container()) == false) {
            throw new IllegalArgumentException("The bucket [" + blobStore.container() + "] does not exist. Please create it before " +
                " creating an azure snapshot repository backed by it.");
        }
    }

instead of

    @Override
    public void initializeSnapshot(SnapshotId snapshotId, List<IndexId> indices, MetaData clusterMetadata) {
        if (blobStore.doesContainerExist(blobStore.container()) == false) {
            throw new IllegalArgumentException("The bucket [" + blobStore.container() + "] does not exist. Please create it before " +
                " creating an azure snapshot repository backed by it.");
        }
        super.initializeSnapshot(snapshotId, indices, clusterMetadata);
    }

As we never call super.initializeSnapshot(...) files are not created and we can't restore what we saved.

Closes #26777.

[imotov]

The changes look good, but we need to figure out the test story here. That shouldn't have happened in the first place.

[dadoonet]

@imotov Agreed. So I discovered that while running AzureSnapshotRestoreTests#testSimpleWorkflow() with -Dtests.thirdparty=true.

The problem is that we never run automatically those tests. The manual tests I did previously were sadly:

• install the plugin
• start elasticsearch
• create an index and some data
• create the repository
• create a snapshot

But I did not test:

• delete the index
• restore the snapshot

That's why I did not hit the issue.

And BTW IT are not compatible anymore with 6.0 / 7.0 because we are now using secured settings.

That's why I also did:

• cb78313
• ba66cd3

Which I'm planning to backport anyway to 6.0 branch.

Do you want me to backport within this PR the IT changes instead of doing it in #26751?

[imotov]

@dadoonet I don't think it really matters if it goes as a part of this PR or another PR. As long as we have a test that would have failed without this change at the end I am fine with either.

[imotov]

LGTM

[s1monw]

lets merge this.