-
Notifications
You must be signed in to change notification settings - Fork 25.4k
Run GeoIp YAML tests in multi-project cluster and fix bug discovered by tests #131521
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
Run GeoIp YAML tests in multi-project cluster and fix bug discovered by tests #131521
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR enables GeoIP YAML REST tests to run in multi-project clusters and fixes a bug in the DatabaseNodeService
class. The changes include refactoring the database checking logic to support multi-project environments and adding new test infrastructure.
- Refactored
DatabaseNodeService.checkDatabases()
to extract project-specific logic into a separate method - Added new YAML test suite for multi-project GeoIP functionality
- Fixed package declaration in existing Java test class
- Updated build configuration to support YAML REST tests
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
File | Description |
---|---|
DatabaseNodeService.java | Refactored database checking logic to support multi-project clusters by extracting project-specific logic |
IngestGeoIpClientMultiProjectYamlTestSuiteIT.java | Added new YAML test suite for multi-project GeoIP functionality |
GeoIpMultiProjectIT.java | Fixed package declaration and removed redundant imports |
build.gradle | Added YAML REST test plugin configuration and dependencies |
Pinging @elastic/es-data-management (Team:Data Management) |
containsInAnyOrder("GeoLite2-City.mmdb", "GeoLite2-Country.mmdb", "GeoLite2-ASN.mmdb", "MyCustomGeoLite2-City.mmdb") | ||
); | ||
}, 10, TimeUnit.SECONDS); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the same as the method in IngestGeoIpClientYamlTestSuiteIT
? Do you think it's worth commoning them up somehow? It seems like quite a lot of code to duplicate — if we did something to how this works that meant we had to do a subtle fix, it would be a pain to have to do it twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. But I was struggling to get methods from IngestGeoIpClientYamlTestSuiteIT
imported here. Do you know how to do it? I am still trying to get it working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, so I guess you might be able to declare a javaRestTestImplementation
on the module where the other IT class is declared. I'm not sure if having test modules that depend on other test modules is allowed or not — most places I've worked before certainly wouldn't consider it best practice. I guess the other option would be to put it somewhere that both IT classes already have access to, e.g. GeoIpHttpFixture
or something... but it kind of doesn't feel like it belongs there either.
I dunno, maybe this isn't worth the effort WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out we have this elasticsearch.internal-test-artifact
gradle plugin that does just what we want. Having test module dependent on another test module feels kind of ok here to me since we are running a MP version of the same tests.
Request putPipelineRequest = new Request("PUT", "/_ingest/pipeline/pipeline-with-geoip"); | ||
putPipelineRequest.setEntity(new ByteArrayEntity(bytes.array(), ContentType.APPLICATION_JSON)); | ||
client().performRequest(putPipelineRequest); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment about commoning up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reused code from IngestGeoIpClientYamlTestSuiteIT
modules/ingest-geoip/src/main/java/org/elasticsearch/ingest/geoip/DatabaseNodeService.java
Outdated
Show resolved
Hide resolved
modules/ingest-geoip/src/main/java/org/elasticsearch/ingest/geoip/DatabaseNodeService.java
Show resolved
Hide resolved
This reverts commit 5f651a3.
import static org.elasticsearch.ingest.geoip.IngestGeoIpClientYamlTestSuiteIT.assertDatabasesLoaded; | ||
import static org.elasticsearch.ingest.geoip.IngestGeoIpClientYamlTestSuiteIT.putGeoipPipeline; | ||
|
||
public class IngestGeoIpClientMultiProjectYamlTestSuiteIT extends MultipleProjectsClientYamlSuiteTestCase { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm probably missing something, but I'm having trouble identifying why we need this dedicated YAML test suite. Can you explain why we can't just run the regular YAML suite in MP mode (i.e. tests.multi_project.enabled=true
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we'd want to run the yaml tests in both MP enabled and disabled mode, is there a way to do that with the existing test suite?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we'd want to run the yaml tests in both MP enabled and disabled mode
100% agree on that
is there a way to do that with the existing test suite?
Once ES-12094 gets implemented, that should be trivial. However, I'm not familiar enough with Gradle to know if there's a simple way to do that right now. Perhaps you can ask in #es-delivery
- mainly for an answer to this question and potentially also a status update on the ticket itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing the issue. Until that is implemented, I think keeping the MP YAML tests in qa/multi-project
Gradle project together with other MP Java rest tests is more organized.
Also asked in the linked Slack channel to see if there's better way of doing this now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for asking in the channel. If we don't find a better way to do it, I think I'd be more in favor of not running the MP YAML tests in the CI yet. I don't think these changes are that small and especially if we're combining them with the fix itself, it'll be annoying to revert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure, leaving the MP YAML tests out of CI seems missing test coverage, considering the amount of code change have been made to make GeoIP project-aware (especially there's already a bug found from these tests). Although MP is not in use yet, so probably not a huge due if there's bug.
Why do we want to revert? If these tests fail in CI then they should be muted, and we can fix them instead of reverting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we're missing test coverage if we don't run this GeoIP YAML suite in MP mode, but there are other suites that we're not covering yet either, and, most importantly, we're not close to running any of this in production. So, I think we can live without coverage a little longer.
Why do we want to revert?
Once the Jira ticket I linked gets implemented, all these changes become redundant, and we can just do something like
tasks.register('multiProjectYamlTest') {
}
or whatever the gradle lines will look like to make a YAML test suite run in MP mode as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once the Jira ticket I linked gets implemented, all these changes become redundant
That's true, I have added a FixForMultiProject
as reminder. For this specific PR, I think there's value including the tests suite as it validates the bug has been fixed. We can always remove it after the linked ticket is implemented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the annotation. I still don't really think it's worth merging these changes, but I also don't think it's worth discussing this any longer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Niels, really appreciate your thought on this. I also don't think it's worth spending more time discussing on this. I agree that this YAML test change is not effortless, we can defer making similar changes for other modules until ES-12094 is implemented.
modules/ingest-geoip/src/main/java/org/elasticsearch/ingest/geoip/DatabaseNodeService.java
Outdated
Show resolved
Hide resolved
modules/ingest-geoip/src/main/java/org/elasticsearch/ingest/geoip/DatabaseNodeService.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of things to add to Niels's points — I will leave the discussion on testing to you as you seem to have more knowledge there.
modules/ingest-geoip/src/main/java/org/elasticsearch/ingest/geoip/DatabaseNodeService.java
Outdated
Show resolved
Hide resolved
modules/ingest-geoip/src/main/java/org/elasticsearch/ingest/geoip/DatabaseNodeService.java
Outdated
Show resolved
Hide resolved
modules/ingest-geoip/src/main/java/org/elasticsearch/ingest/geoip/DatabaseNodeService.java
Outdated
Show resolved
Hide resolved
import static org.elasticsearch.ingest.geoip.IngestGeoIpClientYamlTestSuiteIT.assertDatabasesLoaded; | ||
import static org.elasticsearch.ingest.geoip.IngestGeoIpClientYamlTestSuiteIT.putGeoipPipeline; | ||
|
||
public class IngestGeoIpClientMultiProjectYamlTestSuiteIT extends MultipleProjectsClientYamlSuiteTestCase { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we're missing test coverage if we don't run this GeoIP YAML suite in MP mode, but there are other suites that we're not covering yet either, and, most importantly, we're not close to running any of this in production. So, I think we can live without coverage a little longer.
Why do we want to revert?
Once the Jira ticket I linked gets implemented, all these changes become redundant, and we can just do something like
tasks.register('multiProjectYamlTest') {
}
or whatever the gradle lines will look like to make a YAML test suite run in MP mode as well.
IndexRoutingTable databasesIndexRT = projectState.routingTable().index(databasesIndex); | ||
if (databasesIndexRT == null || databasesIndexRT.allPrimaryShardsActive() == false) { | ||
logger.trace( | ||
"Not checking databases because geoip databases index does not have all active primary shards for" + " project [{}]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit:
"Not checking databases because geoip databases index does not have all active primary shards for" + " project [{}]", | |
"Not checking databases because geoip databases index does not have all active primary shards for project [{}]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great catch on the bug fix!
…cking * upstream/main: (166 commits) Reduce inactive sink interval in VectorSimilarityFunctionsIT (elastic#132288) ESQL: Allow agg tests to process many columns (elastic#132358) Update analysis-lowercase-tokenfilter.md (elastic#132359) Add Sparse Vector Index Options Settings to Semantic Text Field (elastic#131058) Collect node thread pool usage for shard balancing (elastic#131480) Add tasks to validate new style transport versions (elastic#131782) Mute org.elasticsearch.search.routing.SearchReplicaSelectionIT testNodeSelection elastic#132354 Mute org.elasticsearch.xpack.esql.action.CrossClusterAsyncQueryIT testBadAsyncId elastic#132353 Fixes DenseVectorFieldIndexTypeUpdateIT release tests (elastic#132346) Fix testCloseOrReallocateDuringPartialSnapshot (elastic#132049) (Doc) ILM Force Merge not on HDD and happens on hosting node not current phase tier (elastic#130280) Run GeoIp YAML tests in multi-project cluster and fix bug discovered by tests (elastic#131521) Unmutes elastic#132111, seems a transient, non reproducible issue (elastic#132253) Mute org.elasticsearch.search.suggest.phrase.PhraseSuggesterIT testPhraseSuggestionWithNgramOnlyAnalyzerThrowsException elastic#132347 Add AI21 support to Inference Plugin (elastic#131238) OpenJDK EA builds should use https instead of http (elastic#132297) ESQL: Normalize timeseries aggs slightly (elastic#132284) Avoid internal server error on suggester ngram bad request (elastic#132321) [ES|QL] Rerank operator improvements (elastic#132318) Mute org.elasticsearch.xpack.logsdb.qa.LogsDbVersusReindexedLogsDbChallengeRestIT testTermsQuery elastic#132337 ...
This change runs the GeoIP YAML REST tests in multi-project cluster, it also fixes a bug in
DatabaseNodeService
discovered by running the YAML tests in MP mode.Sample test run