Context
In 7.17, we assert that the incoming mappings for index creation has a single out key of _doc (the default single mapping name):
|
assert mapping.size() == 1 : mapping; |
|
assert entry.getKey().equals(mapping.keySet().iterator().next()) : entry.getKey() + " != " + mapping; |
But this is not always true when security indices are created in a mixed cluster (8.x and 7.17) because the mappings are configured without the single-mapping-name in 8.x:
|
.mapping(descriptorForVersion.getMappings()) |
while they are configured with the single-mapping-name in 7.17:
|
.mapping(descriptorForVersion.getIndexType(), descriptorForVersion.getMappings(), XContentType.JSON) |
Therefore, if the request hits a 8.x node first, the assertion will be tripped in the 7.17 node (if 7.17 is the master node). Till today, we didn't have any tests that create a net new security index in 8.x node of a mixed cluster. So the assertions are never tripped. It does not seem to be a problem in production because: (1) assertions are not fired in production; (2) MapperService handles the mappings with or without the single-mapping-type in 7.17:
|
if (type == null || type.equals(rootName) || documentTypeResolver.apply(type).equals(rootName)) { |
|
mapping = new Tuple<>(rootName, (Map<String, Object>) root.get(rootName)); |
|
} else { |
|
mapping = new Tuple<>(type, root); |
|
} |
Though the above is for security indices, it seems that all system indices can have similar issue:
|
.mappings(descriptor.getMappings()) |
|
updateRequest.mappings(mappings); |
Steps to reproduce:
- Start a 7.17 node with
-ea to enable assertions
- Start a 8.x node to form a cluster with the above 7.17 node. Make sure 7.17 is the master
- Create a user on the 8.x node to trigger creation of the security index:
PUT _security/user/foo
{"password":"password","roles":["foo-role"]}
- The 7.17 node crashes with AssertionError
Question
Is simply dropping the assertions in 7.17 the right fix?
It seems to be. However, I am not entirely sure whether the underlying system is fully ready for handling mappings that do not have the single-mapping-name key. It appears to be working fine. In fact, the code is out there for a while and I am not aware of any related bug report. So it most likely works. But I'd appreciate confirmation from people who are more expert for system indices and mapping services.
Context
In 7.17, we assert that the incoming mappings for index creation has a single out key of
_doc(the default single mapping name):elasticsearch/server/src/main/java/org/elasticsearch/cluster/metadata/MetadataCreateIndexService.java
Lines 843 to 844 in 5ad0236
But this is not always true when security indices are created in a mixed cluster (8.x and 7.17) because the mappings are configured without the single-mapping-name in 8.x:
elasticsearch/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/support/SecurityIndexManager.java
Line 393 in d20b9df
while they are configured with the single-mapping-name in 7.17:
elasticsearch/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/support/SecurityIndexManager.java
Line 383 in 5ad0236
Therefore, if the request hits a 8.x node first, the assertion will be tripped in the 7.17 node (if 7.17 is the master node). Till today, we didn't have any tests that create a net new security index in 8.x node of a mixed cluster. So the assertions are never tripped. It does not seem to be a problem in production because: (1) assertions are not fired in production; (2) MapperService handles the mappings with or without the single-mapping-type in 7.17:
elasticsearch/server/src/main/java/org/elasticsearch/index/mapper/MappingParser.java
Lines 186 to 190 in 5ad0236
Though the above is for security indices, it seems that all system indices can have similar issue:
elasticsearch/server/src/main/java/org/elasticsearch/action/admin/indices/create/TransportCreateIndexAction.java
Line 199 in d20b9df
elasticsearch/server/src/main/java/org/elasticsearch/action/admin/indices/create/AutoCreateAction.java
Line 334 in d20b9df
Steps to reproduce:
-eato enable assertionsQuestion
Is simply dropping the assertions in 7.17 the right fix?
It seems to be. However, I am not entirely sure whether the underlying system is fully ready for handling mappings that do not have the single-mapping-name key. It appears to be working fine. In fact, the code is out there for a while and I am not aware of any related bug report. So it most likely works. But I'd appreciate confirmation from people who are more expert for system indices and mapping services.