Thanks Andrea. No objections from the feature point of view, I think it makes sense and it helps decoupling. I guess there are a few important maintenance questions to address.
1) How are we going to manage Kubernetes API compatibility between versions? 2) Is this development compatible with the actual model, or, as we have briefly discussed in the aforementioned issues, would this introduce some breaking change and the need to start a v3 development? 3) If we're planning to open a v3.x development branch, are you planning to provide some upgrade utility from v2 to v3 or will it be up to the final user to do the upgrade? 4) How this is going to change performances (if any)? I think final users may question the presence of more deployments. 5) Major upgrade in golang API is something quite heavy (see what we had to do when moving from v1 to v2 [1]) and hard to do, how do you plan to do the change? and above all, how to you plan to keep maintaining both v2 and v3 at the same time (ie, cherry-picking won't be possible because each unit will change from v2 to v3 unfortunately)? 6) Documentation: are you planning to update all the documentation and diagrams accordingly? Thanks and regards, Pasquale. [1] https://github.com/apache/camel-k/commit/eb9228597203f4c46fe2f488e59b7131826e1bde On Wed, May 8, 2024 at 10:27 PM Andrea <val...@apache.org> wrote: > 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_ > >
