-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a lightning-fast global strategy #2058
Conversation
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... |
Yep but normal user should not create stuffs in the operator namespace
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. |
94fe1a3
to
c88586d
Compare
8a4c7e2
to
9ef1ed1
Compare
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). |
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:
In the new context, when I run an integration, tipically I have:
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 thesystem: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:
Release Note