kamel local run: extension to "build and output" CRs

[ChrWeissDe]

This is a feature request

We have the requirement to build Integration and Kamelet CRs and to store them in a repository. At the moment we use for this "kamel run --output yaml".

Unfortunately this requires always a running Kubernetes enviroment with an installed Operator - as the command validates if the artefact is "compatible with the Opertor version". This check is performed in the function "checkAndShowCompatibilityWarning" of root.go. (Link: https://github.com/apache/camel-k/blob/release-1.9.x/pkg/cmd/root.go)

For our build process it would be much easier if this check could be "skipped". Benefit: we would not need to ensure that there is a running and reachable (!) Kubernetes Cluster with the running Operator. One option (and quite a siple one) would be to add the "--output" parameter also to "kamel local run" command.

Further: in general I think this is a requirment of many people / companys / projects.

[squakez]

I have the feeling we can consider this more as a bug. The CLI should be able to output something even when disconnected. Thanks for reporting and feel free to contribute to the resolution.

[squakez]

By the way, the local and the run have different natures as the local won't be able to handle CRs such an Integration.

[ChrWeissDe]

I done some further analysis - based on "code review" - as I didn't manage to debug the command.

First, when using "kamel run" I see the following statements on the output console: "No IntegrationPlatform resource in xxx namespace Warn: camel-mq-config Configmap not found in xxx namespace, make sure to provide it before the Integration can run Warn: camel-mq-keystore Secret not found in xxx namespace, make sure to provide it before the Integration can run"_

Based on the source code review I think that we talk about the following two code fragements:

(1) checkAndShowCompatibilityWarning in root.go

• relates to "No IntegrationPlattform found ..."
• link: https://github.com/apache/camel-k/blob/main/pkg/cmd/root.go
• here I am not sure if this might be really a bug - as it checks for " !isOfflineCommand(cmd)" and I think this is set in "func (o *runCmdOptions) preRunE(cmd *cobra.Command, args []string)" (?)

(2) func parseConfigAndGenCm in run_help.go

• related to "No ConfigMap / Secret found ...."
• looking at the code this code fragement might work even if no cluster is available (...but of course to check ....)

[heiko-braun]

Can you elaborate on this?

„ We have the requirement to build Integration and Kamelet CRs and to store them in a repository. At the moment we use for this "kamel run --output yaml".

• What are you trying to accomplish?
• What do you intend to store: The yaml, the image?
• How is this artefact being used further down the line?

[ChrWeissDe]

Hi @heiko-braun sure I hope the following explanation clarifies the requirement:

First we have the requirement to store all used "Kubernetes Custom Resources" - in this case e.g. the Integrations, Kamelets, required ConfigMaps and co within a "company wide central" artifact repository.

From the there artefacts are deployed to the different Kubernetes stages - e.g. test, pre-prod (qs) and prod. On the stages itself the CRs will be handled by a (pre-installed) Camel-k operator.

The second requirment we have is that all artefacts - which are stored in the artifact repository - must (!) be build on a central company wide build plattform. This is actually a dedicated plattform - managed by a central team (classic approach - no DevOps ; ) .

In general we have the option to install on the plattform additional required (simple) tools on the build platform. E.g. specific C or Java compile version or a Camel K CLI. However the need of a fedicated Kubernetes Cluster just for the build is seen as "complex" (in terms of setup and manage this cluster).

Thus it would be really beneficial to be just able to use "kamel run" to create the CRs - without a cluster.

Further: I see the requirements also by a couple of other customers- as especially large customer are still running a central build plattform.

The build - in this case the creation of the Camel-K CR - needs to be done on a central Build Server.