[issues-85] New Apache Kafka related Tests

[tommaso-borgato]

Resolves #85

Coupled with Intersmash/intersmash-applications#95

Description

New Apache Kafka related Tests:

• MP Reactive Messaging with per-connector secured connection test
• MP Reactive Messaging Bootable JAR with per-connector secured connection test
• MP Reactive Messaging Bootable JAR with globally secured connection test

Ci Runs:

• eap-8.x-cross-product-face#209
• eap-8.x-cross-product-face#214
• eap-8.x-cross-product-face#243
• eap-8.x-cross-product-face#246
• eap-8.x-cross-product-face#250
• eap-8.x-cross-product-face#254
• eap-8.x-cross-product-face#258

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• Pull Request contains a description of the changes
• Pull Request does not include fixes for multiple issues/topics
• Code is self-descriptive and/or documented
• I tested my code in OpenShift

[fabiobrz]

Thanks @tommaso-borgato.

I've added some comments to your changes, then I'd evaluate whether we should remove the s2i test variant altogether if that is a duplication in the terms that only the provisioning changes, while the application configuration and the tests stay the same (as it seems to me). In such a case, we should remove it because Intersmash is about interoperability testing, rather than provisioning testing.

Finally, I am not sure even at the refactored tests, e.g.: WildflyMicroProfileReactiveMessaging* calsses. Are those still needed, is that a duplication?

[fabiobrz]

This is redundant, the superclass defines the same constant was public, so I guess there's no need to define it here again just to change the value, right?

[tommaso-borgato]

unfortunately it's used in

public static String getRoute() {
		return OpenShifts.master().generateHostname(APP_NAME);
	}

[tommaso-borgato]

application configuration and the tests stay the same

@fabiobrz

The two candidates to be removed would be (WF/XP only):

• WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT
• WildflyBootableJarPerConnectorSecuredKafkaIT

in the following you can find the detailed reasoning ... please check if it makes sense ...

All the 3 following applications configure MP_MESSAGING_OUTGOING_SSLTO_WILDFLY_ELYTRON_SSL_CONTEXT and hence, it makes sense two of them can be deleted:

1. WildflyMicroProfileReactiveMessagingPerConnectorSecuredApplication (WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT)
2. WildflyBootableJarPerConnectorSecuredKafkaHelmApplication (WildflyBootableJarPerConnectorSecuredKafkaIT)
3. WildflyS2iPerConnectorSecuredKafkaHelmApplication (WildflyS2iPerConnectorSecuredKafkaIT)

WildflyS2iPerConnectorSecuredKafkaIT vs WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT

both are S2I deployments of the same app
with the same per-connector SSL and same tests. If testing different provisioner is not a goal of these Kafka tests, one of them can be removed

--> I'd remove WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT

WildflyBootableJarPerConnectorSecuredKafkaIT vs WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT

looking at WildflyBootableJarPerConnectorSecuredKafkaHelmApplication and WildflyMicroProfileReactiveMessagingPerConnectorSecuredApplication, beyond the deployment mechanism (Helm+bootable JAR vs S2I image), the Kafka/SSL configuration is identical: both set the same per-connector env vars
(MP_MESSAGING_OUTGOING_SSLTO_WILDFLY_ELYTRON_SSL_CONTEXT and MP_MESSAGING_INCOMING_SSLFROM_WILDFLY_ELYTRON_SSL_CONTEXT) with the same CLIENT_SSL_CONTEXT_NAME =
"kafka-ssl-test", same KEYSTORE_PATH = /etc/secrets/ca.p12, and same password derivation from the amq-streams-cluster-ca-cert secret

--> once again I'd remove WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT

And now you are wondering "since both WildflyS2iPerConnectorSecuredKafkaIT and WildflyBootableJarPerConnectorSecuredKafkaIT are equivalent to WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT, aren't they a duplicate too?" ...

WildflyS2iPerConnectorSecuredKafkaIT and WildflyBootableJarPerConnectorSecuredKafkaIT

comparing WildflyBootableJarPerConnectorSecuredKafkaHelmApplication and WildflyS2iPerConnectorSecuredKafkaHelmApplication: both classes extend WildflyBootableJarGloballySecuredKafkaHelmApplication and both deploy via Helm Charts. The Kafka/SSL configuration is identical: same per-connector env
vars, same CLIENT_SSL_CONTEXT_NAME, same keystore path, same password, same secret, same volume mount — all inherited from the parent.

--> I'd remove WildflyBootableJarPerConnectorSecuredKafkaIT

[fabiobrz]

application configuration and the tests stay the same

@fabiobrz

The two candidates to be removed would be (WF/XP only):

* `WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT`

* `WildflyBootableJarPerConnectorSecuredKafkaIT`

in the following you can find the detailed reasoning ... please check if it makes sense ...

All the 3 following applications configure MP_MESSAGING_OUTGOING_SSLTO_WILDFLY_ELYTRON_SSL_CONTEXT and hence, it makes sense two of them can be deleted:

1. `WildflyMicroProfileReactiveMessagingPerConnectorSecuredApplication` (`WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT`)

2. `WildflyBootableJarPerConnectorSecuredKafkaHelmApplication` (`WildflyBootableJarPerConnectorSecuredKafkaIT`)

3. `WildflyS2iPerConnectorSecuredKafkaHelmApplication` (`WildflyS2iPerConnectorSecuredKafkaIT`)

WildflyS2iPerConnectorSecuredKafkaIT vs WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT

both are S2I deployments of the same app with the same per-connector SSL and same tests. If testing different provisioner is not a goal of these Kafka tests, one of them can be removed

--> I'd remove WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT

WildflyBootableJarPerConnectorSecuredKafkaIT vs WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT

looking at WildflyBootableJarPerConnectorSecuredKafkaHelmApplication and WildflyMicroProfileReactiveMessagingPerConnectorSecuredApplication, beyond the deployment mechanism (Helm+bootable JAR vs S2I image), the Kafka/SSL configuration is identical: both set the same per-connector env vars (MP_MESSAGING_OUTGOING_SSLTO_WILDFLY_ELYTRON_SSL_CONTEXT and MP_MESSAGING_INCOMING_SSLFROM_WILDFLY_ELYTRON_SSL_CONTEXT) with the same CLIENT_SSL_CONTEXT_NAME = "kafka-ssl-test", same KEYSTORE_PATH = /etc/secrets/ca.p12, and same password derivation from the amq-streams-cluster-ca-cert secret

--> once again I'd remove WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT

And now you are wondering "since both WildflyS2iPerConnectorSecuredKafkaIT and WildflyBootableJarPerConnectorSecuredKafkaIT are equivalent to WildflyMicroProfileReactiveMessagingPerConnectorSecuredIT, aren't they a duplicate too?" ...

WildflyS2iPerConnectorSecuredKafkaIT and WildflyBootableJarPerConnectorSecuredKafkaIT

comparing WildflyBootableJarPerConnectorSecuredKafkaHelmApplication and WildflyS2iPerConnectorSecuredKafkaHelmApplication: both classes extend WildflyBootableJarGloballySecuredKafkaHelmApplication and both deploy via Helm Charts. The Kafka/SSL configuration is identical: same per-connector env vars, same CLIENT_SSL_CONTEXT_NAME, same keystore path, same password, same secret, same volume mount — all inherited from the parent.

--> I'd remove WildflyBootableJarPerConnectorSecuredKafkaIT

Thanks for this report @tommaso-borgato - I do agree with you, let's remove redundant applications/tests that only differ based on provisioning. The OpenShift test suite would handle that. Intersmash should be about testing interoperability features, rather than provisioning technology.

[fabiobrz]

LGTM, thanks @tommaso-borgato, merging.