Provide kustomize installation configuration for install of camel-k

[phantomjinx]

(Split of from #1820)

Start to offer camel-k as an install with kustomize rather than needing to download the kamel cli, allowing install with standard tools;

This will require consideration of different production setups, tailoring the config directory to support patches for different use-cases, eg. including addons, installing on different types of cluster;
Need to gauge any comparable loss of flexibility as compared to the kamel cli;

[phantomjinx]

Now looking at this. Could someone assign to me please?
Thx.

[astefanutti]

This will enable #1503, and eventually the removal of kamel install.

[phantomjinx]

Current progress: master...phantomjinx:kustomize

@astefanutti
Would you expect all of the registry and olm parameters to be included in the Makefile and kustomized??

[astefanutti]

Thanks @phantomjinx!

Here is my current line of thought:

• I'd rather avoid turning the kamel install options complexity into the Makefile
• I'd rather propose the option for users to run kustomize build config| kubectl apply -f - or kubectl -k dir, i.e., the Makefile is optional
• That means it is expected users modify the files directly, like editing the ports, commenting out patches, ...

The idea is that we get back to a declarative, rather than an imperative style (with lots of options), configuration style.

Specifically:

• For the registry configuration, it should ideally be auto-magically be done with Use local registry config from cluster #1802, but in the interim, we could provide a Secret example, for users to adapt;
• For the IntegrationPlatform resource created by kamel install, that is the recipient of most of the configuration options, we could have an IntegrationPlatform example, that would be well documented for users to adapt as it suits them.

WDYT?

[phantomjinx]

@astefanutti

Getting back to looking at this, this week. I agree with your approach although I like the use of the Makefile for indicating to the user which kustomize directory they should run, eg make app, make operator, make setup, make install-platform. This feels easier typing than kustomize build config ... .... That's said avoiding options & env vars much preferred.

[astefanutti]

@phantomjinx I agree Makefile is a valuable source of truth for conventions on how to build / deploy the project. With my proposal, I was suggesting to avoid introducing another layer of configurability in the Makefile, and just have well documented kustomize files, that people can edit directly to configure the deployment. Then they can use the targets from the Makefile, or directly use the kustomize CLI.

[phantomjinx]

@astefanutti
Done the PR. Might need some careful review and experimentation before final merging.

[astefanutti]

It's been fixed with #2284 👏🏼.