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

Introduce a BuildItem in DevKafkaService to add additional config #25140

Closed
wants to merge 1 commit into from

Conversation

zhfeng
Copy link
Contributor

@zhfeng zhfeng commented Apr 25, 2022

Fix #25094

@quarkus-bot
Copy link

quarkus-bot bot commented Apr 25, 2022

Thanks for your pull request!

The title of your pull request does not follow our editorial rules. Could you have a look?

  • title should not end up with ellipsis (make sure the title is complete)
  • title should not contain an issue number (use Fix #1234 in the description instead)

This message is automatically generated by a bot.

@zhfeng zhfeng changed the title Fix #25094 Introduce a BuildItem in DevKafkaService to add additional… Introduce a BuildItem in DevKafkaService to add additional config Apr 25, 2022
HashMap<String, String> configs = new HashMap<>();
configs.put(KAFKA_BOOTSTRAP_SERVERS, address);
additions.forEach(c -> {
configs.put(c.getConfig(), address);
Copy link
Contributor

Choose a reason for hiding this comment

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

The BuildItem is used exclusively to set the Kafka's server address as a value for other keys?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, we use it in camel.component.kafka.brokers see apache/camel-quarkus#3742

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also you can check the detail about the motivation of these changes in #25094

Copy link
Contributor

Choose a reason for hiding this comment

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

I see, I am just concerned that the class name DevServiceKafkaAdditionalBuildItem may be too generic for this reason

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, it is hard to name it :) any thought ?

@geoand geoand requested a review from ozangunalp April 26, 2022 06:08
Copy link
Contributor

@ozangunalp ozangunalp left a comment

Choose a reason for hiding this comment

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

I don't think that this is the right solution for this problem.
We need to understand why DevServicesLauncherConfigResultBuildItem doesn't contain the dev service config in native mode.
The code here seems to be the right way of getting the dev service config.

@zhfeng
Copy link
Contributor Author

zhfeng commented Apr 26, 2022

But in camel-quarkus-kafka, the above build step seems not run at all in native mode. I'm not sure it is because we produce RunTimeConfigurationDefaultBuildItem which do not be consumered in native?

@ozangunalp
Copy link
Contributor

@zhfeng In integration tests, the application is built in "normal" mode, without dev services or test mode augmentation.
The availability of dev services for native integration tests is somewhat simulated with a separate build and injected to the application config, as you see it on the logs -Dkafka.bootstrap.servers=...

That's why contrary to what I wrote before, the previous code is not the right way of doing this.

In hindsight, I don't completely understand the need to have a camel.component.kafka.brokers default config only for the tests.
I think it is better to handle this case inside the test case.
You can check out io.quarkus.test.common.DevServicesContext which lets accessing dev service properties from tests, including integration tests.

Maybe @geoand would have another take on this?

Ref #25094

@geoand
Copy link
Contributor

geoand commented Apr 26, 2022

In hindsight, I don't completely understand the need to have a camel.component.kafka.brokers default config only for the tests.

I don't undertand this requirement at all either :)

@zhfeng can you describe the end goal of what you are trying to do?

@zhfeng
Copy link
Contributor Author

zhfeng commented Apr 26, 2022

@ozangunalp camel-quarkus-kafka extension reads camel.component.kafka.brokers and autowire it into the camel-kafka during the camel-quarkus based application bootstrap.

@gastaldi I want to get the camel.component.kafka.broker with the same value of kafka.bootstrap.servers automatically both in jvm and native mode. And in native, just like -Dcamel.component.kafka.brokers=... in args when launching the native test. Currently there is a workaround to set it in application.properties

%prod.camel.component.kafka.brokers=${kafka.bootstrap.servers}

@jamesnetherton do you have any input here?

@zhfeng
Copy link
Contributor Author

zhfeng commented Apr 28, 2022

@ozangunalp I find some similar codes with HibernateOrmProcessor.java which produce RunTimeConfigurationDefaultBuildItem to set some properties on Dev Services managed database.

So I wonder this is only availiable in JVM but not Native testing?

@ozangunalp
Copy link
Contributor

Same for hibernate, that runtime default config would not be set on the application under test during integration tests.
That is why you would actually need quarkus.hibernate-orm.database.generation=drop-and-create in properties file for those ITs to work.

@zhfeng
Copy link
Contributor Author

zhfeng commented Apr 28, 2022

Thanks for explanation. So I think it could be much more reasonable to introduce such a BuilidItem in DevServiceKafka which could be very helpful for other extensions in IT native testing.

@ozangunalp
Copy link
Contributor

I couldn't find where does the camel.component.kafka.brokers property is defined. If it is a safe assumption you can write camel.component.kafka.brokers=${kafka.bootstrap.servers} as a default configuration property in the camel extension.

@zhfeng
Copy link
Contributor Author

zhfeng commented Apr 29, 2022

yeah, we have an example https://github.com/apache/camel-quarkus-examples/tree/main/kafka. We only want camel.component.kafka.brokers=${kafka.bootstrap.servers} in Dev or Test profile when DevKafkaService is enabled. That's the reason we introudce a BuildStep in camel-quarkus-kafka extension.

Since the native IT test is running in prod profile, apache/camel-quarkus-examples#86 could be a good way.

@cescoffier
Copy link
Member

Shouldn't this be done by the camel extension?
Our dev service for Kafka can emit a build item with the configuration if needed, but that's all we can do.

As highlighted before, having

camel.component.kafka.brokers=${kafka.bootstrap.servers} 

is the right way to do it Today.

@zhfeng
Copy link
Contributor Author

zhfeng commented May 5, 2022

Thanks @cescoffier ! As I understand, the purpose of dev services is avoiding or lessing the configurations when running the tests. That was the motivation we did in camel-quarkus-kafka extension before. So I think it is only possible to achieve this target both in JVM and Native mode by introducing a BuildItem to produce an additional configuration.

@cescoffier
Copy link
Member

@zhfeng I do not follow. First, dev services are not about reducing the configuration, but about running infrastructure services automatically.
Then, why can't you in the camel-quarkus-kafka define the property as mentioned above?

@zhfeng
Copy link
Contributor Author

zhfeng commented May 5, 2022

@cescoffier yeah, we can define the property but kafka.bootstrap.servers is only availiable when kafka dev service is enabled. We have to run the tests in different environments (dev services enabled and disabled).

@cescoffier
Copy link
Member

This property is set by the dev service, but is used every time. So in prod mode, the user would have to set it (or use SBO).

@zhfeng
Copy link
Contributor Author

zhfeng commented May 5, 2022

Sorry, what is SBO ?

@cescoffier
Copy link
Member

Service Binding Operator

@zhfeng
Copy link
Contributor Author

zhfeng commented May 9, 2022

Thanks all for reviewing. I'd like to close this PR and follow @cescoffier recommendation to set the property in prod mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kafka triage/invalid This doesn't seem right
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Introduce a BuildItem in DevKafkaService to add addtional configs
5 participants