Over time, we have been trying to address multi tenancy requirements with a number of, often inconsistent, efforts. As a result, as today, the camel-k bundle available through operator hub sets up a camel-k operator upon installation which then relies on *IntegrationPlatforms* to configure its behavior.
The *IntegrationPlatform *was meant to: • configure various aspect of the operator i.e. the registry where container images are pushed, some maven build configurations options, etc • provide a basic multi tenancy model where each tenant is tied to a platform and scoped using an *operator*_*id *(in the form of a label/annotation on any resource that should be reconciled by the same operator) • provide a basic support for platform vs user configurations i.e. the platform admin can configure some aspect of the camel-k operatore but users can further customize them by creating a local *IntegrationPlatform* • provide a basic support for running multiple configured platforms by introducing the concept of secondary platform Even if some initial support for having multiple running camel-k operators exists, in order to have another operator installed, a deployment must be hand crafted and deployed to kubernetes resulting in additional manual work to be done and increasing the complexity of handling updated because the deployment must be amended manually (the camel-k bundle is not aware of such additional operators). Also, as dealing with multiple *IntegrationPlatforms* is very confusing, it is not used very often and discouraged, in fact the concept of *secondary IntegrationPlatform* has been removed since version 2.3. Over time *IntegrationPlatform *has become a place to also store settings that are somewhat sensitive and should be ideally restricted to administrators for changing, but that is cumbersome to do on just some fields of a custom resource. Recently, in order to address this problem as well, the concept of *IntegrationProfiles* has been introduced to separate the settings that are safe to be tweaked at user level. To properly address multi-tenancy requirements, we should introduce a new model where the *IntegrationPlatform* is not used only to configure some aspect of the operator, but also as a way to request the deployment of a tailored Camel K operator tenant. Within this model there won’t be a single camel-k operator dealing with a multitude of configurations and behaviors but a number of tailored camel-k operators reconciling specific resources with specific requirements. To make this possible the camel-k operator should to be split into: • *camel-k platform* controller which is responsible to reconcile *IntegrationPlatforms* • *camel-k operator* which is responsible to reconcile camel-k CR such as *Integration*, *Kamelet*, *Pipe*, etc The work has been extensively discussed in _https://github.com/apache/camel-k/issues/3397_. This is going to be a gradual process which will require a number of individual PRs to refactor the codebase and amend the operational model in a non destructive way: 1. _move the handling of IntegrationPlatform resource to a separate operator_ <https://github.com/apache/camel-k/issues/4948> which will result in an additional Pod being deployed by the Camel K bundle. Such new Pod will be responsible for reconciling the *IntegrationPlatform* resources only for which there is _an open PR_ <https://github.com/apache/camel-k/pull/5119>. 2. Move the deployment of a camel-k-operator tenant to the camel-k-platform controller instead of being automatically deployed by the camel-k bundle. More info can be found in the related issues discussions: _https://github.com/apache/camel-k/issues/4949_ _https://github.com/apache/camel-k/issues/4950_ _https://github.com/apache/camel-k/issues/4951_
