Native build fails with OpenAPI spec

[hernanDatgDev]

What happened?

When running an integration in native mode and including an openAPI specification(with use of --open-api) the integration container is not created. With debug logging it's seen that a new integration kit is created successfully however it is not considered usable by the operator since it does not contain the correct number of sources for the integration. As a result, the operator stops processing and the only achievement is an IntegrationKit in Ready phase, and an Integration stuck in BuildingKit phase.

Technical findings from debugging the operator:
At the time of the Integration/IntegrationKit comparison in pkg/controller/integration/kits.go:hasMatchingSources() the Integration contains 2 sources:

• The original source code
• Reference to a configmap containing the generated DSL from the provided openAPI specification
  📓 Note: Within the operator this is considered a GeneratedSource

The IntegrationKit only contains one source:

• The original source code

When the IntegrationKit is being created, both of the integration sources are considered for inclusion in the kit in pkg/trait/quarkus.go:sourcesRequiredAtBuildTime(). This decision is based on the language settings for the source and because the generated source is created in xml it is valid for native builds, but not included at build time. As a result it is not included and when the kit is created it only has one source which fails the check mentioned above.

I've confirmed this behavior by running a timer-log.xml integration in native mode. It runs successfully without any source code included in the IntegrationKit since it's written in xml.

I've considered workarounds, however I'd rather come to a sustainable solution for the native builds when generated xml sources are added to the Integration.
📓 Note: The source # comparison in pkg/controller/integration/kits.go:hasMatchingSources() also compares the Content field of the sources. Since the generated source is a reference to a configmap, the Content field is actually empty. If this logic is kept then there needs to be a way to also ensure that the generated source (if it is included in the IntegrationKit) is compared appropriately after the # check.

Steps to reproduce

1. Create a configmap containing any valid OpenAPI specification
2. Run a non-xml integration with the following

• --trait=quarkus.build-mode=native
• --open-api=configmap:{your-open-api-cm}

Relevant log output

Logs added to pkg/controller/integration/kits.go:hasMatchingSources() with --open-api trait:
{"level":"info","ts":"2023-11-29T21:55:40Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Gathering source information.."}
{"level":"info","ts":"2023-11-29T21:55:40Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Source count","integration-sources":2,"kit-sources":1}
{"level":"info","ts":"2023-11-29T21:55:40Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Comparing sources","integration-source":"package [omitted for length]","kit-source":"package [omitted for length]"}
{"level":"info","ts":"2023-11-29T21:55:40Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Sources equal!"}
{"level":"info","ts":"2023-11-29T21:55:40Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Comparing sources","integration-source":"","kit-source":"package [omitted for length]"}
{"level":"info","ts":"2023-11-29T21:55:40Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Sources NOT equal!"}

Without --open-api trait:
{"level":"info","ts":"2023-11-29T22:54:05Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Gathering source information.."}
{"level":"info","ts":"2023-11-29T22:54:05Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Source count","integration-sources":1,"kit-sources":1}
{"level":"info","ts":"2023-11-29T22:54:05Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Comparing sources","integration-source":"package [omitted for length]","kit-source":"package [omitted for length]"}
{"level":"info","ts":"2023-11-29T22:54:05Z","logger":"camel-k.CUSTOM-LOGGER","msg":"Sources equal!"}

Camel K version

v2.1.1

[gansheer]

Hi @hernanDatgDev, are you working on this issue ?

[hernanDatgDev]

Hey @gansheer I have been working on it but I'm not sure if I have the best approach. I'm hoping to get some feedback to see if I'm going in the right direction though.

[hernanDatgDev]

@gansheer I have a solution that is working locally but I'm concerned about my use of camel.DefaultCatalog(). I didn't find any already implemented way to get a specific catalog; perhaps I just missed it. In either case I'll create a draft PR soon and perhaps we can go from there with feedback.

[gansheer]

That's good! Don't hesitate to create the draft PR, we will be happy to help you and discuss your solution.

[hernanDatgDev]

Hey @gansheer created the PR: #4987
I'm working on some modifications of it but hopefully the approach is reasonable