OpenAPI & Telemetry traits skipped for sourceless

[hernanDatgDev]

What happened?

OpenAPI & Telemetry traits are not applied as expected when using sourceless integrations. This is believed to be a regression after a previous patch. The following are 2 scenarios describing use of these two traits with sourceless integrations as well as the versions of camel-k that were used for testing.

Scenario 1:

Run a sourceless integration with openApi and telemetry traits.
An application.properties file is created with relevant openAPI and telemetry fields
File is mounted in the pod
Works as expected in v2.2.0 and v2.3.0
Fails in v2.3.2, v2.3.3, v2.4.0-SNAPSHOT:
application.properties is mounted but only has openAPI fields, not the telemetry fields.

Scenario 2: (sourceless image refactored to include openAPI spec and openAPI trait not needed)

Run a sourceless integration with telemetry trait, not the openAPI trait
An application.properties file is created with relevant Telemetry fields
File is mounted in the pod
Works as expected in v2.2.0 and v2.3.0
Fails in v2.3.2, v2.3.3, v2.4.0-SNAPSHOT:
application.properties includes relevant Telemetry fields but is not mounted

Steps to reproduce

Described above ^

Relevant log output

No response

Camel K version

2.2.x, 2.3.x, 2.4.0-SNAPSHOT

[hernanDatgDev]

Originally posted in Zulip: https://camel.zulipchat.com/#narrow/stream/257299-camel-k/topic/application.2Eproperties.20conflict.20with.20Telemetry.20trait

[squakez]

Thanks for reporting. Feel free to have a look if you can. We are tentatively going to add this before releasing 2.4 at the end of the month. Thanks.

[mdebarros]

There is also a 3rd issue observed on 2.3.2.

Scenario 3. When enabling both Telemetry and OpenAPI traits simultaneously.
The application.properties only contains the OpenAPI properties, meaning that the Telemetry properties are being dropped and not merged into the final application.properties. However, the application.properties are correctly mounted into the Integration pod.

@hernanDatgDev were you able to observe the same behaviour on > 2.3.2?

[hernanDatgDev]

@gansheer I didn't realize you assigned this to yourself, I apologize. I've been looking at this and it seems that the isForcefullyEnabled() approach from #5524 also works when applied to the Telemetry trait. I was wondering if this approach might be good enough to apply to other traits that also use an auto feature. As far as Telemetry goes I have this PR(#5693)

[hernanDatgDev]

Also it turns out that this regression doesn't actually have anything to do with the openApi trait and it's just a regression of the telemetry trait. When using the telemetry trait w/ a sourceless integration:
The camel catalog is available until the integration reaches the deploying stage, after which the catalog from the environment variable is nil. Because of this, down the road the application.properties that had previously been configured with telemetry fields is overwritten, essentially removing the fields. The configmap (with telemetry removed) is then mounted into the pod without telemetry configuration which is not desired.