Implementing a global build strategy

[nicolaferraro]

I'm thinking to how we can improve global mode and I ended up with the following mechanism.

When using global mode, the platform where the global Operator is installed (camel-system will be the one) should be the default for all namespaces.

If a namespace has no platform (or it has a "empty" special platform, to deal with issues e.g. default kamelets are not installed in current namespace without a platform), then the global platform is used.

The global platform imposes a global build strategy. A local integration kit is not processed locally, instead it is linked to a global kit. It can be linked to an existing global kit, or a new global kit can be created. Status of the local kit will mirror the status of the liked global kit. In the case of OpenShift, upon completion of the global kit, the imagestreams can be also copied over to the local namespace if needed.

This way:

• Builds are executed in the global namespace and existing kits are shared among all namespaces in the cluster
• A local namespace can still have a custom platform, falling back to current way of working
• There seems to be no way for a user in a namespace to "pollute" the global environment, hitting security issues

Wdyt @astefanutti , @lburgazzoli ?

[lburgazzoli]

I think we may need to revisit some of the options we have for kits, as example you can define properties, secrets and configmaps and you don't want to share them across tenants I guess.

[nicolaferraro]

Right, restricting this to "platform" traits may be an option. I.e. using the existing strategy for edge cases.

[astefanutti]

Sounds good to me.

A couple of questions on top of my head:

• Do IntegrationKit (resp. ImageStream) really need to be mirrored (resp. copied)? It may be possible to avoid copying the ImageStream by binding the system:image-puller role for the global namespace to the local namespace integration service account. Though integration pod defaults to using the default ServiceAccount, and it can be configured in the Integration resource, so I'm not sure how practical that would be.

• Do we want to share build cache among tenants? For example, do we want to enable the routine build strategy in that global setup?

Relates to #1693.

[nicolaferraro]

Cool, the system:image-puller strategy seems much better.

Yes, I'd like using routine to speed up, as often the external builder download times take a lot of time, especially in local clusters.
Afair, registries cannot be changed by some local user, so libraries should be safe. Except for the Jitpack case...

[astefanutti]

Right, I think it's also important to revisit the build scheduling that serialises builds, as it is likely to become a bottleneck in a multi-tenant setup.

[nicolaferraro]

Yeah, @lburgazzoli was proposing to experiment with mvnd #1784 , which afaik supports parallel builds. Also the part that pushes to the registry can be parallelized. By parallelizing, we may not do chained builds, but the overall time should be reduced.

[nicolaferraro]

And that's worth doing it in general, not only in the global scenario tbh.

[lburgazzoli]

We also discussed to have some ordering when executing builds: #592

[astefanutti]

Great, I think that use case is a good driver to move forward on the build ordering / parallelisation work. Granted it's worth doing it in the general case also, as noted by @nicolaferraro.