Automatic installation when creating a Knative Camel Source

[nicolaferraro]

The ideal scenario for Knative users (imo) should be:

• A cluster admin enables Camel-based sources and related resources on a cluster
• A user selects a Camel-based source from a catalog (e.g. operatorhub catalog)
• A user creates an instance of the Camel-based source into her namespace of preference
• The Camel-based source is started

Currently this does not work this way, because the user needs to install the Camel K operator in each namespace where he plans to use sources.

Can we improve this?
How good is the option of creating a master-controller in a camel-k namespace that instantiate the operator and related resources when a Camel-based source is added to a namespace?

@astefanutti , @lburgazzoli

[nicolaferraro]

Is it something managed by the operator lifecycle manager?

[lburgazzoli]

I think we should explore also the option to have an operator that handles multiples namespaces

[nicolaferraro]

Yes, our operator works oob if you specify "" as target namespace. The issue is that the operator is doing heavy work that cannot be shared, e.g. builds.

We can:

• separate builds into their own controller, or
• create a super controller that installs the current operator

Which one is best?

[astefanutti]

The described scenario is exactly what OLM with Operator Hub as config source configured is supposed to provide.

Besides, operator groups now provide tenancy support for operators installed via OLM:

https://github.com/operator-framework/operator-lifecycle-manager/blob/master/Documentation/design/operatorgroups.md#installmodes-and-supported-operatorgroups

An operator can have any combination of installation modes, so the Camel K operator could support both OwnNamespace and AllNamespaces.

Then from the developer catalog UI, user would browse the Camel-based sources and have the ability the instantiate any of them from the UI.

This relates to #523. I'm not 100% sure yet what that means in term of code change and operator execution model. Someone (no name ;)) told me that the AllNamespaces mode just instantiate the operator in each namespace. To be investigated.

[lburgazzoli]

I think we should support both, but I personally won't go to the path of having an additional controller written by us that does the installation & set-up so IMHO:

• if one wants the operator to be installed in each namespace then OLM is the way to go
• we should support handling mutiple namesapce
• we should support separate builder

[astefanutti]

Sounds good to me.

[nicolaferraro]

This has been implemented. Additionally, platforms are auto-created on OpenShift by the platform trait.