Implement a lightning-fast global strategy

[nicolaferraro]

Fix #1799

This is the best strategy I could think about, and it comes with no copies or redundant information.

Basically, the behavior of Camel K is now the following when running an integration with a global operator in another namespace:

• If there's an integrationplatform in the local integration namespace, then Camel K behaves as today
• If there's no integrationplatform in the local integration namespace, then the operator looks for an integrationplatform in the operator namespace (or it creates one when possible, i.e. OpenShift currently) and all the hard work (like checking kits and building images) is done in the global operator namespace

In the new context, when I run an integration, tipically I have:

• Integration in the user namespace
• IntegrationKit in the operator namespace
• Build in the operator namespace
• CamelCatalog in the operator namespace
• IntegrationPlatform in the operator namespace

I.e. the disconnection happens at integration level, all other pieces remain local (in the operator namespace).
To locate the kit and all other platform resources, a new status -> platformNamespace has been added to the Integration and it represents where all supporting resources are located.

On OpenShift, the pull-secret trait also adds the system:image-puller role (thanks @astefanutti) to the integration service account, so no image transfer between namespaces: all (cluster-wide) integrations with the same set of dependencies will point to the same imagestream.

This allows to have, by default, a single builder with warmed up cache, that also builds images for the whole cluster, so images are shared and time to run the integrations is drastically reduced.

Missing parts:

• E2E tests
• Handle explicit references to local kits

Release Note

A cluster-wide global Camel K operator now has the same (or better) performance than local Camel K operators

[lburgazzoli]

How does this strategy handle the case where you programmatic create an IntegrationKit ?

[astefanutti]

Woot! For future references, next steps towards the perfect build system is #592, and possibly #1784.

[nicolaferraro]

How does this strategy handle the case where you programmatic create an IntegrationKit ?

Well, no problems if the integrationKit is co-located with the integration platform (i.e. it's in the operator namespace).

But probaly we should allow also local references... But at the same time we need not to complicate the model too much... thinking...

[lburgazzoli]

How does this strategy handle the case where you programmatic create an IntegrationKit ?

Well, no problems if the integrationKit is co-located with the integration platform (i.e. it's in the operator namespace).

Yep but normal user should not create stuffs in the operator namespace

But probaly we should allow also local references... But at the same time we need not to complicate the model too much... thinking...

Maybe instead of having

status:
    platformNamespace

Each linked resource should report the information about the namespace ?

status:
    kit:
      # optional, current if omitted
      namespace: 
      name:

I guess it won't be too hard :D to have cascading lookup.

[nicolaferraro]

I've deprecated "kit" and added an "integrationKit" object reference property in both spec and status, and implemented the suggested behavior.

The only caveat is that a kit should always follow a platform (same namespace) in order to be built, with the exception of "external" kits that can also be created in the same namespace as the integration (e2e tests included).