Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create first backing index when creating data stream #54467

Merged
merged 10 commits into from
Apr 2, 2020

Conversation

danhermann
Copy link
Contributor

Eagerly creates the first backing index when a data stream is created.

Relates to #53100

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features (:Core/Features/Data streams)

Copy link
Contributor

@henningandersen henningandersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @danhermann , I left a few comments to consider, but looking good otherwise.

if (currentState.metaData().dataStreams().containsKey(request.name)) {
throw new IllegalArgumentException("data_stream [" + request.name + "] already exists");
}

MetaDataCreateIndexService.validateIndexOrAliasName(request.name,
(s1, s2) -> new IllegalArgumentException("data_stream [" + s1 + "] " + s2));

String firstBackingIndexName = request.name + "-000000";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I remember @dakrone mentioning something about not starting from 0, rather from 1 like described in the ILM getting started guide. I am OK either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I think we should be consistent with what ILM does.

new CreateIndexClusterStateUpdateRequest("initialize_data_stream", firstBackingIndexName, firstBackingIndexName);
currentState = metaDataCreateIndexService.applyCreateIndexRequest(currentState, createIndexRequest, false);
IndexMetaData firstBackingIndex = currentState.metaData().index(firstBackingIndexName);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to add:

Suggested change
assert firstBackingIndex != null;

since that is guaranteed to fail tests (the NPE occurring further down could be swallowed).

@@ -250,4 +252,42 @@ private boolean isNonEmpty(List<IndexMetaData> idxMetas) {
return (Objects.isNull(idxMetas) || idxMetas.isEmpty()) == false;
}
}

class DataStream implements IndexAbstraction {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks unused? I think it makes more sense to add this when also building the indicesLookup.

@@ -1377,12 +1379,27 @@ private void validateDataStreams(SortedMap<String, IndexAbstraction> indicesLook
DataStreamMetadata dsMetadata = (DataStreamMetadata) customs.get(DataStreamMetadata.TYPE);
if (dsMetadata != null) {
for (DataStream ds : dsMetadata.dataStreams().values()) {
if (indicesLookup.containsKey(ds.getName())) {
IndexAbstraction existing = indicesLookup.get(ds.getName());
if (existing != null && existing.getType() != IndexAbstraction.Type.DATA_STREAM) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should end up asserting that existing != null, but that can be done in a followup together with populating indicesLookup

if (map.size() != 0) {
if (map.size() == ds.getIndices().size()) {
int numValidIndices = 0;
for (int i = 0; i < map.size(); i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should instead validate that the entries in map are the same as those in ds.getIndices().

Right now it works in the initial create case, but not after we have deleted the first index.

Also it would be good to add a MetaDataTests test that validates that a data-stream pointing to backing indices (with random suffix number) works.

Copy link
Member

@martijnvg martijnvg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few comments.

throw new IllegalStateException("data stream [" + ds.getName() + "] conflicts with existing index or alias");
}

SortedMap<?, ?> map = indicesLookup.subMap(ds.getName() + "-", ds.getName() + "."); // '.' is the char after '-'
SortedMap<String, IndexAbstraction> map =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add this in another change as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind this comment. This change is necessary otherwise the first backing index of data stream can't be created.

@@ -250,4 +252,42 @@ private boolean isNonEmpty(List<IndexMetaData> idxMetas) {
return (Objects.isNull(idxMetas) || idxMetas.isEmpty()) == false;
}
}

class DataStream implements IndexAbstraction {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add the data stream index abstraction in another change? We can use the get index api in the yaml test to check that the index has correctly been created.

(the logic that adds data streams to the indicesLookup is missing here, which would need to be added too, but let's try to this pr small, so that it is easy to review)
(also a number of if statements in the code base may need to be revised because a new data stream type is introduced)

Copy link
Member

@martijnvg martijnvg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some minor comments, LGTM otherwise.

@@ -22,10 +22,15 @@
indices.get_data_streams: {}
- match: { 0.name: simple-data-stream1 }
- match: { 0.timestamp_field: '@timestamp' }
- match: { 0.indices: [] }
- length: { 0.indices: 1 }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can also the index name be checked here inside the indices array field?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martijnvg, it looks like the format of the backing indices response changed when the data stream's indices member was changed from List<String> to List<Index>. It now looks like this:

       {
         "name" : "simple-data-stream1",
         "timestamp_field" : "@timestamp",
         "indices" : [
           {
             "index_name" : "simple-data-stream1-000001",
             "index_uuid" : "V3ONJviCQB68b1BBzMJwMw"
           }
         ]
       }

Is that ok?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is intended. We can add this assert:

- match: {0.indices.0.index_name: 'simple-data-stream1-000001')

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

never mind my comment, you already made this change :)

ALIAS("alias");
ALIAS("alias"),

DATA_STREAM("data_stream");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe add some java doc here?

assertThat(e.getMessage(), containsString("must not contain the following characters"));
}

private static class MockMetadataCreateIndexService extends MetadataCreateIndexService {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe instead of mock class use: Mockito#spy(...) and attach expected behaviour?

@danhermann
Copy link
Contributor Author

@elasticmachine update branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants