rubyTests failing in 8.12.2 logstash

[nikhithakarennagari]

Repro line:

./gradlew rubyTests --stacktrace

Below errors are seen during execution of above command: org.logstash.RSpecTests > rspecTests[core tests] FAILED java.lang.AssertionError: RSpec test suite core testssaw at least one failure. at org.junit.Assert.fail(Assert.java:88) at org.logstash.RSpecTests.rspecTests(RSpecTests.java:72

Below are some of the failures:

rspec ./logstash-core/spec/logstash/api/modules/root_spec.rb:26 # LogStash::Api::Modules::Root should respond to root resource rspec ./logstash-core/spec/logstash/api/modules/root_spec.rb:23 # LogStash::Api::Modules::Root should return a 404 to unknown request rspec './logstash-core/spec/logstash/api/modules/node_stats_spec.rb[1:1]' # LogStash::Api::Modules::NodeStats should return a 404 to unknown request rspec './logstash-core/spec/logstash/api/modules/node_stats_spec.rb[1:2:1]' # LogStash::Api::Modules::NodeStats GET / should respond OK rspec './logstash-core/spec/logstash/api/modules/node_stats_spec.rb[1:2:3]' # LogStash::Api::Modules::NodeStats GET / should set 'jvm.uptime_in_millis' at '/' to be a 'Numeric' rspec './logstash-core/spec/logstash/api/modules/node_stats_spec.rb[1:2:4]' # LogStash::Api::Modules::NodeStats GET / should set 'jvm.threads.count' at '/' to be a 'Numeric' rspec './logstash-core/spec/logstash/api/modules/node_stats_spec.rb[1:2:5]' # LogStash::Api::Modules::NodeStats GET / should set 'jvm.threads.peak_count' at '/' to be a 'Numeric' rspec './logstash-core/spec/logstash/api/modules/node_stats_spec.rb[1:2:6]' # LogStash::Api::Modules::NodeStats GET / should set 'jvm.gc.collectors.young.collection_count' at '/' to be a 'Numeric' rspec './logstash-core/spec/logstash/api/modules/node_stats_spec.rb[1:2:7]' # LogStash::Api::Modules::NodeStats GET / should set 'jvm.gc.collectors.young.collection_time_in_millis' at '/' to be a 'Numeric' rspec './logstash-core/spec/logstash/api/modules/node_stats_spec.rb[1:2:8]' # LogStash::Api::Modules::NodeStats GET / should set 'jvm.gc.collectors.old.collection_count' at '/' to be a 'Numeric'

Most of the failures are like below, with Argument Errors as:

` LogStash::Api::Modules::Logging#logging when setting a logger's log level should throw error when key logger is invalid Failure/Error: status = RSpec::Core::Runner.run(ARGV.empty? ? ($JUNIT_ARGV || ["spec"]) : ARGV).to_i

       ArgumentError:
         Setting "xpack.geoip.downloader.enabled" doesn't exist. Please check if you haven't made a typo.
       # ./logstash-core/lib/logstash/settings.rb:104:in `get_setting'
       # ./logstash-core/lib/logstash/settings.rb:136:in `get_value'
       # ./x-pack/lib/geoip_database_management/manager.rb:52:in `initialize'
       # ./logstash-core/lib/logstash/agent.rb:633:in `initialize_geoip_database_metrics'
       # ./logstash-core/lib/logstash/agent.rb:97:in `initialize'
       # ./logstash-core/spec/support/helpers.rb:57:in `make_test_agent'
       # ./logstash-core/spec/support/shared_contexts.rb:62:in `block in <main>'
       # ./lib/bootstrap/rspec.rb:36:in `<main>'

`

Reproduces locally?: yes

Applicable branches: 8.12.0 onwards

Failure history: Fails from 8.12.0

[nikhithakarennagari]

@andsel , Could you help here..

Thanks in Advance!

[andsel]

Sorry @nikhithakarennagari but I wasn't able to reproduce locally:

org.logstash.xpack.test.RSpecTests > rspecTests PASSED

--------------------------------------------------------------------
|  Results: SUCCESS (1 tests, 1 successes, 0 failures, 0 skipped)  |
--------------------------------------------------------------------

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.5/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 10m 19s
59 actionable tasks: 59 executed
andrea:logstash_andsel (tags/v8.12.2) % ./gradlew clean rubyTests

Did you try ./gradlew clean ?

[nikhithakarennagari]

@andsel , May I know if you are running the OSS version of logstash? Because I see that I am running org.logstash.RSpecTests > rspecTests[core tests] FAILED and for you it is org.logstash.xpack.test.RSpecTests > rspecTests PASSED

[andsel]

I checkout the sources, the tests runs the full source base, it doesn't bother if OSS or not.

[nikhithakarennagari]

@andsel , Thank you very much for checking on it. Let me tell you what I tried. The steps that I am running are: 1.Clone the 8.12.2 tagged Logstash repo from github 2. export OSS=true 3. export LOGSTASH_SOURCE=1 4. export LOGSTASH_PATH=$PWD 5. ./gradlew rubyTests --stacktrace

After the last step, I am facing the errors as indicated above. I have tried ./gradlew clean also.

One thing I have observed is, If I reverted these changes in this commit https://github.com/elastic/logstash/pull/15348 , the rubyTests passed successfully. Another observation is if i set OSS to false, then the test is successful

Let me know if I have to change any settings/configuration in the repo. Once again Thank you for your time and efforts to check this.

[tsaarni]

When running with OSS=true this registration code is not executed https://github.com/elastic/logstash/blob/ee9dfd33260ed956568b47be75497c7bb7165e34/x-pack/lib/geoip_database_management/extension.rb#L11-L17

Therefore the config variable(s) remains "unknown" for OSS=true build - as they probably should be. But then this code now gets executed even if OSS=true

https://github.com/elastic/logstash/blob/ee9dfd33260ed956568b47be75497c7bb7165e34/x-pack/lib/geoip_database_management/manager.rb#L52

and since the config variable was not registered it will print error

Setting "xpack.geoip.downloader.enabled" doesn't exist. Please check if you haven't made a typo.

If running OSS=false the config variables are known since the registration code is executed. Error is not printed.

Error happens also if just running logstash

bin/logstash -e 'input { stdin { } } output { stdout {} }'

and it seems still to be happening in main.

[nikhithakarennagari]

Hi @andsel, Could you please verify on the comment provided by @tsaarni

[andsel]

@nikhithakarennagari His analysis is correct, the point is that export OSS=true shouldn't be set, at the end it's an internal detail. I know it's documented in README and checking if and how to rephrase it.