Skip to content
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

[MO] - optimize unnecessary 3-node cluster in ITs #6400

Closed
wants to merge 5 commits into from

Conversation

see-quick
Copy link
Member

@see-quick see-quick commented Feb 20, 2022

Type of change

  • Enhancement / new feature
  • Refactoring

Description

This PR optimizing ITs, where we used unnecessary three nodes Kafka clusters. I replaced ∀ them to use single-node ∧ thus reducing preparation time 👌🦥. Moreover it resolves this issue [1].

❗️ Before merging this PR we need to release test-container 0.101.0.

[1] - #6367

Checklist

  • Make sure all tests pass

@see-quick see-quick self-assigned this Feb 20, 2022
@see-quick see-quick added this to the 0.29.0 milestone Feb 20, 2022
@scholzj
Copy link
Member

scholzj commented Feb 28, 2022

@see-quick Is this still relevant after #6401?

@see-quick
Copy link
Member Author

@see-quick Is this still relevant after #6401?

Yes, it is :). That PR just moved Kafka container and topic operator to be shared. This PR replaces multiple node clusters with only Kafka container (single node) if possible. But I need to release the test containers to proceed with this...

morsak added 4 commits March 5, 2022 12:36
Signed-off-by: morsak <xorsak02@stud.fit.vutbr.cz>
Signed-off-by: morsak <xorsak02@stud.fit.vutbr.cz>
Signed-off-by: morsak <xorsak02@stud.fit.vutbr.cz>
Signed-off-by: morsak <xorsak02@stud.fit.vutbr.cz>
@see-quick see-quick marked this pull request as ready for review March 5, 2022 11:51
Map<String, String> m = new HashMap<>();
m.put(Config.KAFKA_BOOTSTRAP_SERVERS.key, kafkaCluster.getBootstrapServers());
m.put(Config.ZOOKEEPER_CONNECT.key, kafkaCluster.getZookeeper().getHost() + ":" + kafkaCluster.getZookeeper().getFirstMappedPort());
protected <T extends Startable> Map<String, String> topicOperatorConfig(final T strimziContainer) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need the type parameter? Can't the value parameter have type Startable?

It any case it feels a bit rubbish to require a dependency on testcontainers. We don't actually need any of the methods of Startable, we're just using it because it's a convenient supertype of both StrimziKafkaCluster and StrimziKafkaContainer. Do you think it's worth having a common superinterface for StrimziKafkaCluster and StrimziKafkaContainer in strimzi-test-container, to allow precisely this kind of abstraction in users of strimzi-test-container? It would also be more typesafe, since trying to call this method with any old Startable would then be a compile time error.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And looking at how you're using strimziContainer it seems this interface could just expose a getBootstrapServers and getZookeeperConnectString() (and maybe some methods for the kraft case?) thus avoiding the instanceof entirely.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think this is a good idea to create an interface for such containers, but it would mean another release to get this PR merged. But overall I think it could wait until next release of test container :)

@see-quick
Copy link
Member Author

Closing and I will re-open when strimzi/test-container#34 is implemented.

@see-quick see-quick closed this Apr 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants