Hello, answers inline
On Thu, May 9, 2024, at 10:06, Pasquale Congiusti wrote: > 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? If I get the question correctly I think that this is not affected by what is described here and implemented in the linked PRs. We would do how we would have done it before the proposed changes and in general how we did in the past. > 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? >From a functional point of view these changes are compatible with the current >model, they don't impact how integrations run and their lifecycle. From an >operative point of view we can evaluate if it makes our life easier to include >it after switching camel k main to version 3. > 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? Migrations between different camel k version is regardless of the proposed changes already a pain/open point. So we could evaluate all options including and not limited to have an upgrade procedure documented, or an upgrade tool or stating that it needs to be evaluated case by case or not possible at all. > 4) How this is going to change performances (if any)? I think final users > may question the presence of more deployments. The broader use case of the camel k project has been to ease the run camel integrations at scale on k8s. With that in mind the pictured scenario is the one in witch an operator manage a number N far greater than 1 of integrations, in this context I would say that there is no performance change. However even if we look at the fact that now 2 pods runs instead of one, given that the resources needed by the platform controller operator are a fraction of those needed by the camel k operator I would say that change in performance is at most negligible. > 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)? I don't see that necessarily related to the proposed changes: switching between major version of the project will nevertheless impose some work and some maintenance as all evolution work on a software dose. > 6) Documentation: are you planning to update all the documentation and > diagrams accordingly? To be completely fair the current documentation is not 100% up to date with the architectural status of the project. We can for sure take the opportunity of this effort to updating it a little bit. > > 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_ > > > > >
