deprecate pipeline bus v1

[yaauie]

Release notes

• Deprecates v1 of the pipeline bus; the v2 implementation has been the default since its introduction in Logstash 8.15.0

What does this PR do?

Adds a deprecation warning if Logstash is configured to use the legacy v1 pipeline bus. The legacy implementation was replaced with a more-performant one in 8.15.0, and v1 was only left in place as an "escape hatch".

The ability to select v1 implementation is set to be removed on main in advance of 9.0 via #16644

Why is it important/What is the impact to the user?

It guides users away from the original lock-heavy implementation, which was previously only available as an escape hatch and is no longer necessary.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] I have made corresponding change to the default configuration files (and/or docker env variables)
• I have added tests that prove my fix is effective or that my feature works

How to test this PR locally

1. add -Dlogstash.pipelinebus.implementation=v1 to config/jvm.options
2. start logstash
3. observe relevant entry in the deprecation log

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[donoghuc]

The addition of the logger commit makes sense. Im a bit confused about the retrofit test commit though c51a7d5 is that refactor a general update that is extending a pattern being applied elsewhere you could point me to?

After looking closer:

I see organizational improvements and some more formal coverage of the PipelineBus factory when different configurations are provided using the withSystemProperty helper. Seems reasonable and generally just an improvement to the existing coverage.

[donoghuc]

I think this was just moved around, not introduced but I think its unused.

[yaauie]

Yeah, the first commit just retrofits tests onto the bit that selects which implementation to use, and needed to wrap the existing @Parameterized tests in a @RunWith(Enclosed.class) so that the new tests would run just once instead of for each possible value of the parameter. I made the change in a separate commit because it doesn't actually change anything.

As you saw, the star of the PR is the second commit, which adds the deprecation log and verifies that it is emitted in the right conditions. In retrospect, the other two tests should have a negative assertion.

I'll add those and bounce it back.

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 93e9155

History

• 💔 Build #1967 failed bf76848
• 💚 Build #1813 succeeded e18e466

[donoghuc]

It looks like in the case we have an "unknown" configuration setting we "default" to v1 still. Maybe as part of calling out v1 is deprecated we can also change that fallback to also be v2.

diff --git a/logstash-core/src/main/java/org/logstash/plugins/pipeline/PipelineBus.java b/logstash-core/src/main/java/org/logstash/plugins/pipeline/PipelineBus.java
index 487793d62..b10fa6729 100644
--- a/logstash-core/src/main/java/org/logstash/plugins/pipeline/PipelineBus.java
+++ b/logstash-core/src/main/java/org/logstash/plugins/pipeline/PipelineBus.java
@@ -54,7 +54,7 @@ public interface PipelineBus {
             case "v2": return new PipelineBusV2();
             default:
                 LOGGER.warn("unknown pipeline-bus implementation: {}", pipelineBusImplementation);
-                return new PipelineBusV1();
+                return new PipelineBusV2();
         }
     }

[donoghuc]

It seems like configuring pipeline bus implementation setting itself is or should be deprecated. Maybe the deprecation should be focused on removing that setting rather than the value it is set to.

[donoghuc]

I think the default case for when an unknown setting is encountered should default to v2 https://github.com/elastic/logstash/pull/16643/files#r1889364653

If I understand the introduction of the configuration option for the pipeline bus implementation #16194 it was as a safety latch for any case where using the v2 implementation caused an issue. With the default being v2 and the stability we have observed I would imagine in LS v 9 we would be able to deprecate this configuration option all together (along with replacing v1 with v2). https://github.com/elastic/logstash/pull/16643/files#r1889381525