METRON-2164 Remove the Split-Join Enrichment Topology

[nickwallen]

The Split-Join Enrichment topology has been deprecated since November 2018. Metron defaults to using the Unified Enrichment topology currently. This PR completely removes the Split-Join topology from the code base.

Here is the original discuss thread on deprecation.

Testing

1. Launch the CentOS 6 development environment.

2. Ensure telemetry is being indexed and can be found via the Alerts UI.

3. Go to Ambari > Metron > Configs > Enrichment > Topology and change some of the settings on this panel. Restart the Enrichment topology and ensure that the settings have taken effect.

4. Again, ensure telemetry is being indexed and indirectly that the Enrichment topology restarted correctly.

Pull Request Checklist

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.

• Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

• Has your PR been rebased against the latest commit within the target branch (typically master)?

• Have you included steps to reproduce the behavior or problem that is being changed or addressed?

• Have you included steps or a guide to how the change may be verified and tested manually?

• Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:

• Have you written or updated unit tests and or integration tests to verify your changes?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

• Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

[mmiklavc]

Looks good @nickwallen. Thanks for working on this! +1 by inspection.

[MohanDV]

Looks good @nickwallen , +1 Verified on centos 6 full dev ,

1. verified that telemetry is being indexed and can be found via the Alerts UI
2. updated the batch size in enrichment configs restarted the topology and verified the indices are created.

Great work , Thank you !

[mmiklavc]

@nickwallen realized 1 thing we need before merging this - please add a note about this Jira and the feature removal in Upgrading.md.

[nickwallen]

Thanks for the reviews @MohanDV and @mmiklavc . I added a note to the upgrading doc about this change.

[mmiklavc]

+1

Looks like Travis is being finicky again? There doesn't appear to be any build detail.

[nickwallen]

The successful run prior to the doc change was here. The build for the latest commit with the doc change is pending here. I think Travis is just a bit behind right now.

[mmiklavc]

Hm, not sure what this is all about. There's nothing here that should be multi-threaded or potentially intermittent in failing:

Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.082 sec <<< FAILURE! - in org.apache.metron.pcap.mr.FileFilterUtilTest
test_getPaths_leftEdge(org.apache.metron.pcap.mr.FileFilterUtilTest)  Time elapsed: 0.019 sec  <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<2>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:834)
	at org.junit.Assert.assertEquals(Assert.java:645)
	at org.junit.Assert.assertEquals(Assert.java:631)
	at org.apache.metron.pcap.mr.FileFilterUtilTest.test_getPaths_leftEdge(FileFilterUtilTest.java:116)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

[mmiklavc]

@nickwallen merge with master and your build should pass now.