Refactoring traits to allow addons and add master trait (as addon) #1274
Conversation
|
I am curious, you are talking about |
Not directly related. There was the need to move some logic out of the core, and it was easier for me to do this kind of refactoring while developing a new trait (master). The leader election is part of the camel master component. The why/how is explained here: https://www.nicolaferraro.me/2017/10/17/creating-clustered-singleton-services-on-kubernetes/ That example was for spring-boot and required some configuration to work. In Camel K now it works out-of-the-box (just use a |
| } | ||
|
|
||
| /* Base trait */ | ||
|
|
||
| func newBaseTrait(id string) BaseTrait { | ||
| // NewBaseTrait -- | ||
| func NewBaseTrait(id string, order int) BaseTrait { |
There was a problem hiding this comment.
Wonder if we should have some constants that could help choosing the right value for the order field
There was a problem hiding this comment.
I was thinking the same, but couldn't find a good strategy since we have so many traits ;)
There was a problem hiding this comment.
I've opted for defining some relevant constants that addons may need (I've though to the cases mentioned above), but still use numbers for the core. Have a look.
There was a problem hiding this comment.
LGTM, so as future step we could think to generalize this pattern as is exactly the same we are using for the builder so we should probably come up with a sort of a reusable finite step machine framework
nicolaferraro
force-pushed
the
addons
branch
2 times, most recently
from
fab4b85
to
22dd722
Compare
nicolaferraro
force-pushed
the
addons
branch
from
22dd722
to
f81fda3
Compare
|
Let's merge this.. GH actions are flacky today.. |
Fix #1234
Needs apache/camel-k-runtime#242
This removes the trait static lists and allow to dynamically define traits also in other packages. This added the possibility to define an "addons" package. Currently addons are always loaded, but technically they can be easily disabled at both build time or runtime.
The idea is, for the future, to include addons for other external projects, so that Camel K can leverage them to auto-configure the integrations.
Examples of traits that are best placed in the addon package are:
About the master component: it's using the
camel-k-runtime-mastermodule, which embedscamel-kubernetesto do leader election.It's enabled by default when someone uses a route like:
So that that route is started only once, no matter how many
replicasyou set in the integration (works also with auto-scaling integrations).By default, each integration has its own lock domain (i.e. configmap), but configuration can be tweaked to let two different integrations share the same lock if needed.
Release Note