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

Erroneous Index Set prefix conflict #7573

Open
williamtrelawny opened this issue Feb 27, 2020 · 6 comments
Open

Erroneous Index Set prefix conflict #7573

williamtrelawny opened this issue Feb 27, 2020 · 6 comments

Comments

@williamtrelawny
Copy link
Contributor

Expected Behavior

Index Set prefixes should not conflict if they are in their entirety distinct strings, even if they start with some of the same characters.

Current Behavior

Have existing Index Set with prefix "cisco". Create a new Index Set with prefix "ciscoasa". API complains that new Index Set prefix conflicts with existing prefix:

{"type":"ApiError","message":"Index prefix "ciscoasa" would conflict with existing index set prefix "cisco""}HTTP/1.1 100 Continue

Possible Solution

Not sure exactly how the matching test goes for Index Set prefixes, but it appears to be based on a certain length at the start of the string. I have another instance where there are two Index Set prefixes that start with the same 2 characters but deviate after the 3rd, so there must be some matching logic that fails once the beginnings of the strings match further down the string.

Or perhaps this fails because the entirety of the "cisco" prefix matches against the other prefix "ciscoasa", which is causing the error.

Either way, I consider this a failure of the matching system.

Steps to Reproduce (for bugs)

  1. Create Index Set with prefix "cisco"
  2. Attempt to create Index Set with prefix "ciscoasa"... API error from above.

Context

Trying to create separate indices for various Cisco devices- ASA, Firepower, ISE, etc., and want the prefixes to reflect the different device types.

Your Environment

  • Graylog Version: 3.0.2
  • Elasticsearch Version: 6.7.1
  • MongoDB Version: 4.0.8
  • Operating System: OEL-7.5
  • Browser version: n/a
@jalogisch
Copy link
Contributor

[z#843198]

@jalogisch
Copy link
Contributor

// Build an example index name with the new prefix and check if this would be managed by an existing index set
final String indexName = newConfig.indexPrefix() + MongoIndexSet.SEPARATOR + "0";
if (indexSetRegistry.isManagedIndex(indexName)) {
return Optional.of(Violation.create("Index prefix \"" + newConfig.indexPrefix() + "\" would conflict with an existing index set!"));
}
// Check if an existing index set has a more generic index prefix.
// Example: new=graylog_foo existing=graylog => graylog is more generic so this is an error
// Example: new=gray existing=graylog => gray is more generic so this is an error
// This avoids problems with wildcard matching like "graylog_*".
for (final IndexSet indexSet : indexSetRegistry) {
if (newConfig.indexPrefix().startsWith(indexSet.getIndexPrefix()) || indexSet.getIndexPrefix().startsWith(newConfig.indexPrefix())) {
return Optional.of(Violation.create("Index prefix \"" + newConfig.indexPrefix() + "\" would conflict with existing index set prefix \"" + indexSet.getIndexPrefix() + "\""));
}
}

According to the Code the example should work at all.

@Littlericket
Copy link

Littlericket commented Nov 17, 2023

@jalogisch @florianpopp still happening in 5.2.1:

{
  "type": "ApiError",
  "message": "Index prefix \"index_naming_test\" would conflict with existing index set prefix \"index_naming\""
}

@bloodhunterd
Copy link

I have the same problem in 5.2.1.

I'm also surprised there aren't more people who have the problem, or maybe they do but don't share it and just use cryptic indexes so there's no conflict.

@hasturo
Copy link

hasturo commented Feb 16, 2024

Was in progress for opening a new Bug on this one also, but found this report. Like you iam suprised that this is so long open but like you assume, i just switched to other name generation.

But in general it would be a lot easier for me if this was fixed because using natural named prefixes is a lot more human.

/hasturo

@bloodhunterd
Copy link

It's not a blocking bug, but it's always annoying to first find out what exactly the problem is and then think about what a good work-around could be.

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

No branches or pull requests

6 participants