Knative service not working when using sourceless Integration in v2.3.1
A regression as described in https://camel.zulipchat.com/#narrow/stream/257299-camel-k/topic/Catalog.20not.20found.20for.20sourceless.20integration.20after.20upgrade
Hi @squakez we've been doing some additional testing with 2.3.1 and have noticed there are some other traits that are not working as expected. At the moment looks like Knative-service, Health, and Logging traits are not working as expected. I'd like to know if it makes sense for us to take a look at what it might take to contribute solutions to these problems. One approach we discussed was to change the way that traits determine if a catalog is required or not, perhaps with some sort of "sourceless" flag where the catalog is not required. In other words, that the catalog would only be required for "source-ful" integrations.
Each of those trait require somehow the catalog to perform its logic. You can see in the code. The check we've added lately it's a guard to make sure the operator won't panic at runtime when the catalog is going to be required. As I wrote in the chat thread, each of the traits need to be carefully reviewed in order to make it work with the concept of "sourceless" Integration. Take the logging trait. You can see that the way we're expecting this trait to be configured is fully driven by the catalog [1], so, in its absence, you need to perform those settings via the right property substitution instead of a trait.
An other possibility that we need to discuss and analyze would be the opportunity to let the user choose manually a Camel Catalog to attach in order to let it perform those trait configuration. However, this may defeat the entire sense of the feature itself, as, at this point, the user would need to provide too much configuration, versus the original idea where we wanted the user to be able to build externally and forget about any other detail.
I reinforce the message stated before. This feature will naturally converge to something more stable and mature, which mean that, while iterating development we may discover things that required to be adjusted to fit into the Camel K operator wider design.
[1] https://github.com/apache/camel-k/blob/32be17e5b9f69466586a3b14ce1d8813aa06beef/pkg/trait/logging.go#L122-L125